Stream: implementers
Topic: Should two micro services update the same Resource?
Håkan MacLean (Jun 07 2021 at 12:14):
I have a question about FHIR data modelling in a world of Micro Services. Specifically, I'm thinking about a case if different micro services should be allowed to update the same FHIR Resource.
Let's take an AllergyIntolerance as an example. A Patient fills in a Questionnaire about their allergies and a "PatientService" creates a rather sparse AllergyIntolerance in a FHIR Server. A "ClinicianService" reads this resource and shows it to a Clinician. After gaining more knowledge (e.g. questions to the patient, lab tests etc) the Clinician can now enter more information about the Patient's allergy. The question is - should we update the existing AllergyIntolerance or create a new one? Originally I had hoped to update the existing one, but I'm starting to doubt it. Reasons:
- To show that the updated data comes from the Clinician, we would probably want to update the AllergyIntolerance.asserter field to be the Clinician
- However, this means the Clinician now vouches for all the fields in the Resource, not just the ones the ClinicianService might have read & updated (above is provided we PATCH, if we instesad do a PUT, the data from the Patient is "lost", see below).
- After the update, the first version of the resource is sort of soft-deleted. If you query the FHIR Server for AllergyIntolerances asserted by the Patient it no longer exists, unless you know the exact version.
If we instead create a new Resource, how would you suggest linking them together? Using the Linkage Resource? Provenance Resource?
Håkan MacLean (Jun 07 2021 at 12:15):
I'm thinking @Myles Bell might have thought about these things :). Or might talk about them on Wednesday?
Vassil Peytchev (Jun 07 2021 at 12:59):
I don't think the example with AllergyIntolerance is a good one:
- there would be an AllergyIntollerance resource for each allergy.
- in my experience patient reported allergies, once recorded, are never dismissed by clinicians. They can be marked as 'refuted" if some kind of testing is performed to demonstrate that there isn't actually an allergy.
For the general question, whether different micro services should update the same FHIR resource, I'd say yes (unless there is a clear use case why that would cause problems). Use of the Provenance or AuditEvent resource would likely be a must if there is a need to distinguish which parts of the original resource were modified by which service.
Håkan MacLean (Jun 07 2021 at 13:58):
Thanks for chiming in @Vassil Peytchev !
In my simple example above, I'm thinking we're only talking about *one * allergy.
Can you think if of an example where it really does make sense for say a Patient and Clinician service to update the same resource? With my bullets above I'm starting to question it. Even if you use Provenance or AuditEvent to show which fields were modified, we still have the problem of the Patient version being soft-deleted.
Myles Bell (Jun 07 2021 at 14:37):
I think its reasonable for different services to update a resource if that is known, tested, and your services understand the more complex provenance. It certainly increases the complexity of the system though, as you describe, so I would avoid it if possible. So I would probably choose to link the two somehow in this case or ensure that the clinicians at least verify all fields.
Preferably micro services would own their own data and be the only ones making changes to their own data directly, to make them as decoupled as possible. Having services set up around products is much more common than around domains though so being able to decouple the services is a long term goal rather than practical thing you can do now. Having separate domains is very briefly mentioned in my talk but not in any depth in the 15 mins
Lloyd McKenzie (Jun 07 2021 at 14:38):
In general, users are only going to want to see one authoritative entry for each allergy in the record. More than that produces cognitive load of trying to figure out which record is 'accurate. You certainly wouldn't want a patient to record an allergy and a clinician not to be able to see it. If a patient records something and a provider marks it as refuted, that's a legitimate thing to happen. Certainly better than creating a new record.
Håkan MacLean (Jun 09 2021 at 18:08):
Lloyd McKenzie said:
In general, users are only going to want to see one authoritative entry for each allergy in the record. More than that produces cognitive load of trying to figure out which record is 'accurate. You certainly wouldn't want a patient to record an allergy and a clinician not to be able to see it. If a patient records something and a provider marks it as refuted, that's a legitimate thing to happen. Certainly better than creating a new record.
The clinician would definitely be able to see the resource. But I'm starting to think if it's better that they see it and then create a new Resource and then we somehow link them together. If the Clinician creates a v2, then the version created by the Patient can no longer be found when quering the FHIR server for AllergieIntolerances created by the patient. And if the Patient then updates the resource yet again with new info, suddenly the EMR can no longer find any AllergyIntolerances that have been "asserted" by a Clinician.
Vassil Peytchev (Jun 09 2021 at 20:38):
Why does the EMR need to find an AllergyIntolerance asserted by the physician? Maybe there are assumptions that I am missing.
From what I can tell, you are concerned with the following sequence of events, with my assumptions added:
- Patient creates an AllergyIntolerance resource on a FHIR server, different from the EMR.
- The physician, using his EMR, is reviewing the patient's record, and via querying the FHIR server, sees the patient-created AllergyIntolerance information obtained from he FHIR resource.
- The physician, using his EMR, reviews the AllergyIntolerance information, updates, and asserts it, and the EMR updates the AllergyIntolerance resource on the FHIR server.
- Patient views the newly updated AllergyIntollerance resource, and makes additional updates.
As far as the EMR is concerned, the patient-updated AllergyIntolerance resource is perfectly fine, because the physician-asserted information (and the original patient-entered information, for that matter) are already within the EMR. If the EMR needs to get the latest version of the AllergyIntolerance resource, it can do that, and alert the physician of the differences within the EMR, allowing him to re-assert the information, and update the resource again.
Lloyd McKenzie (Jun 10 2021 at 14:59):
Nothing stops you from having two sets of AllergyIntolerance records - one managed by the Patient and one by the Practitioner. You could use extensions to link them. However, that wouldn't be a 'typical' workflow. More common would be patients being able to put 'unverified' allergies directly into the clinical record. They might also be able to add notes to existing allergies. Providers would modify the same records to verify or refute them. History and Provenance would allow you to go back and see who did what.
Håkan MacLean (Jun 10 2021 at 16:45):
Lloyd McKenzie said:
Nothing stops you from having two sets of AllergyIntolerance records - one managed by the Patient and one by the Practitioner. You could use extensions to link them.
You mean like creating a custom extension? I would have thought the Linkage resource be the perfect fit for this use case?
Lloyd McKenzie said:
More common would be patients being able to put 'unverified' allergies directly into the clinical record.
Hmm, maybe this is the use-case I'm trying to solve, but this is where I get confused. How would we go about creating this unverified state in practice on a FHIR server? If we allow the Patient to update the same resource, we are effectivey overwriting the verified Clinician version in the FHIR Server. If someone then queries the FHIR server for verified AllergyIntolerances, they would get 0 hits after the Patient update?
(Even though the ClinicianService/EMR would could of course still have its verified version of the AllergyIntolerance)
Vassil Peytchev (Jun 10 2021 at 18:36):
If someone needs the verified AllergyIntolerance, could they query the ClinicalService/EMR for it?
Håkan MacLean (Jun 10 2021 at 18:42):
Vassil Peytchev said:
If someone needs the verified AllergyIntolerance, could they query the ClinicalService/EMR for it?
In theory, yes. However, the point of this project is to decouple services from each other. So instead of quering the EMR directly, we want services to communicate through events and the FHIR Server, that aggergates all events, should be seen as the "ground truth" for health data. So, in practice, no :).
Vassil Peytchev (Jun 10 2021 at 19:12):
In this case, the requirements for the FHIR server go waaaaaay beyond the requirements for data exchange. Full history, provenance and AuditEvent support for every possible resource is just the bare minimum. With that bare minimum, getting the verified AllergyIntolerance based on the Provenence record is not hard.
Lloyd McKenzie (Jun 11 2021 at 03:27):
Linkage would certainly be an option. To my knowledge, no one's actually implemented it though...
Håkan MacLean (Jun 11 2021 at 12:46):
Vassil Peytchev said:
In this case, the requirements for the FHIR server go waaaaaay beyond the requirements for data exchange. Full history, provenance and AuditEvent support for every possible resource is just the bare minimum. With that bare minimum, getting the verified AllergyIntolerance based on the Provenence record is not hard.
Ah, brilliant. Never thought of that. I.e. search through Provenances to find AllergyIntolerances that have been created by Clinicians.
How would one go about this? Create some SearchParameter resource with FHIRPath to query for Provenance records that have been created by Clinicans that point to AllergyIntolerances?
Or is there a way to search through the history of a certain Resource instance?
Vassil Peytchev (Jun 11 2021 at 14:24):
A "brute-force" way to find the verified version might look something like this:
- Obtain the AlleregyIntolerance resource. If that is verified, you are done. Otherwise
- GET [base]/Provenance?target=[base]/AllergyIntolerance/[id]$activity=4
- Go through the set of Provenence resources, and find the latest AllergyIntollerance version
For 2. I am assuming that a search parameter of type Reference will match versioned references. Or do we need a :below modifier?
Elliot Silver (Jun 11 2021 at 15:33):
Vassil Peytchev said:
For 2. I am assuming that a search parameter of type Reference will match versioned references. Or do we need a :below modifier?
From the search spec:
When searching on versioned references, the following rules apply:
- If a resource has a reference that is versioned, and chaining is performed, the criteria should ideally be evaluated against the version referenced, but most systems will not be capable of this because search is only defined to function against the current version of a resource
- Where a search does not act on the referenced version, search results SHOULD contain a OperationOutcome with a warning that indicates the discrepancy
- If a resource has a reference that is versioned and _include is performed, the specified version SHOULD be provided.
Doesn't look like we call out searching against all versions.
Vassil Peytchev (Jun 11 2021 at 16:44):
Shouldn't the :below modifier work:
Obtain the current version of the resource (plain non-versioned search).
Get the latest version from the ETag
do a GET [base]/Provenance?target:below=[base]/AllergyIntolerance/[id]/_history/[current version]
Paul Church (Jun 11 2021 at 16:49):
I don't think :below applies to that kind of reference search. It applies to a bunch of cases (canonicals, uris, hierarchies) but there's no indication in the spec that it applies to versions.
Vassil Peytchev (Jun 11 2021 at 16:51):
Shouldn't it?
Paul Church (Jun 11 2021 at 16:53):
hmm, I guess if you're searching by the fullURL it makes sense because that's like the URI case?
If you're searching for a local ref AllergyIntolerance/[id]/_history/[version] I think that would be a new assumption.
Vassil Peytchev (Jun 11 2021 at 17:04):
I will start a new topic to see what can be clarified, maybe I am missing something.
Last updated: Apr 12 2022 at 19:14 UTC
