FHIR Chat · How to represent the source systems in a restful response?

Stream: implementers

Topic: How to represent the source systems in a restful response?

Johan Eltes (Mar 18 2018 at 17:08):

We (Sweden) has an architecture that depends on the ability for a query endpoint (query existing data) to report the source system origin of each clinical data/record of the response. Each connected EHR system has a nationally provisioned identifier. The data of an EHR may be (locally, regionally) replicated into a regional data hub that acts as the server to which the national intermediary forwards requests to get the requested responses. Each record of the response should contain the identifier of the originating system (EHR) instance. We struggle on how to map that to FHIR. Any ideas are appreciated! Our current case is a restful GET on the Observation resource.

Lloyd McKenzie (Mar 18 2018 at 17:43):

In R4, we're introducing Resource.source, however it's a string. This may be a situation where a country-specific extension would be appropriate. (The alternative is to use Provenance.)

Grahame Grieve (Mar 18 2018 at 20:16):

tehcnically, it's a uri, and it's very much in scope for using it like this

Johan Eltes (Mar 19 2018 at 07:13):

Thanks! I would prefer an II type but a string/URI would do. We could synthesize a "protocol" to represent the coding system. Regarding Provenance - to my understanding- there is no reference from Observation to Provenance? Maybe indirectly via basedOn. But there is - in our case - no necessity that the source system of the basedOn resource is the same as the source system of the Observation.

Johan Eltes (Mar 19 2018 at 07:23):

I had a chat with @Alexander Henket (Nictiz) the other day to synchronize our requirements. Sweden (national reference architecture/HIE) and Netherlands (Spine) share the same architecture for aggregating responses at a national API end point, sourced from multiple local end-points. In order to evaulate the quality of an aggregated response (query existing EHR data), the ultimate client will need a kind of "aggregation report" that - for each consulted source system (as known by the record locator) - states wether data retrieval was successful or not. In our current architecture of SOAP-based end points, Sweden uses a custom response soap header ("aggregation report") that is injected by the aggregating node. Are there any thoughts on introducing concepts related to the use of (aggregating) intermediaries into FHIR?

Richard Townley-O'Neill (Mar 19 2018 at 08:15):

There is indeed no reference from Observation to Provenance. The reference goes the other way.
Any reference to Provenance from Observation would need to be an extension.

Grahame Grieve (Mar 19 2018 at 08:20):

see this: https://chat.fhir.org/#narrow/stream/implementers/subject/Facade.20for.20multiple.20backends

Johan Eltes (Mar 19 2018 at 09:16):

Thanks. Not sure though how Provenance->Observation (target) reference could be used to resolve the source system of the Observation contained in a system that is loosely coupled to the client? The client would do Observation/GET to retrieve a list of observation from an aggregating node/forwarding intermediary. The client does not by then know the origin of the observations. The only source of an observations Provenance would be the source system of the Observation. Without knowing the source system of an observation, the client client system will not be able to query the Provenance of the Observation? I guess the only option is to retrieve the provenance as part of the original request for observations?