HL7 Argonaut FHIR

announce
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
21

@awatson1978

Abigail,
We’ve helped ambulatory EMRs and labs with this same issue for roughly the past 3 years: scalabull.com , a sample API we offer to EMRs: docs.scalabull.apiary.io . It seems you may be focused on a more abstract version of the problem - we work primarily between labs and ambulatory EMRs. That said, we would absolutely love to discuss merging efforts and helping you if it makes sense!

You seem knowledgable regarding this space, so I may be stating the obvious, but there are a few quirky things that we run into which may be worth having an open discussion around in order to help the project succeed in the lab-EMR space. I don’t mean to hi-jack your thread, but I think this could be interesting information for some people browsing thru! Would love to hear your thoughts:

  • We regularly see that CAP requirements imply that labs need to do some degree of testing when connecting to an external EMR. This is a bit gray, but usually labs are requesting screenshots or PDF reports that reflect the EMR display of results or requisitions for every single interface, and generating / adjusting these is often the most tedious part of the interface setup process. Even with a modern system based around the latest technology, there is still a labor-intensive setup process… Part of our service to partners is that we automate this testing process - it’s gotten some good feedback from labs. If a process for this setup phase is included in the protocol (thus avoiding the manual labor), labs have a tangible cost incentive to adopt & support the protocol.

  • Maybe around 80% of the labs we encounter are partnered with 3rd parties that handle EMR connectivity on their behalf, and it seems that’s mostly because labs don’t often employ software engineers. Scalabull falls into this 3rd party bracket, as do companies like Halfpenny, 4Medica, Lifepoint, Emdeon, etc. (I’ve seen reports of about 30 service providers in the industry, with around 10 of them handling most of the connections). Although, I believe our new beta solution is the cheapest & most efficient for labs by a factor of 10x (disclaimer, I’m the founder of Scalabull :stuck_out_tongue: ). But, a new highly-efficient protocol could be smothered in the lab-EMR space unless you can find a way to align with or work-around these ‘hubs.’ For many of these companies, this is a threat to replace their business model as they typically charge a flat fee for every single HL7 connection created to an EMR, so it may be tough to get them onboard if you’re providing a more efficient way to do things and replacing their billable hours… It would be possible to work around them if leveraging the protocol requires very little manual labor on the lab’s part and if you can automatically distribute the update to the lab’s EMR/LIS installation, e.g. allowing the labs to use the new protocol without the hub’s intervention… We don’t charge per connection (our model is unlimited connections for $x/month), so we’re more than happy to align with something more efficient.

  • Admittedly, we don’t have vast exposure to the different EMRs in the market, but right now in the ambulatory EMR space it seems most vendors are looking to support ordering in an efficient way. I’ve seen that the long-standing EMRs have offered this service for some time now, and MU2 certified EMRs generally seem to have the technology - although I don’t see many EMRs actually creating these bi-directional connections at scale. However, maybe if the server applications you’re creating include straightforward ways to access test compendiums, requisitions, and specimen labels for laboratories, this would remove a large part of the manual setup process for EMRs and they may be willing to take the time to add OAuth support to cut their bottom line. We give EMRs a way to grab this information from us via an automatic API, and I would say it’s our strongest selling point to partnering with new EMRs.

  • I think the most recurrent issue I run into is that almost all ambulatory EMRs charge fees for interfaces, and therefore labs can usually only afford to connect a few clients at a time. We see a good deal of labs having to turn-down interface requests from clients because of this price wall. And, having worked on the EMR side, we are guilty of charging this fee as well - simply because there is a labor intensive process for creating new connections to labs… If this new protocol gives EMRs a way to instantly connect with labs (and includes all automatic testing procedures), there might be a way to waive the fees since connections would require zero effort on the EMR’s part. That said, in practice it will probably be a little bit of push & pull: if you can help reduce the fees that EMRs charge, labs will be more willing to use the solution, but if the fee reduction isn’t practical for EMRs they won’t use the protocol in the first place… Putting this argument differently, most EMRs are charging money for interfaces and they may be hesitant to adopt a protocol that removes their HL7 interface revenue stream. In our experience, this has been the #1 reason EMRs don’t want to rely on a 3rd party like us - they either have a process that is profitable or sustainable and there aren’t tangible reasons for them to tamper with this.

  • Roughly speaking, I think LabCorp & Quest make up about 40% of the EMR-lab interface projects we complete for EMRs. And in order to complete those projects, we first had to go thru a pretty tedious certification processes for their protocols. After spending a year developing and testing solutions that conformed to LabCorp & Quest’s standards (which combine the industry standard Hl7 interface process with web services), we can much more easily set up connections with labs that are using the standard HL7 interface process. On one hand, finding a way to combine efforts with LabCorp & Quest could possibly put your protocol in the hands of most ambulatory EMRs within a few years. On the other, not being aligned with them raises some complexity for most of the ambulatory EMRs - they’ll have to support yet another format and it may not be a priority.

    Hopefully this doesn’t come off as off topic, or over-complicated :worried: Do these points resonate with your experiences? Are we approaching the same problem?

