The EHR platform.
Governed from the start.

Version 1.0 · September 7, 2026 · Free public reference architecture

This report defines a proposed electronic health record (EHR) platform across clinical operations, data, integrations, security, deployment and governance. It explains where AI can assist, what must govern it, and how AutoGovern could support the resulting evidence. It is a design reference, not a claim that AutoGovern is an EHR or that these clinical capabilities have been built.

The reference setting is a US provider organization with outpatient and inpatient care, multiple facilities, external laboratories, pharmacies, imaging providers, payers and patient access. An outpatient-only implementation can omit inpatient modules. Specialty care, local law, contracts and certification objectives require further design. Capacity figures, service targets and delivery estimates below are planning assumptions, not statutory requirements or validated production results.

1. What the EHR platform is responsible for

An EHR maintains the longitudinal patient record and supports the work of delivering care: identifying patients, documenting encounters, placing orders, receiving results, administering medication and coordinating follow-up. It also enables authorized exchange and patient access. The record combines structured clinical data with narrative documents and links to imaging. See the ONC EHR overview.

The proposed platform has three connected responsibilities:

• Clinical system of record: authoritative clinical facts, orders, signatures, amendments and workflow status. The EHR owns these transactions.
• AI services: bounded assistance using approved data and tools. AI output is a proposal until the applicable clinical or operational review completes.
• Governance and evidence: owners, policies, risks, approved versions, evaluation references, exceptions, monitoring coverage and review decisions. AutoGovern can be extended in this role.

Patients and proxies use a portal; clinicians use encounter and longitudinal-chart views; nurses use task lists and medication administration; pharmacists verify medication workflows; registration teams manage identity and appointments; health-information-management staff manage corrections and release of information. Clinical leaders, privacy/security teams, auditors and operations teams have separate oversight views. An auditor does not automatically need chart access.

Success means correct care-team access to a reliable record, safe completion of clinical tasks, traceable changes, usable patient access and demonstrable control performance. A dashboard score alone cannot establish any of these outcomes.

2. Functional architecture and clinical modules

Each module has a product owner, a clinical or operational accountable owner, a data steward, a risk record and an acceptance test set. Appointment scheduling can tolerate a different outage pattern from medication administration; classify criticality by workflow rather than applying one availability target to everything.

3. Complete logical architecture

Read the architecture from users to clinical transactions to data. External exchange, AI execution and governance cross these layers only through authorized interfaces. The public education site occupies a separate, anonymous content boundary and has no connection to patient records.

The API gateway authenticates requests and limits abuse, but domain services also authorize each record operation. The policy decision uses organization, actor, role, patient relationship, purpose, sensitivity, workflow and applicable permissions. Never trust organization or patient identifiers merely because the browser supplied them.

Start with modular services or a modular application whose transaction boundaries are explicit. Split independently scaled integrations, inference and analytics from the clinical transaction path. A separate microservice for every FHIR resource would add operational complexity without necessarily improving safety. Publish architecture decisions explaining storage boundaries, deployment choices and failure behavior.

FHIR is an exchange specification, not an authorization system. Security must surround and enforce its use. See HL7 FHIR R4 security guidance. The diagram's gateway and governance components are proposed design controls; they are not evidence that a vendor already implements them.

4. Physical deployment, capacity and trust zones

Use separate production and nonproduction accounts/projects, credentials, encryption keys, networks and storage. Nonproduction starts with synthetic records; any authorized use of real data needs its own reviewed controls. A deployment environment label alone is not isolation.

Within the selected region, spread critical application instances and database replicas across independent availability zones. Cross-region recovery is an explicit design decision based on agreements, latency and failure analysis. Managed hosting and a BAA do not by themselves prove the deployment is appropriately configured. Review the exact cloud services and business-associate arrangements using HHS cloud guidance.

For initial sizing, assume 500,000 registered patients, 2,000 concurrent staff sessions and a 300-request/second clinical peak; load-test at twice the estimated peak. These are example inputs, not a benchmark. Measure writes, chart query mix, attachment sizes, imaging storage, interface bursts and AI concurrency separately. Autoscale stateless readers and workers, bound inference concurrency, and protect the database with connection budgets. Shed optional AI and analytics load before essential clinical workflows. Recalculate capacity with the actual site's activity and recovery requirements.

5. Data architecture, identity and record integrity

The relational clinical store is authoritative for transactional state. Documents and imaging live in purpose-built stores with controlled references. Search indexes, caches, analytics tables and vector stores are derived copies; they must enforce the source permissions and have defined refresh and deletion behavior. Do not treat an embedding as de-identified data.

