Connecting a model to a clinical record establishes connectivity. A production system also needs an evidence chain that professionals can inspect, challenge and test.
A clinician asks an AI assistant to summarize the available record before an appointment. The answer is readable and includes citations. Yet several engineering questions remain: was the correct patient selected, did historical findings become current claims, and did access restrictions conceal relevant information?
These are not questions about prose quality. They concern the relationship between source data, application permissions and generated statements.
For clinician-facing summarization, the proposed starting point is therefore an evidence architecture, not a model leaderboard. The design below separates intended use, clinical meaning, authorization, traceability and evaluation. It is a reference design, not a validated clinical product or a diagnostic method.
Define what the assistant may claim
Begin with a narrow task contract: summarize specified categories of available information for professional review, within a defined time window. Identify the intended reviewer and the actions the assistant cannot take.
A drafting assistant should not automatically acquire the ability to modify a chart, place an order or contact a patient. Those capabilities belong to separately designed workflows with their own authorization and safety requirements.
Make limitations part of the output contract. If an integration fails or permission is unavailable, the assistant should identify the resulting evidence limitation rather than imply completeness. Crucially, “no relevant record was retrieved” must not become “the patient has no relevant history.”
That distinction should appear in product requirements and evaluation cases, not merely in a disclaimer at the bottom of the interface.
Preserve meaning through transformation
FHIR supplies resources and exchange mechanisms; implementation still requires attention to resource lifecycle, validation, patient links, time zones and access control. HL7 addresses these responsibilities in its FHIR R4 Clinical Safety checklist, sections 7.10.2 through 7.10.7.
Treat structural and semantic checks as separate activities. Structural validation examines conformance to the selected FHIR version and applicable profiles. Semantic review examines whether timestamps, identifiers, terminology mappings and status information preserve the meaning required by the task.
Do not assume a recent import timestamp makes an old clinical finding current. Preserve the distinction between clinical event time, document creation and subsequent processing.
Where normalization could affect interpretation, retain a protected reference to the original representation. If a mapping changes or a source is corrected, the application should be able to identify affected derived content instead of leaving an obsolete summary unexplained.
Conflicting sources should remain visible as conflicts. The model should not quietly adjudicate a disagreement that the product has no approved method for resolving.
Authorize before assembling context
For this design, retrieval operates within a server-established user, organization and patient context. Retrieved text and model-generated arguments must not be able to replace that context.
SMART App Launch 2.2 uses OAuth scopes to negotiate delegated access, with underlying permissions enforced elsewhere in the access-control stack. Its “Scopes and Launch Context” specification explicitly allows responses to be filtered or rejected by those underlying policies.
For example, patient/Observation.rs requests read and search access to observations for the patient in context. It is not permission to search every patient’s record. The same specification recommends examining granted scopes rather than assuming the authorization server granted everything requested.
Apply equivalent boundaries to search indexes, cached evidence and document chunks. An embedding pipeline should not erase the patient and organization associations needed to enforce access later.
Prefer pre-retrieval filtering of the authorized corpus, followed by validation before prompt assembly. Reject cross-boundary results and investigate the cause rather than asking the model to ignore them.
[FIGURE #01]Figure 1. Proposed evidence-first architecture for clinician-facing record summarization. Access decisions precede retrieval; source metadata accompanies the evidence; generated text remains a draft. Conceptual design, not a validated clinical deployment.
Build an inspectable evidence package
Instead of forwarding disconnected text fragments, assemble an evidence package containing source identifiers, relevant dates, status, transformation information and known retrieval limitations.
A factual statement should point to the resource or passage that supports it. A link to an entire chart may be navigable, but it does not establish whether the cited evidence supports a particular sentence.
Preserve two distinct forms of traceability. HL7’s FHIR R4 Provenance specification, section 6.3.1, describes the entities, agents and activities involved in producing or changing a resource. The same section distinguishes that lineage from AuditEvent records of system activity.
Use lineage to investigate where information came from. Use operational audit records to investigate who requested it, what was accessed and which decisions followed. Neither mechanism should be presented as proof that a generated clinical statement is correct.
Set explicit access and retention policies for these artifacts. Prefer protected references and necessary metadata to indiscriminate duplication of clinical text in diagnostic logs.
Evaluate the pipeline in parts
NIST’s Generative AI Profile, AI 600-1, is a companion to the AI Risk Management Framework. It addresses risks including confabulation and data privacy and discusses pre-deployment testing and ongoing monitoring; it is not a clinical certification.
For the proposed architecture, translate those concerns into separate retrieval, generation and workflow tests. This separation makes a failed summary more actionable: missing evidence requires a different remedy from misrepresentation of correctly retrieved evidence.
| Dimension | Proposed test | Review artifact |
| Patient isolation | Attempt retrieval under mismatched patient context | Authorization decision and rejected request |
| Evidence coverage | Compare retrieved items with a reviewer-defined evidence set | Missing and irrelevant items |
| Claim support | Check factual statements against cited passages | Unsupported or overstated claims |
| Temporal fidelity | Include historical, corrected and conflicting records | Date and status errors |
| Missing information | Remove evidence or restrict access deliberately | Whether limitations remain visible |
| Professional review | Ask reviewers to verify and correct the draft | Correction burden and review time |
These are proposed evaluation dimensions, not reported results. Define reviewer qualifications, case selection, severity categories and acceptance criteria before testing. Report the denominator and distinguish clinically consequential errors from presentation defects.
Include cases where a limitation statement is the correct response. An evaluation set containing only complete records will not test whether the assistant handles incomplete access responsibly.
Consider an illustrative medication-history task: one source records a historical prescription while another records a later discontinuation. A useful test asks whether the draft preserves that sequence and cites both sources. This is a hypothetical test case, not a patient record or observed result.
Make changes reviewable
Place model versions, prompts, retrieval settings and terminology mappings under change control. Record enough configuration information to compare behavior before and after a release without retaining unnecessary sensitive content.
For every material change, rerun the relevant evaluation cases and inspect regressions. A different model can change phrasing; a different retrieval configuration can change which evidence the model ever sees.
Assign authority to pause the feature and define the evidence needed to resume it. Professional review should be a supported workflow with inspectable sources and correction mechanisms, not an assumption that a busy clinician will catch every defect.
The proposed engineering standard is not perfect generation. It is an explicit, testable relationship between authorized evidence, generated claims and accountable decisions. In clinical AI, fluency belongs at the presentation layer; the foundation should be evidence that can be challenged.
