EHR Integration#

Conceptual Explanation#

HL7 v2 vs. FHIR R4: Different Purposes

HL7 v2 and FHIR R4 are not competing standards; they address different integration scenarios:

• HL7 v2 ADT feeds: Real-time event notification. When a patient is admitted (ADT^A01), transferred (ADT^A02), or discharged (ADT^A03), an HL7 v2 message is sent to all subscribed downstream systems in near real-time. HL7 v2 is the mechanism for maintaining census information and triggering workflows based on patient location changes.

• FHIR R4 REST APIs: On-demand data retrieval. When an AI system needs the patient's current medication list, recent lab results, or active diagnoses, it queries the FHIR API. FHIR is pull-based; the requesting system asks for data when it needs it.

For clinical AI systems: HL7 v2 ADT feeds are used to trigger AI workflows based on clinical events (patient admitted → start discharge planning AI background process). FHIR R4 APIs are used to retrieve the patient data the AI needs to do its work.

SMART on FHIR: Authorization for Clinical Applications

SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on FHIR) is an authorization framework that allows external applications to obtain permission to access FHIR API data on behalf of a patient or clinician. It is built on OAuth 2.0 and OpenID Connect, with healthcare-specific extensions.

SMART on FHIR defines two launch contexts:

• EHR launch: The application is launched from within the EHR (e.g., the clinician clicks a button in the EHR that opens the AI application). The EHR passes the current patient and encounter context to the application.
• Standalone launch: The application is launched independently and requests authorization separately.

For clinical AI systems embedded in the EHR workflow, EHR launch is the preferred pattern: the AI system inherits the clinician's session context (patient ID, encounter ID) without the clinician needing to enter it.

Core Architecture#

Common Mistakes#

Polling FHIR Instead of Using Subscriptions or ADT Feeds. Organizations that poll FHIR APIs on a fixed interval to detect patient status changes hit EHR API rate limits, add unnecessary load to the EHR, and receive stale data between polls. Use HL7 v2 ADT feeds or FHIR Subscriptions for event-driven workflows.

Requesting Broad SMART Scopes. An AI application that requests patient/*.read (read all FHIR resources for the patient) to avoid managing specific scopes creates unnecessary PHI exposure. EHR platforms increasingly reject overly broad scope requests in the app review process.

Writing AI Output Outside the EHR. AI-generated clinical content (discharge summaries, clinical notes) must be stored in the EHR as the authoritative medical record. Organizations that store AI output in a separate AI platform database create a fragmented medical record that does not meet Joint Commission completeness standards.

Missing HL7 v2 Acknowledgment Handling. HL7 v2 senders expect an Application Acknowledgment (AA) or Application Error (AE) response for every message. AI systems that consume HL7 v2 messages without sending proper acknowledgments cause the sending system to retry, creating duplicate messages.

Best Practices#

• Use FHIR R4 APIs for data retrieval; use HL7 v2 ADT feeds or FHIR Subscriptions for event notification
• Request minimum necessary SMART on FHIR scopes — one resource type at a time where possible
• Cache FHIR data appropriately (patient context changes infrequently within an encounter) to reduce EHR API load
• Write AI-generated clinical content back to the EHR via FHIR DocumentReference — keep the medical record complete and authoritative
• Register AI applications through the EHR vendor's official app registration process (Epic App Orchard for Epic environments) rather than using developer credentials in production
• Implement CDS Hooks for EHR-integrated recommendations — it is the standard-based alternative to EHR vendor customization

Alternatives#

Interview Questions#

Q: A clinical AI system needs to retrieve a patient's active medications list when a physician opens a prescription order. Design the EHR integration.#

Category: System Design Difficulty: Senior Role: AI Architect / Healthcare AI Engineer

Answer Framework:

This is a CDS Hooks use case with FHIR R4 data retrieval. When the physician initiates the prescription order workflow, the EHR fires the order-sign hook (or medication-prescribe if the EHR supports it). The AI application, registered as a CDS Hooks service, receives the hook call with the prefetch payload.

The prefetch payload should include the patient's active MedicationRequest resources — declare the prefetch template in the CDS discovery endpoint so the EHR populates it without a separate API call from the CDS service. This avoids an extra round-trip to the FHIR server at hook-fire time, which would add latency during the prescription workflow.

The CDS service then processes the medication list, checks for drug-drug interactions or allergy conflicts with the new prescription being signed, and returns a CDS Card if an issue is identified. The card should display the specific interaction, the clinical severity (informational vs. warning vs. critical), and a suggested alternative if applicable.

Key design considerations: the CDS service must respond within the EHR's timeout window (typically 5 seconds) — LLM inference should only be invoked if needed for complex interaction reasoning, not for simple lookup-based checks that can be answered from a drug interaction database without LLM. The system must also implement circuit breaker logic: if the CDS service is unavailable, the EHR must be able to proceed without the CDS response (clinical workflow cannot block on external AI service availability).

Key Points to Hit:

• order-sign CDS Hook as the trigger
• Prefetch payload for the medication list (avoids extra latency from a separate FHIR call)
• 5-second response time constraint — consider whether LLM is needed or simpler lookup suffices
• Circuit breaker: CDS service unavailability must not block clinical workflow

Key Takeaways#

• FHIR R4 and HL7 v2 are complementary standards: FHIR for data retrieval, HL7 v2 ADT for real-time event notification
• SMART on FHIR authorizes AI applications to access FHIR data on behalf of specific patients within specific contexts — always request minimum necessary scopes
• CDS Hooks is the standard-based mechanism for embedding AI recommendations in the EHR workflow without EHR vendor customization
• Clinical AI output (notes, summaries) must be written back to the EHR via FHIR DocumentReference — keeping the medical record complete and authoritative
• EHR API rate limits are a real production constraint; design AI systems to cache FHIR data and avoid polling patterns
• CDS Hook services must respond within EHR timeout windows and must implement circuit breakers — clinical workflow cannot be blocked by an unavailable AI service