Bell Eapen MD, PhD.

Bringing Digital health & Gen AI research to life!

DHIS2 and longitudinal health records: Connecting systems to get the best of both worlds!

DHIS2 is a health information system that revolutionized the way healthcare data is managed. It is open source and is a byproduct of a multinational action research project initiated from Oslo and first implemented in India. 1Currently, DHIS2 is the world’s largest health management information system (HMIS) platform, in use by 67 low and middle-income countries. 2.28 billion (30% of the world’s population) people live in countries where DHIS2 is used.

DHIS2 is a public health information system (PHIS) where the unit of management is a group or a geographical region and not individuals. It is unfortunate that this distinction between a typical EMR (a longitudinal health record) and a public health information system to manage population health is not clear to many policymakers.

The growing popularity of machine learning and artificial intelligence applications make the PH agencies rethink their data management strategies. A longitudinal health record is essential for most ML and AI applications for creating complex predictive models. PH agencies are gradually realizing the importance of data warehouses in managing the changing healthcare data management applications and workflows. Hence, the next generation of public health information systems should be able to efficiently handle longitudinal as well as group/cross-sectional data.

The easiest strategy to adopt may be to make existing PHIS systems talk to each other by leveraging the recent advances in health information exchange. HL7 may not be ideal for this purpose as it relies on a patient-centric model. FHIR may be more capable to deal with this, but the underlying REST interface may not support real-time data exchange.

RabbitMQ and Apache Kafka are industry standard open-source messaging frameworks that can be leveraged for real-time communication between disparate systems such as DHIS2 and OSCAR EMR / OpenMRS. DHIS2 supports both out of the box, and I have modified the DHIS2 docker container optimized for message exchange. A sample Java client is also available from my fork. The repo is here.

If you have ideas/want to work on creating DHIS2 connectors for EMRs like OSCAR EMR or OpenMRS, please comment below. OpenMRS has an existing module that can pull certain reports from DHIS2.

References

1.
Braa, Monteiro, Sahay. Networks of Action: Sustainable Health Information Systems across Developing Countries. M. 2004;28(3):337. doi:10.2307/25148643

Published by Bell Eapen on | Permalink

Usability of Federated Clinical Viewers

As I have discussed before in my interoperability series, federated viewers are remarkably effective within regional contexts, beyond which scaling of the model becomes impractical. I have also discussed the need and ways of building intelligence into a federated framework. Here I am going to expand further on my previous ideas.

Published by Bell Eapen on | Permalink

Interoperability for Doctors and Healthcare professionals Part I

It is important for health information systems to talk to each other. Unfortunately they speak different languages. This article is not for eHealth experts to understand the nuances of interoperability (HIE), but for health care professionals to have an idea about what is out there and what can be expected in the future.

When we consider HIE we have to think about what is being exchanged (package), how the information is organized (format) and how it is being transported (protocol). Though it is not essential to know, few terms that you might recognize are: HL7, XML for format and HTTP, TCP/IP for protocol. (Have you heard of MLLP? Google it!) The donor has the information in a certain format and protocol while the recipient expects it in a particular format and protocol.

At the core of all HIE platforms such as MirthConnect or OrionHealth’s Rhapsody, is an engine that does this conversion. Format and protocol of donor to format and protocol of recipient. Simple eh?

Is pragmatic interoperability the best solution?- M. Martineau @eHealthMusings explores a pragmatic Rhapsody approach http://t.co/XMkMXAEdt7

— Orion Health Canada (@OrionHealthCA) December 11, 2014

Now most of these platforms have a user interface or IDE for making this connection. You can also introduce certain filters at this stage. Enterprise systems like Rhapsody presents an attractive visual interface, whereas open source solutions may not be very user friendly.

What else can the engine do? It usually keeps a log of all package deliveries and whether the delivery was successful. If the delivery failed, it can attempt again and alert the maintenance team through a console. The console can even be mobile as in rhapsody. Though the engine can store the package itself for a limited time, storing the package is not really its job.

The donors could be:

  • A single department in a hospital sending lab reports.
  • All departments in a hospital sending all sorts of information.
  • Several hospitals in a region.

The recipient could be:

  • Another department in the same hospital expecting a lab test report.
  • A family physician who wants real time access to the lab reports for his patients admitted in the hospital.
  • A researcher who wants to know blood sugar status of all the diabetes patients. (population health)

We need a separate layer between the engine and the recipient to support all these use cases. Let us call this layer mediator.

The mediator can pull data in real time from donors or store it in a local database. The first one is the federated model while the other one is the centralized model. Federated is slow but up-to-date while centralized is fast but not concurrent. Mixed model has both and is preferred. The so called clinical viewers are federated mediators with a web interface.

