Stream: implementers
Topic: Cross-Resource Referecnces
Grahame Grieve (Jan 16 2017 at 19:36):
Question I've been asked:
if an Observation refers to both a Patient and Encounter, does the Encounter have to refer to the same patient.
Grahame Grieve (Jan 16 2017 at 19:36):
my usual answer to this is : probably, but it's very difficult to say that absolutely must
Grahame Grieve (Jan 16 2017 at 19:36):
but is there anywhere in the spec where we really have to have consistent references like this?
Rick Geimer (Jan 16 2017 at 19:39):
I think it is best practice, but not always enforceable. Patient is optional on encounter. What happens if you create the Encounter first (without a patient), then create the Patient, and finally the Observation that points to both.
Vassil Peytchev (Jan 16 2017 at 19:40):
If we go by the 80-20 rule, wouldn't you say that they must match, and outliers need an extension?
Vassil Peytchev (Jan 16 2017 at 19:41):
I understand the question for the cases when the reference to patient is present in both places
Grahame Grieve (Jan 16 2017 at 19:58):
80-20 rule - have to understand this: it is about design disagreement
Grahame Grieve (Jan 16 2017 at 19:58):
it's not just patient, but patient is probably the most iportnat
Vassil Peytchev (Jan 16 2017 at 20:06):
If the encounter and the observation "almost always" point to the same patient, that is 80+% of the cases. This also allows cases of encounter without patient to default implicitly to the patient in the observation. A "third-party encounter" is explicitly placed in an extension.
Grahame Grieve (Jan 16 2017 at 20:08):
it's not whether the encounter+observation pointing to the same patient is 80% of cases, it's about whether 80+% of systems require them to to be the same in all cases
Vassil Peytchev (Jan 16 2017 at 20:15):
I would guess that 95+% of systems expect the patient to be the same.
Vassil Peytchev (Jan 16 2017 at 20:16):
Should we make them check to verify?
Simone Heckmann (Jan 16 2017 at 22:50):
Scenario:
There are duplicate Patients A & B in the system.
They're being merged by referencing B --> A,
Patient B is set to "inactive"
The encounter E has been created before the merge and still points at B
The observation is created after the merge and points at the active Patient A and the Encounter E
Simone Heckmann (Jan 16 2017 at 22:53):
The assumption that Encounter and Observation always reference the same patient is only safe if merging Patients means updating all references.
Vassil Peytchev (Jan 16 2017 at 23:21):
Same patient is not the same as the identical patient resource. I think it is important to be the same patient.
Bo Dagnall (Jan 17 2017 at 00:09):
This potential problem isn't just about patients. Given the ability to create a network of referenced resources, the pattern where resource A references resource B and resource C, and resource B also references resource C is quite common (e.g., duplicate references to patient, provider, organization, encounter, condition or any other common resource). I agree that in most cases, the reference from A to C should be the same as the reference from B to C ( i.e., both A and B point to the same instance of C), but there are times where this may not be true. The problem is that I don't know of any way in FHIR to express when duplicate references should resolve to the same instance or not. If it is intentional for A to reference a different instance of C than B does, how do you communicate this? Further, if the references to C from A and B are meant to be the same, I believe we should be able to enforce this to avoid data quality issues that may arise.
Grahame Grieve (Jan 17 2017 at 00:55):
so I have 2 questions in this space:
- is there anywhere in the spec itself where we need to enforce consistent references
- what are the requirements for a language that makes statements about this?
Grahame Grieve (Jan 17 2017 at 01:41):
so we'll talk about this Wed breakfast. 7:30 am - get some breakfast downstairs, then come up to room 1146 and we'll discuss this
Lloyd McKenzie (Jan 17 2017 at 02:01):
@Grahame Grieve We could probably grab a room from Lillian that's a bit closer than having everyone go all the way up to your room if you want - shall I ask?
Grahame Grieve (Jan 17 2017 at 02:02):
sure
Grahame Grieve (Jan 17 2017 at 02:02):
thx
Grahame Grieve (Jan 18 2017 at 05:50):
reminder - if you're interested in this topic, we'll be talking about it 7:30 am in room 1146 (bring your breakfast upstairs). If you can't get to floor 11, PM me directly and I'll come down and bring you up
Elliot Silver (Jan 18 2017 at 05:58):
Can someone post a summary of this discussion after tomorrow morning? Thanks.
Grahame Grieve (Jan 18 2017 at 16:26):
Summary:
- yes, we need to provide some framework to allow the conformance layer to make statements about consistency
- mostly, what you want to make is statements about the compartments we already have defined - most critically, patient
- we're going to add some warning wording associated with the patient compartment explaining the kind of cases that cause record sets to cross patients (mother/baby, transplants/tranfusions, family history (genetics), family counseling)
- we will create a new resource that describes networks or clusters of resources. This will describe a tree of resources, and indicate, for each reference/target combination, what the rules are.
- an example of the kind of thing that this resource is dealing with can be seen here: http://fhir.hl7.org.au/fhir/rcpa/cprofiles.html
- when we make rules about the join between resources, we can make simple rules about compartments, or complex rulues using fhirpath
- this 'PackageDefinition' resource (working name) will also find use in several other places, including the _include parameter.
- you might see some drafts of this in the current build before R3, but it won't be part of R3
Elliot Silver (Jan 18 2017 at 17:57):
@Grahame Grieve Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
