Stream: implementers
Topic: Pop Health: Person vs Patient vs Provenance
Michelle (Moseman) Miller (May 26 2016 at 19:10):
When leveraging FHIR on a population health platform, are there any best practices around how to represent the person’s longitudinal record?
Option 1 (undesirable)
Person1 links Patient A (from EHR A) and Patient B (from EHR B) and Patient C (from Claim C), which has the drawback that resources (e.g. allergies, conditions) are segregated by source system and not truly longitudinal:
Person 1
-
Patient A
- Allergy A1
- Allergy A2
- Condition A1
-
Patient B
- Allergy B1
- Condition B1
-
Patient C
- Condition C1
- Condition C2
Option 2 (preferable)
All longitudinal record data references a single Patient and uses Provenance to convey the source system/origins of that data, which would look closer to:
Patient 1
-
Allergy A1
- Provenance EHR A
-
Allergy A2
- Provenance EHR A
-
Allergy B1
- Provenance EHR B
-
Condition A1
- Provenance EHR A
-
Condition B1
- Provenance EHR B
-
Condition C1
- Provenance Claim C
-
Condition C2
- Provenance Claim C
One challenge with option 2 is that Patient has a single set of demographics, such as a list of addresses, yet the provenance/source/origin of each address in the list may differ.
In short, I’m just curious if anyone else has thought about a FHIR implementation of a longitudinal person record (to use as a sounding board for issues like these)?
Peter Bernhardt (May 26 2016 at 19:54):
Michelle, we're looking at the same use case. And we agree on using option two and curating data to remove duplicates and resolve data conflicts between different source systems. This also requires doing some work around patient matching. We aren't using Provenance but rather private extensions to capture meta data about the source of incoming data to solve the same problem.
Grahame Grieve (May 27 2016 at 21:37):
I guess it's not clear, but the target on a provenance can have a fragment identifier, and so indicate a particular piece of information in the resource
Michelle (Moseman) Miller (May 28 2016 at 03:22):
Are there any examples to show how to do that? Stated another way, my requirement is for Provenance.target to reference Patient.address[1] for example, and not Patient.address[2].
Grahame Grieve (May 29 2016 at 09:56):
you have to use id - so
<address id="23">
<blah...>
</address>
<Provenance>
<target value="....#23">
<Provenance>
Brian Postlethwaite (May 31 2016 at 00:04):
Option 1 I would have thought would be the most normal, as this does not require the actual merging/changing of any data, and just permits the view of the content.
The inelligence then needs to be in the "client app" that is then traversing the data.
Brian Postlethwaite (May 31 2016 at 00:05):
Option 2 needs processing to take the seperate systems from Option 1, and put them all under the same interface.
This could however be done by a facade over Option 1 which I haven't thought too much about.
Brian Postlethwaite (May 31 2016 at 00:06):
Then the Provenance records participate also.
(@Grahame Grieve do these need to be standalone, or can they be contained in the resource?)
Grahame Grieve (May 31 2016 at 00:15):
right now you can't really contain them in a resource.
Grahame Grieve (May 31 2016 at 00:16):
have you seen the X-Provenance header?
Brian Postlethwaite (May 31 2016 at 00:17):
Will have a look, thanks
David Hay (May 31 2016 at 00:18):
what google thought: https://en.wikipedia.org/wiki/Provenance_(The_X-Files)
Josh Mandel (May 31 2016 at 15:27):
Yeah, I couldn't find this with google either.
Chris Grenz (May 31 2016 at 21:53):
@Grahame Grieve The problem with using a fragment in target is that the resource itself (here, the combined Patient) must be annotated with ids. I'm planning on proposing an extension to target that would allow the use of a profile element to indicate what element(s) are targeted. This would relieve the need to modify the resource just to make specific element level targets.
Chris Grenz (May 31 2016 at 21:53):
Anyone have any thoughts on this?
Grahame Grieve (May 31 2016 at 22:13):
most people would find that impossibly complicated. You could use an expression to indicate externally if you didn't want to add ids
Last updated: Apr 12 2022 at 19:14 UTC
