HL7 Argonaut FHIR

announce
1

Hi all,
I’m excited to announce that the Clinical/Healthcare Working Group seems to be rallying around the recent HL7 Argonaut FHIR Phase 2 initiative, and we’re going to be adding HL7 FHIR as a new subproject to the Clinical Meteor Track. We’ve secured sponsorship, funding, and participation commitments from both university and corporate parties, and are going to be setting up HL7 and OAuth2 testing sprints through the rest of the year.

Some of the involved parties are in startup stealth mode and/or operating under NDA agreements; so for the time being, suffice it to say that this initiative is being spearheaded by the University of California at Santa Cruz, the Open Genomics Core, and the Open Health Imaging Foundation. We have at least two corporate entities that have pledged to devote resources this autumn as well.

As such, I’m opening up this thread for anybody interested in integrating HL7 and/or OAuth2 services with Meteor. This thread is for introducing yourself to the Meteor/FHIR community, system architecture discussions, exchange of implementation resources, and coordinating test sprints.

If you have any questions, please feel free to post them here. We’ll be adding more details as they come in.
Sincerely,
Abigail

HL7 Argonaut FHIR Homepage
Argonaut Project Implementation Program
Argonaut Project Google Group
Sample Patient Data
NodeOnFHIR
node-oauth2-server

Implementation - Sprint-1

10 Likes
2

So the Argonaut FHIR had it’s first organizational call today, and released some documents, including the Implementation - Sprint-1 wiki page…

Welcome to Argonaut’s first implementation sprint!

We’ll focus on the basics, beginning with two FHIR API calls that every participating server should expose, and every participating client should invoke:

GET /Patient/{id}
Retrieve a patient’s basic demographics and identifiers, given a unique patient id. Think of this as the “Hello world” of FHIR.

GET /Patient/{id}/DocumentReference?type={}&created={}
Search for available documents about a patient, given a unique patient id. Optional search parameters can filter results on:

  • type a code describing this document (see below for details)
  • created creation date

So, it looks like we have some endpoints to implement. The question is… which REST library does Clinical Meteor want to use?

Given that we need to write an API that conforms to the FHIR standards, my inclination is towards using nimble:restivus

@corvid - I think you may find some interesting reading on the Implementation-Spring-1 document. In particular, the Argonaut project is going to be implementing a full OAuth 2 implementation over the upcoming weeks; and if you cross-reference with the Sprint 1 Spreadsheet, it looks like folks will have access to specialist from Epic, Cerner, UC Santa Cruz, McKesson, Aegis, etc.

3 Likes
3

Hi Abigail,
I am curious - what will HL7 Argonaut FHIR enable for an application built using Meteor? What are some examples of the kind of interoperation it would enable for our Meteor app? Thanks!
Dave Donohue

1 Like
4

Hi Dave,
So, the idea behind HL7 FHIR is that the EMR industry last month collectively decided to join the 21st century, and start using Restful interfaces as an interoperability standard.

Before HL7 FHIR, the standard for HL7 had been point-to-point communications; and the industry best-practice for any web services was to use WS-Security. (Personally, I think people chose the technology in part because of the SOAP acronym, knowing that it had the right branding to be sold within the industry; even if the underlying technology was a nightmare.)

Anyhow, HL7 FHIR is an industry initiative to bring Restful OAuth2 interfaces to EMR systems. As such, we’ll probably be looking at two packages: an HL7 FHIR focused OAuth2 server; and an an HL7 FHIR client. The client may very likely to be simply forked from the existing account-oauth packages that make accounts-facebook and accounts-github work. The server is going to be a bit more difficult, and require us creating an OAuth2 server; and then packaging it up.

The traditional architecture approach for an HL7 interface would be to have an inbound query log; so it’s very possible we’ll expose an HL7 collection with hook and triggers, that the rest of the application can inspect and interact with. The HL7 FHIR package’s job will be to set up the OAuth2 server, authenticate requests, parse the API endpoints, log the query to the interface log, then fire off various hooks and triggers.

We’ll probably need to create a reference implementation of FHIR/MeaningfulUse compliant collections and/or create a rules engine for applications that choose not to use the reference implementation.

With all that said-and-done, we should have one or two packages that will allow us to connect to the following electronic medical records, healthcare networks, healthcare information exchanges, research networks, and provider networks:

