Bell Eapen MD, PhD.

Bringing Digital health & Gen AI research to life!

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.

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?

when I see a company mentioning they use angular, I read it as: no tech insight, no vision, hates life. #AngularJS
— Fredrik Carlsson (@fizk) November 15, 2014

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?

AngularJS could effectively separate presentation from storage. Our data scientists could work on the data layer (let me call it enterprise EHR) and concentrate on interoperability and population health. Our interface experts could work on the presentation layer customizing it for each department and each doctor, accommodating their workflow. (Let me call it Bring Your Own EMR #BYOE). We need a glue to bring both sides together. My vote is  for JSON/REST in the short term and RDF in the long term.

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..)

Related articles