
Our cases
Clients about us
Healthcare interoperability
HL7 v2, HL7 FHIR R4, IHE, ISiK and MIO. What actually moves between the hospital system, the practice system, the lab and the ePA.
Why interoperability decides whether a project works

Healthcare interoperability means the receiving system understands the data clinically. A PDF that only a person can read is not an exchange. The hospital system, the practice system, the lab, radiology and PACS stay separate systems. The interface translates admission, order, result and document. If the shared structure is missing, the workflow stops even when each application runs on its own.
In Germany the profiles are not a free choice. HL7 v2 still carries messages between hospital systems. HL7 FHIR R4 carries ISiK and the KBV medical information objects. The specifications are published by HL7 Germany. What is mandatory in hospital is on the gematik ISiK page. The MIO catalog is kept by the KBV.
Where the exchange breaks
Four breaks explain most standstills. They are not defects of the individual application.
Patient identity
The case number, the insurance number and the subsystem id are not the same identifier. Without a map the lab creates a second patient. PIX and PDQ help only when both sides know the same domain.
Two formats
HL7 v2 and HL7 FHIR R4 do not replace each other. A lab order often travels as a v2 message. The ISiK interface in the hospital speaks FHIR. Middleware has to keep both, not drop one of them.
Terminology
An in-house lab code is silent for the neighbouring system. LOINC, SNOMED CT and ICD-10-GM are the terminologies the specifications name. Which one is mandatory is stated in that profile, not in a general list.
A document without structure
A finding as a PDF stays readable and is not computable. For defined ePA content the object is a MIO, a FHIR bundle. The file alone does not meet that rule.
A project from our work
Connect with students for live 1-on-1 college insights and tours

EXPERTISE
Education
TECHNOLOGIES

Our work on integration projects
The interface, not a new hospital system
We build the interface and the middleware between systems that already exist. The hospital system stays with hospital software. Imaging sits with PACS, the lab with laboratory software.
The interface, not a new hospital system
We build the interface and the middleware between systems that already exist. The hospital system stays with hospital software. Imaging sits with PACS, the lab with laboratory software.
Profile and test
We map to the profile the other side requires: the German base profile, ISiK or a MIO. Acceptance runs against the vendor test system. gematik’s ISiK confirmation is a separate procedure, not a side effect of the mapping.
Running the interface
Messages that are not acknowledged stay visible in a queue. A silent loss is the most common operational failure. The standards are introduced on healthcare IT consulting.
Hospital, practice, record, FHIR
The record integrations are listed under EHR integrations and in the integration overview. FHIR interfaces are on FHIR API integration. The telematics connection is a separate page. The existing service page remains at interoperability solutions.
Further system interfaces
Named products have their own pages. Those pages describe the connection to that system. They do not replace the German mandatory standard. 75health, Aba Ehr, Abelmed, Advancedehr, Advancedmd, Allscripts, Altapoint, Altera Digital Health, Amazing Charts, Aprima Medical Software, Athenahealth, Carecloud, Centralreach, Charm Ehr, Chartlogic, Compulink Healthcare Solutions, Cpsi, Curemd, Drchrono, Dricloud, E Mds Chart, E Med Practice, E Medsys, Eclinicalworks, Ehr, Ehr 24 7, Elation Health, Epic Systems, Ethomas, Evident, Greenway Health, Harris Caretracker, Iknowmed, Insync Emr
Further system interfaces, continued
Intelligent Medical Software, Ipatientcare, Juno Emr, Kareo Clinical, Medgen Ehr, Medhost, Medicspremier, Meditech, Medworxs Evolution, Micromd Emr, Netsmart Technologies, Nextgen Healthcare, Nexus Clinical, One Touch Emr, Oracle Health, Oscar Emr, Patientclick, Practice Ehr, Practice Fusion, Praxis Emr, Prognocis Emr, Relimedemr, Sevocity Ehr, Simplepractice, Springcharts Ehr, Theraplatform, Totalmd, Ultra Charts, Veradigm, Vista, Vitera Intergy, Webedoctor, Wellsky, Wrs Health We do not promise that every one of these systems speaks the same profile.
Interfaces to the hospital system, the practice system and the lab
The path of one order. Each line is a hop. None of them covers the others.
Register the patient in the hospital system
The hospital information system assigns the case and the stay. Lab, radiology and the record have to recognise that identity. A second local number without a map creates duplicates.
FormatHL7 v2 ADT
Register the patient in the hospital system
The hospital information system assigns the case and the stay. Lab, radiology and the record have to recognise that identity. A second local number without a map creates duplicates.
FormatHL7 v2 ADT
Order to the lab
The order from the hospital system to the LIS carries the test and the specimen. HL7 v2 is the usual path for this in German hospitals. A FHIR order replaces that message only when both sides have agreed it.
FormatHL7 v2 ORM or OML
Result back
The lab returns the result to the ordering system. Values need a terminology the receiver knows. LOINC is the usual path for lab observations when the profile requires it.
FormatHL7 v2 ORU
Image and report
RIS and PACS exchange the order and the image. The image format is not the report message. Both channels are tested separately.
FormatOrder plus image
ISiK inside the hospital
Subsystems in the hospital read and write patient and movement data over the FHIR interface of the ISiK modules. That is exchange inside the hospital. It is not access to the telematics infrastructure.
FormatHL7 FHIR R4
The practice system writes to the ePA
The practice system places defined content into the electronic patient record as a MIO. The bundle follows the KBV specification. A PDF in the same place is a different object.
FormatMIO
Middleware maps
Middleware translates identity, code and message. It does not keep its own patient register as the source. The source stays the leading system, hospital or practice.
FormatMapping
Test against the other side
Each interface is run against the vendor test system, including errors and retries. For ISiK the gematik confirmation procedure is added. A passed test of one message does not cover the others.
FormatAcceptance per channel
Standards: HL7 v2, FHIR and IHE profiles
The standard, what it describes, and whether it is mandatory in Germany. ISiK table as read on the gematik site on 6 October 2026.
- No ranking, only the standard
- Mandatory only where statute or the specification says so
- Another profile does not satisfy the requirement
Timeline of a connection
The ranges are planning corridors for a known counterpart with a test system. They are not a quote and not a promised date. The ISiK confirmation runs at gematik and is not included here.
One channel
Weeks
one known v2 profile
- ADT, order or result, one direction
- The vendor test system is required
- Not a few days
- Character set and version are part of it
- No fixed price in this table
Several systems
Per channel
hospital, lab, radiology, practice
- Each hop is counted on its own
- The lab does not replace imaging
- Practice and hospital are two sources
- Identity is agreed once and tested per system
- Middleware maps, it does not invent a profile
ISiK
Separate procedure
gematik confirmation
- Stage 3 since 1 July 2025
- Stage 5 published, date still open
- Fee under the telematics fee regulation
- SNOMED CT licence for the implementation
- Not inside the weeks of the message channel
What clients say
INDUSTRY RECOGNITION

