Written By Michael Thomas
In order to achieve health system interoperability, we need to identify and address the challenges that create barriers to reaching it. Although some of these obstacles can be categorized as “the obvious”, there are just as many that aren’t so distinct. Each one derives from one or more phases of the system development life cycle and in many cases aren’t easily rectifiable. For example, the fact that a simple CT scan can produce 10GB of raw data creates a difficulty in itself. The issue isn’t so much the amount of data but instead is storage. Another important hindrance to note is from the legal perspective. State laws vary as when it comes to the handling and sharing of patient information. In itself, this is a complex challenge but once you include federal laws and regulations, our struggle for interoperability remains a tough task.
Listed in the table below, you can see many of the challenges to interoperability we face. Albeit a strenuous task, with an unforgiving effort level and improved provider collaboration, interoperability can be accomplished.
Table 1: Challenges to Successful Interoperability
Interoperability Best Practices
In the process of developing and adapting new and legacy systems to interoperability, some best practices have been identified. The application of these practices by providers during requirements gathering, system development and upgrade phases will make interoperability much more achievable. The key may be the implementation of Data Governance. A well spelled out, closely maintained standard in conjunction with Master Data Management and Data Stewardship will put us on the right path. With these practices at the foundation, interoperability is even more achievable once we include and apply the remaining identified best practices listed below in Table 2.
Table 2: Interoperability Best Practices
Simplified Health Integration Pattern of FAST HEALTHCARE IINTEROPERABILITY RESOURCES (FHIR)
FHIR is an integration pattern that incorporates a toolset that is designed specifically to support the unique healthcare needs for electronic data exchange and information modeling standards. It consists of a collection of resources, standard describing data formats and a public API used for exchanging electronic health information. Some of the many relevant patient care elements included in FHIR are the patient, practitioner, prescribed medications, conditions, and adverse reactions. FHIR is able to quickly locate the exact data being requested via these resource elements. Additionally, national standards such as, LONIC for laboratory values and RxNorm for medications, are used to manage the data. The primary goal of FHIR is to provide health care providers and any other authorized person(s) access to health care records on different devices, such as computers, tablets and smartphones. It also supports medical app offerings that are integrated with existing systems.
By offering discrete data resources as a service, FHIR is an alternative solution for a document-centric approach. The implementation of FHIR can be fairly quick and easy because it is designed using web standards for data representation. These standard technologies include HTTP based RESTful protocol, HTML and CSS for user interfaces, OAuth for authorization,0 XML or JSON for data representation, and ATOM for database query operations.
Features of FHIR: FHIR is a granular way to exchange electronic health data without the complex workflow of the traditional HL7 standard. The modular approach (plug and play) of FHIR makes it easier for developers to create apps without significant coding. With apps being easier to develop, innovation can arise from a broader base. FHIR allows the exchange of data with any application that utilizes the public API. The core process mainly focuses on reference and conformance implementation as well as connections. FHIR uses RESTful approach which removes overhead like SOAP and follows the 80/20 rule. This means hitting 80% general use cases rather than hitting the remaining 20% of exceptions. Apart from technical factors, it addresses some real market requirements and allows people to make and save money by offering medical device integration, mobile healthcare applications, and flexible and custom workflow.
Why FHIR: FHIR has defined the core clinical record keeping features that focuses on what is important for the provider and the patient. Those features include general information (allergy, conditions, family history, and procedures), medications and immunizations, diagnostics, and device interactions. Each clinical feature is mapped to a unique set of related elements. For example, the patient condition is mapped to: stage, evidence, location and related item allowing the system to associate important information to the patient condition. Whereas, medication is mapped to package, content, product and ingredient. The HL7 Work Group invested significant time and energy to tailor FHIR specifically for the healthcare provider and the patient. Although much of the work on FHIR has concentrated on EHRs, the same technologies can be applied to patient-centric apps, such as the Personal Health Record (PHR) to share specific information with the patient at the right time. This allows for an app to be designed to remind the patient to complete physical therapy exercises during post-surgical rehabilitation or help to remind a patient to comply with a prescribed medication regiment.
If FHIR were to become the national standard using the public API, it would dramatically accelerate health interoperability nationwide. In fact, the ONC JASON Task Force has made the recommendation to establish and maintain public API for this very use. The standard of FHIR explores new efficiencies to improve data quality at the point of care, improve healthcare delivery, and reduce bottom line costs.
Implementing FHIR: The implementation of FHIR uses a variety of web technologies. Although the implementation is simple, great care must be used to ensure the integrity and security of patient-related data exchange between healthcare facilities. If VA publishes and offers an interface to send rich and informative data to a partner, then it’ll help developers save time from creating a new interface from scratch. Specifically, developers will be granted appropriate permissions in order to have direct access to data. On the other hand, developers can implement this by writing code in Java, C, C#, Corepoint and Iguana.
FHIR supports data exchange over a wide range of systems that center on patient care, such as the EHR/PHR, and the associated decision support and document sharing applications. The EHR/PHR offers a RESTful API, which allows end level users to access their own medical record via their personal mobile device or web client. Document sharing involves accessing a collection of documents associated with or contained in a patient record. The most popular framework used for document sharing is IHE (Integrating the Health Enterprise), which supports XDS (Cross Enterprise Document Sharing). FHIR system is also used to implement decision support into a clinical system. Clinical decision support may be used for: checking drug-drug interaction, early warning for patient health, suggesting commonly missed diagnostic data, and identifying candidates for alternative treatment.