FHIR Facade

The core mechanism involves intercepting a FHIR RESTful request (e.g., GET /Patient/123) and dynamically translating it into the legacy system's native query language. This is not a static mapping; the facade parses FHIR search parameters like _lastUpdated, _include, and chained parameters, converting them into equivalent SQL, NoSQL, or proprietary API calls. The result set from the backend is then transformed into a valid FHIR Bundle resource before returning it to the client, ensuring the legacy system appears fully FHIR-native without any code modification.

Legacy data rarely conforms to FHIR profiles. The facade applies a mapping layer that normalizes non-standard data models into compliant FHIR Resources during the read path. This includes:

• Structural transformation: Flattening nested legacy objects into distinct FHIR resources.
• Terminology mapping: Translating local proprietary codes into standard terminologies like SNOMED CT or LOINC using a pre-configured ConceptMap.
• Identifier translation: Assigning a logical FHIR ID to a record that may have a composite key in the source system, maintaining a stable identity for external consumers.

A robust facade supports not only reads but also transactional writes. It exposes standard FHIR operations like create, update, and $validate. When a client sends a FHIR Transaction Bundle, the facade decomposes it into discrete operations, executes them against the legacy system's API or database in the correct order, and manages the rollback logic if a step fails. This allows modern SMART on FHIR applications to write data back to an aging mainframe or proprietary clinical data repository as if it were a native FHIR server.

To support complex querying, the facade must implement a subset of the FHIRPath specification and the full FHIR search syntax. This engine evaluates conditional references, reverse chaining, and _has parameters without materializing the entire dataset. For instance, a query for Observation?subject:Patient._has:Condition:subject:code=XYZ requires the facade to execute a sub-query against the legacy system's diagnosis table to filter observations, a capability that distinguishes a true facade from a simple REST wrapper.

The facade is designed as a stateless, horizontally scalable middleware layer. It stores no clinical data itself; it is a pure compute layer that relies entirely on the source of truth in the legacy backend. This design ensures that the facade does not create a new data silo. It leverages caching only for performance-critical reference data like StructureDefinitions and ValueSets. This statelessness simplifies deployment in containerized environments like Kubernetes, allowing the translation layer to scale independently of the often-monolithic legacy database.

The facade dynamically generates a CapabilityStatement resource that accurately reflects the intersection of what the FHIR standard allows and what the legacy system can actually support. It does not falsely advertise full FHIR conformance. If the backend cannot support a specific search parameter, the facade omits it from the CapabilityStatement.rest.resource.searchParam list. This honest signaling is critical for FHIR Validator tools and client applications to programmatically discover the real limits of the legacy system without encountering runtime errors.

The foundational HL7 standard that the facade exposes. FHIR defines a RESTful API and a set of modular 'Resources' (Patient, Observation, Condition) representing granular clinical concepts. A facade must translate its internal query logic into these standard JSON/XML representations and HTTP verbs (GET, POST, PUT). Understanding the core resource definitions and search parameters (e.g., GET /Observation?patient=123&code=LOINC) is essential for building an accurate translation layer.

A common backend data model often sitting behind a FHIR Facade. The Observational Medical Outcomes Partnership (OMOP) CDM standardizes observational health data into a person-centric relational schema. A facade in this context must translate FHIR's resource-oriented requests into SQL queries against OMOP's standardized vocabularies and tables (e.g., mapping a Condition resource to the CONDITION_OCCURRENCE table). This pattern is critical for enabling large-scale analytics across disparate data sources.

A path-based expression language used to navigate and extract data from FHIR structures. In a facade architecture, FHIRPath can be used to define dynamic mapping rules between the legacy schema and the FHIR output. Instead of hard-coding every field transformation, a facade engine can evaluate expressions like Condition.code.coding.where(system='http://snomed.info/sct') to extract and validate specific coded elements before serving the response.

The FHIR resource that defines the rules a facade must enforce. A StructureDefinition specifies which elements are mandatory, what data types are allowed, and what terminology bindings are required for a specific use case (e.g., a US Core Patient profile). The facade's translation engine must validate that the generated FHIR output conforms to these profiles, ensuring syntactic and semantic interoperability even when the underlying data is messy or incomplete.

A mechanism for real-time event notification that elevates a facade from a passive translator to an active data synchronizer. When a legacy system updates a record, the facade can emit a FHIR Subscription notification to interested clients. This requires the facade to monitor the backend's change data capture (CDC) logs and translate internal events into standard FHIR topic-based notifications, enabling event-driven architectures on top of static legacy data stores.

The semantic translation layer critical for facade accuracy. A TerminologyService API allows the facade to validate and translate local proprietary codes into standard terminologies like SNOMED CT or LOINC. A ConceptMap resource defines the explicit mapping rules. For example, a facade might use a ConceptMap to translate an internal billing code 'ABC-123' into a standard SNOMED diagnosis code before populating a FHIR Condition resource, ensuring semantic consistency.