FHIR© Implementation Guide - DRAFT
Point of Care Diagnostics FHIR IG
- CI Build
Point of Care Diagnostics FHIR IG - Local Development build.
HL7 FHIR (Fast Healthcare Interoperability Resources) is a rapidly emerging healthcare interoperability standard.
There is considerable and growing industry enthusiasm for the interoperability approaches exemplified by FHIR.
HL7 FHIR was created as a response to the perceived general failure of HL7 Version 3 to be a widely adopted, all-encompassing, proscriptive standard for “plug-and-play” exchange.
Another dimension of FHIR capability is the ability to bring information into an EHR or other user-facing technology using a FHIR-based app.
The SMART-on-FHIR approach, instantiated in the Argonaut Project implementation guide, has been adopted by leading vendors as a mechanism for presenting information from an external app into the workflow of an authorized user.
FHIR has been rapidly embraced by the industry as a standard of the future. This is in part due to focused public and private initiatives such as Argonaut,
Health Services Platform Consortium (HSPC) and the DaVinci Project among others.
Commercial platform-as-a-service implementations of FHIR are available from Google, Microsoft Azure, IBM and many other plaform vendors.
Point of Care Diagnostics eco-system is diverse and includes patients, caregivers, hardware based measurement devices, mobile devices, care delivery healthcare systems patient portals. The diagram below shows some of these typical systems. These systems are used based on need and data is collected and used for care delivery.
The following are definitions of the systems involved.
Identity Management Systems: A system that captures the biometrics of a patient and creates an identity for the patient uniquely. Currently IRIS and Fingerprint biometrics are commonly used.
The system compares the captured biometrics with existing biometrics and either reuses existing patient identity based on the match or creates a new identity. Typically Identity management systems contain a biometric
capturing device and an accompanying mobile app. The capture device and the mobile app can also exist on the same physical mobile device.
Objective Measurement Systems: This is a physical unit that is capable of administering specific lab tests, vital signs and collect results. Examples of systems are
Figure 2 below shows typical communication and data flow patterns between systems. As shown Patients interact with physical devices which maybe biometric devices, objective measurement devices, mobile devices administering subjective measurement apps. Typically most objective measurement devices external to mobile devices use bluetooth or other NFC methods to commuicate with mobile applications using proprietary data structures. Similarly mobile applications which interact with each other on the same physical device use Intents to transition the user from one app to another and provide a native experience. Lastly mobile applications which are communicating with external web based systems use RESTful APIs with HTTP protocols to communicate the data.
Currently most systems are unique providing specific functions and they provide their own mobile applications. However there is no orchestration between these devices and applications outside of caregivers executing specific workflows. Also these siloed systems prevent data interoperability and also breaks in workflows when a user has to jump from subjective to objective measurement and back. Creating a MGD platform that addresses the above concerns and will provide greater value when the individual systems can be combined together in workflows to diagnose diseases more effectively in resource poor settings.
The MGD platform will have to work in resource porr settings. It must be designed to solve a problem where remote access to EHR and/or cloud access is limited by connectivity concerns. The MGD platform has to enable advanced functions in machine learning and analytics to return outcomes based on input data from remote monitoring.
The following are the user stories that have been identified for development of the MGD platform.
The Figure 3 below shows the abstract model with the various systems involved, communication protocols and payloads.
As shown below the MGD platform will have two components
MGD Mobile App: MGD Mobile App is an app that co-exists on a mobile device along with other objective, subjective and identity management applications and facilitates orchestration and interactions .
The MGD Mobile App will use Intents specifically to communicate with the other applications using FHIR payloads.
The reason for choosing Intents based communication is to allow for presenting native experience for users when they transition from applications to applications.
Also when compared to other approaches such as WebAPIs, WebViews, Chrometabs app to app communication on mobile devices use Intents.
This model allows for device manufacturers, app developers providing subjective, objective or identity management solutions to integrate easily with the MGD platform by using a uniform specification.
MGD Cloud Platform: MGD Cloud platform is a software system that provide web based APIs to all the data collected by the MGD Mobile App and make it available to other systems using FHIR APIs.
The MGD Platform is designed and enables the point-of-care diagnostics eco-system to achieve the following