Applied Bimatics - An Informatics & eHealth Blog

I am a clinician with a passion for informatics. This blog is about my eHealth journey exploring interoperability in Electronic Medical Records (EMR/EHR), Patient Safety, Pharmacovigilance, Data Analytics, Clinical Research and Bioinformatics in a clinical context. Comparing Canadian, Indian and Middle Eastern healthcare systems and services. Join our open facebook group here: https://www.facebook.com/groups/clinical.bioinformaticians/


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?





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!

Labels: , , , , ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post


AngularJS and Electronic Health Records

I am not an Angular expert (as yet) though I used it for one of my successful applications called LesionMapper™. For the uninitiated, AngularJS is (yet another) javascript framework that is different in many ways. It extends HTML and implements the exciting concept of two-way data binding for dynamic web apps. If you are still skeptical about whether angular is big, please take a note of their logo that has a small (in)significant subscript: ‘by Google’. My intention here is not to dissect AngularJS and compare its many features or to disambiguate the diverse terminologies such as ‘directives’ and ‘expressions’ that makes it seem more daunting than it actually is.

Photocredit AngularJS @ github and jfcherry @ flikr (Images altered)

For health professionals, the bottom line is that AngularJS makes browsers powerful and can perform some of the tasks that are traditionally relegated to the server. So how is it going to improve our EMRs? During my student days, I have seen a popular regional EMR with a dismal user-interface. I have also seen a health analytics platform with more than 100 dropdowns on a single page. I have seen doctors returning to paper after failed EMR experiments. I have seen regional clinical viewers reeling under usability concerns. Can angularJS make any difference?


A tool cannot change everything. Angular as a tool is not going to be a panacea. But the concept may change the way we think and organize our electronic health record systems. The traditional way of seeing EMRs as data-centric models was rejected by us, health professionals. Blame it on technology averse senior doctors or blame it on the inefficient healthcare system not learning from banks and airline industry, the fact is, eHealth failed to deliver! Will a new version with an improved interface change this? Unlikely!

EHealth has to accommodate our workflow, not the other way round. Because EMR is the tool, not us, physicians!
I know this is not my idea, and we have discussed this here before. How can AngularJS change this?
I am a huge fan of reverse innovation, and I am excited to see initiatives such as http://www.bahmni.org/ building AngularJS based customization layer on top of OpenMRS.org. True open source projects such as OpenMRS foster innovation (reverse or not).. It should open the eyes of others calling themselves open-source without being truly open! (Well.. that is another story..)


Labels: , , , , ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post


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.

  • Eapen BR (2014). “HIEBR: Health Information Exchange Benefits Realization Tool” Applied Bimatics - An Informatics and eHealth Blog.[Internet] Accessible from: http://bioblog.gulfdoctor.net/2014/11/health-information-exchange-benefits-evaluation-HIEBR.html

Please Like/Share below 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


Labels: , , , , ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post


If Ebola Spreads to Canada

While reading the news about the public health agency of Canada taking all possible steps to prevent the spread of Ebola to Canada, with a glass of Ontario wine in my hands, I for a brief moment thought, what if ………

Picture credit DFID @ Flikr (Image altered and text added) - If Ebola spreads to Canada

So let me set the context right. I am not an infectious disease expert, though my post on cutaneous signs of Ebola virus infection got more attention that it deserved. I am not an epidemiologist either to comment authoritatively on what healthmap is doing. To me it is the social media version of what John Snow did two centuries back to identify the epicentre of the cholera outbreak and established epidemiology as a speciality.

So if Ebola spreads to Canada, How do we identify the epicentre and take preventive measures? Turn to healthmaps and see where it originated and take measures to contain? Healthmaps will get that information from Google news and similar services. We have half a dozen major Health Information Exchange (HIE) initiatives in the country and would probably have accurate records of where each case presented with the characteristic symptoms. But we would look up to healthmaps and google since we cannot use HIE data for research!
I am not a health policy expert neither am I an HIE architecture expert. But to me, if we have to realize the benefits of the ever increasing number of HIE initiatives, we have to find a way to use the wealth of the information there for population health. If we get it right, privacy is not even a concern.