Since Scalabull is a relatively young company, I do have to be careful about where we can spend our time so that we’ll be around for years to come. That said, if you feel we’re aligned, I’d really love to help build-out and push this initiative forward. The caveat is that we’d need to find some funding thru the project or find another means to justify this from a revenue perspective. I’m happy to seek that out independently, but would also like to discuss that with you since it seems you’ve been able to do the same.

Would love to chat with you (or anyone else interested in this topic reading over this thread). Feel free to reach out to me at zach at scalabull dot com!

Thanks!
Zach Boldyga

3 Likes
22

Hi Zach,
Welcome to the Meteor forums. Great insights; great comments.

So, yes… not to put too fine a point on it, but HL7 FHIR stands to drop the bottom out of the integration services market.

My experience has been that HL7 integration is usually something like a $5,000 line-item on systems installation. Buy a digital microscope; centrifuge; ultrasound scanner; voice recognition system; whatever… somewhere in the bill will be a $5K installation fee for HL7 point-to-point bidirectional interface. At the hospital I used to work at, we had 30 interfaces when I began; and probably 50 when I ended. It was enough to keep a few people employed full-time just doing HL7 interface work (and on-call).

With HL7 FHIR, however, we have a RESTful interface with one-to-many connections. So, we’re anticipating there to be a $5K to $10K installation fee to set up a FHIR server (depending on LDAP integration; hardware installation etc.) with something like a $1,000 fee per resource (which will mostly involve writing a SQL query at the ORM layer). If a hospital wants to implement all 100 resources, that will still keep one of those HL7 analysts busy for most of a year; but once each resource is mapped, the analyst will have effectively finished the job and can move onto other projects. In effect, it’s a write-once, read-as-much-as-you-like interface.

Device vendors should be able to get interoperability for $15,000 or so, since they’ll only have a few (3 to 5) resources to implement.

Once a lot of the initial mapping is completed, it should be a paltry $250 to write the AJAX to connect to a pre-existing FHIR server; and we’ll see bidirectional connectivity for as low as $500. Which matches your factor of 10x.

As the price drops, the entire interconnectivity market is going to become much more liquid, and folks will begin bypassing the hubs; and things will become much more mesh-like. Personally, I anticipate peer-to-peer applications following a WordPress model to become a trend in the consumer market in about 2 years.

As for testing, take a look at both Project Crucible and the Touchstone Project. Most all of the big players are on board with FHIR. So while the hubs, integrators, and exchanges based on V2 aren’t going to be happy that their billable hours are drying up; they all knew that it was stimulus money from HITECH. They’re simply going to have to get more competitive. The EMR vendors however… their main sources of revenue isn’t in HL7 integration services, so they could care less. It helps them to be more accessible, and people are demanding it.

