openEHR is a non-profit tool for using open health data standards. openEHR has the potential to completely change the foundations of the healthcare system and its relationship to information technology. In openEHR, all EHR Information is an instance of the stable Reference Model.
HL7 FHIR is the latest technology from HL7, an international non-profit organization that streamlines global health efforts. Unlike previous standards, FHIR is a more advanced open-source health data collection model. It is much easier for developers to work with this platform. FHIR data and tools, based on the health model, provide interoperability at the local level.
“Electronic health records were supposed to do a lot: make medicine safer, bring higher-quality care, empower patients, and yes, even save money.”
— Fred Schulte and Erika Fry, Kaiser Health News and Fortune magazine
FHIR’s primary mission is to create a system-to-system (B2B) and system-to-application (B2C) nexus. The B2B part is essentially an information-based approach; the B2C part meets basic needs, facilitating the creation of state-of-the-art health system applications.
The main goal of openEHR is to solve the problem of durable and computable records in an open source patient management system. This is a long-term, and forward-looking challenge addressed through the use of platform architecture. openEHR itself only offers some elements of this platform. The platform itself must have terminology, drug databases, and service interfaces.
- One can define FHIR in terms of a library of “resources” and a technical approach of “profiling” and “extending” to support localization. You can read more about the terminology on the FHIR website. There is a “clinical modeling” layer located inside the FHIR XML.
- openEHR has extensive coverage of patient citizen information, and significant coverage of the clinical model domain. Besides, openEHR has limited API compatibility.
- FHIR has more API coverage. This is because coverage depends on what the format relies on. FHIR is a cutting-edge project that has done an excellent job of creating APIs for complex tasks.
The U.S. Department of Health and Human Services finalized the long-awaited interoperability access rules, focusing on driving interoperability and giving patients better access to their healthcare records.
FHIR And OpenEHR: How To Use “+ Or Vs.”
openEHR defines the complete architecture of the EHR platform for managing clinical data definitions. We need to figure out how to use the two projects and whether they are mutually exclusive within the same health care problem.
Let’s talk about how they work together. When choosing FHIR over openEHR, it is worth creating mappings between openEHR archetypes and FHIR resources to ensure technical implementation. This way, you can have an openEHR CDR and access it through FHIR.
If a medical provider wants to implement FHIR on top of the openEHR environment in addition to their interfaces, this will require some effort. There are two main ways. The first one is as simple as possible: it is the same as implementing an HL7v2 or CDA export channel from the system. We mean that for each FHIR + API resource, you need to create a unique interface and a server part that uses AQL to retrieve information from openEHR.
“The introduction of digital capabilities into the healthcare system will help significantly speed up all field processes through automation. All members to the processes will have access to information at all times, which will significantly save time in transferring medical data from provider to provider.”
— Vlad Medvedovsky at Proxet, custom software development solutions company
The second, more extensive approach is to create new “resource partitions” on a common FHIR communication platform. This approach’s main advantage is that it allows developers to communicate with openEHR in the FHIR style and using an FHIR application development approach. However, it is worth keeping in mind that the machine creates the interface content from the corresponding source model rather than FHIR’s resources.
FHIR Use Cases – Where Health Systems Can Use FHIR
The idea behind FHIR is to provide a set of resources. In turn, it should lead to the provision of fast and easy data exchange to support scenarios in the medical field. Let’s look at three basic FHIR use cases.
Personal Health Data
More and more patients want access to their medical records. Every year, the number of patients who use apps to collect health data increases significantly. In turn, this has led to the emergence of services such as management example of personal health records or the automatic addition of data to patients’ existing mobile device cards by medical providers. The timeframe for implementing such projects is concise compared to more traditional health system projects. The system must work in tandem so that patients and clients can connect to PHRs and EHRs from different medical providers, depending on their situation and location.
Sharing Medical Information
The exchange of medical data (test results, diagnoses, images from tests) can accelerate coordination of recovery significantly, saving a lot of time. Unfortunately, the IHE XDS standard does not support the REST interface or mobile devices. This, in turn, dramatically limits access to medical records from mobile devices. IHE has implemented FHIR integration with XDS to create a Mobile Health Documents profile. This enables you to use MHD to access the XDS repository built on top of the FHIR tools.
Decision Support
The digitalization of healthcare continues to evolve rapidly. At the same time, use of medical IT for decision support is becoming more prevalent. A significant benefit of electronic structured medical data records is automatically inputting information into business processes. FHIR supports everyday decision-making and interactions between different systems. This format can also provide continuous access to the information you need. This allows medical providers to work together to support decision-making.
Analytics And Business Intelligence
The top priority for developers is implementing an exchange of computable, actionable data between various medical IT services. This exchange is a prerequisite for digital transformation. In a healthcare system, this interoperability helps all parties get up-to-date information continuously. Custom software development solutions can be a useful tool for implementing the digitalization of medical data.
“I predicted that we would hear a lot of buzz about advances in artificial intelligence and machine learning. I expected to read headlines about shiny new solutions such as AI-driven transcription services and ambient listening technologies that would propel us to new health IT era with highly usable solutions that would help clinicians do their jobs better”
— David Lareau, CEO of Medicomp Systems of Chantilly, VA
Digital health departments face enormous challenges all the time. And even though the best efforts of all parties involved are being made, healthcare is lagging far behind other fields in implementation of automated data collection and analysis through digitalization.
Health information research is almost a solved problem at this point. Business analysts have been using SQL for decades.
Regarding the process of analyzing medical information, many data analysts expect to be able to create a relational data model. The concepts modeled in healthcare are suited to such a model. By default, FHIR provides a set of REST APIs you can use to explore medical records. However, the capabilities of these APIs are significantly limited right now. One can overcome this by going under the API and querying the data directly. The difficulty with the direct-query approach is that the information is likely stored in a non-relational format, so you will have to use more complex and less understandable SQL dialects to explore and retrieve this data.
There are other ways, but it is worth considering that several steps are required to build a simple interface for more comfortable use. In contrast to openEHR, a native query language called AQL has already been invented, providing a very close interface. Experts can seamlessly adapt to work with this language.
Deployed Solutions With OpenEHR
Googling ‘openEHR how to use’? Here is a possible solution. OpenEHR supports composition and specialization by providing the ability to adjust general models to more localized forms. In the openEHR forum and related technologies, the models being built stem from health care communities. In FHIR, the stated strategy is to build each FHIR resource as a model of the supernet of data found in legacy systems and directly address developers’ needs.
This leads to different results—FHIR models are directly used by developers but are unlikely to be easily reused in various technologies, such as generating user interface forms. It has tools to generate XSD, JSON, Xforms, and other formats that developers may need.
We also have a relatively extensive theoretical base for EHRs in openEHR. This will be important for the interoperability of clinical process deployed solutions in eHealth infrastructures.
Proxet is already able to provide software to improve the quality of an electronic open medical record. Staffed by experts and developers with years of experience, Proxet can safely and easily implement these technologies in your projects so they can be more successful.