These are exchange mappings, not a requirement to use FHIR JSON as the entire database schema. Fix the supported profiles and terminology versions with each partner. Maintain terminology mappings for codes and units, preserving original values when normalizing; uncertain mappings enter a steward queue instead of becoming clinical facts.

For every clinical change, record the actor, source system, patient/encounter, previous version, clinical event time and recorded time. Use optimistic concurrency to reject stale edits and database transactions for linked state changes. Signing freezes that version; corrections create an attributable amendment. Record imported facts as imported, including their source and uncertainty. A confident AI summary cannot upgrade an uncertain source into a confirmed diagnosis.

Identity merges need a preview of affected charts, dual verification for high-risk cases, merge history and a tested unmerge process. Quarantine ambiguous incoming identifiers. AuditEvent records security-relevant activity; Provenance records the origin and transformation of information. See FHIR AuditEvent and FHIR Provenance.

6. Interoperability and reliable exchange

The integration engine translates partner formats into validated domain commands. It must not write directly around clinical business rules. Separate transport receipt, technical acceptance, clinical acceptance and workflow completion in both storage and dashboards.

Reference specifications: SMART App Launch, CDS Hooks and DICOM web services specification. FHIR R4 is a proposed compatibility baseline here, not a claim that it is the latest release or sufficient for every certification objective.

Write the clinical transaction and an outbox event atomically. Publish asynchronously with stable event IDs, schema versions, correlation IDs and source versions. Consumers deduplicate and tolerate at-least-once delivery. Partition ordering where needed by patient/order; do not assume global ordering. Define retry budgets, dead-letter handling, replay authorization and reconciliation totals. A duplicate order replay must not create a second prescription or lab request.

An event envelope should carry organization, opaque resource reference, event type, version and time; keep payloads minimal. Even opaque patient-linked metadata may remain sensitive. Monitor oldest unprocessed event, missing acknowledgements and mismatched counts. Exercise partner downtime, delayed corrections, duplicate messages and out-of-order results before go-live.

7. End-to-end clinical workflows and AI insertion points

Registration through completed care

1. Registration verifies identity and resolves potential duplicates; creates or selects the patient and encounter.
2. The clinician reviews allergies, medications, history and current observations with source dates visible.
3. An optional scribe produces a clearly labeled draft. The clinician compares it with the encounter, corrects it and signs the final note.
4. The clinician places orders through controlled EHR workflows. Clinical rules validate required context, units and permissions.
5. External services acknowledge orders and return results; the EHR validates patient/order matching and records result status.
6. The responsible care team receives results, acknowledges review and completes follow-up. Critical-result escalation operates independently of optional AI.
7. Discharge/referral tasks transfer responsibility explicitly. The portal exposes permitted information under the applicable release policy.
8. Coding, quality reporting and governance consume approved records or minimized evidence; none silently rewrites the clinical history.

Order-to-result failure handling

Clinician -> EHR: signed order with patient, encounter and version
EHR -> DB + outbox: atomic order and delivery event
Worker -> Laboratory: stable order identifier; retry safely
Laboratory -> Integration: receipt/acceptance or rejection
Integration -> EHR: validated result + status + source version
EHR -> Inbox: named recipient + backup + due/escalation policy
Care team -> EHR: acknowledgement + follow-up task/outcome
Corrected result -> EHR: new version; notify and reopen affected work

A timeout means delivery is uncertain, not that it failed. Reconcile with the laboratory before resubmission can create duplicate work. An unmatched result enters a staffed resolution queue; it is never attached to the closest-looking patient by an AI guess. Dashboard status distinguishes “received,” “reviewed,” “patient informed” and “follow-up complete.”

AI scribe sequence

Clinician -> Workflow: confirm encounter and approved recording process
Workflow -> Policy service: verify user, purpose, data and approved AI release
Policy service -> AI gateway: scoped, short-lived request authorization
AI gateway -> Approved provider: authorized audio/text; configured retention
Provider -> EHR draft area: draft note + model/prompt/source references
Clinician -> EHR: inspect, edit and sign through normal clinical controls
EHR -> Protected evidence: version, reviewer and outcome references
Operations -> Retention process: apply audio/draft retention and verify outcome

If the AI service fails, the clinician uses ordinary documentation. If the patient changes or source data changes materially, invalidate the draft's approval context. A signed note records actual authorship/review; it must not falsely imply that a clinician personally observed AI-invented facts.

8. Where AI fits: care delivery and governance assistance