Emerging paradigms like NoSQL and RDF may be ideal for data representation in mixed model. I have discussed RDF before. Will discuss NoSQL soon!

Published by Bell Eapen on | Permalink

Health Information Exchange Benefits Realization Tool HIEBR

One of the most promising trends in Health Information Technology (HIT) is Health Information Exchange (HIE). Several HIE initiatives are jostling for space in the HIT arena in many areas. Like most other public HIT projects, funding depends on benefits evaluation. Benefits evaluation could be a difficult undertaking requiring careful planning even for an Electronic Health Records system.

Health Information Exchange Benefits Realization Tool
Image credit USDA @ Flikr (Image altered and text added)

The goal of HIE is to facilitate access to and retrieval of clinical data to provide safer, timely, efficient, effective, and equitable patient-centered care. All the goals are subjective open to varied interpretations, making benefits evaluation in HIE, a nightmare.

Canada Health Infoway (CHI) published a benefits evaluation indicator technical report in 2006, that was upgraded to a new version in 2012. After comprehensive search and literature evaluation CHI has proposed the various parameters that are important under various scenarios with a broad focus.

HIEBR is an attempt at creating a simple tool based on the CHI report for evaluating HIE benefits from a user perspective. The focus is on simplicity and HIEBR is not claimed to be a comprehensive HIE benefits evaluation tool. The questionnaire has 10 Likert scale questions that have to be scored from 0-4 giving you a score ranging from 0-40. This is multiplied by 2.5 to represent this on a more user-friendly scale of 100. However, it should be noted that HIEBR score does not represent a percentage. The main purpose of HIEBR is to assess the impact of an HIE initiative. So it is designed to be administered pre and post HIE implementation and compared using non-parametric statistical tools.

SUSie is another tool that combines System Usability Scale with basic benefits realization questions incorporated, retaining the SUS style. Please cite this page as below, add your study reference in our wiki page, and share this page if you use this tool.

Cite this article as: Eapen BR. (November 1, 2014). Health Information Exchange Benefits Realization Tool HIEBR. Retrieved December 22, 2024, from https://nuchange.ca/2014/11/health-information-exchange-benefits-realization-tool-hiebr.html.

Click here to download a PDF copy of HIEBR

HIEBR TOOL
My current methods of obtaining patient health information from external organizations are:
Strongly Agree Agree Undecided Somewhat disagree Strongly Disagree
Complete
Accurate
Relevant
Timely
Available when needed
Organized
My current methods of obtaining patient health information from external organizations have a POSITIVE impact on:
Strongly Agree Agree Undecided Somewhat disagree Strongly Disagree
My work performance
Improving healthcare costs
Quality of patient care
Privacy and security of Personal Health Information

Published by Bell Eapen on | Permalink

Apple HealthKit: Health Information Exchange for Apps

Last year, one of my colleagues proposed an add-on for a popular fitness app as a course project. There has been a whopping increase in the number of health and fitness apps, monitoring a variety of parameters from blood sugar to the number of strides you take. As my colleague pointed out, all the necessary features are never there in any single application. How do you write an add-on for an existing app? Apps do not talk to each other much like their big brothers: health information systems.

English: Mediated Reality running on Apple iPhone
(Photo credit: Wikipedia)

Apple is trying to solve just that, with its new HealthKit framework. HealthKit allows apps that provide health and fitness services to share their data with the new Health app in the cloud and with each other. A user’s health information is stored in a centralized and secure location and the user decides which data should be shared with your app. I have a couple of friends currently working on population pharmacokinetics. HealthKit may be an ideal framework for sharing pharmacokinetic data too.

Though HealthKit is lingering over a last minute bug that slows down apps that use this framework, it may be a novel and effective tool for app designers. However whether the technology will bring the prophesied ‘Healthcare revolution’ remains to be seen. The new generation apps are going to make life difficult for physicians, already inundated with lots of data. Hope the proverbial ‘Apple a day’ does not happen!

Be on the watch out for the Apple watch as well. I feel Apple watch is more likely to be a disruptive innovation than HealthKit itself. Watch is always more intimate and ubiquitous than any other wearable device. The built-in accelerometer, heart-rate sensor and GPS along with Apple’s ingenuity provides enough reason to expect amazing functionality.

Addendum:

