Stream: patient empowerment
Topic: Updating Task
Virginia Lorenzi (Mar 28 2021 at 05:59):
@David Hay @James Agnew @Vassil Peytchev For Patient Request for Corrections, it was proposed that we add an operation to Task to support adding notes in a controlled manner from both the requestor and the fulfiller. We would like to test this in the May connectathon, but I think we would need a server to participate that can in some way take in that operation. Do you guys have any ideas or could you help?
David Hay (Mar 28 2021 at 06:18):
Hi Virginia - I'm not sure that I can help out in person (but you never know :) ). However, if I was prototyping this I'd use node red as an 'intermediate' server to expose that operation and communicate with the back end server. I've written a few blog posts about this pattern if others are interested..
Virginia Lorenzi (Mar 28 2021 at 06:24):
@David Hay @Lloyd McKenzie @James Agnew @Vassil Peytchev Alternatively, it was proposed that we use Patch to update/add/delete specific inputs and outputs of Task and to add notes to Task. It appears, according to the capability statement, that HAPI R4 can support Patch of Task so we could test this method in May. Is there any way in an implementation guide to specify that only certain fields can be patched and only in certain ways? For example, I think we would only want to allow:
add/update/delete of Task.input[any index]
add of Task.note[new index]
Could we specify that in the IG? Or by saying the IG supports Patch can all fields be patched with all patch operations?
Virginia Lorenzi (Mar 28 2021 at 07:28):
It will be remote of course. I will look.
Lloyd McKenzie (Mar 28 2021 at 14:02):
I don't really understand the purpose behind doing this. It can be done, but isn't a pattern used anywhere else in FHIR. If you want to add a reaction to an allergy, you replace the whole AllergyIntolerance. If you want to add a discharge date to Encounter, you replace the whole Encounter. Why would we do anything different here? PATCH is used to allow slightly smaller instances, but doesn't have any innate limitations on what you can change. It's also not widely supported (no expectation for it in US Core).
The nice thing about using pure update is that if you want to add a note and update the status, you can. Business rules determine what a particular user is allowed to change and when. You won't see any business rules in the reference implementations. If you want to change the drug and patient on a legal prescription, all the reference servers will be fine with that. However, all such servers also allow introduction of business rules that constrain what changes are allowed in what circumstances - and by whom. That would be the 'standard' way of ensuring that existing notes aren't removed. The fact it's easy to wipe someone's notes with a reference implementation doesn't really matter.
Virginia Lorenzi (Mar 28 2021 at 21:25):
The idea of an IG is to create a more plug and play interface that reduces unintended consequences. What you describe sounds like base FHIR functionality that can lead to variances.
As I understand, no one is updating allergies using FHIR. I thought PUTs were rarely used. @David Hay seems to have ran into a similar problem: https://fhirblog.com/2019/08/13/updating-a-resource-using-patch/
If you can point me to groups that are using PUTs as you describe I would like to talk to them.
If the application is simply an add on to the base system and the person writing the data is the owner, then PUT is fine. There are use cases for provider facing SMART apps that I would be quite comfortable with this approach. But when one system owns some fields and another owns others IMO its a problem. I would not want the lab overwriting the doctor's order. I would not want the patient updating the Medical Record number but updating street address might be OK. The doctor can update the med order but not the fill details because the pharmacist owns that.
So in this case we do not want the patient overwriting the providers words or the provider overwriting the patient's words.
I noticed with Argonaut they did not allow PUTs of scheduling resources and instead created custom operations.
Lloyd I very very much respect your opinion and know you feel strongly about this and feel I must be missing something, but several of us are not yet comfortable with this concept. Maybe I/we are just not seeing it clearly. @Vassil Peytchev
This is currently the roadblock for us in using Task or Task alone.
@Josh Mandel @Brett Marquard wondering what Argonaut is thinking about PUTs to EHRs with shared ownership of fields and the value of PATCH or custom operations.
Lloyd McKenzie (Mar 28 2021 at 22:56):
PUTs aren't widely supported in US-Core, but when they are, I'm pretty certain it won't be with operations. There is no expectation that the system performing the update is the owner. There is zero chance of the lab overwriting the doctor's order - because the lab will define who's allowed to update what. The whole point of FHIR is that there's a single interface that everyone can write to - and any variations in what is accepted and rejected is handled at the business layer, not the interface layer. The result is that you don't have to develop custom interfaces every time there's a new use-case or a variation in permissions.
Virginia Lorenzi (Mar 29 2021 at 05:00):
OK I can see that. But the server side needs IG help too. If I write back the whole Task and update 5 of the fields but really was only supposed to update 3, isn't this the kind of business guidance we would put in an IG? Even if its just a PUT?
Lloyd McKenzie (Mar 29 2021 at 05:29):
Perhaps. If we agree that there are universal business rules that everyone must enforce (and the implementers are onside with those rules), they can definitely go in the IG. However, it also starts to tread into territory where HL7 has historically been reluctant to go - dictating application internal behavior. And we need to be careful. When you start saying "existing messages can't be changed", what happens if a message is erroneous? What happens if it contains information that wasn't consented to be shared? What if it's offensive? If we allow changes only for a period of time, what's the period of time? Those are decisions that are typically made by the software developers or are sometimes even configurable by site. My recommendation for the first go around would be to just provide a list of "things implementers should consider setting rules around" and leave it to them to figure out what makes the most sense - and only intervene with stronger language in a future version of the IG if inconsistency is interfering with interoperability or if the loser guidance is manifesting problems in the real-world. When you start being too tight from the outset, you can paint yourself into a corner pretty quickly.
David Hay (Mar 29 2021 at 17:48):
Hi @Virginia Lorenzi - the use of patch for the registry there wasn't really my first choice - the dev time really didn't want to use PUT (which was my preference). Don't forget that the server isn't obliged to accept all the elements in the updated resource supplied via PUT - if business rules mean a change is not acceptable they can always reject the update, possibly returning an OperationOutcome with the reason why...
Virginia Lorenzi (Apr 07 2021 at 06:15):
@Debi Willis note David Hays perspective above.
Dave deBronkart (Apr 08 2021 at 16:58):
Lloyd McKenzie said:
I don't really understand the purpose behind doing this. It can be done, but isn't a pattern used anywhere else in FHIR. If you want to add a reaction to an allergy, you replace the whole AllergyIntolerance. If you want to add a discharge date to Encounter, you replace the whole Encounter. Why would we do anything different here?
I'm joining this two weeks later but I'll note (as you probably are aware) that this use case (negotiating a requested correction) may be highly vulnerable to dueling edits: entirely possible that the provider pulls a copy for a moment to add something, just as the patient end does, and they might overwrite each other.
My very non technical view of this project's tangles is that at bottom of it all, nobody every planned to have EMR data elements be a collaborative project, eh???
Now tell me I've overlooked something important, which I probably have
Lloyd McKenzie (Apr 08 2021 at 17:12):
Dueling edits will be even more common with other resources - e.g. Encounter - changing beds, adding notes, updating discharge plans, etc. FHIR is fully robust in the face of dueling edits. We don't need to do anything 'special' for our use-case.
Dave deBronkart (Apr 08 2021 at 17:16):
Lloyd McKenzie said:
Dueling edits will be even more common with other resources - e.g. Encounter - changing beds, adding notes, updating discharge plans, etc. FHIR is fully robust in the face of dueling edits. We don't need to do anything 'special' for our use-case.
Holy cow, @Virginia Lorenzi @Vassil Peytchev @Debi Willis @Abigail Watson @Maria D Moen have we been clear about this? My strong recollection is that the risk of overwrites was a major worry. If not, what does that area of concerns reduce to?
Maria D Moen (Apr 08 2021 at 20:42):
I recall overwrites being a concern too, although I would "assume" that the original is maintained and changes occur with full history are stored, so over-writing should be accommodated.
Virginia Lorenzi (Apr 09 2021 at 01:02):
@Lisa Nelson had this concern as well. People's worries just do not seem to be going away and in an obstacle to us moving forward with Task - is there some examples out there in the real world where this both sides writing same resource with fhir is being tested with FHIR IGs? @Josh Mandel @Jeffrey Danford @Vassil Peytchev @John Moehrke Thanks.
Josh Mandel (Apr 09 2021 at 03:04):
I'd imagine shared care plans might be at least a partial example in this space. Wonder if @Tom Stanis might be able to comment on use cases where multiple parties are updating a FHIR resources, and whether the built-in versioning (and If-Match header-based update semantics) are working well enough?
John Moehrke (Apr 09 2021 at 11:38):
Even if versioning is not supported by the server. The server is allowed to have business rules that reject changes to elements that the requesting actor is not allowed to change. Thus we don't need to build this into the Implementation Guide, certainly not into the profiles. We can point this out to the implementer.
So, for example. The server hosting the Task can forbid (with error, or silently) changes to elements of Task that are tracking the status of the custodian. The server hosting the Task can forbid the changing of elements, except when it is proper.
John Moehrke (Apr 09 2021 at 11:40):
The basic REST pattern would seem to imply that whatever the client posts is simply kept by the server. This is indeed the "pattern", but it is the pattern that gets influenced by the security layer (authentication and authorization), the privacy layer (consent, and privacy principles), and the business layer. REST is not everything, it is just the API interaction pattern.
John Moehrke (Apr 09 2021 at 11:47):
So, just express the considerations for business/privacy/security rules that would assure that the elements of the Task that are persisted are the proper ones at each interaction. This is to say that during the "Create" is when some elements are recorded that are never allowed to be changed by anyone. This "never allowed to be changed by anyone" is a business rule that is part of policy and systems design. An "Update" by the patient will have different expectation. An "update" later by the custodian will have different expectations. These expectations are should be discussed, but few of them should be made really strict. You can express the need for policy with some examples, without expressing exact policy. The expressing of exact policy can sometimes be helpful, but most of the time over expression of policy will create an IG that is too ridged and thus fragile to variations.
John Moehrke (Apr 09 2021 at 11:48):
Often showing an example (reference) policy with examples is sufficient to inform your reader the kind of thing they need to be ready to adjust to policy.
Tom Stanis (Apr 10 2021 at 03:51):
I like the concept of "optimistic locking" in general for database updates. It is both straightforward to implement and scalable. I've used it at a major tech company project on their core database and it worked well and was highly robust. :)
The FHIR scheme for doing this is good, although I have a few nits:
- It would prefer if versionId was an increasing integer rather than an arbitrary string. I realize this is probably done for compatibility, and we can just use lastUpdatedOn, but things are a little easier to debug (and at least one major vendor is using integers here).
- I'm generally not a fan of server generated ids as the spec says for versionId. Idempotency is easier with client generated ids. This also forces a GET after a PATCH/UPDATE which is really inefficient for most databases.
So far, while we use the care plan resource for our internal data structure, I have yet to attempt writing that resource back to the EHR, especially because our main EHR partner does not yet support writing CarePlans.
Lloyd McKenzie (Apr 10 2021 at 04:35):
The main reason for not mandating versionId value or allowing client-assigned versions is that most FHIR interfaces are facades on existing legacy implementations. These limitations typically have deeply embedded assumptions around how version ids will work and having clients assign them simply isn't a viable option.
You don't need to do a GET after a PATCH/UPDATE because the PATCH/UPDATE response always provides the version id in the Location header (and the eTag header). Also, PATCH and PUT can echo back what was actually stored in those situations where it's not exactly what the client sent, so the client and server both have the same understanding of starting-point for subsequent changes.
Tom Stanis (Apr 10 2021 at 05:32):
Yeah, I totally understand the compatibility problem you are talking about.
Wasn't aware that you could get the server to echo back the full object on PATCH/UPDATE, that's useful.
Lloyd McKenzie (Apr 10 2021 at 05:53):
It's up to the server whether it does, though you can indicate a preference with a header in the request. If a server isn't storing things "as submitted" and allows updates, it's an extremely good idea to echo back the content.
Lloyd McKenzie (Apr 10 2021 at 05:53):
(And IGs could mandate that.)
Last updated: Apr 12 2022 at 19:14 UTC