But what I’m really excited about is that HL7 FHIR resources work perfectly well on the database. This doesn’t apply to SQL/Oracle systems; but for JSON datastore like Mongo, we can go from wire-to-database and database-to-wire with no ORM mapping layer. Meaning the FHIR resources are perfectly viable as database schemas, not just wire transfer formats. That means we can seemlessly connect applications to the same Mongo collections as long as the applications use the same FHIR resources. In effect, the HL7 standards committee provided a database spec for writing our own EMR apps and got the big vendors to agree to be compatible. So, we think we can induce demand for HL7 FHIR by simply writing FHIR compliant apps.

As far as funding goes, I just bundle HL7 into consulting arrangements. I’ve yet to meet a company that doesn’t want HL7 connectivity; and FHIR gives an easy standard to rally stakeholders around. Instead of having inane conversations about “Should we call it a Company or an Organization or an Entity?’” you can just point to FHIR and say, “Here’s the schema for an Organization; lets get to work.” And everybody is happy to get on board, because they want to be doing crazy advanced stuff like medication reconciliation or 3D stereotactic surgery or pharmacy robots or genome sequencing… not debating ontologies.

Anyhow, we’ve just about got the FHIR server all set up… we have the OAuth server, the REST API, and the FHIR resource schemas. Now we just have to put it all together. And then connect a sample app to query the server. Plenty of opportunity to participate and contribute.

Best,
Abigail

23

Abigail,
Thanks for the great info!

I agree that REST APIs and modern protocols are without a doubt going to permeate into healthcare, finally. What I find strange about the FHIR initiative is that the reference lab world is not currently participating. There are probably around 100 LIS/LIMS systems with a strong foothold in the market, some of them with a enough manpower to be great candidates for this initiative (e.g. Orchard, LabVantage). Additionally, there are labs that have entire divisions dedicated to creating these interfaces - e.g. LabCorp, Quest Diagnostics, Bioreference. And then there are ambulatory EHRs that would need to adopt the protocols as well for them to have benefits for the labs… I see that Practice Fusion is on the list of participants, which is great news, but there are about 600 additional ambulatory EMRs in the US marketplace. We see many labs entertaining connections to upwards of 100 different ambulatory EMR systems.

I’ve struck up a conversation with some of the FHIR directing team to see if there is any insight into why these parties aren’t participating. In any case, I’ll stop spamming the meteor forum with this info! I’ll let you know if anything comes out of the discussions!

1 Like
24

Can’t speak for the LIS market, but my suspicion is that the ambulatory EMR market is getting ready to have a big shakeup and lots of mergers/acquisitions are on the horizon. The stimulus money created a lot of opportunistic entrepreneurs who were in a race to get a product to market. (I tend to think of them as the ‘rabbits’.) Now that the stimulus money is all but run out, we’re going to see whose business models are on shaky ground; and the career EMR folks are going to start showing the stuff they’ve been working on the past five years (who I think of as the tortoises).

Many of those ambulatory EMR players… particularly the ones that are less than 5 years old… they’re not at the table because they don’t even know that this is a table they should be at. These are also the people who built systems using .Net and PHP on SQL databases and hadn’t been in the business of EMR prior to the stimulus.

Personally, I think this is a great space for these kinds of conversations, because it a) lets others in the Meteor community know that Meteor can be used for these kinds of problems, and b) lets MDG know that there the healthcare community is active and thriving.

1 Like
25

HOT DAMN.

Meteor has the beginnings of an HL7 FHIR server now. As far as EMR systems go, Meteor. Is. On. The. Map.

https://github.com/clinical-meteor/hl7-resource-diagnostic-order

Documentation
Get yourself an OAuth2 server over at prime-8-consulting/meteor-oauth2, complete with some snazzy documentation.

2479×2690 217 KB

FHIR Resources

And then drop in the brand new HL7 Diagnostic Order resource, which uses SimpleSchema to conform to the HL7 Diagnostic Order Resource Schema. This is the first HL7 resource, out of over 100, that uses OAuth2. So, there’s going to be a lot more of these resources in the next month or two, as we ramp up and begin connecting applications to the big EMR systems like Cerner, Epic, Allscripts, etc.

