Webinar

Last week Brian Murphy (from Chilmark) and myself gave an Orion Health sponsored webinar entitled “The Future of Healthcare Integration: FHIR® and How It Supports an API-Based Ecosystem” – Brian spoke about the need for such an ecosystem, and I talked about how FHIR could support it.

The webinar appeared to go well (though it’s hard to tell from the presenter end!) but what was great was that we had a lot of questions – many more than we had time to address. So It thought it might be useful to give at least my answers to them – as detailed below. As always, these are my own opinions – feel free to agree or disagree in the comments below.

Oh, and here’s a link to the recording – currently you still need to register to view it – I’ll update the link if I get a direct one.

Does this replace HIE or is it an empowering way to do hie?

I think it’s empowering & enhancing rather than replacing. An HIE is a way of storing information that should be shared amongst those participating in a persons care (including the person themselves) and FHIR enables that by defining a common way of representing the content of that information as well as ways that it can be shared & packaged.

Does this support a push model? Or is it primarily pull? Is there mapping layer for HL7 2x?

There is work being done in defining push API’s for FHIR – details here: http://hl7.org/fhir/2015May/pushpull.html and http://hl7.org/fhir/2015May/subscription.html and will likely be enhanced in future revisions of FHIR.

With regard to v2 mapping, each resource has sample mappings to a number of previous versions including v2 – accessible from a tab at the top of each resource description. However, as v2 implementations are notoriously different, it is likely that each implementation will require some custom work. This was the motivation for the enhancements to the Rhapsody integration engine, with a sample scenario here: http://fhirblog.com/2014/10/06/fhir-messages-part-2/

Can you implement FHIR on a cloud based platform?

Absolutely! Indeed, such an implementation is likely to be very common – especially with newer systems, and where there are existing cloud based systems that need to implement FHIR.

