We are considering using FHIR for sending data captured via a local care pathway form to a regional provider and we’re trying to understand the pros & cons of the Messaging paradigm vs the RESTful.
The data on the form will likely comprise items from numerous FHIR resource, so an update to the provider/server will need to update various resources. The pathway form may be repeatedly updated during it’s lifetime so updates to the provider/server will be iterative. And the data captured is based on data held locally, not at the provider, so any identifiers will be ours (not the regional provider’s/server’s).
I understand the Messaging specification is “not provided to fill any functional deficiency in the RESTful API” so I’m assuming RESTful can fulfil these requirements. However, I’d like to understand the practical implications of one method over the other (possibly in terms of message orchestration).
Can anyone point me at a useful practical comparison?
I gave a presentation at DevDays that covered some of this, but it won’t be publicly available for 6 months. The general rule is that REST will give you greater interoperability with more systems.
With REST, the data structures (the resources) and the allowed operations (create, search, update, etc.) are all nailed down. Systems only need to decide which they’re going to support.
With messaging, there’s a need to negotiate and agree on what the message event codes will be, what behavior they’ll drive, what resources will be included in the message bundle, and what the allowed responses will be. As a result, messaging will only function in an environment where the participants have performed additional negotiations to agree on all of those things - and then customized their systems to support them.
A simple example is that all of the public test servers support all of the REST operations, but none of them support messaging (because the author of the test servers can’t know what messaging events might exist, nor have the logic to ‘process’ an arbitrary message).
Messaging has a few benefits:
It allows data to be processed asynchronously (i.e. response comes outside the HTTP timeout window in which the request is posted) - though Task can achieve that end so long as there’s a system that can hold the Task and allow both sender and receiver to update it
It allows routing of information through multiple intermediaries. (While RESTful servers can proxy other interfaces, there’s a limit to how deeply these can stack without running into performance issues.)
It doesn’t require persistent identity on the information shared (though ‘contained’ resources can work around this in some situations)
It doesn’t require persistent identity on the information shared (though ‘contained’ resources can work around this in some situations)
On this point, would the RESTful process be to create/update all referenced resources first, and then use the server’s logical resource ID of those dependencies in subsequent resources that referenced them? It looks like such reference/dependency complications can be overcome via a batch/transaction REST operation, is that correct?
The persistent id issue is more about query. If a system doesn’t have a persistent identifier for something, it’s hard to make it available consistently at the same location (or update it to the same location). Obviously if you can store someone else’s id, you’re fine. But if you’ve got a v2 back end, you may not have any ability to pass data back into the system.
I’ve been trawling the documentation but struggling to confirm… can/does a FHIR server allow an API create operation (with no id) to update a resource if it’s found to already exist?
We have no intention/desire to persist & reuse the regional provider’s logical resource id - it would make sense for us to keep sending the resources as we know them to the FHIR server, and allow the server to manage the create vs update part.
There’s got to be a pretty well established use case for this, I’d have thought?
The FHIR spec allows for conditional update (create resource if not already exists based on some search criteria supplied by the client, else if found 1 match then update existing resource) however it is up to the FHIR Server implementation to support this ‘create as update’ aka upsert
eg of a conditional update request PUT [base]/[type]?[search parameters]
Thanks Blessed. I dismissed the upsert paragraph as it proposes a client designated logical ID on the proviso that all systems adhere to a local policy to avoid clashes. That seems a bit… rogue somehow!
I think conditional updates is what I’m looking for. I hadn’t noticed the “No matches, no id provided” action. That’s a shame, and surprising, it’s only for trial use but good to see it’s there.