Does a SMART scope authorize sending EHR data to an LLM?

A SMART scope authorizes defined interactions with FHIR resources. It can express that an application may read or search particular resource types under a user or system context. The scope does not name the later LLM destination or prompt fields. It does not cover model retention terms or enterprise AI usage policy. Build a second decision before the model request. That decision should use the initiating identity and purpose. It should evaluate the selected fields and data classification against the approved route. Preserve a link to the SMART authorization so an investigator can reconstruct both calls without treating them as one permission.

Should the gateway store the full prompt and response?

Retention should follow the approved evidence design for the use case. Full content can help incident reconstruction, but it can also create another store of ePHI. Many control tests need identity and the patient-context reference. They also need resource classes and classification. Record the destination and policy version, then preserve the outcome and timestamp rather than a duplicate clinical note. Counsel and privacy owners should approve when content is retained. Security and clinical owners should approve too. Together, they should determine how the content is encrypted and who can retrieve it. They should also determine when it is deleted.

Can a service account carry enough identity for policy?

A service account can support policy when the application supplies reliable workload context. Identify the workload and owner. Record the approved job and purpose. Add the patient or cohort reference and route. Validate those claims instead of trusting a free-text header. An interactive clinician assistant needs the clinician identity as well. The policy should distinguish a nightly approved batch from an ad hoc export, even when both calls originate from the same host.

Where should a model-generated note be approved?

Approval belongs in the clinical application or EHR workflow. The reviewer needs the source record and generated text. The review must also show edits and attribution, along with the authority to reject the output. The EHR write must use the appropriate SMART or native authorization. A gateway can record the model interaction and inspect the response while it crosses the managed route. It lacks custody of the later clinical decision and chart-signing event.

What is the first integration test to run?

Trace one real workflow across both boundaries. Start with the SMART launch and record its user and patient context. Record the scopes and resource access too. Follow the selected fields into prompt construction. Then verify the classification and approved destination. Record the policy outcome and model response. Finish at the clinical review and any EHR write. The test passes when every transition has one accountable owner and a stable identifier joins the records without copying unnecessary ePHI.

AI EHR Integration Security: Split the EHR and LLM Boundaries

An EHR-to-LLM integration makes two different authorization decisions. The first lets an application read selected FHIR resources from an electronic health record. The second sends some of that material to a model endpoint over HTTP. A SMART token can authorize the first call without answering whether a discharge note or medication list may enter the second one. It also does not decide whether a patient identifier may enter that request.

I would reject any architecture diagram that draws those calls as one arrow. When the handoff omits identity, purpose, data classification, and model approval, the second request loses the context needed for policy and investigation.

TL;DR

SMART App Launch controls an application's access to FHIR resources and patient context.
The later LLM request needs its own identity and data classification. It also needs a destination and policy decision.
Keep EHR authorization and EHR writes with their existing owners. Clinical review and patient-safety decisions stay there too.
Use gateway evidence only for authenticated HTTP model traffic deliberately routed through the gateway.

SMART controls the EHR access decision

The current HL7 SMART App Launch implementation guide uses OAuth 2.0 patterns for applications that connect to FHIR systems. A user-facing launch can carry the selected patient as launch context and delegate part of the user's permissions to the application. Backend Services covers a headless client whose permissions were assigned out of band. SMART scopes then describe permitted FHIR interactions and resource types. They also describe search operations.

That mechanism answers a precise question: which FHIR resources may this client read or change under this authorization? Token introspection can expose associated scopes and users, along with patients and other context. Private-key JWT authentication can establish the client without sending a shared secret over the wire.

The token says nothing about an LLM destination. It also says nothing about the prompt assembled after the records arrive. An application with permission to read an Encounter can still create a model request containing fields that exceed the approved purpose. Treat SMART authorization as the source boundary, then evaluate the model destination and prompt under a separate policy.

The handoff needs a typed data contract

The integration should create a typed handoff record between FHIR retrieval and prompt construction. Start with the use case, such as summarizing a discharge record for a clinician already assigned to the patient. Name the FHIR resource types and fields the application is allowed to retrieve. Then define which fields may enter the prompt and which must be removed. Some fields can be replaced with stable tokens.

