Skip to main content

Enabling IT in Healthcare by simulating Patient Data

In the current times of pandemics and disease outbreaks, it is of paramount importance that we leverage software to treat diseases. One important aspect of healthcare is Patient Management. IT systems have to be developed which can support management at an enormous scale. Any development of such good software system requires data which is as realistic as possible but not real. There has to be a fine balance between privacy and enabling developers to anticipate the myriad health scenarios that may occur. Towards this initiative, healthcare industry has been standardizing around the HL7 (Health Level 7) protocol. The HL7 protocol itself has undergone transformation from pipe-based formats (v2.x) to JSON/XML based (FHIR) modern formats. FHIR is the future of HL7 messages and is being increasingly adopted. However given the slow nature and reluctance by healthcare providers to change or upgrade their systems, a majority of hospitals still use the HL7 2.3 format.

FHIR is a modern format. There are lots of tools available to simulate patient data in FHIR format including the wonderful open-source Synthea tool which runs through a fictional patients entire life journey creating fake encounters, observations and such. However to my surprise, there are not many tools which can generate data in v2.3 legacy format.

So I took this as an opportunity to create a tool of my own - MayaMaker. This is an open-source GPL-licensed tool which uses Synthea data and NHAPI library to introduce scheduling algorithms between a patient's encounters to create fake ADT (Admission, Discharge, Transfer) messages. One can generate messages for one encounter or all the encounters that a person may have in their lifetime. You can view the source code on Github or view the live demo site here - https://mayamaker.azurewebsites.net/. If you need to automate the message generation, there is an API available here - https://mayamaker.azurewebsites.net/swagger/index.html

Hope this tool is a small step in helping software professionals in healthcare industry and make the world a better place.

(Pull Requests welcome!)

Comments

Post a Comment

As far as possible, please refrain from posting Anonymous comments. I would really love to know who is interested in my blog! Also check out the FAQs section for the comment policy followed on this site.

Popular posts from this blog

Integrating React with SonarQube using Azure DevOps Pipelines

In the world of automation, code quality is of paramount importance. SonarQube and Azure DevOps are two tools which solve this problem in a continuous and automated way. They play well for a majority of languages and frameworks. However, to make the integration work for React applications still remains a challenge. In this post we will explore how we can integrate a React application to SonarQube using Azure DevOps pipelines to continuously build and assess code quality. Creating the React Application Let's start at the beginning. We will use npx to create a Typescript based React app. Why Typescript? I find it easier to work and more maintainable owing to its strongly-typed behavior. You can very well follow this guide for jsx based applications too. We will use the fantastic Create-React-App (CRA) tool to create a React application called ' sonar-azuredevops-app '. > npx create-react-app sonar-azuredevops-app --template typescript Once the project creation is done, we

Centralized Configuration for .NET Core using Azure Cosmos DB and Narad

We are living in a micro services world. All these services are generally hosted in Docker container which are ephemeral. Moreover these service need to start themselves up, talk to each other, etc. All this needs configuration and there are many commercially available configuration providers like Spring Cloud Config Server, Consul etc. These are excellent tools which provide a lot more functionality than just storing configuration data. However all these have a weakness - they have a single point of failure - their storage mechanism be it a file system, database etc. There are ways to work around those but if you want a really simple place to store configuration values and at the same time make it highly available, with guaranteed global availability and millisecond reads, what can be a better tool than Azure Cosmos DB! So I set forth on this journey for ASP.NET Core projects to talk to Cosmos DB to retrieve their configuration data. For inspiration I looked at Steeltoe Con

Add Git Commit Hash and Build Number to a Static React Website using Azure DevOps

While working on a React based static website recently, there was a need to see exactly what was deployed in the Dev/Test environments to reduce confusion amongst teams. I wanted to show something like this: A quick look at the site's footer should show the Git Commit Hash and Build Number which was deployed and click through to actual commits and build results. Let's see how we achieved this using Azure DevOps. Git Commit Hash Azure DevOps exposes a variable called  $(Build.SourceVersion) which contains the hash of the commit. So I defined a variable in the Build Pipeline using it. Build Id and Build Number Azure DevOps also exposes two release time variables  $(Build.BuildId) and  $(Build.BuildNumber) which can be used to define custom variables in the pipeline. So we have a total of 3 variables defined: Next we use these variables in our React App. I created 3 global variables in index.html and assigned a token value to them. < script   type = "text/JavaScript&quo