Epic spokesman Brian Spranger offered still more detail, describing to VentureBeat’s Mark Sullivan how a device such as the WiThings Wi-Fi-enabled scale could “notify HealthKit that it has a new weight and ask HealthKit to store that weight in the database on the iPhone.” From there, “If the patient has given permission for the MyChart app on their phone to know about that data, HealthKit ‘wakes up’ the MyChart app and tells it there’s new data,” according to Spranger. “The MyChart app on the phone then transmits that weight back to the EpicCare EHR system where it can be used appropriately as part of the patient’s medical care.”

More data is probably as dangerous as the lack of it!

Published by Bell Eapen on | Permalink

Intelligent Federated Model of Health Information Exchange Clinical Viewers IFCV

I have blogged about federated search clinical viewers before. Essentially such viewers query source health information systems in real time and provide the user with a consolidated view. There is no data repository, ensuring data integrity and data privacy. Though the system can be slow because of the real-time search, there are many successful regional implementations of this type.

There is an obvious disadvantage for federated model of health information exchange viewers. Intelligence cannot be built into such viewers. Since there is no server side data storage, there is no scope for server side processing. The data comes together only in the rendered view. Some  mixed systems that have a data-repository provide some crude warning flags that are not-real time. But clinically useful alerts are beyond the capabilities of federated systems. So how do we build intelligent federated clinical viewers?

Intelligent Federated Clinical Viewer #IFCV

As HTML5 specifications mature, intelligence can be built into clinical viewers by client side processing and storage. Though local database storage implemented by Safari is too insecure at this stage for this purpose, it might become viable in the future. Some useful functionality can be built with the Session storage functionality that has been expanded to store up to 4MB of data depending on browser implementations. This is much more than the conventional cookie storage. The Sessions object persist only till the window is active and is reasonably secure. I have listed some typical use cases below.

A typical pharmacy module of a clinical viewer brings together all the medications the patient is on from all source hospitals. A client side script could identify drug interactions by analysing the view. This is beyond the local EHR system as disparate systems do not talk to each other.

If all the active drugs can be stored locally during the pharmacy module view, contraindications such as steroids in hyperglcemia can be alerted when the lab module is accessed. These intelligent alerts could be clinically invaluable.

The utopian dream of cross-communicating EHRs are still a long way in the future. Regional federated clinical viewers are going to rule the roost for some time. So intelligent federated clinical viewers may be worth a consideration. I don’t know whether this is already in the pipeline for vendors such as Mulesoft, Medseek or Mirth. If not, a link here (and a mail) will be highly appreciated when they do.

Twitter hashtag for this topic: #IFCV

Published by Bell Eapen on | Permalink

Resource Description Framework (RDF) and Population Informatics
English: A PICTURE OF A RDF
A PICTURE OF A RDF (Photo credit: Wikipedia)

I have been an RDF fan even before I used it for dermbase. I promptly signed the Yosmite Manifesto and blogged about it last year. After gaining more experience in the regional health information exchange initiative(s), I still feel that RDF is important, but in a different way.

Most federated regional clinical viewers query host databases, convert the results into an intermediary format (mostly xml or HL7), apply filters and then provide a consolidated view in the browser and mobile as html embellished with jQuery. Though this seems not-so-scalable technology, it works remarkably well in a regional context. Federated clinical viewers also attempt to create data warehouses on top of the Clinical Viewer. Such data warehouses have enormous potential in population informatics and RDF could be an ideal framework for this purpose.

RDF is a proven technology that is schema agnostic. However in this context the biggest advantage of RDF is its data-atomic nature that enables each data element to be queried, changed, or deleted independent of any other data element. RDF blank nodes can be used to effectively anonymize the data. From a data analytics perspective representation in the RDF format makes data amenable for “reasoning” to discover new knowledge.

Genomic data analytics has revolutionized pre-clinical research. Growing popularity of Health Information Technology (HIT) and Health Information Exchange (HIE) has not yet resulted in a similar impact on population health. There are some fundamental differences between genomic and clinical data.

The fundamental characteristics of genomic data are:

1. The data format is simple though it can be annotated in different ways.
2. Raw data is collected first without consideration of relevance. Hypothesis formulation and analysis come later.
3. The data is mostly anonymous.
4. The format and analysis protocol remain the same.

The clinical data has different characteristics:

1. The data is often complex and hence it is difficult to have a uniform format.
2. Data is collected to prove or disprove a hypothesis/diagnosis. Hence only relevant data is collected.
3. The data is often tagged to an individual.
4. The analysis protocol and data collection depends on the hypothesis/diagnosis.

