FHIR Chat · Resolving Multiple Sources · implementers

Stream: implementers

Topic: Resolving Multiple Sources


view this post on Zulip Josh Lamb (Feb 05 2021 at 15:59):

Hello

For app developers, if you connect someone to multiple sources of data how is that data resolved in the UI? How do we ensure that the information shown to a user has been reconciled internally, in a way to enable a common understanding of the data between patient and provider. Do we combine records (e.g. if we have multiple Patient records we combine the info, or we just pick one?)

@Michele Mottini any thoughts?

view this post on Zulip Michele Mottini (Feb 05 2021 at 16:06):

We mostly try to deduplicate the data, and we indicate the source and the conflicts in some cases - but it is all custom logic depending on the kind of data

view this post on Zulip Cooper Thompson (Feb 05 2021 at 16:13):

I've been thinking about client-side de-duplication at lot recently. Give the Cures rules, I am expecting that we'll see health systems (and payers) that will be exposing multiple FHIR endpoints for a single organization. This was something called out in the ONC Cures rule as something they specifically wanted to enable:

Token introspection will allow implementers of § 170.315(g)(10)-certified Health IT Modules to use API authorization servers and authorization tokens with various resource servers. This functionality has the potential to reduce complexity for implementers of § 170.315(g)(10)-certified Health IT Modules authorizing access to several resource servers and reduces the overall effort and subsequent use of § 170.315(g)(10)-certified Health IT Modules consistent with the goals of section 4002 of the Cures Act to enable the use of APIs without “special effort.” Although we do not specify a standard for token introspection, we encourage industry to coalesce around using a common standard, like OAuth 2.0 Token Introspection (RFC 7662).

This means that for single-organization, multi-endpoint access, clients will likely need to be performing some level of de-duplication, as it seems unlikely that individual FHIR servers will be able to perform on-the-fly de-duplication of their API content based on what other API servers in the same enterprise are returning.

view this post on Zulip Josh Lamb (Feb 05 2021 at 16:48):

Once we can get point to point communications figured out, I do not see the need to deduplicate if we only consider data from trusted sources. The point of care source can determine the relevant patient record. So if you are connecting to healthsystem x, you use the patient record from healthsystem x.

view this post on Zulip Josh Lamb (Feb 05 2021 at 16:50):

secondary sources (like a file artifact converted to clinical data) will cause duplication.

view this post on Zulip Lloyd McKenzie (Feb 05 2021 at 17:09):

Data gets duplicated into source systems. For example, the same lab report may well be stored in the systems of numerous hospitals. Patient systems and others will almost never be able to directly query the lab. It has nothing to do with 'trust', it has to do with the fact that information propagates, and that information is shared from wherever it propagates to.

view this post on Zulip Lloyd McKenzie (Feb 05 2021 at 17:10):

Not sure what you mean by "point to point" communications. Most of what we're trying to enable with FHIR interfaces is "pull" communications, where the system who wants data queries for it from whatever systems they have access to.


Last updated: Apr 12 2022 at 19:14 UTC