HL7 and FHIR in German Hospitals: What Interoperable HIS Interfaces Mean for Digital Discharge Management
Hospital IT landscapes are rarely built around a single system. A hospital information system (HIS) holds administrative and clinical records, specialist departments run their own solutions, pharmacy, laboratory, radiology and nursing documentation each add their own data, and an increasing number of processes reach beyond the hospital into outpatient care.
Interoperability is what allows those systems to share information in a way that receiving applications can actually interpret. HL7 v2, FHIR and — in Germany — ISiK are the standards that make this possible, while gematik, the Telematikinfrastruktur (TI), KIM and the ePA define the national infrastructure in which healthcare information is exchanged securely.
This article explains how these pieces relate to each other, why they are not interchangeable, and what they mean in practice for one of the most interoperability-dependent hospital processes: discharge management.
For the operational and regulatory basics behind this topic, see our guide to hospital discharge management.
For the next stage — analytics and forecasting on top of coordinated workflows — see AI and predictive discharge management.
Why hospital interoperability matters more than ever
Modern hospital workflows almost never run inside one application. A single decision — can this patient go home tomorrow? — depends on information held in the HIS, in nursing documentation, in medication and pharmacy systems, in case management notes and in confirmations from external providers.
It is useful to distinguish two different levels here. Data exchange means one system can send information to another in a structured, machine-readable form. Workflow interoperability means the receiving system can use that information to drive a process: assign a task, resolve a dependency, update a status, or trigger the next step.
Most standardisation work addresses the first level. Hospitals feel the second one: information may be technically available and still not reach the person who has to act on it, at the moment that action would help.
- Standardised interfaces reduce the cost of every new integration
- Vendor-independent formats protect hospitals from lock-in
- Structured data can be reused for operations and analytics, not just display
- Reliable interfaces are a precondition for cross-organisational care
- Without standards, every connection becomes a bespoke project
Interoperability is infrastructure. It determines what is possible operationally — but on its own it does not organise work.
HL7 v2: the established backbone of hospital integration
HL7 (Health Level Seven) is the family of standards that has shaped clinical messaging for decades. In German hospitals, HL7 v2 is still the workhorse: admission, discharge and transfer messages, order entry, results reporting and many departmental integrations run over v2 message streams, frequently brokered by an integration engine.
HL7 v2 is a messaging standard. Systems exchange events — a patient was admitted, a result is available, an order was placed — in a compact, segment-based format. It is robust, extremely widely deployed, and well understood by hospital integration teams.
What it does not offer is a modern query model. A message tells you that something happened; it does not give an application a clean way to ask for a specific piece of information on demand. That is where the evolution toward API-based interoperability begins.
Importantly, existing HL7 v2 infrastructure does not disappear because FHIR arrives. In practice the two coexist for years: v2 keeps carrying established event flows while FHIR is introduced for new, application-facing use cases. Hospital integration strategies should assume complementarity rather than replacement. (Earlier HL7 versions are historical context only and are not a basis for new integration work.)
FHIR: resources and REST APIs for modern healthcare applications
FHIR (Fast Healthcare Interoperability Resources) is the modern HL7 standard for healthcare interoperability. Instead of messages only, FHIR defines resources — Patient, Encounter, Condition, MedicationRequest, Practitioner, Task and many more — as discrete, addressable units of clinical and administrative information.
These resources are exposed through REST APIs using familiar web mechanics: an application can read, search, create or update a resource over HTTPS and receive structured JSON. That makes healthcare information far more accessible to applications than a proprietary export or a nightly file drop.
The practical consequence is that a new application no longer needs a bespoke integration for every data need. It needs authorised access to a defined set of resources.
- Resources: standardised, granular units of healthcare information
- REST APIs: read, search and write over ordinary web protocols
- Profiles: national or project-specific constraints on resources
- Versioned, testable, and friendly to modern software tooling
FHIR should be understood as an interoperability standard, not as a workflow solution. It defines how information can be represented and requested. It does not define who is responsible for a task, when it is due, or what happens when it is blocked.
ISiK: German hospital interoperability specifications built on FHIR
ISiK (Informationstechnische Systeme im Krankenhaus) is the German specification framework that makes FHIR concretely usable in hospital information systems. It exists because a standard alone leaves too much room: two vendors can both claim FHIR support and still be incompatible in practice.
ISiK is therefore more than 'a FHIR API'. It consists of standardised interoperability specifications that use FHIR resources together with defined hospital use cases for information exchange between hospital information systems and other applications. It specifies profiles, required capabilities and expected behaviour, so that third-party applications can rely on defined capabilities and expected behaviour when integrating with an ISiK-conformant interface.
The ISiK Basismodul (base module) covers the fundamentals almost every application needs — patient administrative data, encounters/cases, and basic search and read access. Further modules extend this into areas such as medication, documents, appointment and care information.
For hospitals, ISiK is what turns 'our KIS supports FHIR' into a plannable integration statement. For hospital IT vendors and KIS providers, it defines a common baseline that can reduce project-specific interface work.
- FHIR standard
- ISiK profiles
- Defined use cases
- KIS interfaces
- Applications
KIS, KAS, ISiP and MIO: the terms behind the acronyms
German hospital IT discussions rely on a set of terms that are worth separating precisely, because they describe different layers of the same landscape.
- KIS (Krankenhausinformationssystem): the hospital information system — the primary system of record for administrative and clinical data
- KAS (Klinisches Arbeitsplatzsystem): the clinical workplace system used by physicians and nurses for documentation, orders and results at the point of care
- ISiP (Informationstechnische Systeme in der Pflege): the equivalent specification effort for IT systems in nursing and long-term care, extending interoperability beyond the hospital walls
- MIO (Medizinisches Informationsobjekt): standardised, semantically defined medical information objects — such as structured medication or immunisation information — used to make specific content interoperable rather than only its transport
KIS and KAS describe systems. ISiK and ISiP describe interoperability specifications. MIO describes standardised content. Mixing these levels is a frequent source of confusion in requirement documents.
The German digital-health infrastructure: gematik, TI, KIM, TI-Messenger, ePA and E-Rezept
gematik is the organisation responsible for the German Telematikinfrastruktur and for specifying and approving central applications and components within it. gematik shapes major parts of the national digital-health ecosystem — but it does not operate every interoperability standard in existence, and HL7 and FHIR are international standards developed outside it.
The Telematikinfrastruktur (TI) is the protected national network for the German healthcare system. It connects authorised participants — hospitals, practices, pharmacies, payers — and provides identity, security and the platform on which national applications run. Its purpose is secure, standardised exchange of healthcare information between verified parties.
KIM (Kommunikation im Medizinwesen) is the TI service for secure, formal message exchange: an authenticated, encrypted email-like channel used to send documents such as discharge letters or referral information between authorised healthcare participants.
TI-Messenger complements this with real-time messaging for short, organisational and professional communication between healthcare participants — closer to a secure chat than to formal document exchange.
The ePA (elektronische Patientenakte) makes patient-held records available across care settings. Its practical value in a hospital depends not only on technical access but on integration into the KIS/primary system and into everyday workflows such as admission and discharge. Access alone does not create usable clinical context.
The E-Rezept matters for hospitals mainly at the transition from inpatient to outpatient care: discharge medication has to be prescribed, obtainable and reliably dispensed after the patient leaves — discharge, medication, transition to outpatient care and pharmacy form one continuous chain rather than separate steps.
- TI / KIM / TI-Messenger → secure healthcare communication and information exchange
- HL7 / FHIR / ISiK → interoperability between healthcare and hospital information systems
- ePA / E-Rezept → national applications built on that infrastructure
- Operational applications → turn interoperable information into coordinated action
These layers are not interchangeable. KIM and TI-Messenger move messages between people and organisations; ISiK and FHIR make system data usable by applications. And communication is not workflow orchestration: even with secure channels in place, hospitals still need a way to coordinate tasks, responsibilities, blockers and timing.
Why discharge management is the clearest test of interoperability
Discharge is unusually demanding because it pulls information from almost every part of the hospital, and then from outside it. A single discharge may depend on the HIS, medical documentation, nursing, medication and pharmacy, case management, social services, post-acute care, transport and external healthcare providers.
Standards make that information exchangeable. They do not, by themselves, make the discharge happen. The operational challenge is a chain that no single standard covers end to end:
- Data
- Tasks
- Responsibilities
- Blockers
- Timing
- Action
This is exactly where interoperability becomes operationally valuable — and where its limits become visible. Available data plus an unassigned task still equals a delayed discharge.
WardPilot: an operational layer on top of existing HIS systems
WardPilot follows the principle already stated in its architecture: we do not replace your HIS — we orchestrate on top of it. The hospital information system remains the system of record; WardPilot adds the operational layer those systems were never designed to cover.
Relevant information is consumed from existing systems through HL7 and FHIR REST APIs, and turned into shared operational state: who owns which discharge step, what is blocking it, and how ready each patient actually is.
This is an architectural stance, not a compliance claim. WardPilot does not assert ISiK, gematik, TI or KIM certification, and interoperability capabilities always depend on what a specific hospital's systems and interfaces provide.
- Existing HIS
- HL7 / FHIR / APIs
- WardPilot
- Tasks, blockers, responsibilities
- Operational visibility
- Predictive operations
From interoperability to Hospital Operations Intelligence
Once structured operational data exists — not just clinical records, but task states, blockers, resolutions and timings — hospitals can begin to see patterns that were previously invisible.
- Open discharge tasks across wards
- Unresolved blockers and who they sit with
- Workflow bottlenecks in the discharge chain
- Recurring causes of delay
- Discharge readiness per patient
- Delayed-discharge risk
- Expected rather than only planned discharge timing
- Capacity implications for bed management
- Interoperability
- Structured data
- Integrated workflows
- Operational visibility
- Analytics
- Predictive discharge management
- Hospital Operations Intelligence
Interoperability is the foundation of this progression, not its conclusion. Standards make information available; operational systems turn that information into coordinated action.
HL7, FHIR and ISiK: common questions
Turn interoperable data into coordinated discharges
WardPilot gives hospital teams a shared operational view of discharge workflows, open tasks and post-acute coordination – on top of the existing HIS, not instead of it.