RDF framework would allow abstracting population data from normal everyday HIE data for clinical practice, but both operating within the same ecosystem. The framework will also allow clinical data to have the analytics friendly qualities of genomic data. The clinical viewer can push data into the RDF repository without a separate warehousing process thereby reducing overhead and increasing relevance. New generation wearable devices and monitors can push anonymized raw data directly into the RDF repository. The privacy and security concerns of this architecture will be minimal.

There is another hitherto unexplored advantage for such a clinical RDF repository. Temporal data related to climate changes and other events such as natural calamities can also be pushed into the “structureless” RDF repository making it possible to assess the population health impact of such events.

Published by Bell Eapen on | Permalink

SUSie: SUS based questionnaire for assessing usability and physician attitude toward health information exchange
evaluation of eyetracking after an usability test
evaluation of eyetracking after an usability test (Photo credit: Wikipedia)

Health information exchange (HIE) allows healthcare providers and patients to access and securely share medical information electronically. Several organizations are now emerging to provide both form and function for HIE efforts, both on independent and governmental/regional levels. However the biggest challenge is Change Management, as healthcare providers are exposed to one more ICT tool that they need to master for providing quality care.

There are no formal tools to study individual and organizational attitude towards HIE or to measure their usability. Physician attitude towards the impact of HIE on reducing healthcare costs, improving quality of patient care, saving time and their concern about data privacy and security are important in HIE adoption. Usability is also of vital importance in the meaningful use of HIE tools.

SUSie (SUS for HIE) is an attempt at creating a useful tool for measuring the above factors. It is modelled based on System Usability Scale (SUS), one of the most used questionnaire for measuring perceptions of usability. Five additional questions were added to assess factors that are specific for HIE. The scoring is based on a scale of 5 ranging from Strongly disagree(1) to Strongly agree (5). The ratio of positively and negatively worded questions are maintained and the final multiplication factor was changed to 1.67 to represent the final score on a scale of 100. I hope that this would make the interpretation similar to SUS and benefit from the prior experience available for SUS. The questions and details of scoring are explained below.

If you use SUSie, please cite this webpage and the articles below:

  • Brooke, J. (1996). “SUS: a “quick and dirty” usability scale”. In P. W. Jordan, B. Thomas, B. A. Weerdmeester, & A. L. McClelland. Usability Evaluation in Industry. London: Taylor and Francis.
  • Wright, Adam et al. “Physician attitudes toward health information exchange: results of a statewide survey.” Journal of the American Medical Informatics Association 17.1 (2010): 66-70.
  • Eapen BR (2014). “SUSie: SUS based questionnaire for assessing usability and provider attitude toward health information exchange.” Applied Bimatics – An Informatics & eHealth Blog.[Internet] Accessible from: http://bioblog.gulfdoctor.net/2014/06/susie-hie-usability-physician-attitude.html

Questions:

  1. I think that I would like to use this Health Information Exchange System frequently. 
  2. I found this Health Information Exchange System unnecessarily complex. 
  3. I think this Health Information Exchange System will reduce healthcare costs. 
  4. I think that I would need the support of a technical person to be able to use this Health Information Exchange System. 
  5. I thought this Health Information Exchange System was easy to use. 
  6. I thought there was too much inconsistency in this Health Information Exchange System. 
  7. I think this Health Information Exchange System will improve Quality of Patient Care. 
  8. I found this Health Information Exchange System very cumbersome to use. 
  9. I found the various functions in this Health Information Exchange System were well integrated. 
  10. I am concerned about the privacy and security of healthcare information on this Health Information Exchange System. 
  11. I found this Health Information Exchange System can save me time. 
  12. I needed to learn a lot of things before I could get going with this Health Information Exchange System. 
  13. I would imagine that most people would learn to use this Health Information Exchange System very quickly. 
  14. I found that I had to significantly change my workflow to use this Health Information Exchange System.
  15. I felt very confident using this Health Information Exchange System.

SUSie uses the following response format:

Scoring SUSie

  • For odd items: subtract one from the user response.
  • For even-numbered items: subtract the user responses from 5
  • This scales all values from 0 to 4 (with four being the most positive response).
  • Add up the converted responses for each user and multiply that total by 1.67. 
  • This converts the range of possible values from 0 to 100 instead of from 0 to 60.

Interpreting SUSie (Based on SUS)

  • The value is not a percentage.
  • Average value is approximately 68.
  • This is not a validated questionnaire.
  • A percentile graph for SUS and other relevant information is available here: http://www.measuringusability.com/sus.php (courtesy: Jeff Sauro )
  • SUSie may be used to compare groups or for comparing pre and post intervention.

I have created a wiki page for updates. Please add any use-cases you can think of to the Wiki page.

Published by Bell Eapen on | Permalink