Current verified foundation
The deployed infrastructure skeleton establishes a deliberate starting boundary for Dental Studio. It does not yet establish a production boundary for the full suite:
- Private frontend origin: static application files are stored in a non-public Amazon S3 bucket and delivered through CloudFront Origin Access Control.
- Protected document storage: the PHI-capable document bucket blocks public access, requires TLS, enables versioning, and uses server-side encryption with a customer-managed AWS KMS key.
- Staff identity: Amazon Cognito is configured as the staff identity provider with TOTP MFA and groups for administrator, front-desk, clinical, and billing roles.
- Staff API boundary: the API Gateway staff route requires a Cognito JWT before a request reaches the application function.
- Recovery foundations: DynamoDB point-in-time recovery and document versioning are enabled in the infrastructure design.
- Restrained logs: API Gateway access logs are designed to omit raw URLs, headers, query strings, bodies, tokens, and patient information.
Patient and staff access are different problems
Staff access
Staff access is designed around authenticated users, MFA, and role-aware application authorization. Identity-provider validation is only the first gate; the finished application must also enforce practice isolation and permissions on every read and write.
Patient access
The initial patient flow is designed around a high-entropy, one-time, expiring invitation rather than a permanent patient account. The token should be exchanged for a short-lived application session, invalidated after use, and kept out of logs and conventional URL paths.
Work required before a production PHI deployment
The application API is currently a smoke-test placeholder. Before a production pilot handles real patient data, at minimum, Dental Studio must complete and verify:
- application-level tenant and practice isolation on every data path;
- one-time invitation creation, expiration, exchange, revocation, and replay protection;
- role and resource authorization beyond identity-provider group membership;
- safe upload validation, content-type enforcement, malware handling, and controlled downloads;
- audit events that support operations without recording PHI unnecessarily;
- retention, deletion, backup, recovery, and legal-hold decisions;
- exact production origins, security headers, monitoring, alerting, and incident response;
- practice-specific acceptance testing and an approved data-flow inventory.
Each suite module expands the control boundary
A longitudinal patient record requires durable provenance, correction and amendment handling, scoped access, export, retention, and reliable history. Insurance and billing add payer and clearinghouse credentials, transaction controls, remittance integrity, payment boundaries, reconciliation, and financial audit requirements. Prescription and pharmacy workflows add licensed-authority checks, patient choice and consent, qualified network partners, jurisdiction-specific rules, fulfillment exceptions, and delivery evidence.
Those controls cannot be inherited from the intake module by assumption. Each integration and data flow must be implemented, threat-modeled, contractually authorized, tested, monitored, and accepted for its real production role.
Security questions for pilot discovery
A responsible pilot starts by answering practical questions: What information is collected? Who reviews it? Where is the system of record? How long is it retained? Which staff roles can see each item? Which payer, clearinghouse, payment, prescribing, pharmacy, and delivery partners are involved? What happens when information is wrong or a transaction fails? What evidence must the practice preserve?
Those answers shape the implementation. They are not replaced by a generic security checklist.