In a recent blog, the opinions of the JASON Report Part II with regards to CDA were analyzed. The review of CDA was lukewarm at best. However, the report did spend a significant amount of time talking about future possibilities. The main focus of the future possibilities was HL7 FHIR.
FHIR was discussed extensively in the report because JASON thought it lends itself well to the health IT vision which was stated as:
Focus on the health of individuals rather than the care of individuals.
Key to this vision is the establishment of a robust health data infrastructure that could also be used to enable a Learning Health System. But one major impediment that remains is the critical need for open APIs for EHR connectivity and to stimulate entrepreneurial ideas. One solution to this impediment is seen as the FHIR standard, which JASON sees as a “significant improvement over CDA.”
The JASON report describes CDA as a container for information. The problem with the container is that it is hard to sort out all the data in the container into usable chunks. FHIR solves this by organizing the data into smaller usable chunks called resources. These resources standardize the exchange of information as modular components.
Resources contain basic pieces of information and can be extended to fulfill specialized requirements. Resources can also be bundled together to satisfy the same messaging and document workflows that the health IT industry uses today. In a previous post, I detailed the interoperability paradigms of FHIR, including REST, messaging, documents, and services. Examples of resources include Patient, Medication, and CarePlan to name a few. Like CDA, each resource has a human readable element as well as coded entries.
Because these resources are simple in structure and clearly defined, they are viewed as something that is easy to parse and extract the data. Not to mention, it is always possible to extract the human readable portion. The resources, which can be encoded in XML or JSON (not to be confused with JASON – the organization writing the report), are lightweight and easily adaptable to web applications which is something that has not existed in health IT to this point.
According to the report, of even greater importance than the lightweight and clearly defined resources is the ability to support representation state transfer (REST). There are several design features listed in the report which give evidence to REST being such a good choice:
- Separation of concerns about the storage of data and the interface to the data
- The communication is essentially stateless between requests
- Load balancing can easily be employed on the server side
- Client caching can be enabled for efficiency
- Servers can send code to clients to extend functionality
- Applications present a uniform interface, with four guiding principles:
- Resources are identified via URLs
- Clients, with permission, can modify the resources on the server
- Messages are self-descriptive
- Transitions of the data are performed using hyperlinks
With REST in place as a paradigm for interoperability, along with the simple modular structure of resources, JASON believes that FHIR sets the stage for a major shift in the way healthcare data is exchanged, and make data more readily available when and where it is needed to support the future vision of healthcare.