Symptomatic, LLC

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

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.

READ MORE
2 upvotes20 views

As an network mesh technology, a recurring design challenge for us is to create isomorphic (same-shaped) javascript code that supports FHIR data anwyhere... server, client, database, tooling, microcontrollers, etc. That means compiling our code to both Android and iPhone; and to both Windows and Mac and Linux. Electron gets us our desktop deployment and is our gateway into the world of Windows.

READ MORE
2 upvotes18 views

We use XCode for compiling our Javascript to iOS. We do that using Cordova/PhoneGap, a bridge technology that runs the javascript in a dedicated UIWebView on iOS. Doing so suffers a performance penalty because we're running interpreted code instead of native, so it's often a bit sluggish compared to native apps. We're looking forward to see how much WebAssembly can improve on things; and until then, we focus on having real clean UI code. If all the components are functional, tested, don't have side-effects, and are non-blocking, then even the interpret code can feel like a native app. It takes a lot of discipline to write clean Javascript code that can do that, though. Lastly, we use the Meteor pipeline to launch XCode as a build step.

READ MORE
2 upvotes17 views

Babel was included with Meteor, by our upstream technology provider MDG (Meteor Development Group). It translates different dialects of javascript. I'm not sure if it's more help or hindrance, but it mostly gets the job done and I don't have to fuss with it's controls too often.

READ MORE
2 upvotes17 views

There aren't many static language analysis tools out there for Javascript. As I understand it, that has a lot to do with it being an interpreted language. But it may also be to ESLint having gotten out in front of the problem and having a fairly huge library of options it supports. It's what most everybody uses and is considered a best practice. So that was mostly good enough for us, since it gets the job done.

READ MORE
2 upvotes16 views