Stream: workflow
Topic: Task to incorporate external data
Josh Mandel (Jun 28 2021 at 20:22):
@Lloyd McKenzie on a scale of 1 to 10 (1 == it's fine, 10 == it's the worst), how much do you dislike the following use of contained? Would you prefer to stick this kind of content in... valueAttachment.data with some kind of FHIR JSON content b64 encoded? Or in a single contained Bundle? And if so, how would you enable links among the resources inside?
Goals here:
1) provide a clear place to put data that a Task relies on, even before the "receiving" system has committed to storing/incorporating them at any persistent location -- which is why we've got this Task in the first place,
2) provide a way to explicitly call out certain resources like Observations as directly needed by the Task, and others like Device as ... playing a supporting role,
3) provide a way to link between the Task and the supplied resources, and between supplied resources like Observation -> Device
Example payload to POST /Task
{
"resourceType": "Task",
"status": "requested",
"intent": "order", // App is requesting the incorporation of the data
"basedOn": { // Optional "data request"; when known, this can help EHR process quickly/correctly
"reference": "ServiceRequest/123"
},
"code": {"coding": [{"code": "incorporate-external-data"}]},
"input": [
{
"type": { "coding": [{ "code": "data-to-incorporate"}]},
"valueReference": {
"reference": "#obs1"
}
},
{
"type": {"coding": [{ "code": "data-to-incorporate"}]},
"valueReference": {
"reference": "#obs2"
}
}
],
"contained": [
{
"resourceType": "Observation",
"id": "obs1",
"effectiveDateTime": "2021-06-02T10:14:51Z",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "29463-7",
"display": "Body Weight"
}
]
},
"valueQuantity": {
"value": 68.4,
"unit": "kg",
"system": "http://unitsofmeasure.org",
"code": "kg"
},
"device": {
"reference": "#dev"
}
},
{
"resourceType": "Observation",
"id": "obs2",
"effectiveDateTime": "2021-06-02T18:25:10Z",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "29463-7",
"display": "Body Weight"
}
]
},
"valueQuantity": {
"value": 68.4,
"unit": "kg",
"system": "http://unitsofmeasure.org",
"code": "kg"
},
"device": {
"reference": "#dev"
}
},
{ // This is for context only; the EHR may use it or not, and still consider the request fulfilled
"resourceType": "Device",
"id": "dev",
"identifier": [
{
"system": "http://wittech.net",
"value": "S200/123-xxx-456"
}
],
"displayName": "WiTscale S200 Bluetooth Smart Digital Bathroom Scale",
"manufacturer": "WiT",
"modelNumber": "S200",
"serialNumber": "123-xxx-456"
}
]
}
Josh Mandel (Jun 28 2021 at 21:02):
From discussion on FHIR-I, using contained here gets an OK score from Lloyd (say 1-3 -- "totally comfortable")
Josh Mandel (Jun 28 2021 at 21:12):
One thing that still favors a dedicated $incorporate operation, over POST /Task: if the EHR wants to immediately accept (or reject) the request, the using Operations, the EHR can return a Task to the client as the operation's return value, without having to persist a Task resource anywhere. But using POST /Task kind of requires (I think!) the EHR to persist the Task. Is that right?
Lloyd McKenzie (Jun 28 2021 at 22:18):
A POST of a Task could result in a response where the Task already had a completed status and an output, but yes, it'd be stored on the endpoint. (How long the endpoint retains completed Tasks and who it allows to see Tasks created by someone else might vary.) From an EHR perspective, presumably they do persist - at least for audit purposes - the fact that a request for write came in and what was done with it, whether processed synchronously or asynchronously. So, at least in theory, there should be a persisted structure that could be used to satisfy the endpoint on read.
Josh Mandel (Jun 28 2021 at 22:40):
EHR data persistence requirements don't necessarily mean "stuff we want to expose on a FHIR endpoint long-term" though. Anyway, I don't think this is a show-stopping concern; just trying to evaluate pros and cons at this stage.
Josh Mandel (Jun 28 2021 at 22:48):
BTW @Lloyd McKenzie in the example above you encouraged me to use Task.intent of order but the definition doesn't apply:
The request represents a request/demand and authorization for action by a Practitioner.
Does this definition need to be updated, or is request a bitter fit for intent? (To be clear, I'd rather leave off intent altogether; I don't think marking it required is helping here.)
Lloyd McKenzie (Jun 28 2021 at 23:22):
Can you submit a change request? The intent is absolutely that order can be initiated by someone other than a Practitioner. The key thing is that it's initiated by someone who has the authority to ask for it directly - as opposed to needing some subsequent step to ask for the action to occur.
Josh Mandel (Jun 29 2021 at 00:59):
Eric Haas (Jun 29 2021 at 01:46):
For US Core We got beat up for this for 2 years a year by pharmacy over intent = "order" with this as a resolution
SHALL include all prescribed and “self-prescribed” MedicationRequest resources with an intent = “plan” representing reported medications
based on that insanity the intent is going to be 'plan' to avoid endless discussion
Josh Mandel (Jun 29 2021 at 02:12):
Fine by me. Or unknown. The field isn't relevant for this use case, so I'm not sure why it's required.
Lloyd McKenzie (Jun 29 2021 at 04:07):
Plan is definitely wrong.
Lloyd McKenzie (Jun 29 2021 at 04:07):
Plan is "it'd be nice if this happened, but I'm not asking for anything to happen, and it's not appropriate for any action to happen yet"
Lloyd McKenzie (Jun 29 2021 at 04:08):
It's the equivalent of sticking something in a care plan. It's expected/hoped to happen at some point in the future, but it's not supposed to happen 'now' and there's no actual 'request' for it to happen.
Lloyd McKenzie (Jun 29 2021 at 04:08):
'order' is "I have the authority to ask for this, and I'm asking for it right now".
Lloyd McKenzie (Jun 29 2021 at 04:09):
And the latter is definitely what's happening here. The person requesting doesn't get to decide what happens with the request, but they definitely have authority to ask :)
Lloyd McKenzie (Jun 29 2021 at 04:18):
Self-reported meds as a 'planned' MedicationRequest is fine because in that case, there's no request for action from the patient. (It's a kludge because those should actually be MedicationUsage as they're not really 'requests' at all and you should be using two resources, but it's an accepted/workable kludge.)
Last updated: Apr 12 2022 at 19:14 UTC
