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/

The information presented here is not intended to diagnose, treat, cure or prevent any disease. Always seek the advice of your own physician or other qualified health care professional. Read full Disclaimer.

Loading .., Please wait!

RELATED LINKS
| Skin Deep - A Dermatology Blog | Hair Loss Blog - A Trichology Blog | Virtual Dermatologist - A Dermatology Expert System | ONTODerm - A Domain Ontology for Dermatology]

Friday, April 11, 2014

Electronic Health Records heartbleed

Open Source Media Framework Icon
Open Source Media Framework Icon (Photo credit: Wikipedia)
Finally we presented our ultra small EHR project (TED) on wednesday with the promise of pushing it into GitHub as an open-source project soon. The biggest challenge in small turnkey EHRs is data security and privacy. While we were presenting our project the world was desperately seeking the patch for the Heartbleed bug and CRA Canada shut down its portal to avoid any potential data security breach. We are still not sure about the impact of this bug worldwide. So what exactly is heartbleed and how can it effect the burgeoning open-source revolution in health informatics?

Heartbleed is a bug in a widely used open-source encryption method called openSSL. When two computers are securely connected by this method there is a mechanism for periodic checking of this secure connection. We now know that this process was not secure after all, as there was a flow in this method that made the data in the RAM of the computers potentially visible to intruders. The data in the RAM of the computer at any time is likely to be the most sensitive including information such as passwords. This vulnerability was present for almost 2 years till it was spotted recently. Though the obvious question at this point is, who knew about this vulnerability before, the potential ramifications of heartbleed extends right to the heart of the open-source philosophy in secure software systems such as EHRs.

Though it is unlikely, there is a possibility that heartbleed bug was intentionally introduced into the software by someone in the open-source community. This is an eye-opener to massively open-source EHR products. The people managing such open-source projects must be aware of the possibility of a security breach by malicious code introduced by the contributors. It may not be easy to spot such vulnerabilities.

Many EHR systems employ openSSL encryption making them vulnerable to heartbleed. Though patching may happen fast in active and funded projects, it may be delayed for some projects making them potentially vulnerable to heartbleed for extended time. Since this vulnerability is known, the chances of potential exploitation is quite high. Though healthcare data is probably less interesting to hackers than other data sources (contrary to what most of us in eHealth think), heartbleed could give healthcare CEOs some heartburn if not a bleed for days to come.

Labels: , , ,

Saturday, February 01, 2014

Yosemite Manifesto on RDF as a Universal Healthcare Exchange Language

