⏱ 7 min read
European healthcare systems are becoming increasingly interconnected. Citizens receive treatment abroad, prescriptions are dispensed across borders, and pharmacovigilance signals must be detected at continental scale. At the same time, regulators demand traceability, identity precision, and lifecycle control over medicinal products.
For Enterprise Architects operating in regulated environments, this creates a fundamental challenge: how do we design an architecture that supports operational clinical interoperability while preserving regulatory master data authority?
Two standards dominate this landscape: HL7 FHIR as the operational interoperability fabric, and IDMP (ISO 11615 and related standards) as the medicinal product semantic backbone. This covers how to integrate both within an enterprise architecture framework, applying TOGAF ADM across all architecture layers.
Two Worlds: Operational Exchange vs Regulatory Authority
HL7 FHIR: Runtime Clinical Interoperability
FHIR (Fast Healthcare Interoperability Resources) defines modular resources — Patient, Medication, Observation, Encounter — exchanged through REST-based APIs using JSON or XML. FHIR is optimized for real-time exchange, distributed systems, API-driven ecosystems, and clinical workflow support. modeling integration architecture with ArchiMate
FHIR answers one fundamental question: how do healthcare systems exchange information consistently at runtime?
IDMP: Regulatory Master Data Governance
IDMP (Identification of Medicinal Products) defines structured medicinal product data across four levels: Substance, Pharmaceutical Product, Medicinal Product, and Packaged Medicinal Product. IDMP is about identity, authorization, traceability, and lifecycle governance.
IDMP answers a different question: what exactly is this medicinal product, and what is its regulatory status?
Applying TOGAF ADM to HL7 and IDMP
The TOGAF Architecture Development Method provides the governance framework for integrating these two standards across all architecture layers.
Phase A: Architecture Vision
The architecture vision addresses four key drivers: safe cross-border dispensing, regulatory harmonization, product authorization verification, and adverse event traceability. The vision is a federated semantic interoperability architecture using FHIR for operations and IDMP as the regulatory backbone.
Phase B: Business Architecture
The business architecture identifies core capabilities: prescription validation, product authorization checking, adverse event reporting, and cross-border reimbursement processing. FHIR supports the clinical workflow capabilities while IDMP supports the regulatory validation capabilities.
Phase C: Data Architecture
The data architecture defines five enterprise data domains, each with clear ownership and governance.
The critical architecture principle here: IDMP is not a FHIR extension. It is an authoritative master domain referenced by FHIR resources, not embedded within them. This separation ensures that regulatory master data maintains its integrity regardless of how operational systems consume it.
Phase D: Application Architecture
The application landscape spans national EHR systems, FHIR servers, API gateways, terminology services, IDMP master data hubs, and pharmacovigilance platforms. The critical design decision is the separation of concerns between operational APIs and regulatory master data systems, connected through a semantic mediation layer.
Phase E: Technology Architecture
The technology architecture splits into two complementary stacks. The FHIR stack relies on REST APIs, OAuth2/OpenID Connect authentication, and API gateways. The IDMP stack requires a Master Data Management platform, workflow engine for regulatory processes, versioning engine for product lifecycle, and a graph database for complex ontological relationships between substances, products, and regulatory statuses.
Phase F: Opportunities and Solutions
Three integration patterns emerge from the architecture analysis. First, federated FHIR with centralized IDMP: each member state operates its own FHIR infrastructure while referencing a shared IDMP master. Second, a semantic mediation layer translates between FHIR medication resources and IDMP product identifiers. Third, event-driven pharmacovigilance validation uses IDMP product data to correlate adverse events across borders in near-real-time.
Phase G: Governance
Architecture governance for cross-border health systems requires critical controls at multiple levels: EU-level FHIR profiling to ensure consistent resource structures across member states, IDMP data stewardship to maintain product master data quality, terminology governance for shared vocabularies like SNOMED CT and ATC, and version management policies that ensure backward compatibility as standards evolve.
Phase H: Architecture Change Management
Healthcare standards evolve continuously. The architecture must support ontology evolution as medical knowledge advances, backward compatibility to avoid breaking existing integrations, identifier continuity so that product references remain valid across versions, and traceable versioning that satisfies regulatory audit requirements. integration architecture diagram
Technology Stack Considerations
Why Graph Databases for IDMP?
IDMP data is inherently ontological. A single medicinal product has relationships to substances (potentially multiple active ingredients), pharmaceutical forms, routes of administration, marketing authorizations across jurisdictions, packaging hierarchies, and regulatory lifecycle states. Relational databases can model this, but graph databases (such as Neo4j or Amazon Neptune) represent these relationships more naturally and support the kind of traversal queries that pharmacovigilance analysis requires. TOGAF roadmap template
Event-Driven Architecture for Pharmacovigilance
Adverse event detection across 27 EU member states requires an event-driven approach. When a national system reports an adverse reaction via FHIR, the pharmacovigilance platform must correlate this with IDMP product data, identify the specific substance and product variant involved, and check for signal patterns across the entire EU dataset. This is a natural fit for event streaming platforms like Apache Kafka combined with complex event processing.
The Semantic Mediation Challenge
The most technically demanding component is the semantic mediation layer that bridges FHIR and IDMP. A FHIR MedicationRequest references a medication using a code (typically from a national formulary). The semantic mediation layer must resolve this code to an IDMP-compliant product identifier, which in turn links to the full substance, pharmaceutical form, and authorization chain.
This resolution is not a simple lookup. It requires navigating terminological hierarchies, handling regional product variants, and managing temporal validity (a product code that was valid last year may have been replaced by a new formulation). This is where the investment in both terminology governance and graph-based data management pays off.
Implications for Enterprise Architects
For Enterprise Architects working in EU healthcare, several design principles emerge from this analysis: Sparx EA best practices
- Separate operational and regulatory concerns — FHIR and IDMP serve different purposes and must not be conflated into a single data model
- Invest in semantic mediation — The bridge between FHIR and IDMP is the most complex and most valuable component
- Design for federation — Each member state will operate its own clinical systems; the architecture must support this diversity
- Centralize what must be consistent — Product identity and regulatory status must be authoritative and consistent across all member states
- Plan for evolution — Both FHIR and IDMP standards will continue to evolve; the architecture must absorb changes without breaking integrations
Conclusion
In mature EU healthcare ecosystems, IDMP becomes the semantic spine that provides authoritative product identity and regulatory governance, FHIR becomes the interoperability fabric that enables clinical systems to exchange data at runtime, and TOGAF provides the governance structure that ensures operational agility and regulatory authority coexist without semantic compromise.
This architectural pattern — federated operations with centralized master data, connected through semantic mediation — is not unique to healthcare. It applies wherever enterprise architects must bridge operational systems with authoritative reference data across organizational and jurisdictional boundaries. free Sparx EA maturity assessment
For guidance on applying ArchiMate modeling and TOGAF frameworks to regulated healthcare environments, or to explore how Sparx Enterprise Architect can serve as the repository for this kind of multi-standard architecture, get in touch.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture is a discipline that aligns an organisation's strategy, business operations, information systems, and technology infrastructure. It provides a structured framework for understanding how an enterprise works today, where it needs to go, and how to manage the transition.
How is ArchiMate used in enterprise architecture practice?
ArchiMate is used as the standard modeling language in enterprise architecture practice. It enables architects to create consistent, layered models covering business capabilities, application services, data flows, and technology infrastructure — all traceable from strategic goals to implementation.
What tools are used for enterprise architecture modeling?
Common enterprise architecture modeling tools include Sparx Enterprise Architect (Sparx EA), Archi, BiZZdesign Enterprise Studio, LeanIX, and Orbus iServer. Sparx EA is widely used for its ArchiMate, UML, BPMN and SysML support combined with powerful automation and scripting capabilities.