Accenture
AcutalMeds Corp.
AEGIS
Aetna
Akana
American Medical Association
Amida Technology Solutions
Apigee
Applied Informatics
athenahealth
Bespoke Systems
BIDMC
Care at Hand
Carebox
Carefluence
Carolinas HealthCare System
Cerner
CipherHealth
DoD/VA
Drajer LLC
Duke Medicine
EMR Direct
Epic
GE
Geisinger
Hackensack University Medical Center
Health Samurai
Infor
Intermountain Healthcare
InterSystems Corporation
Massachusetts eHealth Collaborative
Mana Health
Mayo Clinic
McKesson
Medfusion
MedicaSoft
MEDITECH
MITRE
MobileSmith
ModuleMD
NavHealth
Netsmart
NextGen
Office of National Coordinator
Optum (UnitedHealth Group)
Orion Health
OSIA Medical
Partners Healthcare
Pokitdok Inc.
Practice Fusion
Premier Inc
Qvera
Redox Engine
Reliant Medical Group
River Rock Associates
RxREVU
Surescripts
The Advisory Board Company
The Sequoia Project (formerly Healtheway)
Trinity Health
UC Santa Cruz
UPMC
US Postal Service
Vetter Software
VigiLanz Corporation
VSee
xG Health Solutions
Xperterra

So, it’s a pretty significant initiative; and will position Clinical Meteor as being interoperable with all the major players in the future!

2 Likes
5

Oh, snap!

HL7 just arrived in the Meteor ecosystem.

http://hl7-argonaut-fhir.meteor.com/
https://atmospherejs.com/clinical/hl7-fhir

It’s super basic; but it’s almost the entirety of the the Sprint 1 Implementation spec. Still need to figure out to add the Authorization: Bearer {server-specific-token-here} token to Restivus; but otherwise… I think we’ve got something to begin iterating with.

2 Likes
6

Ooof. Just landed in Santa Cruz (yay!), and am looking at the Argonaut Sprint 2, and it involves a basic OAuth2 implementation.

I’m considering creating an Atmosphere wrapper for the oauth2-server package, and then adding it to the hl7-argonaut-fhir package.

Any discussion, comments, recommendations, or thoughts would be much appreciated.

1 Like
7

Hmmm… Sprint 3 Docs released, and we’re starting to fall behind a bit. Anybody who wants to dive into OAuth and security, please give me a ping.

1 Like
8

Hi @awatson1978 what is the status of this? I am a bit lost on the state of this project and what is would yield in terms of capabilities.

9

Hi @dpdonohue…
The status is that it’s going a lot slower than I’d like! :confused:

Are you familiar with HL7? It’s an interconnectivity standard between EMR and healthcare systems. It’s the interconnectivity standard. This project gets Clinical Meteor apps connected with the rest of the healthcare ecosystem. Simple as that.

A little backstory: For a long time, HL7 was based on a peer-to-peer protocol. But in the last year, the healthcare industry finally decided to join the 21st century, and adopt HTTP and RESTful interfaces into the HL7 standard. So, HL7 FHIR is the HTTP version of the HL7 protocol. Everybody will be using it and supporting it. All the big players are already on board.

So this project is simply about getting Meteor apps connected to existing EMR systems (and letting existing EMR systems get data from a Clinical Meteor app).

It does involve building an OAuth2 server, however, which is where we’re currently at. :frowning:

But we’ve been doing a lot of research, and have found a non-Meteor group to collaborate with, who are building an HL7 FHIR interface for their Mongo database using Express (I think). So, we’re got some leads on how the data collections should be architected (they’re using a PatientData collection with huge records). And they’ve also mentioned that they’re using the oauth2orize package, which is what I’m now looking at.

https://www.npmjs.com/package/oauth2orize

I think there will be a lot of movement in November on this.

1 Like
10

From a pragmatic perspective, here’s a use case of it in action:

  • St. Mary’s Hospital has an EMR system called OldPracticeManagement.
  • SpiffyStartup is using Clinical Meteor to create a new app called SocialHealthRecord.
  • SpiffyStartup contracts with St. Mary’s Hospital to provide a PatientPortal to OldPracticeManagement, using their shiny new SocialHealthRecord app.
  • As part of the contract, they set up an HL7 interface between St. Mary’s and SocialHealthRecord.
  • Jane Doe moves to a new state, and registers in a new healthcare plan HappyPatients.
  • Jane visits St. Mary’s Hospital, where she doesn’t exist in OldPracticeMangement.
  • The receptionist creates an account for her in OldPracticeManagement system.
  • The HL7 interface then sends a message to SocialHealthRecord and tells it that there’s a new patient named Jane Doe in the system.
  • SocialHealthRecord can later query OldPracticeManagement for a list of Jane Doe’s medications using the HL7 interface.
  • When the Radiologist finishes reading Jane Does’s report, and submits it to OldPracticeManagement, the HL7 report forwards the report to SocialHealthRecord.