Layered Semantic Web Technology Stack
Layered Semantic Web Technology Stack (Photo credit: jalbertbowdenii)
The Bring Your Own EMR (#BYOE) pronounced 'bio', as explained in my last post relies on a reliable interoperability platform. I have always believed that RDF is the key to successful interoperability. RDF has successfully been employed in several other fields and has many stable tools such as jena. I was searching the web for information on how to present the advantages of an RDF based interoperability platform for healthcare data. Then I found this website.

Yosemite Manifesto, pretty much summarizes whatever I had in mind and a lot more! They are also trying to raise awareness about the possible advantages of adopting the RDF platform by requesting researchers to sign a form. I have already signed. Have you?

I am starting a wiki page for #BYOE too.

Labels: , , ,

Saturday, January 25, 2014

Bring Your Own EMR (#BYOE)

The e-Health lessons from healthcare.gov debacle is being debated widely. The idea of applying large scale IT initiatives in clinical domains has its own risks. As we relentlessly move towards a fully digital healthcare ecosystem, is it possible to hide some of its complexities from the clinicians?

Patient empowerment is the buzzword in eHealth now and clinicians are generally viewed with some skepticism. EHealth has learnt over the years (in the hard way) that the clinicians may be reluctant to relinquish their firm grip on clinical data. After all they generated the data and they are the custodians though they do not own it!

One of the approaches worth trying is to give the clinicians control and freedom over their end of things. In other words, separate enterprise EMR from the physician EMR. However the key to success in this scenario is interoperability.

Interoperability of EMRs are being actively explored by many research teams and organizations. However the emphasis is on better standardization. As interoperability emerges as a global paradigm, the standardization strategy that has failed for the last decade or so, still seems impractical?

Bring Your Own EMR
I am working on an interoperability solution that segregates physician EMR solutions logically and physically from Enterprise EMR solutions. I would like to call this Bring Your Own EMR (#BYOEpronounced as 'bio'. The general framework is shown above. If you would like to join the #BYOE initiative or give feedback, shoot me an email!!

Creative Commons Licence
Bring Your Own EMR by Bellraj Eapen is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at http://bioblog.gulfdoctor.net/2014/01/bring-your-own-emr-BOYE.html.

Please cite this page as: Eapen BR. Bring Your Own EMR (#BYOE) . Available from: http://bioblog.gulfdoctor.net/2014/01/bring-your-own-emr-BOYE.html

Labels: , , , , ,

Sunday, January 05, 2014

Facebook and Ajax

Christmas pudding decorated with skimmia rathe...
Christmas pudding decorated with skimmia rather than holly. (Photo credit: Wikipedia)
Today is the last day of my Christmas break and the winter term will officially start tomorrow. I did use my break in a productive way as I mentioned in my post last week. To continue with my exploration, I found out two more things the hard way. So I thought I would share it here so that you guys can probably save some time.

I decided to learn how to make a facebook app. So I registered for a developer account and got my AppID and secret key. I made a word game in php for dermatology and decided to port it to the facebook canvas. The facebook interface asked for the normal application URL and the https URL. Near the https field, it is mentioned that https is a requirement from Oct 11th onwards. Since it is only the beginning of 2014 with a good 10 months to October, I decided to leave the https blank. The form submission was accepted without any problems and I was given a new 'blank' canvas.

Despite my best efforts at debugging, the canvas remained perpetually blank. After hours of googling, I found out the bitter truth. The October 11 is not Oct 2014, but Oct 2011 and is over 2 years back! So facebook needs a secure https URL for displaying external apps in the facebook canvas and it is mandatory for the last 2 years. I have no complaints about facebook's security policies and probably this is a good thing. But why the Oct 11 is still mentioned there without the year, and why the form is getting validated without an https url still!!

The other thing I found out the hard way was the (simple fact :) ) that: Ajax is basically javascript obeying the Same-origin policy. Your backend php script (or any other script) should be on the same server. Again no complaints, but......

Here is my DermGame who could never make it to the facebook, but got a facelift with Ajax. Sorry for the mangled interface and template.

Labels: , , , ,

Monday, December 30, 2013

Deploying Java applications with embedded derby database

Ruby on Rails
Ruby on Rails (Photo credit: Wikipedia)
I have been trying to brush up my programming skills during the christmas break. I recently added the tagline "Dermatologist who codes" to my elevator speech. My plan is to sharpen my java skills and to learn python and ruby on rails. I believe coding real world applications is the best way to learn/sharpen any programming language.

Here is the first innovative application, Dermatology Image Tagger that I made. I believe this would be quite useful to dermatologists for organizing clinical images. Afterwards I made a simple java database application for a colleague. I never explored the deployment of java applications before. I hit google to find useful resources, but found only very few. The one I found most useful was Aparna's blog. Here she succinctly explains how to use the Java embedded derby database. The only thing I had to figure out the hard way was to use the connection string as below to force creation of the database in the working directory. I also added a 'create table' button for initial deployment.

 String host = "jdbc:derby:imfdb;create=true";
            String uName = "your_username";
            String uPass= "your_password";
            con = DriverManager.getConnection(host, uName, uPass);
            stmt = con.createStatement();

She has also written an very useful article on deploying java desktop applications. I followed her instructions to package all required files into a single executable jar file for Mac and an exe file for windows. I have used this for DIT. Thanks Aparna for making life easy for me!

Pink in honor of breast cancer awareness programs
Pink in honor of breast cancer awareness programs (Photo credit: beapen)
I am still exploring python and Ruby on Rails. So far I have been really impressed by the way Ruby on Rails managed to make web application development intuitive. I also learnt git for version tracking and joined github. I have added few learning projects for python and RoR that may be useful applications if developed properly. Feel free to fork, watch or star them and if you are on github too, a follow will not hurt.

So this will be my last post for 2013. Will meet you all again in 2014.

Labels: , , , , ,

Sunday, December 15, 2013

What is wrong with the culture of medicine?

“What is wrong with the culture of medicine?”

I posted an article about burnt-out doctors that got lots of comments in DsB. Here is an excellent TED talk from Dr Zubin Damania, Director of Healthcare Development for Downtown Project Las Vegas.

“Medical schools are like Hogwarts where doctor wizards are trained to cure muggles using arcane contraptions like pagers (owls)”.

He has a plan to fight back against a system that can dehumanize doctors and patients alike. He is just too good. Must watch!


This article proposes telehealth as the future of healthcare delivery through virtual consultation and remote diagnosis. It will not only reduce the burden on secondary health care provision, but also improve the quality where accessibility to secondary care is limited. With the dwindling number of dermatologists in many parts of Canada, teledermatology also has huge potential. I am working on a dermatology imaging standard called DICODerm. I am planning to propose it to DICOM standards committee through Canada health infoway once it is completed. WG-19 (DICOM dermatology group) discontinued such a move long back, but when I proposed this idea in DsB I received huge support. Our ongoing work is available here. Standardization is a huge bottleneck for teledermatology systems, and if we can agree on a DICOM standard for dermatology, existing PACS systems may be used for store-and-forward teledermatology.

Labels: , , , , , ,

Sunday, September 22, 2013

Physician-patient encounter for HMIS & eHealth

A physician performs a routine checkup on a pa...
A physician performs a routine checkup on a patient at the medical clinic. (Photo credit: Wikipedia)
As physicians, the patient-encounter is a routine process that we hardly analyze in a scientific manner. But the physician-patient encounter is extremely important from the perspective of health management information systems. Though the workflow and thought-flow may vary based on the setting, individual and specialty, I have tried to summarize basic steps in a physician-patient encounter.

Initially there will be a rapport building phase for new patients which naturally will be unstructured. This is followed by history taking and clinical examination. A physician may take notes during this process, but the information on his notes generally will be semi-structured. This information is transcribed into the EMR in a fully structured form though free form text may be needed to capture certain elements.
Physician patient encounter

The basic steps in a physician-patient encounter 

The physician arrives at a list of probable diagnosis (differentials) following which the physician may go back to history taking and examination to find more clues for a definitive diagnosis. Clinical decision support systems (CDSS) may be useful during this phase. Physician requests  investigations and comes to a more specific diagnosis.

Management starts with a specific diagnosis in most cases. CDSS helps during this phase along with computerized physician order entry (CPOE) and ePrescription. When the patient comes for follow-up, these steps are repeated and the initial diagnosis is re-evaluated.

Labels: , , , , , ,

ALL RIGHTS RESERVED GulfDoctor.net