Stream: Canadian eReferral
Topic: CodeableConcept - using .text as "notes" for a code
Tim Berezny (Jun 07 2021 at 20:55):
Is it ok to use the .text of a CodeableConcept to add an ad-hoc description of a .coding.
Example: I want to create a servicerequest.code.coding called "revoke-reason", then use servicerequest.code.text to enter a pain text description for the reason like "Patient found another service". It would be hand-entered and could be different every time.
Is this ok from a FHIR standards perspective - if we specify that this is how it'll be used in an iGuide?
Lloyd McKenzie (Jun 07 2021 at 20:57):
That's absolutely appropriate and is one of the intended uses.
Tim Berezny (Jun 07 2021 at 20:57):
Oh fantastic, you've warmed my heart.
Vassil Peytchev (Jun 07 2021 at 21:57):
I am confused. How does a ServiceRequest.code of "revoke-reason" make sense here?
Lloyd McKenzie (Jun 07 2021 at 23:52):
Ah, missed that part. Agree that "revoke-reason" doesn't sound like an appropriate coding for ServiceRequest.code. My response was about ServiceRequest.code.text being a free text description of the service request.
Tim Berezny (Jun 08 2021 at 12:24):
Yes, that is another dimension to it. Using the ServiceRequest.code seemed like the most appropriate of the existing elements to use. Since it means "what is being requested/ordered", it doesn't seem like to much of a stretch to update a ServiceRequest with a code about why it WASN'T ordered (i.e., revoked).
The best alternative I can think of would be an extension. (ServiceRequest.notes is another option, but wouldn't have enough precision)
With that logic, would it make sense to use .code, or should we go for an extension?
Vassil Peytchev (Jun 08 2021 at 12:51):
Sounds like you need the request-statusReason extension.
Tim Berezny (Jun 08 2021 at 12:59):
Oh great, thanks @Vassil Peytchev
Lloyd McKenzie (Jun 08 2021 at 13:47):
ServiceRequest.code is never a "reason". It's always a "what to do" (or if doNotPerform=true, "what to not do"). The reason for the ServiceRequest is captured in ServiceRequest.reason. request-statusReason would be the reason for the state of the order. E.g. if you had a "do not do" order that was suspended, the status reason would be why it was suspended.
Last updated: Apr 12 2022 at 19:14 UTC
