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.

Fonts and typography are fun. Material Design is a framework (developed by Google) that basically geeks out on how to assemble your typographical elements together into a design language. If you're into fonts and typography, it's fantastic. It provides a theming engine, reusable components, and can pull different user interfaces together under a common design paradigm. I'd highly recommend looking into Borries Schwesinger's book "The Form Book" if you're going to be working with Material UI or are otherwise new to component design.

https://www.amazon.com/Form-Book-Creating-Printed-Online/dp/0500515085

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.

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.

We use Mocha for our FDA verification testing. It's integrated into Meteor, our upstream web application framework. We like how battle tested it is, its' syntax, its' options of reporters, and countless other features. Most everybody can agree on mocha, and that gets us half-way through our FDA verification and validation (V&V) testing strategy.

We mostly use rollup to publish package onto NPM. For most all other use cases, we use the Meteor build tool (probably 99% of the time) for publishing packages. If you're using Node on FHIR you probably won't need to know rollup, unless you are somehow working on helping us publish front end user interface components using FHIR. That being said, we have been migrating away from Atmosphere package manager towards NPM. As we continue to migrate away, we may publish other NPM packages using rollup.

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.

We were long time users of TravisCI, but switched to CircleCI because of the better user interface and pricing. Version 2.0 has had a couple of trips and hiccups; but overall we've been very happy with the continuous integration it provides. Continuous Integration is a must-have for building software, and CircleCI continues to surprise as they roll out ideas and features. It's leading the industry in terms of innovation and new ideas, and it's exciting to see what new things they keep rolling out.

React was a very contentious decision among the Meteor community. We started off with Blazejs, which itself was based off of Handlebars. We liked the HTML-like syntax of Blaze and how nurses, doctors, and other clinicians could become familiar with it. However, the code wasn't very reusable and it was neither modular nor composeable nor testable, and became a major headache to maintain. React solves the problems of composeability and reusability and testing isolation, at the price of having worked the problem backwards and having wound up with a quirky syntax that runs within Javascript that looks similar to HTML but isn't. Nonetheless, React is quickly become a classic example of functional programming techniques, what with its' pure components. All in all, an enjoyable technology to work with that brings some sanity to front-end user interfaces.

Fast Healthcare Interoperability Resources (FHIR) provides standard data objects in JSON format for the healthcare industry. Since JSON objects are hierarchical and tree-like, we had a need to defensively 'pluck' fields from our JSON objects and do lots of mapping. We tried jQuery and Underscore and a few other technologies like FHIRPath; but Lodash has been the most well supported, works in the most contexts, has the cleanest syntax, etc. We particularly like the ES6 version of Lodash, where we can import the method names directly, without resorting to * or _ syntax. We got hooked on the 'get' function to defensively pluck fields from objects without crashing our user interface, and have found countless uses for the other lodash functions throughout our apps. Lodash is great for developing and optimizing algorithms.