Medical alarms have appeared on the Emergency Care Research Institute’s list of top medical hazards four times — twice in the number one spot. According to a recent FDA survey, bad sound design for medical devices accounted for 566 deaths over four years, mostly because the sounds can be so annoying that they get turned down so doctors and nurses can concentrate, leading to potentially deadly consequences.
In this TEDx McMaster talk from February 2021, Michael Schutz, an associate professor of music cognition and percussion, explains how his research with the Music Acoustics Perception Learning (MAPLE) lab is helping to create better alarms — and better patient outcomes.
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
Serverless is the new kid on the block with services such as AWS Lambda, Google Cloud Functions or Microsoft Azure Functions. Essentially it lets users deploy a function (Function As A Service or FaaS) on the cloud with very little effort. Requirements such as security, privacy, scaling, and availability are taken care of by the framework itself. As healthcare slowly yet steadily progress towards machine learning and AI, serverless is sure to make a significant impact on Health IT. Here I will explain serverless (and some related technologies) for the semi-technical clinicians and put forward some architectural best practices for using serverless in healthcare with FHIR as the data interchange format.
Let us say, your analyst creates a neural network model based on a few million patient records that can predict the risk for MI from BP, blood sugar, and exercise. Let us call this model r = f(bp, bs, e). The model is so good that you want to use it on a regular basis on your patients and better still, you want to share it with your colleagues. So you contact your IT team to make this happen.
This is what your IT guys currently do: First, they create a web application that can take bp, bs and e as inputs using a standard interface such as REST and return r. Next, they rent a virtual machine (VM) from a cloud provider (such as DigitalOcean). Then they convert this application into a container (docker) and deploy it in the VM. You now can use this as an application from your browser (chrome) or your EMR (such as OpenMRS or OSCAR) can directly access this function. You can share it with your colleagues and they can access it in their browsers and you are happy. The VM can support up to 3 users at a time.
In a couple of months, your algorithm becomes so popular that at any one time hundreds of users try to access it and your poor VM crashes most of the time or your users have to wait forever. So you call your IT guys again for a solution. They make 100 copies of your container, but your hospital is reluctant to give you the additional funding required.
Your smart resident notices that your application is being used only in the morning hours and in the night all the 100 containers are virtually sleeping. This is not a good use of the funding dollars. You contact your IT guys again, and they set up Kubernetes for orchestrating the containers according to usage. So, what is Serverless? Serverless is a framework that makes all these so easy that you may not even need your IT guys to do this. (Well, maybe that is an exaggeration)
My personal favourite serverless toolset (if you care) is Kubernetes + Knative + riff. I don’t try to explain what the last two are or how to use them. They are so new that they keep changing every day. In essence, your IT team can complete all the above tasks with few commands typed on the command line on the cloud provider of your choice. The application (function rather) can even scale to zero! (You don’t pay anything when nobody uses it and add more containers as users increase, scaling down in the night as in your case).
What are the best practices when you design such useful cloud-based ‘functions’ for healthcare that can be shared by multiple users and organizations? Well, here are my two cents!
First, you need a standard for data exchange. As JSON is the data format for most APIs, FHIR wins hands down here.
Next, APIs need a mechanism to expose their capabilities and properties to the world. For example, r = f(bp, bs, e) needs to tell everyone what it accepts (bp, bs, e) and what it returns (at the bare minimum). FHIR has a resource specifically for this that has been (not so creatively) named as an Endpoint. So, a function endpoint should return a FHIR Endpoint resource with information about itself if there is no payload.
What should the payload be? Payload should be a FHIR Bundle that has all the FHIR Resources that the function needs (bp, bs and e as FHIR Observations in your case). The bundle should also include a FHIR Subscription resource that points to the receiving system (maybe your EMR) for the response ( r ).
So, what next?
Take the phone and call your IT team. Tell them to take Kubernetes + Knative + riff for a spin! I might do the same and if I do, I will share it here.
Neural Network and deep-learning are the buzzwords lately. Machine learning has been in vogue for some time, but the easy availability of storage and processing power has made it popular. The interest is palpable in business schools as well. The ML related techniques have not percolated much from the IT departments to business, but everybody seems to be interested. So, let us build a Neural Network model in 10 minutes.
This is the scenario:
You have a collection of independent variables (IV) that predict a dependent variable (DV). You have a theoretical model and want to know if it is good enough. Remember, we are not testing the model. We are just checking how good the IVs are in predicting DV. If they are not good predictors to start with, why waste time conjuring a fancy model! Sounds familiar? Let’s get started.
The three model.add statements represent the three layers in Neural Network. The number after Dense is the number of neurons in each layer. You can play with these values a bit. These settings should work in most business cases. Read this for more information.
Most of us would have heard about PHIPA, the Personal Health Information Protection Act and QCIPA, the Quality of Care Information Protection Act. The foundation laws that are aimed to protect your Personal Health Information from those hackers and crooks who would love to get their hands on your personal information. Even with the establishment of these laws we have seen many breaches, some of which really shot to the limelight in the past recent years.
However, the word in town is that a new Bill had recently passed the third reading. The Bill 119 or the Health Information Protection Act is all set to make amendments to the PHIPA AND QCIPA. Amendments range from the mandatory reporting of privacy breaches to doubling the existing fines for offenders. According to Dr. Eric Hoskins, the Minister of Health and Long-Term Care “This legislation gives our health care system the necessary tools to protect the private health information of patients in Ontario…” and hopefully it does.
The advancement in health information technology has ushered a new era in providing quality care for people but at a very expensive price, privacy of one’s personal information. Systems should be designed, developed and deployed keeping in mind that security of the personal health information is kept a key criteria. Workflows should be redesigned in healthcare institutions and other organizations to include a culture of reporting privacy breaches and to study such situations to avoid the breaches in the future. Laws and regulations can play only so much to enforce protection, it is the duty of the people involved to follow and practice the law.
Interoperability is one of the highest trending words that one might hear if they are stepping into the wonderful world of EHealth. It has become so necessary that one would probably have a chapter or two on it in every health informatics degree.
Interoperability in simple terms is the way in which one system communicates with another to help ease the decision making process and thus aide in improving the care process. Imagine one day Ms. Jane Doe is scheduled for an MRI by Hospital A. Now in the absence of an interoperable environment the radiology facility would have to either physically transport the scans through a person, fax or courier. However, imagine if there was a situation where the radiology facility could update the hospital A of the status of the MRI scan as well as send the scans directly to the medical record associated with Ms. Jane. Such a situation would save Hospital A a lot of money, time and help improve the quality and time of the decision making process. This situation shows one of the benefits of implementing an interoperable system and there are many more !
However, there are some tricky areas one needs to eliminate (which is quite hard) to achieve the true benefit of having an integrated health information system. Prominent being that of privacy and security. An advance in technology also means an advance in techniques for hacking. There is always a threat lurking to steal one’s personal health information to earn some big bucks or use it for some other illegal purpose especially in developing countries where there aren’t as stringent privacy laws to protect health information.
Activiti is a BPMN automation tool that makes communication between business analyst and the developers easy. Activiti has a web-based graphical interface for business analysts to prepare workflows that can be enhanced by developers adding Java code using an Eclipse plugin. It has a lightweight engine that can be embedded in Java applications to deploy the workflow and an explorer for deploying the process definitions online. Activiti also has a REST interface.
Activiti uses an in-memory database by default. Installation requires Java and servlet container like Tomcat. I have created a puppet script to automate activity installation in a virtual machine. The script installs activity Explorer and the REST interface with the mySQL database. if you want to connect to an external database you can make the necessary changes in the properties file within the code folder.
Installation instructions for Activiti
There are ways of creating a virtual Linux machine in your laptop (Mac and Windows). Virtualization leaves your operating system untouched, and the virtual machine can be removed without a trace after use. Without further ado, you can install this in 5 easy steps using my puppet script.
1. Install VirtualBox.
2. Install Vagrant.
3. Download and extract the zip file below to any folder.
EMRs and EHRs are of vital importance to health informatics students. Though there are several popular open-source products such as OSCAR EMR, installing them on your laptop can be cumbersome.They are designed for server installations with several prerequisites such as a backend database and a servlet container such as Tomcat. Though OSCAR EMR has an old Windows version, it has been marked as deprecated. If you are not a Linux geek, here is how you can install an EMR (OSCAR), an EHR (OpenMRS) and the popular statistical package R with R-Studio server. That is everything you need for your eHealth sojourn!
There are ways of creating a virtual Linux machine in your laptop (Mac and Windows). Virtualization leaves your operating system untouched, and the virtual machine can be removed without a trace after use. Without further ado, you can install this in 5 easy steps using my puppet script. Obviously, this is for testing only and not for production.
1. Install VirtualBox.
2. Install Vagrant.
3. Download and extract the zip file below to any folder.