This is a story of how a health IT guy goes looking for an easier way of doing a tedious task, can’t find that easier way anywhere, ends up building it himself, saves a lot of time, and gets a happy lesson in the value of shared, open-source software.

In my position as a ­­­­­software architect at Lantana, I regularly work with Fast Healthcare Interoperability Resources (FHIR). About a year ago, I was developing an application which stores FHIR resources in XML, but provides them to the user interface in JSON. Converting data from one format to the other is a routine task, but the prospect of so many resource instances to convert left me feeling grumpy. Then it hit me: Surely I couldn’t be the first developer faced with this chore—right? Someone must have come up with an automation solution of some kind for this task—right? I checked online at GitHub and other likely places someone might have stashed a useful bit of code like this, and… nothing. I slumped back in my chair with a groan. But what if…? I sat up straight, opened my trusty JetBrains WebStorm JavaScript editor and started coding.

Several hours later, I plugged in the first of the XML instances and gave the brand-new conversion component a trial run. It worked! Along with the relief of now having a labor-saving tool to speed up my work, I was pleased with having come up with something that others might find useful (and maybe even improve). Components (or “modules”) already existed for doing similar conversions in C#, Java and other languages, but as far as I could tell, this was the first one for JavaScript applications.

I decided to make the component open-source because it is small and would probably not receive a lot of my attention once initially developed. Being an open-source module, there was also a chance that the open-source community might help maintain it and identify bugs and happily, that was the case. I uploaded my work to the NPM registry (as “fhir”) and to GitHub (as “FHIR.js”). The module supports the following:

• Converting FHIR resources between JSON and XML formats: This is important because many UIs use JSON, while server applications (that process and analyze the data) often use XML. Both JSON and FHIR are supported in FHIR.
• Basic validation of resource instances (aka: “sample”) to the requirements of a profile; which determines if elements are allowed for the use-case and validates value sets.
• Server-side deployment, for applications that require a server to process data and serve it to a user interface.
• Client-side deployment, for applications which run entirely from the browser and don’t require any server/database to function.

The first version of the component wasn’t perfect: JavaScript didn’t have particularly great support for processing XML. There were a few modules that converted XML into JSON, but they all had some difficult deployment scenarios or had programming quirks that made them difficult to use. A year later, these issues have been largely resolved with new open-source code that I integrated into the FHIR.js module as part of the version 2 release. And version 2 contains something else that wasn’t in my original upload: the contributions of others.

Downloads per month (from npm-stat.com)

To my surprise, according to npm-stat, the open-source module has received over 4,000 downloads in the last year! Furthermore, we had several people identify some issues we were able to resolve, and even some pull/merge requests (a request to integrate changes into the main code repository) for modifications that they made in their own forks of the original component code. These pull requests identified bugs that were yet to be identified by my use-cases.

I will continue to maintain and improve this component, happy to know that my quick, on-the-fly solution has proven useful to more people than I originally anticipated—and found a few collaborators along the way!