Avatar of Abigail Watson

We were looking to build a stack that natively supports Fast Healthcare Interoperability Resources (FHIR), which is the emerging interoperability protocol that Electronic Health Records (EHRS) are required to support under the MACRA and 21st Century Cures Laws. FHIR defines common data objects in XML/JSON format, so we naturally gravitated towards Javascript's native support of JSON. We didn't want vendor lock-in from Microsoft, Oracle, or Apple; and really appreciated that Javascript is installed in pretty much every web browser and on every phone.

Put another way, the emerging healthcare interoperability protocols require support of web technologies instead of desktop (.Net/Java) or bioinformatic pipelining technologies (Python). So we chose Javascript accordingly, and have been very pleased with that choice.

READ MORE
3 upvotes109 views

We actually spent three or four years trying to avoid using ExpressJS, as it's more low-level than we would like. Our goal is to develop a modern tech stack that's productive for bioinformaticists, clinicians, and superpatients; and that means abstracting away from raw TCP and header management. We prefer most of those things to be already worked out, so we can save that mental effort for managing medical terminologies and ontologies. So, for a long time, we were using Meteor's DDP protocol instead of HTTP. It works great. But it's not widely supported. Eventually, we had another company volunteer some open-source code that sorted out the details of an Express based FHIR server implementation. So we were happy to pull it in since someone else was already managing it. Long story short, we include ExpressJS as a deep dependency in the Node FHIR Server Core library we use from Asymmetrik.

READ MORE
2 upvotes416 views

Most bioinformatics shops nowadays are hosting on AWS or Azure, since they have HIPAA tiers and offer enterprise SLA contracts. Meanwhile Heroku hasn't historically supported HIPAA. Rackspace and Google Cloud would be other hosting providers we would consider, but we just don't get requests for them. So, we mostly focus on AWS and Azure support.

READ MORE
2 upvotes406 views

Fast Healthcare Interoperability Resources (FHIR) supports JSON and XML datatypes as it's default data types. We chose Javascript for it's native JSON support and inclusion in every web browser on the market. We also liked it's open source ecosystem, as we had been burned by vendor lock-in from Microsoft and Oracle in the past.

READ MORE
2 upvotes387 views

The Node on FHIR project began nearly 5 years ago, when we were using building bioinformatics visualizations using D3.js hosted from PHP. At the time, we were working on phylogenetic trees, cladograms, family genealogies, gene networks, and similar complex data structures. JSON or XML were the obvious data structures for such a task. We chose JSON at the time because we had access to a great open-source JSON data store called MongoDB. When Fast Healthcare Interoperability Resources (FHIR) was announced, it included support for XML and JSON data types. And considering how much we've invested in Node/Javascript, we decided to formalize around JSON.

READ MORE
2 upvotes387 views

We wanted a JSON datastore that could save the state of our bioinformatics visualizations without destructive normalization. As a leading NoSQL data storage technology, MongoDB has been a perfect fit for our needs. Plus it's open source, and has an enterprise SLA scale-out path, with support of hosted solutions like Atlas. Mongo has been an absolute champ. So much so that SQL and Oracle have begun shipping JSON column types as a new feature for their databases. And when Fast Healthcare Interoperability Resources (FHIR) announced support for JSON, we basically had our FHIR datalake technology.

READ MORE
2 upvotes367 views

Fast Healthcare Interoperability Resources (FHIR) uses XML and JSON data objects by default. And as much as .NET and Java support those data types, there's simply better support and a more native experience when using Javascript. We were looking for a full-stack javascript solution to build websites and apps with. And Node has met all of our expectations. It's great.

READ MORE
2 upvotes107 views

The Fast Healthcare Interoperability Resources (FHIR) standard specifies the use of HTTP endpoints for use in the healthcare industry. This is a huge improvement over legacy HL7 v2 interfaces that used pipe delimitated push messaging over TCP. However, as one might expect, HTTP for healthcare requires a particular flavor of HTTP, in order to support HIPAA level security, consent mechanisms, identity management, and various other topics necessary to protect patient safety and privacy. Postman has been our swiss-army pocket knife in managing the syntax, test servers, extensions, security tokens, and all the other low-level details in making FHIR work. It's been a champ and our go-to utility for developing HTTP endpoints.

READ MORE
2 upvotes96 views

In the field of bioinformatics, we regularly work with hierarchical and unstructured document data. Unstructured text data from PDFs, image data from radiographs, phylogenetic trees and cladograms, network graphs, streaming ECG data... none of it fits into a traditional SQL database particularly well. As such, we prefer to use document oriented databases.

MongoDB is probably the oldest component in our stack besides Javascript, having been in it for over 5 years. At the time, we were looking for a technology that could simply cache our data visualization state (stored in JSON) in a database as-is without any destructive normalization. MongoDB was the perfect tool; and has been exceeding expectations ever since.

Trivia fact: some of the earliest electronic medical records (EMRs) used a document oriented database called MUMPS as early as the 1960s, prior to the invention of SQL. MUMPS is still in use today in systems like Epic and VistA, and stores upwards of 40% of all medical records at hospitals. So, we saw MongoDB as something as a 21st century version of the MUMPS database.

READ MORE
2 upvotes91 views

We chose React on the advice of the Meteor Development Group, which acts as our upstream technical advisors. We had a prior investment in BlazeJS, due to it's optimistic UI, latency compensation, and real-time updates. However, the BlazeJS code wasn't composable and didn't lead to good reuse, as it was already overly abstracted. It also carried with it a lot of baggage from the default HTML DOM. We have enjoyed React's functional components, deterministic rendering, testability, composability, and widespread support. It's taken some time to get used to, but fits in very well with a functional programming style. We had also taken a look at AngularJS components, but they were always half-baked in comparison to the active React community.

READ MORE
2 upvotes91 views