FHIR Resource Response

And a screenshot of accessing a FHIR resource using our OAuth2 access token. Squeee!

1720×1138 141 KB

Contributors
A big shout out to @rodrigok with the Rocket.Chat team for putting together the original rocketchat-oauth2-server.

And another shout out to @vangorra at prime-8-consulting, for putting together the prime8consulting:meteor-oauth2-server and prime8consulting:meteor-oauth2-client packages and demo apps needed by HL7 FHIR, and for putting up with all my unsolicited input, documentation, and pull-requests; and for

And @sashko… bang-up job with simple:json-routes package and the Middleware support.

ChecklistManifesto Example
Oh, and ChecklistManifesto now has support for OAuth2, in theory. A ClientApplication would need to be registered, which there’s no UI for yet. The HL7 DiagnosticOrder resource ships with the OAuth2 server, though… so, yeah, it should be serving up REST routes and be a super-basic FHIR server.

2 Likes
26

This looks really exciting! I’ve been wondering how to use FHIR with Meteor and am so happy to have found this thread.

My background is in critical care informatics, but have been wondering how to develop personal health/fitness apps within an EHR context.

1 Like
27

Yes! Check out Clinical Meteor RC14! We published a FHIR Server, FHIR Client, and 18 FHIR resources!

For a personal fitness app, you’ll probably want to use the following resources as part of your database schema:

Patient
Device
DeviceMetric
Observation
NutritionOrder
NutritionIntake (preliminary)

2 Likes
28

Big news with the Argonaut FHIR project. As part of my graduate school Capstone Project, it looks like I’ve got access to one of the very first Epic 2015 box in production, supporting HL7 over REST protocols. <3

According to open.epic.com, Epic has currently implemented 20 of the 100 FHIR resources. There’s currently an overlap of 11 resources, which have been implemented by both Clinical Meteor and Epic.

Currently Implemented by both Epic & Clinical Meteor
Care Plan
Condition
Device
DiagnosticReport
Family History
Goal
Medication
Observation
Patient
Practitioner
Procedure

I’m currently prioritizing the following 9 resources, which should bring the Clinical Meteor project up to full HL7 interoperability with Epic 2015.

Prioritized To Implement
AllergyIntolerance
Appointment
Binary
DocumentReference
Immunization
MedicationStatement
MedicationOrder
Schedule
Slot

We’ve currently got Argonaut Sprint 2 completed; and now have an institutional backer willing to test Meteor + Epic. This is happening.

So, a few takeaways:

  1. If you have any interest in collaborating on an open-source appointment/resource scheduling module in React… please reach out to me. That’s a pretty clear module that uses the above resources which needs to get made. We have some prototypes; so this will be a maturity level 2 project, where we want to put together an actual working calendaring solution with QA tests, wireframes, interoperability resources, etc.

  2. If you have projects that use any of the above 20 resources; particularly the 9 which need to be implemented… please reach out to me. Creating the atmosphere/npm packages from the standard spec isn’t all that difficult; but we do need stakeholders to actually try to use the resources in production in some capacity.

29

More great news! Apple is adopting FHIR and joining the Argonaut Project!!! :champagne: :confetti_ball: :cake:

So, as of Meteor 1.4, we now have Enterprise Mongo support which provides encrypted data at rest. And now HealthKit is going to support FHIR. That means we’re going to have HIPAA compliant storage on the server and HIPAA compliant storage on the SMARTPHONE. And every Clinical Meteor app that uses the FHIR resources is going to have access to data from the HealthKit apps.

Talk about skating to the puck!

30

FHIR continues to grow. We now have a strategy moving forward for incorporating Apollo and GraphQL queries.

3 Likes
31

BAM!!!
Health Records in iOS 11.3 using HL7 FHIR.

2 Likes