Why One Database per Clinic Protects Patient Records

A clinic database connects a person’s identity with appointments, diagnoses, prescriptions, laboratory results, and payment history. That concentration makes the database useful during care and sensitive outside the clinic. A one database per clinic design gives each clinic a defined data boundary before encryption or staff permissions enter the picture.

CareClinic security and privacy controls use that boundary as one layer in a wider design. Current provisioning gives each new clinic workspace a dedicated MySQL database and credential. The application resolves the clinic from its subdomain, then opens the database assigned to that clinic. Tenant checks remain in the data access layer as another control.

Clinic administrators and doctors should understand what this architecture covers, where its protection ends, and which staff practices still determine whether a signed-in person can read a chart.

What one database per clinic means

Many multi-tenant systems place records from several customers in the same tables. Each row carries a tenant identifier, and each query must filter for the right customer. That approach can work when the application applies the filter without error. It also makes one condition responsible for separating many organizations.

CareClinic’s current provisioning process creates a distinct database for each new clinic workspace. It also creates a database user whose privileges apply to that clinic database. During a clinic request, the platform selects the connection assigned to the resolved clinic. A query running through that clinic connection starts inside the clinic’s database boundary instead of a shared set of patient tables.

The platform still keeps control-plane information, such as tenant domains, plans, and module settings, in a platform database. Clinical workflows use the clinic database selected for the request. This split lets the platform manage subscriptions without treating the platform database as the home of each clinic’s clinical record.

Maintenance and migration code retains a shared-schema fallback for older tenant data without a dedicated database configuration. Tenant filters become the primary separation control on that path. This fallback explains why CareClinic keeps tenant identifiers and filters even after current provisioning creates a dedicated database.

A dedicated database does not mean a dedicated physical server. Several clinic databases may run on the same managed database cluster. Host security, database administration, patching, credential storage, and recovery controls still matter. The dedicated database narrows what a clinic application credential can reach and gives operations teams a clinic-sized unit for migration, backup, and recovery work.

Database isolation limits the reach of common failures

Security planning works better when a clinic asks how far a failure can travel. A staff account, application credential, database query, or restore operation can fail in different ways. A separate clinic database limits several of those paths.

Consider a query that updates more rows than its author intended. A clinic-specific connection confines the query to tables in that clinic database. Consider a clinic application credential that an attacker obtains. Its database privileges cover the assigned database rather than every clinic database in the platform. Database isolation gives administrators a smaller containment boundary for investigation and recovery.

CareClinic retains tenant identifiers and tenant-aware repository checks inside those dedicated databases. The application injects the tenant identifier into tenant-scoped writes and filters reads by tenant. On a dedicated database, those checks repeat a boundary the connection has established. Their value appears when older data uses a shared-schema fallback, during maintenance code, or when a future deployment mistake points a connection at the wrong location.

Isolation tests add evidence that these controls work together. Tests create separate tenants and check that one tenant cannot read another tenant’s rows. A clinic should expect this type of evidence from a system that claims tenant separation. Architecture diagrams alone cannot show whether every repository and maintenance path follows the rule.

Per-clinic encryption protects copied data

Database separation controls reach through database connections. Encryption addresses a different event: someone obtains stored data outside the approved application path. A copied database, old backup, replica snapshot, or discarded disk can bypass the query boundary because the person already has the stored bytes.

CareClinic encrypts registered identity and clinical fields with AES-256-GCM. The platform derives encryption material for each clinic, so ciphertext from one clinic requires that clinic’s key material. The protected field registry covers patient names, contact details, addresses, full dates of birth, insurance information, medical notes, diagnoses, treatments, prescriptions, appointment intake, consultation details, dental records, and other registered sensitive fields.

This field-level approach matters because a patient list can reveal sensitive information before anyone reads a diagnosis. A recognizable name in a specialty clinic may disclose more than an unlabeled clinical note. Encrypting identity fields removes the readable patient list from a copied database while preserving the record inside the authorized application.

Encryption has limits. A user who signs in with a valid account can read fields permitted by that user’s role. The application must decrypt information so the doctor can treat the patient and the receptionist can confirm the correct chart. Encryption at rest cannot decide whether the person at the keyboard should have that account.

CareClinic also keeps a small set of demographic values usable for reporting. Sex and civil status use deterministic blind indexes, and birth year remains readable for age brackets. A person studying a stolen database could infer low-cardinality demographic codes through frequency analysis. The full date of birth and registered identity fields keep their field-level encryption. Stating that exception gives clinic administrators a more accurate basis for risk review.

Protected search keeps the front desk usable

Encrypting names creates an operational problem. A database cannot sort or search ordinary ciphertext as if it were a surname. Leaving names readable would solve the search problem by weakening the privacy control.

CareClinic uses two protected methods. Blind indexes support exact matches for normalized email addresses, phone numbers, and patient identity combinations. The system calculates a one-way code under clinic-specific key material. The same normalized value inside one clinic produces the same code, which supports matching. The same value in another clinic produces a different code, which reduces cross-clinic correlation.

