Guest author Uwe Porwollik continues our series on interoperability with a blog post on the global IHE (Integrating the Healthcare Enterprise).
Our last blog post examined how the IHE initiative manufacturer neutrality in the healthcare system. IHE compliance means that medical devices and software that processes health-related information can be integrated into medical IT systems via “plug and play.” However varied the use cases may be for manufacturer-neutral medical devices and software, they are all based on the same formula for success: quick access to relevant information! The global IHE initiative achieves this objective with the interoperability cycle. The cycle ensures that IHE-compliant and easy-to-integrate products are produced. This means that for every medically relevant process a dedicated profile is created on the basis of which hardware or software manufacturers for medical diagnostics or treatment can ensure the interoperability of their products. But what do the different phases on the way to interoperability look like?
Definition of workflow descriptions
The IHE follows a process-driven approach. This is why the first phase of the interoperability cycle needs people who are involved in medical activities on a daily basis and who are well acquainted with the existing processes: doctors, healthcare providers, therapists and those who look after the administrative and technical side of the medical processes. They describe all the common use cases and workflow descriptions where medical information is generated, processed, stored, or provided using IT. An overarching IT infrastructure (ITI) is needed to formulate functioning medical processes. The processes described in the ITI form the basic infrastructure for exchanging medical information.
The Cross-Enterprise Document Sharing (XDS) profile, for example, describes how medical documents are exchanged. The Audit Trail and Node Authentication (ATNA) profile is fundamental, particularly in terms of data protection. It sets out the access and authentication processes for patient information. Patients are clearly identified using the Patient Identifier Cross-Referencing (PIX) profile. Only if a workflow is described as a separate process from the later products can universal IHE profiles emerge.
The following three profiles can be designated for the medical domains: Sharing Laboratory Results (XD-LAB) describes how lab results are shared. In the field of pharmacy, the Community Medication Prescription and Dispense (CMPD) profile provides information about the workflows involved in issuing and processing a prescription. In Cardiology, the Cardiac Cath Workflow (CATH) profile maps the processes for cardiac catheterization procedures and integrates demand, scheduling, imaging, storage, and viewing of cardiac catheterization examinations.
Search for “supporting” standards
The second phase is the turn of the manufacturers and developers. Which relevant standards are there on the market that can be used for the processes? Regardless of whether messages are transmitted using the HL7, DICOM, CDA or other standards, defining how a standard should be used for the respective process is still a requirement. Because in practice one HL7 message is not automatically the same as another HL7 message! The question of how whichever standard must be used correctly for each process is just one principle that needs to be defined during the interoperability cycle.
Development of technical specifications
In connection with the standards, technical specifications for IT systems are described in the third phase. These ensure that the defined workflows and processes are also technically supported. How should a blood pressure monitor, an X-ray machine, or an MRI scanner communicate so that it can exchange information with its environment in any system? The initiative is working with the manufacturers to define the technical requirements and architecture of the devices.
Software tests on Connectathons and Show Cases
While the first three phases are for the production of IHE profiles (guidelines for interoperability), the as a test phase ensures the smooth implementation and application of these profiles in IHE-compliant products. The word Connectathon is a combination of the words connect and marathon and it certainly lives up to its name. The annual event is like a huge five-day “LAN party,” where developers work flat out to prove the IHE conformity of their products. The test results are published transparently in integration statements and in a product registration. The reward for months of development work.
At international showcases, entire IHE ecosystems are presented to the public in phase five. The initiative demonstrates in its many presentations and training programs just how broad the service portfolio of IHE-compliant products is.
The objective: easy to integrate products
At the end of the interoperability cycle, phase six optimally consists of IHE-compliant products that can be easily integrated into unique and well-established IT infrastructures in hospitals and health insurance companies. On the one hand, beneficiaries include patients who can feel confident that in an interoperable environment all their relevant information is available for diagnosis or treatment purposes. On the other hand, clinical and healthcare staff can work with devices and software, on whatever interface and existing infrastructure, for optimal support in their daily work! Because IT interoperability doesn’t just mean electrifying analog processes, but creating the space to innovate in a multi-disciplinary healthcare system.
In the next blog post, you can find out how an international methodology is adapted to the German healthcare system with the IHE Cookbook.
- Part 1: What is IHE? Standard or Initiative?
- Part 2: Manufacturer-Neutral IT in the Healthcare Sector
- Part 4: The IHE Cookbook
About the author:
Uwe Porwollik, Partner eHealth. Business, sales and project success in the health sector.