Stream: implementers
Topic: ServiceRequest.Status valueSet inconsistency
Tim Berezny (May 30 2019 at 14:45):
I'm trying to figure out the valueSet for ServiceRequest.status (which is "Required").
On the ServiceRequest resource page (https://www.hl7.org/fhir/servicerequest.html) it says the values are:
draft | active | suspended | completed | entered-in-error | cancelled
However on the RequestStatus valueSet page (https://www.hl7.org/fhir/valueset-request-status.html) it says
draft | active | on-hold | revoked | completed | entered-in-error | unknown
There is inconsistency for on-hold, revoked, and cancelled. Also, it wasn't too long ago i looked at the valueSet and I believe that it had revoked AND cancelled (which i though was helpful to have both, as revoked I associate with revoking consent to send the request, while cancelled is more generic - it could be cancelled by the sender, by the provider, by the patent, due to snow-storm etc...). Removing cancelled from the list (And the different valueSets on these two pages) has caused some complications in our implementation guide for serviceRequest.
@Smita Kachroo @Ion Moraru
Lloyd McKenzie (May 30 2019 at 15:17):
@Grahame Grieve Why isn't the short description validating against the code lists anymore?
Lloyd McKenzie (May 30 2019 at 15:18):
@Tim Berezny The value set is the authoritative list.
Note that the status of the ServiceRequest represents the state of the authorization, not the state of the fulfillment activities. (The latter would be captured using Task)
Tim Berezny (May 30 2019 at 15:34):
Thanks @Lloyd McKenzie , I follow what you mean by using a task for the state of fulfillment activities, can you expand a bit on the statement/philosophy behind the word - state of "authorization" for the ServiceRequest.status? I feel like I 70% know what you mean by that but need a few more words to get to 100%.
John Wills (May 30 2019 at 16:35):
@Lloyd McKenzie @Tim Berezny Couple of questions: With referrals sent between systems in a "de-coupled" approach using the messaging paradigm, would the sender be expected to have visibility of and/or access to the status of task resources for activities executed on the recipient systems in response to the request? Given that the task resources don't exist on the sending system and that receiving systems don;t expose a restful interface to tasks based on a servce request, should status of downstream activities (represented in tasks) be shared using the communication resource or does it make sense to share the tasks directly? ( Also, would the Request State diagram also be updated to reflect the new valueset, or is it intended tobe at a higher, more generic level?
Lloyd McKenzie (May 30 2019 at 16:36):
All request resources with an intent of 'order' essentially represent an authorization for something to happen "This patient should be on this medication" or "This patient needs an MRI" or "This patient should have their cholesterol checked". It doesn't necessarily identify who should do those things or specifically say "do it now". An order/referral for an MRI might result in a solicitation going to several different organizations before you find one who has availability to do the test needed in the timeframe desired. Each of those "please fulfill this order" requests are managed by Task. The order doesn't change as you ask for someone to fill the order and they say "I'm thinking about it", "yes I can", "no I can't". All of that is reflected in the Task. The order only changes when the testing is complete and the order requester decides that they're happy with what's been done or the requester gets fed up with waiting and cancels the order because it's no longer useful.
Eric Haas (May 30 2019 at 16:36):
Can you make a gforge tracker to correct the short description? not only for ServiceRequest but for the request pattern and State Diagram and wherever else this occurs
Lloyd McKenzie (May 30 2019 at 16:39):
@John Wills It depends what you're doing with your messages. The MessageHeader.event (and sender and receiver) overlap significantly with Task so you don't necessarily need Task to use messaging to say "please fulfill" or "yes I will" or "no I won't". However, if you want to send a message that says "so how's it going?", the response will almost certainly need to be conveyed with Task - because there's no other resource that can represent the "progress towards completion" state of a request.
Lloyd McKenzie (May 30 2019 at 16:40):
@Eric Haas I'd prefer for Grahame to identify why the build tool isn't checking this. Once it does, we'll have no choice but to go in and fix all of the descriptions that are broken.
Ion Moraru (May 30 2019 at 17:26):
So, in this context, considering the messaging is supported by specific event codes in the message header can we rely on the ServiceRequest.status to indicate the progress of the service/order at a given point in time?
Tim Berezny (May 30 2019 at 17:31):
@Ion Moraru from the perspective of the RECEIVER progressing the referral and telling the sender that they have processed the referral, my interpretation of @Lloyd McKenzie 's comments above would be no, that Task is better suited to this purpose.
Lloyd McKenzie (May 30 2019 at 17:55):
ServiceRequest.status won't reflect progress. It reflects the state of the authorization. The authorization will stay "active" even if the filler decides they're not going to action it. (Because someone else might later be asked to action the same order.)
Tim Berezny (May 30 2019 at 18:00):
Got it, thanks @Lloyd McKenzie .
One question from an implementation standpoint on the RECEIVING end of the ServiceRequest ... let's say that the receiver wants to do some work on the referral/serviceRequest in their RECEIVING system. e.g., add some notes, add an attachment, fix an incorrectly submitted phone number. How does the receiver making these changes (which are the norm form most referral processing processes) align with updating a ServiceRequest resource and its authorization?
Lloyd McKenzie (May 30 2019 at 18:11):
There are a couple of possibilities. In some cases, the "actioning" system might have the authority to update the source-of-truth copy of the ServiceRequest. In that case, it just makes an update. In other cases, it will have a local "filler" copy of the order and will make the changes in its own copy (to reflect what it's actually going to do), while the original ServiceRequest remains unchanged. In really fancy environments, you could also submit a Task to the placing system requesting that it revise the original ServiceRequest, but that's probably overkill for this requirement.
Tim Berezny (May 30 2019 at 18:55):
Thanks @Lloyd McKenzie , that helps a lot. Can you clarify what "filler" means?
Lloyd McKenzie (May 30 2019 at 19:07):
Placer is the individual/system that creates the order/request/authorization. Filler is the individual/system that performs all or part of the order/request/authorization. So in pharmacy, the placer would be the clinician and the filler would be the pharmacy (and possibly also the nurse who administers the med). In a referral, the placer would be the clinician/practitioner who makes the referral and the filler would be the clinician/agency that is asked to accept the referral.
Tim Berezny (May 30 2019 at 20:00):
@Lloyd McKenzie Thanks that helps a lot
Grahame Grieve (May 30 2019 at 21:23):
I don't know why it's broken. It certainly is supposed to check that those are correct
Lloyd McKenzie (May 30 2019 at 22:19):
@Grahame Grieve Do you need a tracker item?
Grahame Grieve (May 30 2019 at 22:40):
I'd say so, since it's likely to be a technical correction in R4
Grahame Grieve (May 30 2019 at 22:46):
because the value set was defined differently
Grahame Grieve (May 30 2019 at 22:59):
fixing that gives this scary list:
Grahame Grieve (May 30 2019 at 22:59):
ERROR @ ActivityDefinition.kind: The short description of an element with a code list should have the format code | code | etc (should be Kind of resource) (src = ResourceValidator)
ERROR @ ActivityDefinition.intent: The short description "proposal | plan | order" does not match the expected ("proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option") (src = ResourceValidator)
ERROR @ AllergyIntolerance.verificationStatus: Status element code "presumed" not found in status-codes.xml (src = ResourceValidator)
ERROR @ AppointmentResponse.participantStatus: The short description "accepted | declined | tentative | in-process | completed | needs-action | entered-in-error" does not match the expected ("accepted | declined | tentative | needs-action") (src = ResourceValidator)
ERROR @ CarePlan.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ CarePlan.status: Status element code "revoked" not found in status-codes.xml (src = ResourceValidator)
ERROR @ CarePlan.status: The short description "draft | active | suspended | completed | entered-in-error | cancelled | unknown" does not match the expected ("draft | active | on-hold | revoked | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ CarePlan.activity.detail.kind: The short description of an element with a code list should have the format code | code | etc (should be Kind of resource) (src = ResourceValidator)
ERROR @ ClinicalImpression.status: Status element code "in-progress" not found in status-codes.xml (src = ResourceValidator)
ERROR @ ClinicalImpression.status: The short description "draft | completed | entered-in-error" does not match the expected ("in-progress | completed | entered-in-error") (src = ResourceValidator)
ERROR @ CodeSystem.filter.operator: The short description of an element with a code list should have the format code | code | etc (should be Operators that can be used with filter) (src = ResourceValidator)
ERROR @ Communication.status: Status element code "not-done" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Communication.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Communication.status: Status element code "stopped" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Communication.status: The short description "preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error" does not match the expected ("preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ Communication.priority: The short description of an element with a code list should have the format code | code | etc (should be Message urgency) (src = ResourceValidator)
ERROR @ CommunicationRequest.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ CommunicationRequest.status: Status element code "revoked" not found in status-codes.xml (src = ResourceValidator)
ERROR @ CommunicationRequest.status: The short description "draft | active | suspended | cancelled | completed | entered-in-error | unknown" does not match the expected ("draft | active | on-hold | revoked | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ CommunicationRequest.priority: The short description of an element with a code list should have the format code | code | etc (should be Message urgency) (src = ResourceValidator)
ERROR @ Condition.clinicalStatus: Status element not registered in status-codes.xml (src = ResourceValidator)
ERROR @ Contract.status: Status element not registered in status-codes.xml (src = ResourceValidator)
ERROR @ Contract.status: The short description "draft | active | suspended | cancelled | completed | entered-in-error | unknown" does not match the expected ("amended | appended | cancelled | disputed | entered-in-error | executable | executed | negotiable | offered | policy | rejected | renewed | revoked | resolved | terminated") (src = ResourceValidator)
ERROR @ Contract.contentDefinition.publicationStatus: Status element not registered in status-codes.xml (src = ResourceValidator)
ERROR @ Contract.contentDefinition.publicationStatus: The short description "draft | active | retired | unknown" does not match the expected ("amended | appended | cancelled | disputed | entered-in-error | executable | executed | negotiable | offered | policy | rejected | renewed | revoked | resolved | terminated") (src = ResourceValidator)
ERROR @ DeviceRequest.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DeviceRequest.status: Status element code "revoked" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DeviceRequest.status: Status element code "unknown" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DeviceRequest.status: The short description "draft | active | suspended | completed | entered-in-error | cancelled" does not match the expected ("draft | active | on-hold | revoked | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ DeviceRequest.intent: The short description "proposal | plan | original-order | encoded | reflex-order" does not match the expected ("proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option") (src = ResourceValidator)
ERROR @ DeviceRequest.priority: The short description of an element with a code list should have the format code | code | etc (should be Indicates how quickly the {{title}} should be addressed with respect to other requests) (src = ResourceValidator)
ERROR @ DocumentReference.docStatus: Status element code "preliminary" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DocumentReference.docStatus: Status element code "final" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DocumentReference.docStatus: Status element code "amended" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DocumentReference.docStatus: Status element code "entered-in-error" not found in status-codes.xml (src = ResourceValidator)
ERROR @ DocumentReference.docStatus: The short description "preliminary | final | appended | amended | entered-in-error" does not match the expected ("preliminary | final | amended | entered-in-error") (src = ResourceValidator)
ERROR @ GraphDefinition.link.target.compartment.code: The short description of an element with a code list should have the format code | code | etc (should be Identifies the compartment) (src = ResourceValidator)
ERROR @ Immunization.status: Status element code "not-done" not found in status-codes.xml (src = ResourceValidator)
ERROR @ ImmunizationEvaluation.status: Status element not registered in status-codes.xml (src = ResourceValidator)
ERROR @ Media.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Media.status: Status element code "stopped" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Media.status: The short description "preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown" does not match the expected ("preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ MedicationRequest.intent: The short description "proposal | plan | order | original-order | instance-order | option" does not match the expected ("proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option") (src = ResourceValidator)
ERROR @ NutritionOrder.status: Status element code "revoked" not found in status-codes.xml (src = ResourceValidator)
ERROR @ NutritionOrder.status: Status element code "unknown" not found in status-codes.xml (src = ResourceValidator)
ERROR @ NutritionOrder.status: The short description "proposed | draft | planned | requested | active | on-hold | completed | cancelled | entered-in-error" does not match the expected ("draft | active | on-hold | revoked | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ NutritionOrder.intent: The short description "proposal | plan | order" does not match the expected ("proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option") (src = ResourceValidator)
ERROR @ Procedure.status: Status element code "not-done" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Procedure.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ Procedure.status: Status element code "stopped" not found in status-codes.xml (src = ResourceValidator)
ERROR @ RequestGroup.status: Status element code "on-hold" not found in status-codes.xml (src = ResourceValidator)
ERROR @ RequestGroup.status: Status element code "revoked" not found in status-codes.xml (src = ResourceValidator)
ERROR @ RequestGroup.status: The short description "draft | active | suspended | cancelled | completed | entered-in-error | unknown" does not match the expected ("draft | active | on-hold | revoked | completed | entered-in-error | unknown") (src = ResourceValidator)
ERROR @ RequestGroup.intent: The short description "proposal | plan | order" does not match the expected ("proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option") (src = ResourceValidator)
ERROR @ RiskAssessment.status: Status element not registered in status-codes.xml (src = ResourceValidator)
ERROR @ ServiceRequest.status: Status element not registered in status-codes.xml (src = ResourceValidator)
ERROR @ ServiceRequest.status: The short description "draft | active | suspended | completed | entered-in-error | cancelled" does not match the expected ("draft | active | on-hold | revoked | completed
Lloyd McKenzie (May 31 2019 at 00:12):
Tim Berezny (May 31 2019 at 01:21):
@Lloyd McKenzie is there a generally accepted way to indicate that a version of a request resource is a "filler" or "placer" version?
Eric Haas (May 31 2019 at 01:26):
identifier type is a clue
Tim Berezny (May 31 2019 at 01:31):
But i might have both the placer and filler identifiers recorded on the ServiceRequest?
Eric Haas (May 31 2019 at 01:33):
I realized that as well
Lloyd McKenzie (May 31 2019 at 02:08):
Request.intent allows you to distinguish filler orders from original orders
John Silva (May 31 2019 at 05:04):
In the 'old HL7 V2 days' ;-) the notion of filler, placer, tracker and informer were well defined in the order request workflow (Chapter 4 I believe). Does the FHIR Workflow (or Task) pattern have this nice definition of these roles in 'order fulfillment'?
Lloyd McKenzie (May 31 2019 at 12:04):
Probably not as good as it should. Do you want to submit a change request?
John Silva (May 31 2019 at 13:42):
Sure -- on which page -- the Task (pattern) page?
Lloyd McKenzie (May 31 2019 at 14:59):
Workflow pages I think.
Grahame Grieve (May 31 2019 at 23:52):
I fixed all the errors related to this in the current build - quite a lot of work
Last updated: Apr 12 2022 at 19:14 UTC
