Sparx EA gives healthcare architects a single governed model for their entire FHIR integration landscape: from resource definitions and API contracts through to the clinical systems that produce and consume health data.
HL7 FHIR (Fast Healthcare Interoperability Resources) has become the dominant standard for health data exchange, required by US regulations, UK NHS frameworks, and Australian digital health initiatives alike. But FHIR is not just a technical specification: it is an architectural commitment. Every FHIR-enabled system exposes a capability statement, conforms to one or more profiles, and participates in an integration topology that must be governed, documented, and evolved over time. Sparx EA provides the modeling environment to capture that architecture coherently. This article explains how to model FHIR resources, API contracts, and capability statements in Sparx EA, how to govern approved profiles using MDG Technology, and how EA GraphLink makes your FHIR architecture queryable in real time.
Key Takeaways
- FHIR Resources (Patient, Observation, DiagnosticReport, Encounter) are best modeled as Information layer Data Objects or UML Classes with a FHIR stereotype in Sparx EA.
- FHIR REST API contracts are modeled as Application Interfaces at the Application layer, linked to the Data Objects they expose.
- FHIR capability statements become architectural standards in your model: governing which endpoints expose which resources.
- Profile governance is an MDG concern: approved implementation-specific profiles are stereotyped and tagged, making non-conformance visible.
- EA GraphLink enables Copilot/Kernaro queries across the FHIR architecture: “which systems are FHIR-enabled and what resources do they expose?”
What HL7 FHIR Is: and Why It Requires Architectural Governance
FHIR is the HL7 standard for health data exchange, built on RESTful APIs and modern web conventions. Unlike its predecessors (HL7 v2 used in legacy lab and ADT feeds; HL7 v3 which was widely criticized for complexity), FHIR is designed for developer accessibility. Health data is structured into discrete Resources: self-contained units of clinical or administrative information. The Patient resource holds demographic data. The Observation resource carries lab results, vital signs, and clinical measurements. DiagnosticReport assembles a set of Observations into a completed diagnostic result. Encounter records the clinical visit or episode.
Each Resource has a defined structure in the FHIR specification, but profiles allow implementers to constrain or extend that structure for specific use cases. The US Core profile defines how Patient and Observation must be populated for US health information exchange. The UK’s NHS Digital has published profiles for NHS Number, GP practice data, and national clinical coding. Profiles are where FHIR moves from a universal standard to an implementation reality: and where architectural governance becomes essential.
Without governance, FHIR deployments fragment. Different teams implement incompatible profiles. Systems that claim FHIR conformance cannot actually exchange data. The FHIR capability statement: a machine-readable declaration of what a server supports: becomes a critical governance artifact, and someone must own it.
Modeling FHIR in Sparx EA: The Information Layer
In Sparx EA, FHIR Resources are modeled at the Information layer: the conceptual level at which data structures are defined independently of how they are technically stored or transported.
The practical approach is to create a UML Class diagram (or ArchiMate Data Object diagram) with a «FHIR Resource» stereotype applied via MDG. Each Resource becomes a stereotyped class. Attributes represent the key FHIR data elements: for Patient, this includes identifier, name, birthDate, gender, address. For Observation, the key elements are code (the LOINC or SNOMED code identifying the clinical measurement), value[x] (the result), subject (the patient), and encounter.
FHIR profiles are modeled as specialisations of their base Resource classes. A «FHIR Profile» stereotype distinguishes approved profiles from the base specification. Tagged values on the profile element record the profile canonical URL, the governing body (e.g., US Core, NHS Digital, local), and the approval status. This gives the governance committee a single view of which profiles are approved for use across the program.
FHIR relationships: references between Resources: are modeled as associations or ArchiMate Association relationships. The Observation.subject reference to Patient, or the DiagnosticReport.result reference to Observation, becomes a navigable association in the model. This allows an architect to trace the data lineage: from a clinical measurement captured in an Observation, through the DiagnosticReport that presents it, to the patient whose record it belongs to.
FHIR API Contracts at the Application Layer
FHIR’s REST API is the transport mechanism for Resource exchange. In ArchiMate terms, each FHIR server endpoint is an Application Interface at the Application layer. The interface is assigned a name corresponding to the FHIR base URL (e.g., https://fhir.hospital.org/R4), and sub-interfaces represent specific Resource endpoints (GET /Patient, POST /Observation).
Each Application Interface is linked to the Data Objects it exposes via ArchiMate Access relationships. The FHIR server application component (modeled as an Application Component) realizes the interfaces and accesses the underlying data store.
The FHIR Capability Statement: the machine-readable declaration of server capabilities: is represented in the model as an Architectural Principle or Constraint element linked to the Application Component. It records: supported FHIR version (R4/R4B/R5), supported Resource types, supported interactions (read, search, create, update), and supported search parameters. This makes the capability statement an auditable part of the architecture model rather than a document living in a separate wiki.
Use Case: Modeling a FHIR-Based Interoperability Architecture
Consider a hospital implementing a FHIR-based interoperability hub connecting its EPR to consumer-facing patient apps and regional data sharing platforms.
As-is state: The hospital EPR (e.g., Epic, Cerner) has a proprietary API. Legacy HL7 v2 ADT feeds connect to the PAS (Patient Administration System). No FHIR capability exists.
Target state in Sparx EA:
- The EPR exposes a FHIR R4 endpoint: modeled as an Application Component (
Epic FHIR Server) with a set of Application Interfaces for Patient, Observation, Appointment, and MedicationRequest Resources. - A FHIR Integration Hub (middleware: Azure Health Data Services or AWS HealthLake) sits between the EPR and consuming applications. It is modeled as an Application Component with a serving interface toward consumers and a used-by relationship toward the EPR FHIR server.
- Consumer applications: the NHS App (UK), a patient portal, a third-party care coordination platform: are modeled as Application Components that use the hub’s FHIR interfaces. Each is linked to the specific Resource types it consumes via Access relationships.
- The data flow is traced at the Information layer: a Patient Observation created in the EPR flows through the hub and is accessed by the patient portal. The ArchiMate Flow relationship carries a label identifying the FHIR Resource type being exchanged.
This diagram becomes the canonical reference for integration decisions: which systems can exchange which data, which profiles are required, and which capability statements have been validated.
Profile Governance as an MDG Concern
FHIR profiles are the core governance challenge in a multi-system FHIR architecture. Different vendors implement different versions of the same profile. Clinical teams request custom extensions. Regulatory requirements mandate specific profiles for particular exchange scenarios.
MDG Technology in Sparx EA is the natural home for profile governance. A «FHIR Profile» stereotype in the MDG carries tagged values for:
Profile URL: the canonical HL7/FHIR canonical URLBase Resource: the FHIR Resource this profile constrainsGoverning Body: who owns and maintains this profileApproval Status: Draft / Approved / DeprecatedMandatory For: which exchange scenarios require this profileConformance Level: SHALL / SHOULD / MAY
When an architect models a new integration, the MDG toolbox makes approved profiles visible and selectable. Non-approved profiles can be flagged by a model validation rule. A Power BI report generated from Sparx EA data shows the profile inventory: how many approved, how many deprecated, how many pending review.
EA GraphLink: Making FHIR Architecture Queryable
A large healthcare organization may have dozens of FHIR-enabled systems, hundreds of Resource types in scope, and multiple overlapping profiles. Keeping track of the architecture through manual review of EA diagrams is not practical for operational governance.
EA GraphLink connects Sparx EA to Microsoft Power BI and AI interfaces including Copilot and Kernaro. Once the FHIR architecture is modeled, GraphLink enables natural language queries:
- “Which systems are FHIR-enabled and what Resources do they expose?”
- “Show me all systems consuming the Observation Resource.”
- “Which profiles are approved for use in the regional data sharing program?”
- “Are there any integrations still using HL7 v2 that have a FHIR migration date?”
These queries return structured answers from the live Sparx EA repository: not a stale document. Program managers and clinical informatics leads get the answers they need without opening the EA tool. The governance team can detect drift between approved architecture and actual implementation.
FAQ
Q1: Do I need a special MDG extension to model FHIR in Sparx EA? Sparx EA does not ship with a FHIR-specific MDG out of the box, but one can be configured using the built-in MDG Technology framework. Sparx Services can provide a pre-built FHIR MDG that includes stereotypes for FHIR Resources, Profiles, CapabilityStatements, and API Interfaces, saving several days of configuration work.
Q2: Should I model FHIR at the UML class level or use ArchiMate Data Objects? For a high-level interoperability architecture, ArchiMate Data Objects at the Information layer are appropriate: they keep the model at the right abstraction level for stakeholder communication. If you need to document detailed Resource element structures (for developer reference or governance purposes), UML Class diagrams with FHIR stereotypes provide greater fidelity. Most organizations use both: ArchiMate at the architecture level, UML for detailed data design.
Q3: How do I handle the difference between FHIR R4 and R4B in the same model? Create a tagged value on each FHIR Server Application Component recording the supported FHIR version. A model validation rule or Power BI report can then surface version mismatches: for example, a consumer application requiring FHIR R4B connected to a server that only supports R4.
Q4: Where do FHIR capability statements live in the model? Capability statements are best represented as Constraint or Principle elements linked to the FHIR Server Application Component via an Association relationship. They can also be attached as linked documents if you need to embed the actual JSON capability statement. The key is ensuring the capability statement is traceable to the server it describes.
Q5: How does FHIR architecture modeling connect to broader clinical system governance in Sparx EA? FHIR sits at the integration layer of a broader clinical system architecture. In Sparx EA, the FHIR integration architecture is one view within a larger model that also captures the EPR/EHR application landscape, clinical workflows at the Business layer, and the technology infrastructure at the Technology layer. ArchiMate relationships trace the connections between these layers, allowing an architect to answer: “if this FHIR server goes down, which clinical workflows are affected?”
Q6: Can Sparx EA help us prepare for a CMS interoperability rule audit? Yes. The CMS Interoperability and Patient Access Rule requires payers and providers to expose specific FHIR APIs (Patient Access, Provider Directory, Drug Formulary). Modeling these APIs and their FHIR Resource coverage in Sparx EA creates an auditable record of compliance architecture: which systems expose which APIs, which profiles are implemented, and which capability statements have been validated.
Q7: How is FHIR profile governance different from standard data governance in Sparx EA? Standard data governance in Sparx EA focuses on data ownership, lineage, and quality rules. FHIR profile governance adds a conformance dimension: not just “who owns this data element” but “which profiles constrain how this element is exchanged, and which systems have been validated against those profiles.” The MDG stereotype approach lets both concerns live in the same model element.
Q8: What is the role of EA GraphLink in a FHIR governance program? EA GraphLink moves FHIR architecture from a tool that architects consult to a service that operational stakeholders can query. Clinical informatics leads, integration managers, and program directors can ask questions about the FHIR landscape: which systems are connected, which profiles are approved, which integrations are still HL7 v2: and receive answers from the live architecture model without requiring EA tool access.
Work With Sparx Services
Your FHIR integration architecture deserves more than a diagram in a wiki. Sparx Services’ Connect engagement creates an EA GraphLink-enabled Sparx EA environment where your FHIR architecture: resources, profiles, API contracts, and capability statements: is modeled, governed, and queryable by the people who need to act on it.
Connect starts at $50,000. Reach out to discuss your healthcare interoperability architecture.