HIE, built to abolish silos, paradoxically created larger silos, because of fragmented systems. The utopian population health requires a glue to bring these silos together. We got it wrong the first time, with data-centric HIS that offered little clinical workflow support and were (inadvertently) rejected by doctors. (We always have the doctors to blame as the universal slow technology adopters. BTW India’s mission to Mars discovered that all doctors in the planet originated from Mars!). We are sure to get it wrong again if we don’t change the data-centric HIE models.

HIE should be versatile, structureless and scalable enough to support disparate clinical use cases. The only option that comes to my mind is RDF.

Labels: , , , , ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post


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!

Please share to read about Apple Watch

Labels: , , , , , , ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post


Intelligent Federated 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 here. 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

Labels: , , , ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post


LesionMapper: Pictographic lesion encoder for Dermatology

An electronic medical record example
An electronic medical record example (Photo credit: Wikipedia)
Grading systems and novel methods of symptom coding is becoming more and more important with the growth of telehealth and electronic health records. It is probable that in dermatology too, a significant number of consultations will move online soon.

Visual Analogue Scale (VAS) is a commonly used tool for measuring subjective sensations such as itching. There is evidence showing that visual analogue scales have superior metrical characteristics than discrete scales, thus a wider range of statistical methods can be applied to the measurements.

Couple of months back, I attended a thesis defense in McMaster in which an innovative web based tool called Pain-QuILTTM for visual self-report of pain was presented. The technique of iconography - pictorial material relating to or illustrating a subject - was employed to represent pain using a flash based web-interface. Pain-QuILTTM tracks quality, intensity, location and temporal characteristics of the pain. Quality is represented by different icons, intensity is represented by a visual analogue scale of 1 -10, location by the position of icon on the body image and temporal characteristics by the time stamp. The clinical feasibility of Pain-QuILTTM has been successfully validated and published (1).
Pain-QuILTTM is a property of McMaster University and is subject to McMaster University's terms of use. It can be accessed here

The iconographic symptom encoding could be applied easily to dermatology as well. Dermatology lesions are primarily visual and dermatological diagnosis to a great extend is based on the type, distribution, intensity and temporal characteristics of the skin lesions. However the representation may be challenging because of the diverse nature of lesions.

Recently I came across fabric.js a javascript library for image manipulation based on HTML5 canvas. Fabric.js was much more versatile and powerful than I expected. I could prototype  LesionMapperTM (that is what I want to call it), in less than 24 hours. The type of lesions are symbolized by representative clinical pictures instead of icons, intensity is represented by the opacity/translucency of the image and the location and distribution by the position and size of the lesion respectively, on the body image. The images can be dragged, enlarged or rotated.

Febrile neutrophilic dermatosis
Febrile neutrophilic dermatosis (Photo credit: Wikipedia)
The icing on the cake is the ability of fabric.js to rasterize the image into a JSON that can be stored easily in a database. LesionMapper allows you to save the LesionMap for 6 months and can be rendered back by providing the ID. If you want to include this as an Electronic Health Record system plugin, do give me a shout by clicking on Contact Me on the menu above.

Take a look at LesionMapper(TM) here!

Ref:
1Lalloo, Chitra et al. "Pain-QuILT: Clinical Feasibility of a Web-Based Visual Pain Assessment Tool in Adults With Chronic Pain." Journal of medical Internet research 16.5 (2014). [JMIR]

Labels: ,


commentAdd Your Comments/Suggestions/Criticisms! | View Comments | Links to this post

About Me

As a Dermatologist and Informatician my research mainly involves application of bioinformatics techniques and tools in dermatological conditions. However my research interests are varied and I have publications in areas ranging from artificial intelligence, sequence analysis, systems biology, ontology development, microarray analysis, immunology, computational biology and clinical dermatology. I am also interested in eHealth, Health Informatics and Health Policy.

Address

Bell Raj Eapen
Hamilton, ON
Canada