Use AI only when a bounded task has an owner, a measured benefit, a risk assessment and a safe alternative. Begin with low-autonomy assistance. The following are proposed use cases, not enabled integrations in AutoGovern.

AI can help prepare a risk assessment, explain a policy, find inconsistent evidence or draft an incident timeline. It cannot provide independent proof that its own output is correct, decide legal applicability conclusively, certify HIPAA compliance or close a material finding solely on its own recommendation. An AI detector's silence is not evidence that no PHI was disclosed.

FDA oversight depends on software function and intended use; clinical AI is not uniformly a device or uniformly exempt. Record the assessment for each function using the FDA clinical decision-support guidance. For applicable certified health IT, review predictive decision-support transparency and intervention risk-management responsibilities; these requirements do not apply identically to every AI tool. See ONC HTI-1 and the decision-support intervention criteria.

9. AI technical architecture and action controls

Maintain a release manifest linking intended use, provider endpoint, model version, prompt/template digest, retrieval corpus/version, tool schemas, evaluation set, approval conditions and expiry. Provider aliases that can change behavior require change detection and a re-evaluation policy. Test fallback providers separately; never route health data to an unapproved endpoint just to maintain availability.

The controlled execution path is:

1. Authenticate the human or workload. Resolve organization, patient and encounter on the server.
2. Check the approved use, role, purpose, permissions and current release manifest. Reject unapproved combinations before retrieval.
3. Retrieve only authorized records. Apply filtering before search and recheck access when fetching results. Include source dates, conflicting facts and missing-data indicators.
4. Treat chart text, attachments, retrieved documents and model responses as untrusted content. They cannot change authorization, select a new recipient or expand tool permissions.
5. Send the approved minimum input to the approved endpoint. Bound context size, time, spend and concurrency. Avoid raw PHI in general traces, analytics and crash reports.
6. Validate output structure and permitted actions. Grounded citations assist review but do not prove factual correctness. Present uncertainty and distinguish source facts from generated inference.
7. Require the specified human review. For writes, bind approval to the exact action, argument digest, organization, patient, encounter, source version and expiry.
8. Recheck authorization and source version at execution; use an idempotency key. Execute through the clinical API, record the actual result, and reconcile uncertain outcomes before retrying.
9. Store minimized decision evidence and protected clinical provenance. Apply the retention schedule to inputs, outputs, audio, caches, embeddings and provider copies.

Do not let a language model construct arbitrary SQL, choose tenant scope, acquire credentials or call unrestricted network destinations. The model never holds broad clinical database write access. Stop controls disable the relevant AI release, tools and queued actions while leaving the ordinary clinical workflow available. Test that revocation reaches workers and cached approvals; a UI toggle alone is insufficient.

10. Governing the EHR: accountability and lifecycle gates

An executive sponsor funds the program and resolves cross-functional priorities. The clinical safety lead owns patient-risk acceptance. The platform owner owns service delivery. Privacy, security, data stewardship and release management retain defined decisions; an AI committee does not replace these responsibilities.

Name actual people and delegates, not only departments. Keep one accountable role per decision; cross-functional approval is represented by distinct required sign-offs. The author of a material change cannot be its only reviewer.

Use NIST's AI RMF Playbook as a voluntary organizing resource. The specific gates above are this architecture's proposed operating model, not a claim that following them establishes compliance.

11. HIPAA, PHI, PII and access governance

Determine obligations from the organization, relationship, information and purpose. HIPAA covers defined entities and business associates; not all consumer health information is HIPAA PHI. PII is broader. Document scope and assign a privacy/legal reviewer using HHS covered-entity guidance.

The Security Rule calls for administrative, physical and technical safeguards for ePHI. Conduct and maintain a risk analysis covering the actual environment, including AI vendors and derived data. The engineering controls below are proposed implementation choices, not a substitute for that analysis. See the HHS Security Rule summary.

