Clinical Track - RC20 - Interoperability, SMART on FHIR, Blockchain

awatson1978 · July 4, 2018, 9:45pm

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.

Release Page
http://clinical.meteorapp.com/release/1.6.0.1-rc20

Usage
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@1.6.0.1-rc20

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

git clone --recursive http://github.com/clinical-meteor/software-development-kit
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.

SMART on FHIR
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 abigail@symptomatic.io 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 https://open.epic.com/Interface/FHIR for details on the Epic implementation of FHIR.

Allergy Intolerance
Bundle
CarePlan
Condition
Device
Diagnostic Report
Goal
Immunization
Medication
Medication Order
Medication Statement
Observation
Organization
Patient
Practitioner
Procedure

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

Blockchain
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
LOINC Web API
Open mHealth Schemas
Node/Python bindings

storyteller · July 5, 2018, 8:17am

Any chance that we could see PRs with some of the functionality that you added to the oauth packages so that they could become more versatile or have your changes been hard-coded (ie. needing patientId instead of it being an option for the provider)?

awatson1978 · July 5, 2018, 4:00pm

Yes, PRs could be doable. The patientId logic is contained in it’s own package. It’s easiest to think of it as an accounts-ehr package, analogous to accounts-google and accounts-facebook. We’ve tried to keep oauth and accounts-oauth as close to the originals as possible. The largest changes to those packages were:

a) putting in robust console logging (enabled with an environment variable)
b) improved debugging messages
c) making the code less terse
d) sequence diagram and documentation
e) handling of the popup dialog (particularly the callback)
f) the /oauth route is based on Meteor.absoluteUrl() and doesn’t handle PORT value

In general, the terseness was hiding edge cases which we need for the hospitals. Throwing errors and failing fast, instead of parsing a returned authentication token that had a patientId along with it. That sort of thing. It looks mostly the same; but a stray return here; or a terse if/else statement there was causing it to fail for the hospital OAuth servers.

If we were to actually put a pull request together, it would mostly boil down to deciding if the environment detection we’re using for debugging makes sense to go into core; implementing a getIdentity() helper function for the patientIds; patching the Meteor.absoluteUrl() call to include PORT; and pulling in the less-terse logic.

I’m not necessarily inclined to spend a lot of effort though. When I’ve tried to create pull requests in the past, there’s always been an excuse of one reason or another why the change shouldn’t be accepted. It’s like pulling teeth. Or arguing with my 20 yr old nephew. I’m kinda cynical about the process nowadays.

If people want the improved code, we’re sharing the improvements and making them available in the following packages.
https://github.com/clinical-meteor/oauth
https://github.com/clinical-meteor/accounts-oauth

I just don’t have the bandwidth to try to convince people of why this needs to go into core. Easier to fork and maintain in a separate release track.

vooteles · July 5, 2018, 8:47pm

Don’t have any knowledge or interest in medical topics personally, but let me just say that it is very positive to see these kind of enterprise-y projects on Meteor. Gives the whole framework a little nudge in a, in my opinion, good direction. With or without pull requests.

storyteller · July 6, 2018, 6:34am

I get you. Do what ever you think is necessary. There is a huge update underway for accounts packages, so I think now is the best time for stuff like this.

so1oonnet · July 21, 2018, 2:09am

Could you share the test scripts you have under meteor-on-fhir-validation?

awatson1978 · July 21, 2018, 4:22am

Not publicly. We might be able to do something under Non Disclosure Agreement and a license; particularly if you’re actively submitting to the FDA or ONC or other regulatory body.

We consider those tests to be intellectual property. Particularly considering the negative pushback we received when we tried to include the Nightwatch testing framework in the Velocity project. People didn’t want our contributions then; and we had to watch all of our contributions get actively deleted and removed by self-appointed community members. That window of opportunity has closed.

We’re wiling to consult and help people set up their own testing; and to provide Six Sigma quality improvement consulting. But the QA tests aren’t open source. Sorry.

a.com · July 21, 2018, 7:06am

Bravo! Open source is great but at some point people have to make a living.

so1oonnet · July 21, 2018, 1:15pm

I understand. Just curious about the ci pipeline and if there is anything you had to do in the tests to make it work. We ran into some issues with circleci pipelines on a project. Your circleci config was very helpful. Thanks!

awatson1978 · July 21, 2018, 3:38pm

If you’re just looking at circleci pipelines, your best bet is probably to take a look at any of the core HL7 Resource packages. They’ve got a .circleci/config.yml file that pulls in a tests/Foo.tests.js file. It’s basically everything you need for an integration test.

Importantly, it’s using meteor test, so doesn’t need any external libraries for the test harness and can inspect internal code like a unit test or verification test. Here’s how to create a baseline app, set up React, install a DDP based microservice, hoist the package into place, and run an integration test.

github.com

clinical-meteor/hl7-resource-observation/blob/master/.circleci/config.yml#L102-L127


- run: cd .. && meteor create --release METEOR@1.6.0.1 --bare baseline
# - run: git clone https://github.com/meteor/todos -b react


- run: cd ../baseline && meteor --version
- run: ls -la


- run: cd ../baseline && ls -la


- run: cd ../baseline && meteor npm install
- run: cd ../baseline && meteor npm install react
- run: cd ../baseline && mkdir packages && cd packages && mkdir hl7-resource-observation 
- run: cp -R ./* ../baseline/packages/hl7-resource-observation 
- run: cd ../baseline/packages/hl7-resource-observation && pwd
- run: cd ../baseline/packages && ls -la


- run: cd ../baseline && npm i --save-dev selenium-webdriver@3.0.0-beta-2 chromedriver
- run: cd ../baseline && meteor add dispatch:mocha practicalmeteor:chai
- run: cd ../baseline && meteor add clinical:hl7-resource-observation 
- run: cd ../baseline && mkdir imports 
- run: cp tests/Observations.tests.js ../baseline/imports/

This file has been truncated. show original

Of course, this is pretty bare bones compared to the validation tests that Nightwatch does. But it’s generally compatible and roughly the same approach. We’re quite happy with it, and will probably be phasing out the Gagarin tests as a result. It’s also how we run the integration tests for the release track.

so1oonnet · July 25, 2018, 10:20pm

This is great! I was able to setup nightwatch tests on circleci with the config. I have basic tests setup right now - just homepage etc.

How have you setup data for the tests? we are using a script in the server data.tests.js that sets up data for all tests. Curious if you has a different approach.