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.
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 
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.
The interoperability of health information systems is much more important than most of us realize. The more we can do to help out the better. And it all starts with knowing more about the challenges the health system as a whole is facing right now.
WOW! I hadn’t the slightest idea that a CT scan can produce as much as 10GB of data! I can only imagine what kind of storage problems you could have when you have thousands of CT scans! Couldn’t this data have a smaller dimension?
That’s why there TONS of health IT positions dedicated to organizing and protecting that data!
Lack of IT education is one of the biggest challenges to interoperability. Unfortunately, hospital executives are often not considering anything else besides their hospital’s need. If they saw things from a larger perspective and focused on making things better for every hospital not just theirs, many good things would happen. And it is clear that executives should undergo some form of IT education so they are prepared for the many problems which will eventually arise. This should be mandatory in our day and age.
You’re right! Hopefully it will be one of those issues that resolves itself with education, like you said, and time.
I hate legal barriers! I mean, if people are trying to save life wouldn’t it be normal that everyone could contribute and make things simpler instead of more complex? It’s like we love putting roadblocks in front of useful things that others are doing. Instead of uniting, humankind is dividing.