INTRODUCTION
Gone are the days when an admin “pulled your chart” when you visited the doctor. Today, a visit to the doctor often looks like this: the doctor types while speaking with you. This introduces a whole new set of questions: How much time is the doctor spending with you vs. doing documentation? Did the doctor (or scribe) capture the depth of your information correctly, or just a summary?
The problem is compounded when you go to an emergency room or specialists outside of your doctor’s practice, who most likely do not have access to your primary doctor’s medical records. You are stuck repeating the same background information to every doctor you visit.
So, what can Health and Healthtech organisations, i.e. those responsible for implementing the health IT systems that we rely on, do to reduce the inefficiencies inherent in the current environment?
BACKGROUND
Previously, health providers as well as the software companies that serve them focused on the digitalisation of medical records for single organisations. In the US, some of this focus can be attributed to the HITECH Act of 2009, which incentivised the implementation of electronic medical records (EMR) in hospitals and physician practices; however, the notion of communication between health providers was all but missing. The Health Information Exchanges (HIEs) created as part of the HITECH Act were supposed to be the first step in implementing data exchange between hospitals, but the HIEs were only regional, and participation was not mandated, leading many organisations to not participate.
More recently, with the passage of the 21st Century Cures Act of 2016 in the US and the European Commission adopting the Recommendation for a European Electronic Health Record exchange format, greater focus is being put on interoperability and the availability of data to the individual patient.
CHALLENGES
Of course, there are standards, most prominently Health Level 7 (HL7) and Fast Healthcare Interoperability Resources (FHIR), which are intended to ease integration and interoperability between health software. These standards define what the data format should be, and – in the case of FHIR – how health data should be transmitted between software products, specifying the use of standard APIs.
The problem, with HL7 in particular, lies in the implementation: many of the major EMR vendors have their own approach to these standards, resulting in less-than-perfect methods for integrating between those vendors.
In addition, while these standards dictate the format and integration method of the data, what’s missing is where they should integrate. This leaves either the use of the few existing HIEs or point-to-point communication between healthcare providers.
With EMR implementations now being pervasive, and standards being available for integrating between EMR providers, we should be able to provide patient-level health information to the doctor and the patient, regardless of which doctor or provider is being visited. In the following, I will examine three approaches that health software companies can take to support the interchange of health data between provider organisations to get that data into the hands of patients.
APPROACH 1: INTEGRATE WITH AN EMR VENDOR AND THEIR HEALTH INFORMATION EXCHANGE
Major EMR vendors offer their own HIE solutions to providers and patients using their software. Here, patients and providers get access to the patient’s health information, regardless of the doctor they visit, as long as those doctors use the same EMR software.
This has some distinct advantages, especially for the patient. As a patient, I am able to log into my primary physician’s patient portal and see all my data collected by that doctor as well as the data entered by any other doctor who uses the same EMR software as my primary physician.
Likewise, my physician is able to see the results from my visits to other doctors or hospitals, including conditions, current and past medication lists, physician notes and discharge summaries.
For health software companies, integrating with the handful of EMR providers offers some distinct advantages. By integrating your software with some of the major vendors, you allow your software to be used by the majority of patients.
The problem with this approach is that the major vendors are not necessarily open to software providers directly connecting with their software. While they offer integration APIs and make their documentation (somewhat) available, their integration documentation is largely aimed at their customers, not third parties.
The solution for many software providers is twofold:
- Write your software around HL7 and FHIR
- Utilise an EMR integration engine
The first step for any organisation looking to integrate their health data with the patient’s data in the EMR is to write their integration APIs in a way that utilises HL7 for the data format and FHIR around the data format and APIs. While this may be obvious, many companies don’t think about external integration and interoperability when they design their applications. However, this really should be part of the architecture from the beginning.
The second step is to utilise an EMR integration engine. There are many of them in the market today, and all of them provide some integration with the major EMR vendors.
APPROACH 2: HIES AND HIE NETWORKS
As mentioned above, the first HIEs were geographically based, i.e. groups of providers from a given region or geography would come together and agree on how to share their data. They were frequently sponsored by either the providers themselves or by state governments. These HIEs had to develop everything from scratch, including decisions on how to share data, what data to share, or how to match patients between providers.
For patients, this type of integration still (somewhat) excludes them. While their data is shared by the various health providers, they themselves are still required to log into multiple provider EMRs in order to get access to their data.
For third-party software vendors, this approach still requires them to integrate with each EMR vendor in order to connect to patient data (see Approach 1).
The solution for many software providers is to connect to an interoperability framework like Carequality, which gives software “implementers” a standard way of communicating with each other. While utilising HL7, it goes beyond that in providing software vendors with a way of actually exchanging the data itself, without having to resort to point-to-point connections.
When Carequality is combined with the CommonWell Health Alliance, which provides a connection between software vendors and not just the definition of that connection, health software vendors are enabled to have their software interoperate and exchange data with each other.
APPROACH 3: POINT-TO-POINT INTEGRATION
Similar to the first approach, this one requires health software providers to reach out to each organisation they want to integrate with and negotiate access to their data using HL7 and/or FHIR. However, instead of reaching out to the EMR vendors, this approach requires negotiating with each healthcare provider about getting access to their EMR.
An example of this can be seen in the approach of major personal health record (PHR) vendors. By using HL7 CCD (Continuity of Care Document), PHRs can download the data from the EMR and present it to the patient.
This is a useful and convenient solution for patients, as they now have one place to find all their relevant health data. For the implementing software company, the disadvantage is that they not only need to know where to get the data from each vendor’s software, but they also have to reach out to individual health systems in order to gain access to their data. While the mechanisms for doing this have been standardised, agreements with each provider still need to be found.
CONCLUSION
Even though we live in an age where data exchange has become ubiquitous, data interchange in the healthcare sector still proves to be a challenge. To add immense value, health software companies must look not only at the best technical ways to transmit health information but should also consider the best and most comfortable solution for their end users: patients, doctors and medical professionals in hospitals and other institutions.