The experience of countries that have created an interoperable national health system, such as the United States and England, conclude that government regulations play a crucial role in changing the approach to healthcare data management.
Germany, too, has been diligently working on constructing an interoperable healthcare system for several years. The country has made progress and has achieved significant results. The Federal Ministry of Health in Germany, or Bundesministerium für Gesundheit (BMG), established the national digital agency to address legacy healthcare systems.
In this article, we’ll cover how the national digital agency addresses the interoperability challenge by creating a standard connecting disparate systems and ensuring meaningful and effective use of healthcare data.
Gematik and Its Role in Popularizing FHIR in Germany
Who is in charge of interoperable healthcare systems in Germany?
Recognizing the importance of interoperability, the German government introduced several legislative measures to promote it. The BMG tasked Germany’s national digital health agency, Gematik, with developing the telematic infrastructure for German Healthcare.
Gematik’s tasks list include:
- defining and enforcing standards for interoperability;
- coordinating digital services;
- supporting collaboration between healthcare institutions.
By setting ISiK FHIR compliance standards, Gematik lays the groundwork for interoperability in the German healthcare system, which is the ability of different information systems to access, exchange, integrate, and use data in a standardized manner. Central to Gematik’s efforts is the implementation of the FHIR standard.
Why FHIR?
Health Level Seven International created the Fast Healthcare Interoperability Resources (FHIR) standard to address the need for the representation, storage, interoperability, and exchange of healthcare data. It is used worldwide to establish interconnected healthcare systems in the Netherlands, Australia, Canada, France, the US, the UK, Denmark, Estonia, and others.
The Interoperabilität zwischen informationstechnischen Systemen in Krankenhäusern und in der pflegerischen Versorgung (ISiK) regulation, introduced under § 373 of the Social Code Book Five (SGB V), mandates the use of standard interfaces for data exchange in healthcare settings, and Gematik’s FHIR ISiK Implementation Guide (ISiK-Basismodul) defines these interfaces.
The Role of ISiK in German Healthcare
One of the most significant challenges in German healthcare is the prevalence of outdated legacy systems, which makes data exchange between different facilities extremely difficult. Previous versions of standards by HL7, compared to FHIR, were unable to support the required level of interoperability and ensure that data is exchanged securely and accurately, representing the exact meaning intended by the system that created the message.
FHIR is an advanced, future-proof data standard that provides APIs for smooth and secure data exchange. Based on popular web technologies and standards like HTTP, JSON, and XML, it is a developer-friendly standard allowing swift integration with existing healthcare systems, making it a perfect solution for creating an interoperable national healthcare system.
The ISiK Project: Overview
The ISiK project standardizes interfaces using FHIR resources, enabling media-free data exchange across diverse hospital systems. ISiK-compliant solutions must include a RESTful API, an FHIR data store, authentication mechanisms, and an integration layer.
ISiK Basic Module
Gematik outlines the FHIR resources designed for health data exchange, where primary systems transfer data objects via a REST-based API. The “ISiK Basic Module” specification, which guides manufacturers, covers a broad range of use cases.
Key cross-use case functionalities supported by the ISiK basic module include:
- Searching for case information by case number
- Searching for patients based on demographic criteria (name, address, date of birth)
- Querying a patient’s insurance information
- Retrieving all diagnoses of a patient
- Locating a patient’s current stay.
Additionally, the ISiK basic module can be combined with other profiles and standards to implement the following use cases:
- Integrating mobile measuring devices without their server infrastructure to transmit patient and case information to or from the primary system (e.g., by scanning a barcode)
- Integrating rarely used subsystems for the interoperable transfer of patient data into the primary system
- Integrating decision support systems
- Standardizing the approach for mass data transfer between systems
- Integrating web-based applications from third-party manufacturers into primary systems (“external call”).
The “ISiK Basic Module” provides a framework for key functions like patient searches and insurance queries. It supports integrating systems and devices, enhancing healthcare interoperability and efficiency.
The deadline for the ISiK interfaces was June 30, 2023.
Who Must Ensure ISiK Basic Module Compliance?
According to Section 373 SGB V, the Gematik confirmation procedure for interoperable data exchange in hospital information systems (ISiK) is mandatory for hospital software products. This process ensures that systems meet the necessary interoperability standards.
Gematik supports manufacturers with the test and simulation environment, Titus. This tool helps ensure ISiK conformity before the confirmation process.
Titus: Testing Telematic Infrastructure
Titus is the test and simulation environment for manufacturers developing primary systems that are compliant with the Telematics Infrastructure. It mimics real-world systems at external interfaces, enabling thorough application or component preparation and testing.
Key Features:
- Latest Specifications: Titus conforms to Gematik’s newest specifications, offering centralized interfaces for primary system applications supported within the telematics infrastructure.
- Early Interoperability Testing: Manufacturers can verify interoperability between components early in development, minimizing the need for error corrections during confirmation and deployment.
- User-Friendly Interface Management: Easily manage, configure, and evaluate communication between your primary system and the test module via a web browser.
The ISiK4PS test module enables testing and confirming ISiK’s implementations according to specified guidelines for interoperable data exchange between hospital information systems.
ISiK Compliance Challenges
German legislation mandates the implementation of basic ISiK FHIR for hospitals, yet many hospitals have been slow to adopt it due to the following factors:
- Lack of enforcement: There are no penalties for ISiK’s non-compliance.
- Legacy systems: Many hospitals rely on outdated formats and old tech stacks.
- Limited resources: Transitioning to modern systems demands significant effort and investment.
Still, the healthcare market is evolving, with manufacturers worldwide eager to develop cutting-edge solutions for patient portals, hospital information systems, and payer solutions.
Clinicians and patients have become more demanding when interacting with e-health systems, pushing for modern technologies that offer faster, more convenient, and more efficient solutions than traditional software approaches in Germany.
The FHIR standard enables migration to modern tech stacks while ensuring compliance with the evolved demands of German healthcare, such as:
- Interoperability: Seamless data exchange between diverse healthcare systems.
- Compatibility: Works well with a wide range of applications and platforms.
- Continuity: Ensures consistent data and process flow.
- Integration with Legacy Systems: Smoothly connects with legacy systems without disrupting functionality.
How to Become ISiK Compliant
Healthcare organizations looking to certify their systems, like patient portals, medical information system portals, or mobile application servers, to meet Gematik’s ISiK profile requirements have two options. They can either entirely overhaul their existing systems, which is usually impractical, or use an FHIR facade or a native FHIR server.
Option 1: FHIR Facade
A FHIR facade receives FHIR requests via an API, translates them into a different internal structure or format, processes them, and then converts the results back to FHIR for external use.
This illustration shows an FHIR facade in front of the solution’s ecosystem, set to expose an ISiK-compliant FHIR API.
Advantages
This approach allows a system to present an FHIR interface to the outside systems, even though it doesn’t store data in an FHIR format.
Disadvantages
As illustrated in the scheme, a backend requiring an FHIR API often operates as an ecosystem composed of numerous systems with customized workflow whose disruption can damage the ecosystem’s functioning. Moreover, a facade has limited functionality compared to a native FHIR solution. For example, a facade will not support all FHIR operations for terminologies and resources.
Though the facade has limited functionality, it can help achieve ISiK certification, satisfy the ISiK compliance requirements for FHIR API implementation, and enter the German healthcare solutions market. However, developing a facade is complex and requires domain expertise and a proven track record in building such solutions.
Real-World Implementations
Our team implemented an FHIR facade using the Kodjin FHIR server to provide real-time extract-transform-load functionality from the proprietary data for one of the largest TPA in Hong Kong. Additionally, we integrated a provider directory FHIR API with the existing data and processes, which allowed a third-party mobile application to connect seamlessly to the appointments FHIR API.
A FHIR Facade is a complex solution often used when implementing an FHIR server isn’t possible. However, a team of FHIR experts at Edenlab can create a practical solution that meets the specific requirements of any project that requires FHIR integration.
Option 2: FHIR Server
This approach offers full FHIR compatibility and is ideal for organizations adopting a more modern, FHIR-centric infrastructure.
This illustration shows the scenario of a verified and certification-ready solution – a FHIR server.
Advantages
The server is an out-of-the-box solution for those who require FHIR compliance. Our Kodjin FHIR server stores data in the FHIR format and provides a compliant FHIR API.
Disadvantages
All the systems involved in the workflows of the entire ecosystem can contain large volumes of data, which can be challenging to convert into an FHIR format.
Real-World Implementation
Our partners at Elation Health have successfully achieved certification by the Office of the National Coordination for Health Information Technologies in the US using the Kodjin FHIR Server and integrating two message brokers.
Kodjin’s uniqueness lies in its microservices architecture, meaning each service can perform its tasks independently. Services can be optimized based on workload needs, such as allocating resources between different microservices depending on a project’s needs.
Kodjin uses an event-driven approach to maximize performance and efficiency. Our server utilizes a powerful message broker, Apache Kafka, which ensures seamless communication between microservices. Kafka handles task queues, ensuring data creation and search processes are interconnected and efficiently managed.
Conclusion
By choosing an FHIR facade or an FHIR server configured to your specific needs and leveraging our expertise, your organization can achieve ISiK FHIR compliance. Our healthcare and FHIR experts will help you pick the right solution to satisfy your project’s needs and regulatory requirements.
Contact us to learn more about how we can help you navigate this process.