• Apply role and contextual access, MFA appropriate to users and risk, short-lived service credentials, privileged-access review and prompt offboarding. Log patient-record reads, exports, changes, emergency access and administration in protected audit storage.
• Encrypt transport and storage; inventory keys and secrets; separate administration; test rotation, restore access and revocation. Review endpoint protection, facility access, workstation use, staff training and secure disposal alongside software controls.
• Record the legal/policy basis for use and disclosure. Apply minimum necessary where required; provider treatment disclosures and requests are among its exceptions. Do not impose a universal new-consent requirement on every treatment workflow. See HHS minimum necessary guidance.
• Implement clinically appropriate emergency access with declared reason, limited duration, prominent audit and subsequent review. A consent-service outage needs a preapproved care-safe policy; it must not silently produce unrestricted access or prevent all emergency care.
• Manage patient access, amendments, proxy rights, sensitive information and release-of-information requests as tracked workflows. Resolve identity and authority before release, and record reasons for restrictions and review paths.
• Set separate retention schedules for clinical records, AI audio/drafts, logs, evidence, backups and analytics. HIPAA does not itself establish a medical-record retention period; other requirements apply. See HHS medical-record retention FAQ.
• Use Safe Harbor or Expert Determination when relying on HIPAA de-identification; name removal or regex masking alone is insufficient. See HHS de-identification guidance.

Assess 42 CFR Part 2 where covered substance-use-disorder records are involved, plus relevant state privacy, minors/proxy, consumer-health and research requirements. Do not label all behavioral-health data “Part 2.” See the HHS Part 2 rule overview. Reconcile access controls with applicable patient access and information-sharing obligations; legal review should identify supported restrictions rather than blanket blocking.

12. Monitoring: operational health, clinical safety and AI risk

Every signal needs an owner, source, denominator, freshness limit, threshold, severity and response. Separate service health from patient outcomes and legal compliance. The examples below are design proposals; clinical leaders must set thresholds using validated local risk and workflow evidence.

Example engineering objectives: 99.95% monthly availability for an agreed clinical API boundary; p95 chart-summary retrieval under two seconds excluding external AI; an alert if a five-minute telemetry feed is stale for fifteen minutes. These are illustrative targets that require load testing and site approval. Define measurement windows and exclusions explicitly. Clinical result escalation times must follow the care setting's approved protocol, not these infrastructure examples.

A monitoring record should include workflow ID, release ID, metric definition, interval, numerator, denominator, source coverage, last successful ingestion, threshold version, reviewer and disposition. Aggregates can still identify small patient groups; apply disclosure controls. Never show a green status when telemetry is disconnected or evaluation coverage is unknown.

13. Incident response, downtime and recovery

Maintain a common incident process with clinical, security and privacy branches. A wrong-patient recommendation may require immediate clinical correction even when no breach occurred; a disclosure can require privacy response even when the application remains available.

1. Record discovery time and affected service/version. Route potential patient harm to the clinical team immediately.
2. Contain through the care-safe runbook: disable an AI release or destination, revoke compromised access, isolate a component and activate ordinary clinical workflows.
3. Preserve authorized logs, source versions, actions and affected-record references in restricted incident systems. Keep patient details out of public guides and general-purpose governance notes.
4. Determine actual scope and outcomes. Reconcile queued actions and uncertain external transactions before restarting workers.
5. Privacy/legal owners assess notification duties, recipients and deadlines. HIPAA breach assessment considers information, recipient, acquisition/viewing and mitigation; individual notice, when required, must be without unreasonable delay and no later than 60 days after discovery. Other duties differ. See HHS breach guidance.
6. Correct patient records through amendments and clinical review; notify affected care teams as appropriate. Address root cause, retest and obtain restart approval.
7. Verify closure with evidence and update training, controls and the risk register.

Define recovery objectives by workflow. An illustrative design target is RPO of five minutes and RTO of one hour for the core clinical database during a major recovery event; this is not an acceptable interruption for every bedside task. Medication administration and urgent care need immediately usable downtime procedures, current authorized fallback information and reconciliation when service returns. Validate achievable RPO/RTO with measured restores and clinical drills.

Protect immutable or otherwise strongly protected backups from application administrators and ransomware. Test restoration of database, documents, identity dependencies, keys, broker offsets and audit linkage together. Multi-zone replication is not a backup. Exercise loss of identity provider, network, region, terminology service, laboratory interface and AI vendor separately. Record who can declare downtime and who verifies safe return to normal care.

14. Risk register and acceptance evidence

Record severity, likelihood, exposure, treatment owner, due date, residual risk, decision authority and next review for each risk. A passed control test reduces a specific uncertainty; it does not make the whole platform compliant. Retain failed tests and restricted-use decisions, not only favorable evidence.

Before production, require integration reconciliation, access/isolation verification, threat and clinical hazard review, representative clinical evaluation, usability/accessibility testing, vendor/data-use approval, load/restore tests, training, monitoring coverage and a rehearsed stop/fallback procedure. Require evidence tied to the exact release and intended setting. Unresolved severe patient-safety risks cannot be hidden by averaging scores.

15. How AutoGovern fits and how much must change