Substring name search uses a narrow patient search workflow. The application decrypts only the identity fields needed for search, builds a working view, encrypts that view before placing it in Redis, and gives it a short lifetime. Patient changes invalidate the cached view. The working set excludes clinical notes and does not enter database backups or tenant archives.

These controls let a receptionist type part of a name or phone number without adding readable patient names back to SQL search columns. They also explain why CareClinic caps broad result sets. A bounded list controls the amount of decrypted identity data held during one search and prompts the user to narrow a vague query.

Clinic analytics still need age and demographic groupings. CareClinic uses blind indexes and readable birth year for those limited reporting functions. The design preserves useful clinic reports while documenting the privacy tradeoff behind them.

Named accounts control access after sign-in

A database boundary and encrypted fields protect storage paths. Clinic accounts govern the daily path through the application. Every doctor and staff member should use a named account. Role-based permissions then limit which routes and records that account can open.

Clinic administrators can require two-step sign-in for selected roles. A password thief then needs the second factor before the account opens. Recovery codes support lost-phone cases, and an administrator can reset enrollment without generating a valid code for another person.

Shared accounts weaken this layer. They prevent the clinic from tying an action to one staff member, make offboarding harder, and reduce the value of an access log. A clinic should remove access when employment ends, review role assignments after job changes, and reserve broad permissions for staff who need them.

Doctors using the CareClinic doctor app work through a separate mobile session boundary. Web and mobile access still belong to the named user and resolved clinic. A clinician should lock the device, protect recovery codes, and report a lost phone so the clinic can revoke access.

Audit evidence shows who opened a record

Many security reviews focus on changes: who edited a diagnosis, released a result, or issued a prescription. Privacy incidents can involve a person who only reads a record. A staff member may open the chart of a neighbor, relative, public figure, or former partner and leave the medical record unchanged.

CareClinic records patient access events with the actor, patient, part of the record, device channel, and time. It keeps medical content out of the log. A clinic administrator can review recent access on the patient page or filter the clinic-wide record access log by staff member, patient, area, or date. The filtered record can support an internal review without copying the chart into an investigation file.

The broader audit trail links entries with cryptographic hashes. Changing or deleting an older entry breaks the chain that follows and makes tampering visible during verification. The control detects changes; it cannot make database-level tampering impossible. Period seals stored apart from the audit database strengthen the evidence by giving reviewers an external comparison point.

The audit trail gains value when clinic leaders use it. Administrators should review unusual access patterns, investigate access outside a person’s duties, and document the result. Doctors should avoid opening charts for informal advice or curiosity. The patient record workflow gives authorized staff a clear route to the information they need, which makes access outside that route easier to question.

Controlled sharing keeps the clinic boundary meaningful

Clinics sometimes need to share selected information with an employer, HMO, patient, or another care provider. A dedicated database should not turn legitimate sharing into an informal export process.

The Employer and HMO Portal uses a guarded cross-tenant read path. The service verifies the company-to-patient association, derives the clinic and patient from that association, and returns an allowlisted projection. It does not expose the clinic’s most sensitive free-text fields through that portal. The portal decrypts shared fields with the owning clinic’s key.

CareClinic also records the basis for a company association. If a patient withdraws consent, the portal refuses later reads through that association while retaining the history of the link. Reads from the company portal enter the clinic’s patient-access trail, giving the clinic evidence of external viewing.

Patient access follows another controlled route. The online patient portal lets patients view and download approved parts of their records through an authorized session. Clinic staff can prepare a patient copy without handing over a raw database export. Released laboratory results and included clinical documents stay within the record-copy workflow.

Multi-location clinic groups should preserve the same boundary. Each physical clinic can operate as a separate tenant with its own database, staff memberships, settings, and encryption material. Group reporting should use an approved reporting projection. Access to another branch’s clinical record needs an explicit sharing and authorization path instead of a broad group account.

What administrators and doctors should review

The following review connects each technical layer with a clinic responsibility:

The public CareClinic user manual explains the staff steps behind patient search, two-step sign-in, access review, and company sharing. Administrators can use CareClinic reports to support operational review, but reports should not replace access governance. Assign one person to own account reviews, privacy contacts, and incident follow-up. Set a review schedule that matches staff turnover and the clinic’s risk.

Doctors contribute through narrower choices. Open the chart needed for the current clinical task. Keep working notes inside the protected record rather than copying them into personal messaging tools. Use the patient or company portal when information must leave the clinic workflow. Report an account, device, or access concern while administrators can still preserve evidence.

A clear boundary supports a clearer security conversation

One database per clinic gives administrators a concrete answer to a basic question: which database connection can reach this clinic’s patient tables? Per-clinic credentials narrow that route. Tenant checks repeat the boundary. Encryption protects registered fields in copied storage. Named accounts and access logs govern the readable view that staff need during care.

Each layer covers a different failure path. The clinic still owns account decisions, staff practices, sharing authority, and response to suspicious access. CareClinic supplies controls that let administrators define those duties and let doctors work inside a patient record without treating privacy as an abstract promise.

Review CareClinic’s security and privacy controls for your clinic.