FHIR Relevance

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

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

HealthCubed which is capable of administering 12 different lab tests such as Hepatitis, Glucose test.

Video vitals which can measure vitals for a patient.

Subjective Measurement Systems: This is a mobile app that can administer an instrument (questionnaire) and collect information about a patient from which it can deduce a diagnosis, treatment plan, orders and follow-ups. An example is the ThinkMD system that can diagnose upto 12 different diagnosis conditions using various questionnaires.

Communication and Dataflow across systems

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.

Ecosystem Constraints

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.

User Stories

The following are the user stories that have been identified for development of the MGD platform.

• Ability to start an encounter with a new patient using Biometrics and Demographics capture device and application
• Ability to start an encounter with a existing patient by capturing biometrics and matching with existing application
• Ability to launch a Subjective Assessment application providing Patient and Practitioner context
• Ability to receive Assessment results from a Subjective Assessment application which includes Diagnosis Results, Treatement recommenendations and follow up visits
• Ability to initiate an Objective measurement using a device providing Patient context
• Ability to receive objective measurement results from a device which includes lab results, vitals
• Ability to discover specific diagnosis/assessments supported by a Machine Guided Diagnostics (MGD) device
• Ability to discover specific tests supported by a Objective Measurement device
• Ability to expose data collected from each clinic via APIs to share
• Ability to orchestrate across devices and applications from different vendors using different technologies

MGD platform Abstract Model for Standards Based Integration

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.

Advantages of using the MGD Platform

The MGD Platform is designed and enables the point-of-care diagnostics eco-system to achieve the following

• Allows for integration of existing measurement devices using a standard approach.
• Allows for application developers to provide their best user experience for their measurement systems.
• Allows for capturing of structured data using standard vocabularies and models
• Allows for orchestration between subjective, objective and identity systems seamlessly in a workflow
• Allows the collected data to be shared across sites and systems using standard APIs
• Fosters Innovation and new measurement systems to be tested and piloted in the eco-system
• Functions in resource poor settings with limited or no-connectivity