AutoGovern's current healthcare workspace stores governance metadata: workflow profiles, data-flow/vendor references, risks, control evidence references, cases and review/export records. The free public healthcare guide provides how-tos and templates. Existing platform governance features can support related inventory and policy work, but their presence does not establish clinical integration or HIPAA readiness.

The recommended product direction is a governance companion to an established EHR, with clinical records remaining in the EHR. AutoGovern receives minimized metadata and evidence references under reviewed permissions. It can organize decisions and expose missing evidence; the clinical system remains responsible for clinical transaction enforcement. Even metadata-only integration needs a privacy review because identifiers and small aggregates may reveal patient information.

A proposed governance model adds: ClinicalUseCase, DataFlow, VendorService, ClinicalHazard, EvaluationRun, ApprovedRelease, MonitoringPlan, MetricObservation, IncidentReference and ReviewDecision. Connect each record to organization, owner, version, evidence reference and lifecycle status. Approval binds a digest of the reviewed release and becomes stale when material inputs change. Model this separately from patient clinical tables; never infer production authorization from a generic “reviewed” badge.

16. Delivery roadmap, effort and decision points

These are rough planning estimates for a governance companion, not quotations or a delivery commitment. Assume two application engineers, one integration engineer, part-time design/QA/security and sustained clinical/privacy reviewers, an accessible partner sandbox and timely contracting. Workstreams overlap; calendar durations must not be added as though all work is sequential. Vendor access, evidence quality and organizational readiness can dominate the schedule.

A practical initial planning envelope is roughly 4–7 months for one controlled integration pilot if access and readiness work proceed in parallel. Re-estimate after discovery. A full EHR would likely require a dedicated multidisciplinary program over multiple years; no credible fixed budget follows from the current repository alone. Buying/integrating a suitable clinical system should be compared with building one before funding a replacement.

Budget separately for partner API access, integration/vendor licenses, cloud and recovery capacity, AI inference, terminology/licensing, independent security/clinical evaluation, training, migration and ongoing support. Use actual vendor quotes and staffing rates. Do not multiply a generic token price by patient count and call it total cost.

17. How to apply this architecture in your organization

1. Choose a bounded workflow. Start with one site and one use, such as reviewed scribe drafts. Identify the clinical decision and forbidden actions.
2. Draw the current system and data flow. Name the actual EHR, identity provider, integration engine, AI endpoint, storage, support systems and recipients. Replace every generic box in the diagram.
3. Assign owners and applicable obligations. Complete the decision table with people, delegates, contracts and jurisdiction-specific reviews.
4. Define evidence before building. Specify clinical acceptance measures, access tests, source coverage, fallback and release conditions.
5. Build in a synthetic sandbox. Validate identity, permissions, duplicate events, stale approvals, unsafe prompts and vendor outages.
6. Review a constrained pilot. Record the exact release, setting, trained users, review expiry and who can stop it. Conduct the separate clinical and operational approvals.
7. Monitor and reassess. Review outcomes and missing telemetry; reopen decisions after material changes or incidents. Expand only within evidenced scope.

Use the free healthcare AI governance guide for step-by-step how-tos and the starter templates for initial records. In AutoGovern, open Governance → Healthcare Governance → choose an organization → create a workflow, then use Data flows, Vendors & BAAs, Risk register, Controls & evidence, Cases, and Review & export. These paths manage metadata today; they do not deploy or monitor a clinical AI service.

18. Architecture handover and decisions still required

Before implementation procurement or clinical approval, produce a site-specific pack: context/container/deployment diagrams; interface contracts and message examples; clinical workflow/state diagrams; schema and terminology mappings; threat model and hazard log; access/permissions matrix; vendor/data-use inventory; evaluation protocol; release manifest; monitoring/incident runbooks; recovery plan; migration reconciliation and cutover plan; and operating/support responsibilities.

Migration must map and reconcile patients, identifiers, allergies, medications, problems, open orders, pending results, documents and historical provenance. Run rehearsals with count and clinical-semantic reconciliation, define a cutover/freeze strategy and rollback boundary, and preserve authorized historical access. Do not declare migration complete solely because row counts match.

Open decisions include the actual EHR and partner interfaces; facilities and specialty scope; patient population; data-sharing jurisdictions; proxy/minor rules; certification and device applicability; approved vendors; achievable latency/recovery targets; evidence retention; support staffing; and acceptable residual clinical risk. Record each decision with its owner and deadline. This report defines the complete reference structure; those site-specific decisions are required to turn it into an executable production design.