The Ontario government is building a connected health care system centred around patients, families and caregivers through the newly established Ontario Health Teams (OHT). As disparate healthcare and public health teams move towards a unified structure, there is a growing need to reconsider our information system strategy. Most off the shelf solutions are pricey, while open-source solutions such as DHIS2 is not popular in Canada. Some of the public health units have existing systems, and it will be too resource-intensive to switch to another system. The interoperability challenge needs an innovative solution, beyond finding the single, provincial EMR.
We have written about the theoretical aspects, especially the need to envision public health information systems separate from an EMR. In this working paper, we propose a maturity model for PHIS and offer some pragmatic recommendations for dealing with the common challenges faced by public health teams.
Below is a demo project on GitHub from the data-intel lab that showcases a potential solution for a scalable data warehouse for health information system integration. Public health databases are vital for the community for efficient planning, surveillance and effective interventions. Public health data needs to be integrated at various levels for effective policymaking. PHIS-DW adopts FHIR as the data model for storage with the integrated Elasticsearch stack. Kibana provides the visualization engine. PHIS-DW can support complex algorithms for disease surveillance such as machine learning methods, hidden Markov models, and Bayesian to multivariate analytics. PHIS-DW is work in progress and code contributions are welcome. We intend to use Bunsen to integrate PHIS-DW with Apache Spark for big data applications.
FHIR has some advantages as a data persistence schema for public health. Apart from its popularity, the FHIR bundle makes it possible to send observations to FHIR servers without the associated patient resource, thereby ensuring reasonable privacy. This is especially useful in the surveillance of pandemics such as COVID19. Some useful yet complicated integrations with OSCAR EMR and DHIS2 is under consideration. If any of the OHTs find our approach interesting, give us a shout.
BTW, have you seen Drishti, our framework for FHIR based behavioural intervention?
Pervasive health monitoring is becoming less and less intrusive with better sensors, and more and more useful with machine learning and predictive analytics.
MHealth (mobile health) could play an important part in pervasive health monitoring. It is difficult for clinicians to efficiently use the data from disparate apps that do not communicate with each other. For example, if a clinician has to monitor a patient’s blood sugar, blood pressure and physical activity, the clinician may have to check data from multiple apps. Another challenge is the difficulty in communicating clinical requirements to app developers and it is difficult to test and approve the clinical validity of these apps. Besides, there are always privacy and security concerns with personal health information.
Open mHealth is a framework introduced to manage the problem of interoperability between apps. It is an open-source project. Open mHealth project provides interfaces for cloud services such as GoogleFit and Fitbit and converts the data into a common data format. BIT model deals with the communication problem between clinicians and developers during app development. Drishti incorporates Open mHealth framework into the BIT model using FHIR as the common data model.
The BIT model is based on the Sense-Plan-Act paradigm from robotics. The BIT model encourages conceptualizing mHealth apps as three distinct components: Profilers that sense data on various physiological parameters such as blood pressure, planners that create a clinical intervention plan and actors that deliver the plan to the users as alerts or messages on their mobile devices. Drishti adopts the BIT model as a design model with all components sharing a central data repository. Drishti makes sharing of information with the doctors easy, by integrating it into an EMR. The central data repository also makes big data applications possible.
The central data repository in Drishti uses FHIR schema for storage. FHIR is a schema for health data created by HL7 that defines ‘Resources’ that can be exchanged as json or xml using RESTful interfaces. Resources support 80% of common use cases and the rest can be supported using extensions. For example, age and gender are defined for a Patient resource, while skin type that is not commonly used is defined through an extension if required. Drishti uses the ‘Observation’ resource for storing data from profilers and the ‘CarePlan’ resource for the planner and actor components.
In the current implementation, the cog is a FHIR server based on the HAPI java library. Planner and actor components are just stubs that can be extended for several use cases. The planner is a python flask app and the viewer is a Vue App that can be used as a native mobile app. Both are templates that can be extended. The entire stack is available on GitHub along with pre-built Docker containers for quick prototyping.
Here is a typical use case. Depression is a common mental health problem, characterized by loss of interest in activities that you normally enjoy. Patients with depression are typically treated with anti-depressant drugs. The clinicians need to track the patient’s activity to assess progress along with medication compliance. The patient can use an activity tracker app and a medication tracker app, both sending data to the cog as FHIR observations. The clinicians can have a consolidated view in their EMR and create alerts or messages (plan) that can be delivered to the patient’s mobile device. The interventions can also be created by AI systems.
Bell Raj Eapen, Norm Archer, Kamran Sartipi, and Yufei Yuan. 2019. Drishti: a sense-plan-act extension to open mHealth framework using FHIR. In Proceedings of the 1st International Workshop on Software Engineering for Healthcare (SEH ’19). IEEE Press, Piscataway, NJ, USA, 49-52. DOI: https://doi.org/10.1109/SEH.2019.00016