Luklabs
Acting CEO
The team is smart, creative, nice, calm, and professional, and they are problem solvers.
WTT Solutions paid attention to details. Most of their first iterations were very close to our intended designs. Consequentially, we didn’t have to do a ton of revisions in the QA phase.
I greatly enjoyed working with them.

ISiK and MIO: what is binding in Germany
Two duties are often mixed. ISiK applies to information systems in the hospital. MIOs apply to defined content of the electronic patient record. The source is the gematik portal, table as read on 6 October 2026.
ISiK stage 3
Base, document exchange, medication, appointment planning, and vital signs with body measurements have been mandatory since 1 July 2025. gematik ends that duty by a formal withdrawal. The table does not yet give that date.
Stage 5 has no date yet
Stage 5 was published on 1 July 2025. The latest date for mandatory implementation is not set. A vendor with a valid stage 3 confirmation receives an extension once that date exists and does not confirm again.
What has been withdrawn
Stage 4 and the stage 2 modules were withdrawn on 1 July 2025. Stage 3 security is not set as normative in the table. An old certificate does not replace the current duty.
KBV MIOs
Medical information objects set syntax and semantics for ePA content, as FHIR R4 XML. The vaccination record, the maternity record and the child examination record are examples. The current catalog is at the KBV, not in this text.
Not the same procedure
An ISiK confirmation is not a MIO implementation and not a connection to the telematics infrastructure. Each of the three duties has its own specification and its own acceptance.
ePA and the telematics infrastructure
01
Access is not content
The telematics infrastructure is the access. The ePA is the record. ISiK is exchange inside the hospital. Three layers, three specifications. Access is described on the telematics page.
02
What goes into the record
Defined clinical content goes in as a MIO. Documents that are only displayed stay documents. The primary system must write the current MIO version and be able to read older versions.
03
Hospital and practice stay the source
The record is not the leading hospital system and not the practice system. It receives what the specification provides. It does not become a second patient record beside them.
04
Apps at the record
An application that exchanges data with the ePA uses the specified interface. It does not invent its own bundle. Whether it is also a DiGA is decided by the BfArM, not by the interface.
05
The page for access
Connectors, cards and telematics deadlines are on connection to the telematics infrastructure. This page does not repeat them.
06
No promise that every write succeeds
We do not promise that every record entry arrives. An insured person’s objection, a missing permission and a module that is not released rightly stop the write.

Typical pitfalls in integration projects
The same eight mistakes return in hospital, lab and record projects. They are a checklist here, not a charge against one product.
Two patient numbers
Case number and insurance number are not mapped. The subsystem creates a second patient. The result is then attached to the wrong identity.
Version and character set
One side sends HL7 v2.3, the other expects 2.5. Or UTF-8 meets another character set. The message arrives and cannot be read.
Z-segments
Vendor-specific segments carry the actual information. The other side ignores them. The log still shows a successful send.
The wrong FHIR profile
A profile from another market, such as US Core, hits an ISiK interface. The resource is valid FHIR and still not the required German profile.
A local code instead of a terminology
The lab value carries an internal key. LOINC, SNOMED CT or ICD-10-GM is missing although the profile requires it. The receiver cannot place the value.
PDF instead of a MIO
A readable document is stored where a MIO bundle is expected. Display works. Further processing does not.
No acknowledgement
The send is not acknowledged, and nobody sees the queue. The result is treated as delivered and never arrived.
A test without the procedure
A successful test against an in-house mock does not replace the vendor test system or gematik’s ISiK confirmation.
Which profiles count in Germany
The target is the profiles published by HL7 Germany, gematik and the KBV: German base profiles, ISiK and MIO on HL7 FHIR R4. IHE profiles XDS, PIX and PDQ remain relevant in individual networks beside them. A profile from another market is not a substitute. The ISiK status is kept by gematik, the MIO catalog by the KBV.