And so forth. Interconnectivity between EMR systems. :slight_smile:

1 Like
11

Love it! That is the best clearest update ever. :grinning:
Next question: what can I do to help?

12

Hi Dave!
Well… we have like $15K of work to do, at a minimum. Most of the folks on the Argonaut calls have a dedicated point-person, and are anticipating 6 sprints at 2 weeks each. So that’s 3 months of work. We’ll be working on this through the end of the year. Take a look through the different tabs of the following spreadsheet to get an idea of where things are, and what kind of resources are being devoted to it…

There’s ping-pong testing involved; because there needs to be a dev on each side of the interface. Which means either we need to double the staffing amount of $15K if we do it internally, or we need to partner up with other groups to halve the costs.

Now, it just so happens that that we have a contact with Furore, who are the folks building an HL7 FHIR interface for Mongo using Express/Mongoose. They’re interested in partnering up. So, maybe worth taking a look through the following websites as well:

http://spark.furore.com/
http://fhir.furore.com/Tooling
http://sparkblog.emc.com/tag/hl7/

So, all that being said, we have the following resources

So the next step is to add the oauth2orize and restivus packages to the hl7-argonaut-fhir package (which I’m going to do in just a bit), and then we need to try to get an OAuth server working.

http://star.psy.ohio-state.edu/coglab/Pictures/miracle.gif

13

So, I just added the oauth2orize dependency to the package, and started updating issues and milestones on the project:

@dpdonohue - you were asking about concrete things you can do to help… you said that you had a couple of devs you’re working with on Biolog.io, right? Are any of them security or network minded? If so, could you ask them to take a look at this thread?

I ask that with the following caveat: getting the OAuth server up-and-running is a particularly thorny bit of network/security programming. And that’s only Sprint 2. Once that’s done, we have a bunch of more clinical-oriented steps, involving tweaking the APIs to they support various queries for Medications, Patient Profiles, Demographics, Treatment Plans, etc.

So, any programming help you can divert/herd/corral on this… well, it would be of help!

14

Hi,

Have you started on this OAuth2 server? We will be working on creating such a package for Rocket.Chat next week.

Should we join forces?

Best,

Gab

15

Not any more than what’s written above. Been completely swamped getting clinical meteor published and this pediatric cancer project launched.

I’m familiar with OAuth, but my real skills are in database management and data visualization. So this connect middleware stuff has been a bit beyond me. It would be an absolute godsend if you could take a look a the Oauth2 server problem.

Anything I can do to help; just let me know.

16

Ok, my team will have a go on building this package. I’ll send the github repo link once we start.

17

Excited to announce that SimpleSchemas for 24 HL7 FHIR Resource objects and 16 DataTypes have been added to the hl7-argonaut-fhir repository.

HL7 FHIR Resource Schemas - Clinical Track
HL7 FHIR Resource Schemas - Additional
HL7 FHIR Resource Schemas - DataTypes

They’re extremely experimental right now, with no guarantee that all the objects required by the schema even exist within the Meteor ecosystem. That being said, anybody who’s interested in HL7 interoperability or to accelerate their application design will find them a good starting place.

Find the original JSON schemas at the HL7 FHIR Resource List.
https://www.hl7.org/fhir/resourcelist.html

Happy to accept pull-requests on this package from anybody who wants to refine schemas or add additional resource objects.

2 Likes
18

@gabrielengel - any news on the OAuth server?

19

Yes! We’ve got it working on Rocket.Chat

Here is the code: https://github.com/RocketChat/rocketchat-oauth2-server

20

This is fantastic news! :smiley:

Next steps are:

  • use OAuth2 to restrict access to a REST API
  • use the REST API to expose an HL7 resource (as defined by a simple-schema)

We’re almost there! We have all the pieces. Just need to put them together!

1 Like