Bell Eapen MD, PhD.

Bringing Digital health & Gen AI research to life!

GIT for doctors (Part 3) – stash, branch, merge, rebase and tag

To continue with our git story: Read the full series on GIT for doctors here

If you think you have made a mistake, you can “stash” the changes. Your file will be returned to the previous state. You have the option of returning to the stash if needed, but this is beyond our scope at present.

Now let us consider another scenario: You have two differential diagnosis for your patient and you want to investigate the patient for both conditions. You may decide to keep two versions of the same case sheet to continue the work up on both differentials. In Git you can create a “branch” for this situation. You can work on branches independently. The main branch or the trunk is called “master” by convention. You can give any name for the other branches.

Embiodea
Embiodea (Photo credit: beapen)

If you decide to consult your colleague, he/she may want to continue working on their copy without changing the “master” file in your possession. So they can work on their “branches” too. Later on if you want to add your differential branch or your colleague’s branch into the master file, you can choose “merge”.

You can create branches of branches. If you want to merge several such branches into the “master”, you have to paste all branches together into a single branch. This is called “rebase”.

If you have to submit a master chart for audit, you can “tag” the chart, so that you can give a name to the current state. “Tagging” for software is generally done when you decide to release a version to the end user.

In the next part, I will discuss how to collaborate with your friends. If you are not on github.com as yet, do register for an account now. If you want to follow someone, let me suggest yours truly: https://github.com/dermatologist

Read the full series on GIT for doctors here

Published by Bell Eapen on | Permalink

GIT for Doctors & healthcare professionals – I

Read the full series on GIT for doctors here

Type 36 JSDF Arm Suit
Type 36 JSDF Arm Suit (Photo credit: Mechanekton)

GIT for us doctors is an acronym for GastroIntestinal Tract. But the GIT I am going to talk about here has nothing to do with GastroIntestinal tract. Do you have any gut feeling about what it is going to be?

Well, GIT according to wikipedia is a distributed revision control and source code management (SCM) system with an emphasis on speed. What has that got to do with healthcare professionals and doctors? As healthcare is becoming tech savvy, healthcare professionals and some doctors have started to recognize and understand, not just completed software products, but their source code as well.

The rising prominence of open-source movement in healthcare will greatly benefit from this, as doctors start contributing actively to healthcare application design and code. When you contribute code to an open-source project, there should be a mechanism to download what others have done, maintain concurrency as others keep adding things, keep track of what you add along with others who contribute, and finally impress the master with your contribution. This process is much more complex than the conventional version control or keeping track of older version by keeping copies of different stages. So that is where GIT steps in.

My aim is not to teach you the nitty-gritties of GIT, so that you will become a master of versioning systems. GIT can be quite challenging for doctors to understand and use. (Can you believe it: It is generally used as a command line tool). My aim is to make you comfortable enough to understand and use GIT in a user-friendly way so that when open source initiatives like openmrs.org talks about using GIT, you will know what they mean. BTW if you use EMRs but have not heard about openMRS.org, do take a look. Maybe you (like me) will also be enticed by their motto “ Write Code. Save Lives.”

Deutsch: Logo von GitHub
Deutsch: Logo von GitHub (Photo credit: Wikipedia)

I will start with actual steps in the next post. In the meantime, join the facebook of GIT called GitHub. https://github.com. If you feel like following someone checkout this guy 😉 https://github.com/dermatologist . Don’t download and install anything as yet. Just register for a new account.

Next, download and install this free ‘windows’ to GIT http://www.sourcetreeapp.com/ from a software company called Atlassian. This (surprisingly not so popular yet!) software will make your first experience with GIT painless, I promise.

Will be back again with more. BTW did I tell you that GIT may be useful for collaborative writing too!? Unfortunately GIT was not around when I wrote this article in a dermatology journal in 2007. http://www.ncbi.nlm.nih.gov/pubmed/18032878

Read the full series on GIT for doctors here

Published by Bell Eapen on | Permalink

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.

Published by Bell Eapen on | Permalink