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?