Support for FHIR Subscriptions

Projects FHIR
1

Since support for FHIR subscriptions is something we (the FHIR squad) have been talking about for a bit, I thought I’d let everyone know about some discussions that are currently happening in the broader FHIR community that could affect this.

First, subscriptions have been fundamentally re-architected as part of R5. In R4, subscriptions are (in essence) a search filter and a communication channel, so that when a resource is created or updated such that it meets the search filter a notification is sent. In R5, subscriptions are broken into a topic, which defines the resource(s) for the subscription and the events on which they happen, and a subscription, which is the registration of a communication channel optionally with some additional filtering. You can read more about the redesign and some of the issues involved with subscriptions in this blog post by one of the main authors of the redesign.

R5 is currently expected to be released towards the end of 2021, but keep reading for an update on that.

There is an attempt to map backport some features of the R5 subscription to R4 subscriptions described in the (in process) implementation guide here. This work is very preliminary right now. You can follow along with this work on the FHIR chat system. I don’t know when this work is expected to be finalised, but hopefully before the end of 2021.

Additionally, the FHIR team have begun discussing the possibility of releasing an “R4A” release, which would be primarily about adding some new resources that are slated to R5 and don’t have equivalents in R4 prior to R5 being released. Among those resources under discussion are the changes to subscriptions. If this “R4A” release happens (and it’s unclear that it will), it’s been proposed for early (around April 2021), but it would result in R5 as a whole probably being pushed back to summer 2022. You can follow that discussion on the FHIR chat system.

Concretely, what does this mean for us?

I want to suggest that we (OpenMRS and the OpenMRS FHIR squad) should hold off on developing support for the subscription API for now and reassess when the guidance from HL7 on these moving pieces becomes a bit clearer. The subscription API is very useful for a number of workflows, but is currently in flux and this flux is caused by limitations discovered while trying to use the current subscription API in almost real-world conditions. For cases where subscriptions are useful, it would probably be better to stand-up an independent HAPI JPA server to handle the subscriptions.

Any thoughts or opinions?

@ccwhite23 @bashir @pmanko @burke

2

Hi @ibacher, thanks for this detailed explanation. And thanks for being our FHIR guru and for connecting us to the FHIR roadmap. Such a post is so instructive!

I’d be curious to know what you guys envision to do with the subscriptions, anything concrete that’s on your roadmap that can be shared? Is it related to the lab workflow you guys are working on?

Sorry to not answer your primary question, obviously it’s aimed at the FHIR experts out here :wink:

3

The short version is “everything” :grinning:… or at least everything where we want to feed a FHIR representation of data to a downstream system.

More concretely,the lab workflow might’ve been handled a bit more cleanly (and perhaps in a more scalable fashion) if we could’ve leveraged subscriptions, as things would flow a bit more similarly to how things work with HL7 v2.

Another component that’s being worked on is passing some subset of resources to an upstream shared health record. This is work UW is doing in Haiti. Again, subscriptions aren’t essential, but could provide a way of lessening some of the load.

Finally, we’ve been talking a bit about some FHIR-based change data capture pipelines and the natural way to represent those changes in FHIR is via subscriptions.

Those are the three big things that occur to me at the moment.

4

Thanks @ibacher for the nice summary of the changes to the Subscription APIs of FHIR. As we discussed in one of FHIR squads, I agree that we should not build the FHIR-based CDC solution based on the current Subscription API. Assuming that we do want to create our common Analytics/ETL solution based on FHIR, we should first create a custom solution for bulk/batch transformation of OpenMRS data into FHIR and if we choose to extend it to do the streaming version too (i.e., CDC), we should probably design it in a way that is compatible with the new Subscription API, such that we can use part of it in future to implement the Subscription API of R5.