Clinical Meteor - RC20 - SMART on FHIR, Open Epic, Blockchain

Happy Fourth of July!

Wow, it’s been 9 months, and we have maybe the biggest update to Clinical Meteor yet. Interoperability. OAuth. Continuity of Care Documents. Patient Charts. Blockchain. Azure. Security Audit.

Since we last did a release (RC19, Aug 2017), we’ve managed to connect Meteor on FHIR to two separate hospitals, and pull medical charts from both. In doing so, we had to fork the oauth packages from core Meteor. It turns out that oauth and accounts-oauth were optimized for Facebook and Google and GitHub, and didn’t support things like receiving a PatientId. So we forked those packages, and implemented the SMART on FHIR specification (which relies on OAuth). Along the way, we started working with a blockchain project that’s implementing a distributed OAuth algorithm; and that got us involved in writing DApps for BigChain. And that involved expanded support for FHIR Consent, Contract, Subscription, and Audit Event resources.

In short, it’s been a crazy busy 9 months. Hopefully we’ll be getting back to our regular quarterly release cycle, and coincide releases with Working Group Meetings.

Release Page
You can find the release manifest file here, along with previous releases.

Although not necessary to use the individual packages or FHIR resources, you can synchronize an app to the baselined dependency versions by running your app with the --release flag.

meteor --release clinical:METEOR@

Software Development Kit
Download the entire Clinical Meteor Software Development Kit, including examples, utilities, design documents, and other resources.

git clone --recursive
cd clinical-meteor 
git submodule update --recursive --remote --merge

Updated Documentation
There’s a lot of new documentation circulating Clinical Meteor, some highlights which include how to:

And new diagrams explaining how the build pipeline work.

Clinical Meteor has forked the oauth and accounts-oauth package and made modifications to add SMART on FHIR support. This primarily involves a patientId field that needs to be picked up and used; and adding support for OAuth scopes based on FHIR resource types. Each application will have different needs around which scopes it needs to access and what it does with the patientId. For those reasons, it’s generally advisable to create a custom SMART on FHIR client package for each app you’re trying to write. We provide the clinical:oauth and clinical:accounts-oauth packages under an MIT license, and provide links to a sample oauth-client library which you can use to start your integration. There is also a symptomatic:smart-on-fhir-client package available for license. Email for more details.

Epic 2015 Interoperability
Clinical Meteor now supports 60 FHIR resources; including the ~16 or so packages commonly supported by Argonaut members (a consortium of EHR vendors). See for details on the Epic implementation of FHIR.

Allergy Intolerance
Diagnostic Report
Medication Order
Medication Statement

Continuity of Care Document

Once all of the above resources from the hospital’s FHIR Server are received, a Continuity of Care Document can then be assembled. The current release of Clinical Meteor supports building CCD on FHIR documents from 150 of the largest hospitals in the U.S which are currently on FHIR DSTU2.

Turnkey CCD implementations are available as a licensed product from Symptomatic.

Fast Healthcare Interoperability Resources
Meteor support for the HL7 FHIR spec can now be included in a project by adding the clinical:hl7-fhir-resources package.

meteor add clinical:hl7-fhir-resources

For individual FHIR resources, use the search command or Atmosphere.

meteor search clinical:hl7-resource
meteor add clinical:hl7-resource-patient  // to add the Patient resource

Packages Confirmed to Work Together
Each release, we publish a list of packages that are known to work together. As we migrate to NPM, we now have two supported package lists that we are keeping under QA. Use these two files as a baseline for which packages to use.

Atmosphere Package Reference
NPM Package Reference

The following chains are confirmed to work with the Clinical Meteor listed above. In particular, we had near seamless integration with IPFS and BigChain. We’re still sorting out details, but it’s very likely that we’ll be pulling them into core.

  • IPFS
  • BigChain
  • Hyperledger
  • Ethereum

Reference Implementation(s)
Meteor on FHIR
HL7 Argonaut FHIR
Personal Health Record
Checklist Manifesto

Validation/Verification Tests
908 validation assertions passed - Meteor on FHIR Interface Engine
67 verification & integration tests across 67 packages

Pending On Roadmap
Desktop App (Meaningful Use Stage 2)
Continuity of Care Document Import/Export
Facebook Profile Parsing
IPFS AutoSwarm
IPFS Documentation
Open mHealth Schemas
Node/Python bindings