ArchGen

HL7 FHIR Interoperability Architecture

Focus: SMART on FHIR + Core Resource Relationships + HL7 v2 to FHIR Mapping. Key areas: Web/Mobile App, FHIR REST API, SMART on FHIR App Launch (optional).

Use this as a block diagram of the system when explaining architecture.

Preview
Edit this example
Diagram caption: HL7 FHIR Interoperability Architecture (SMART on FHIR + Core Resource Relationships + HL7 v2 to FHIR Mapping) has 5 layers: Consumer Applications, SMART on FHIR Authorization Layer, FHIR API & Resource Layer, Integration & Mapping Layer (Legacy HL7 v2 to FHIR), Backend Clinical System Layer.

Prompt

Healthcare interoperability architecture based on HL7 FHIR standards. Visualize the relationship diagram between core resources: Patient, Encounter, Practitioner, and Observation. Show an external 'Patient Portal App' connecting to the FHIR Server via a SMART on FHIR authorization layer (OAuth2). The FHIR Server should interface with a backend Electronic Health Record (EHR) system to map legacy HL7 v2 messages to FHIR resources.
Highlights
  • Layer details · SMART on FHIR Authorization Layer: Modules include OAuth2 / SMART Authorization Server, Consent & Policy Enforcement (Optional).
  • Module responsibilities · Consumer Applications / Patient Portal App (External): Provide patient-facing access to health data; Call FHIR APIs using SMART on FHIR authorization; Render patient timeline across encounters and observations
  • Layer details · Consumer Applications: Modules include Patient Portal App (External), Clinician/Operational Apps (Optional).

Overview

HL7 FHIR Interoperability Architecture (SMART on FHIR + Core Resource Relationships + HL7 v2 to FHIR Mapping) has 5 layers: Consumer Applications, SMART on FHIR Authorization Layer, FHIR API & Resource Layer, Integration & Mapping Layer (Legacy HL7 v2 to FHIR), Backend Clinical System Layer.

Layer details

Show all (5)
  • Consumer Applications: Modules include Patient Portal App (External), Clinician/Operational Apps (Optional).
  • SMART on FHIR Authorization Layer: Modules include OAuth2 / SMART Authorization Server, Consent & Policy Enforcement (Optional).
  • FHIR API & Resource Layer: Modules include FHIR Server (R4/R5), Core Resource Relationship Model (Diagram), FHIR Subscriptions / Eventing (Optional).
  • Integration & Mapping Layer (Legacy HL7 v2 to FHIR): Modules include HL7 v2 Interface Engine, HL7 v2 -> FHIR Mapping Service, Terminology & Code Translation (Optional).
  • Backend Clinical System Layer: Modules include Electronic Health Record (EHR) System, FHIR Persistence Store.

Module responsibilities

Show all (12)
  • Consumer Applications / Patient Portal App (External): Provide patient-facing access to health data; Call FHIR APIs using SMART on FHIR authorization; Render patient timeline across encounters and observations
  • Consumer Applications / Clinician/Operational Apps (Optional): Support clinical workflows using the same FHIR surface; Consume resource relationships for care context; Respect patient consent and scopes
  • SMART on FHIR Authorization Layer / OAuth2 / SMART Authorization Server: Authenticate users and obtain consent; Issue access tokens with SMART scopes; Enforce least-privilege access to FHIR resources
  • SMART on FHIR Authorization Layer / Consent & Policy Enforcement (Optional): Apply patient consent and organizational policies; Filter resources based on scopes and policies; Audit authorization decisions
  • FHIR API & Resource Layer / FHIR Server (R4/R5): Expose standards-based FHIR APIs to external apps; Validate and store FHIR resources and references; Support search and resource relationship traversal
  • FHIR API & Resource Layer / Core Resource Relationship Model (Diagram): Define canonical clinical context links; Enable timeline queries by patient and encounter; Support practitioner attribution for encounters/observations
  • FHIR API & Resource Layer / FHIR Subscriptions / Eventing (Optional): Enable near real-time updates to apps; Reduce polling on frequently changing resources; Support reactive workflows
  • Integration & Mapping Layer (Legacy HL7 v2 to FHIR) / HL7 v2 Interface Engine: Receive and normalize HL7 v2 messages from EHR; Route messages to mapping/transform services; Handle retries, DLQ, and operational monitoring
  • Integration & Mapping Layer (Legacy HL7 v2 to FHIR) / HL7 v2 -> FHIR Mapping Service: Transform legacy segments into FHIR resources; Maintain consistent identifiers and references; Validate against FHIR profiles before persistence
  • Integration & Mapping Layer (Legacy HL7 v2 to FHIR) / Terminology & Code Translation (Optional): Normalize codes to interoperable standards; Improve queryability and cross-system compatibility; Enforce ValueSet constraints
  • Backend Clinical System Layer / Electronic Health Record (EHR) System: Act as system-of-record for clinical data; Emit HL7 v2 messages for interoperability; Support legacy workflows and data capture
  • Backend Clinical System Layer / FHIR Persistence Store: Persist FHIR resources for API access; Support efficient search and relationship traversal; Maintain compliance-oriented retention and auditing

Key flows

Show all (3)
  • SMART on FHIR access: the Patient Portal App authenticates via the OAuth2 SMART authorization server (Authorization Code + PKCE) to obtain a scoped access token, then calls the FHIR Server endpoints (Patient/Encounter/Practitioner/Observation) with least-privilege scopes for read access.
  • Core resource relationships: Patient is referenced by Encounter.subject; Encounter links to Practitioner through Encounter.participant.individual; Observation references Patient via Observation.subject and is clinically contextualized via Observation.encounter -> Encounter, enabling patient-centric timelines and encoun
  • Legacy integration: the EHR emits HL7 v2 messages (e.g., ADT for patient/encounter events and ORU^R01 for results); an interface engine ingests and routes messages to a mapping service that transforms them into FHIR resources (Patient/Encounter/Observation), normalizes codes (LOINC/SNOMED/UCUM as needed), validates aga