Stream: implementers
Topic: Modelling follow-up
Elliot Silver (Jul 11 2017 at 21:56):
I'm trying to figure out how to convey a follow-up request. For example, during an imaging procedure for another issue, the radiologist notices a small lung nodule. Standard practice is to document that on the report, and inform the referring physician that follow-up imaging is needed in, say 6 months.
What I've got so far is:
-
To capture what was seen: A DiagnosticReport with a codedDiagnosis of "suspected nodule", and a result which references an Observation. That Observation would be coded for "nodule" and have a valueQuantity of, e.g., 4 mm, and bodySite of lung. (Would there be an interpretation?)
-
To capture the communication: A CommunicationRequest with: reasonReference pointing to the Observation, reasonCode indicating "Non-critical actionable finding notification", topic (or payloadReference) pointing to the DiagnosticReport, category of notification. (Possibly with basedOn pointing to a PlanDefinition?).
Assuming that all is right, what I'm stumbling over is how do I communicate the "request followup imaging in 6 months" part? Is that a proposed ProcedureRequest? CarePlan? Is it communicated directly (in a coded or non-coded form) in the CommunicationRequest?
Thanks.
Lloyd McKenzie (Jul 11 2017 at 22:41):
I'd say ProcedureRequest with intent=proposal. We may want an extension on DiagnosticReport and/or Observation that allows you to point to "recommended actions". I'm not sure where Communication comes into play?
Elliot Silver (Jul 11 2017 at 22:54):
We're focusing on CommunicationRequest first before looking at Communication, to create a more loosely coupled arrangement. I assume that most of how we capture this in the request will get transferred to the actual Communication.
You're suggesting that the Communication Request have a topic or payloadReference pointing to a proposal ProcedureRequest?
ProcedureRequest already has reasonReference(Condition|Observation). Do we actually need an extension, or just add DiagnosticReport to the existing element? (Now that I see the reasonReference element, it seems to me that an extension from DiagnosticReport/Observation to the ProcedureRequest is pointing in the wrong direction.)
Lloyd McKenzie (Jul 11 2017 at 23:04):
I'm not sure why you need Communication at all. When the radiologist prepares their report, I'd just expect a DiagnosticReport that points to Observations and maybe to ProcedureRequest. No need for Communication/CommunicationRequest in the mix.
Elliot Silver (Jul 11 2017 at 23:20):
I don't have all the details, but my understanding is that the reading radiologist wants a separate communication (phone call, email) from the regular delivery of the report. In part, this is to because the referring physician is often focused on the primary findings, and the secondary ones get lost and the follow-up is missed. The workflow also involves a communication back that the referring physician acknowledges the issue and will schedule follow-up. (I think the model also complicated by the fact that it is designed for cross-institution uses, so a report showing up in my EMR does little to help you.)
Lloyd McKenzie (Jul 11 2017 at 23:29):
You don't need Communication to have a Communication. You can just send the data. If you want strict management of workflow steps, you can also look at Task.
Elliot Silver (Jul 11 2017 at 23:33):
I think what they want is the record of telling the referring physician, and the record of the acknowledgement, for which Communication seems appropriate. However, I'll take your suggestion back to the team.
Lloyd McKenzie (Jul 11 2017 at 23:44):
The record of the transmission could be handled by Provenance. Acknowledgment could vary depending on what you want to do. It could be "here's the scheduled appointment". But if it's just an I saw, then yes Communication might make the most sense there.
Elliot Silver (Jul 11 2017 at 23:58):
GF#13630 added for ProcedureRequest.reasonReference include DiagnosticReport.
Last updated: Apr 12 2022 at 19:14 UTC