How is FHIR API the common interface to join the consumers and holder of information (referring to “Establishing the Ecosystem” slide?

When systems need to share data, they need to have a common way of representing data, a common way to actually move it around and a common language. FHIR establishes the first two in a simplified way that makes it easy for systems to use. The common language is supplied by Terminologies – such as LOINC or SNOMED to which FHIR refers.

It also helps that FHIR follows commonly accepted standards in the way that it represents both resources and the API for exchanging those resources.

When, in your opinion, will FHIR have truly been able to demonstrate success and therefore be ready for widespread use at scale?

Hard to be sure. There is one national programme that is about to go live with the first version of FHIR – they believed that even that early version was better than trying to do it all themselves, so it will be interesting to monitor their progress.

I tend to the optimistic and believe that it will be in months rather than years.

Is there any standardized security for FHIR or is that up to the implementer?

The standard does make recommendations – such as the use of encrypted connections (TLS/SSL) and OAuth2 as an authorization standard, but otherwise quite deliberately stays out of this area. The philosophy is to provide the ‘hooks’ that can be used by the well tested systems that are already in place. Here is more info: http://hl7.org/fhir/2015May/security.html

Where do the top 5 EHR/Ancillary vendors stand in adopting the standard framework?

Most – if not all – are actively investigating FHIR. The Argonaut project (http://www.hl7.org/documentcenter/public_temp_C5E8F68B-1C23-BA17-0C64A05A28B71EAA/pressreleases/HL7_PRESS_20141204.pdf and https://hl7-fhir.github.io/argonauts.html ) for example was established and is funded by vendors who see FHIR as a way forward for them in providing interoperability solutions.

If I already am the owner of a large legacy system, what is the best approach to FHIR? To start with the edge use cases I don’t already accommodate well or at all? Or to start rebuilding my platform from the center out?

Hard to give a definitive answer. Edge cases are often so because they are less common than other ones and so less useful. An approach that many are taking (including Orion Health) is to start by creating ‘façade’ FHIR interfaces to existing stores, and then adding services as needed to support new initiatives – especially in the mobile area.

Because of the interlinked nature of FHIR with many references between resources, it is generally necessary to provide at least read-only access to common resources such as Patient and Practitioner.

Will FHIR replace CCD or C-CDA?

Unlikely in the short term (though they will co-exist) due to the investment that many jurisdictions have made in CDA, but certainly in the longer term. The ease with which FHIR can represent coded data for exchange is going to be attractive for many.

Will you still need to use interface engines with FHIR?

If you’re in an environment where there is are lot of v2 messages which need to be created/understood such a tool is going to be invaluable – at least in the short to medium term (which is why we added the new functionality to our Rhapsody Integration engine). The same applies to CDA – though these documents are rather more tricky to decompose.

Who should spend time learning about FHIR now?

Everyone. Well, at least everyone who is interested in how clinical information is created, exchanged, stored and manipulated. One of the neat things about FHIR is that you don’t need to be an expert in IT – or in health – to understand what the resources mean.

We’re also starting to develop tooling – like http://clinfhir.com/ that presents a simpler User Interface on top of the resources – while showing how the resources contents map to clicial concepts. These tools are still early stage, but will mature over time.

We also encourage people to feed back into the specification either through channels like skype or Stack Overfow or directly from the spec – every page has a link at the bottom that allows comments to be made.

still not yet quite sure what fhir is. is it a replacement for connect or something or direct or soap?

Think of it as the way to represent clinical information, and the way to share it with others. The technologies mentioned could certainly use FHIR resources and other artifacts if needed. There is a workgroup within HL7 actively working on SOAP based services – see: http://hl7.org/fhir/2015May/services.html

What is the security model? Auth model?

As mentioned above, FHIR makes some recommendations rather than defining these models. More details here: http://hl7.org/fhir/2015May/security.html

How many participants on this Webinar?

I believe there were over 200

Where did the fhir repository come from? is this a virtual repository based on all ehr’s?

If this is referring to the FHIR repository in the ecosystem page, then it is intended to represent any repository that exposes FHIR interfaces. This could be a ‘façade’ to an existing system or a native FHIR based repository, and there are examples of both approaches under development.

Are there examples of production FHIR implementation with an EHR vendor in the wild? I heard Duke University in the U.S. is working on one with Epic?

Not really able to ‘name names’ without permission. Certainly Epic (and the other major vendors) are very active in FHIR development.

I did not hear you mention HIPAA compliance. Maybe I missed it. How does the “ecosystem” you are proposing meet HIPAA requirements.

In the US it would certainly need to, but the details – like security in general – are ‘around’ FHIR rather than part of it.

How many organizations are supporting FHIR in production?

Difficult to say at the moment. There are quite a few pilots out there though and the national system going live in a month or so. I think that DSTU2 (expected around August) will be a real catalyst – especially with the support from project Argonaut.

Does FHIR support real-time notifications to a client (such as webhooks)?

Sure. All you need to do is to use FHIR resources as the payload.

Can FHIR work well with other alternative way like FTP etc

No reason why not. You’d need to persist the resources (or more likely bundles) as files – XML or JSON – but that should be straightforward.

How fast would the data exchange rate is using FHIR? Is it by internet speed?

Depends entirely on the underlying infrastructure. The resources themselves are as small as possible (certainly compared with v3) – though there’s a minimum size you can go to. There is an initiative to create an even smaller method of representing FHIR resources on the wire – specifically to support mobile, but would work anywhere. I’m not sure how far that project is along.

can you comment argonaut — the complementary efforts to speed FHIR adoption

Very positive. It showed how the vendors are ‘on board’ with FHIR which is especially gratifying as it was aimed at implementers. Important to note that Argonaut is not a ‘fork’ of FHIR – it merely provided funding for the volunteers who are actually doing the work to accelerate develop of resources and profiles. There’s an enormous amount of work that these guys are doing – and generally in their own time.

Which EHR vendor have already accepted FHIR?

I think that most vendors of any size who are in tune with the market realize that FHIR is now a certainty. It’s no longer ‘if’ as much as ‘when’. The actual reaction varies from active involvement to maintaining a ‘watching brief’. Most, fortunately, are in the former camp!

How well does FHIR allow me to bring in legacy data that was coded or exchanged in HL7 v2, for example?

Very well. In fact, much about FHIR was influenced by v2 which has to be one on the most successful standards on the planet – after all it was first released in 1987, and is still in wide use. There is a good correlation between the segments in a v2 message and resources. And, as previously mentioned, there are sample mappings to get you started, though due to the variability of v2 implementations, an integration engine is going to be an essential tool – at least in the early days.

CDA is likely to be trickier. CCDA should be OK – and one of the goals of the Argonaut project is to give concrete guidance here – if not tooling to convert between CCDA & FHIR. Custom CDA implementations will require extra work though.

Where on the Internet you can go to get information?

The HL7 wiki (http://wiki.hl7.org/index.php?title=FHIR ) is a good place to start, and the specification itself (http://hl7.org/fhir/index.html ) is surprisingly readible for a healthcare standard. (Note that the link above is to the current DSTU1 spec – the DSTU candidate is at http://hl7.org/fhir/2015May/index.html.

There are a number of people who blog regularly on FHIR. My own contribution is at http://fhirblog.com/ , but Grahame Grieve (who started the whole thing) is at http://www.healthintersections.com.au/ , Furore (a Netherlands company that have put significant resource into FHIR, developing many of the tools at http://fhir.furore.com/ and http://thefhirplace.com/ and Rene Spronk of Ringholm (http://www.ringholm.com/column/rs_last_en.htm ) is an assiduous collecter of FHIR related videos https://vimeo.com/channels/hl7fhir .