A useful record identifies the SMART client identifier and the user or service identity. It links the patient-context reference to the granted scopes, then records retrieved resource classes against the purpose code. Prompt classification appears beside the approved model route. The policy version and decision time complete the record. Avoid copying an entire patient chart into the control record. Store references and classifications unless an investigation requires protected content under an approved retention rule.

Picture the review screen: a medication list is visible on the left, while the model request preview on the right contains the patient's full name and medical record number. That visual mismatch should stop the call. The AI data classification guide describes the classification step. The EHR authorization remains valid. The model request fails its separate contract.

HIPAA safeguards follow the ePHI through the model request

NIST SP 800-66 Revision 2, published in February 2024, frames the HIPAA Security Rule around safeguarding electronic protected health information that a regulated entity creates, receives, maintains, or transmits. It directs regulated entities to protect ePHI against reasonably anticipated threats and hazards. The protection also covers reasonably anticipated impermissible uses or disclosures. NIST also maps HIPAA Security Rule standards to Cybersecurity Framework subcategories and SP 800-53 controls.

For an EHR integration, the model-bound request is another transmission of ePHI. The security file should therefore identify the destination and contractual status. It should document the access path and encryption, then cover retention behavior and the incident route. The responsible owner should be named. A business associate agreement belongs in that file when required. It cannot authorize every prompt assembled by the application.

The runtime control should apply the approved purpose to each request. A cardiology summarization route may allow selected Encounter and MedicationRequest fields for an assigned clinician. The same route should reject a batch export assembled by a service account whose purpose is missing. HIPAA AI access logging covers the wider evidence duties around access and review.

Identity must survive both calls

A common integration keeps a detailed user identity for the SMART launch and switches to a shared API credential for the model. The model request then arrives with an application name. It has no reliable link to the clinician or workflow that caused it. Audit teams can reconstruct the EHR read but lose the person and purpose at the AI boundary.

Carry a signed, application-supplied identity context into the model route. Include the user or workload identity and role. Add the use-case identifier and patient-context reference, then state the purpose. The gateway should validate the issuer and expected claims before policy evaluation, then bind the resulting decision to the destination and model deployment.

The identity for a backend service should identify the workload, owner, and approved job. A nightly population-health task and an interactive clinician assistant deserve different policies even when they use the same SMART Backend Services client. A single shared label such as ehr-ai-service hides the distinction that policy needs.

Clinical decisions and EHR writes stay outside the gateway

The model response can cross the managed HTTP route, but its clinical use happens later. A clinician may accept or discard a summary. The clinician may edit it first. An application may write a note back to the EHR. Those events require application and clinical-workflow controls. They include qualified review and attribution, along with version history and write authorization.

DeepInspect cannot establish that a reviewer is clinically qualified from the text of a model response. It also cannot prove that a final note was accurate or signed. Nor can it prove that the note was placed in the correct patient's chart. SMART and EHR controls govern the write. Clinical governance owns validation and patient-safety review. The gateway can preserve the request and response classification. It can also record the policy outcome and route used for the model interaction.

A blocked request proves that protected content never crossed the managed model route. A permitted request proves which policy accepted it. The EHR audit still has to show what was read and written, while the clinical record identifies the person responsible for the final decision.

DeepInspect

DeepInspect can enforce the second decision for authenticated HTTP model traffic deliberately routed through it. The application supplies identity and role, plus purpose and patient-context references. Policy can evaluate those claims with prompt classification and the approved model destination before forwarding the request. Each permit or deny result produces a per-decision record tied to the active policy version. A redact result produces the same record.

SMART authorization and EHR retrieval remain with the EHR application and healthcare owners. Clinical review and chart writes remain there as well. Direct provider calls and local models sit outside the managed route. Vendor features that hide their model traffic also sit outside it. The useful boundary is precise: DeepInspect controls the request that leaves the integration for an LLM and the response that returns through the same HTTP path.

Book a technical deep dive at deepinspect.ai.