Stream: implementers
Topic: ServiceRequest category and code
Martin Grundberg (Feb 18 2020 at 10:58):
We are looking into the ServiceRequest resource. It is obviously a very generic resource for many types of "requests" and "orders", so we need to have a strategy for classifying them correctly.
There are two attributes, ServiceRequest.category and ServiceRequest.code that seem to be relevant to use.
Example use cases could be:
- Radiology referral for a CT Scan of the abdomen
- Laboratory order for a set of investigations such as creatinine, glucose, albumin, calcium, sodium...
- Request for a surgical procedure, specifically a full hip replacement with cement
- Request f to a patient to fill in a form prior to a surgery specifying their life style factors (smoking, alcohol...)
Question 1 - How should we use category?
Is it correct to see ServiceRequest.category as the broader classification of the "type" or ServiceRequest. The examples seem to indicate that. The following examples map very well to our internal "request types". We need to map the ServiceRequest internally to our corresponding data models and internal APIs. For use cases above, would the following be correct for ServiceRequest.category?
1) Imaging
2) Laboratory procedure
3) Surgical procedure
4) ??? (background for this question is that I asked our national Snomed CT affiliate for a concept for this use case)
Question 2 - How should we use code?
Is it correct that ServiceRequest.code should be used for specifying explicitly what is requested? Looking at my use cases again...
1) Computed tomography of abdomen (procedure) SCTID: 169070004
2)
Creatinine measurement, serum (procedure) SCTID: 113075003
Glucose measurement, serum (procedure) SCTID: 22569008
Albumin measurement, serum (procedure) SCTID: 104485008
Serum calcium measurement (procedure) SCTID: 271240001
Sodium measurement, serum (procedure) SCTID: 104934005
3) Total prosthetic replacement of hip joint using cement (procedure) SCTID: 265157000
4) ??? (concept requested from our Snomed CT affiliate corresponding to something similar to "filling in life style factor questionnaire")
Question 3 - How should we then use the cardinalities?
If ServiceRequest.category was correctly interpreted above, is it correct that is has 0..*? I dont think that makes sense as I suspect many will have a similar requirement like we have, they need to map a category to some internal data structure/entity, and it cant be more than one.
On the other hand, ServiceRequest.code has 0..1, if we are expected to use code in the way I suggested above, that doesnt work as you often request multiple things to be done. How should this be handled? Should each investigation in the laboratory ServiceRequest have a child ServiceRequest for each individual investigation using ServiceRequest.basedOn? Or how should we manage it?
Thanks for any input! I think it is extremely important to have a common strategy for this when implementing ServiceRequest support, and ideally others would use the same strategy.
Daniel Karlsson (Feb 18 2020 at 12:25):
There have been similar discussions in the SNOMED on FHIR project group on the category-code issue e.g. here https://confluence.ihtsdotools.org/display/FHIR/Free+SNOMED+CT+set+for+FHIR
We're happy to bring this up for ServiceRequest as we're currently working through the Procedure-CarePlan area now.
Vassil Peytchev (Feb 18 2020 at 13:17):
The 4th use case is unusual for ServiceRequest. It sounds like it is a Questionnaire, where the QuestionnaireResponse will contain the responses. I can see the point that such a Questionnaire can be "ordered" by a provider, and hence the ServiceRequest, but the use case indicates that the Questionnaire is within the context of a surgical procedure.
Lloyd McKenzie (Feb 18 2020 at 15:02):
Multiple categories allow you to classify the order in different ways. So you can do radiology vs. lab vs. surgery, but you can also do inpatient vs. outpatient or physician order vs. resident order or any number of other categorizations.
If you're ordering multiple things, each one is a distinct Request - because each one might be suspended, resumed, cancelled, completed, etc. independently. If you're actually in one of those rare situations where multiple activities are intrinsically linked and their states can't be manipulated independently, then set their intent to "option" and use the RequestGroup resource to manage the collection of them.
Multiple things ordered at the same time should be able to be grouped using the groupIdentifier element as defined in the Request pattern. However, it appears that ServiceRequest is missing this element. I've submitted FHIR#26316 to deal with this. (@Eric Haas do you know why this element is missing?) In the interim, you may need to use an extension.
basedOn doesn't allow linking parent/child. It's about a fulfillment chain. E.g. lab filler order D is based on physician placer order C is being done based on care plan B which in turn was based on clinical decision support recommendation A.
Martin Grundberg (Feb 18 2020 at 15:41):
Vassil Peytchev said:
The 4th use case is unusual for ServiceRequest. It sounds like it is a Questionnaire, where the QuestionnaireResponse will contain the responses. I can see the point that such a Questionnaire can be "ordered" by a provider, and hence the ServiceRequest, but the use case is indicates that the Questionnaire is within the context of a surgical procedure.
There is even a standard extension on ServiceRequest for this use case: https://www.hl7.org/fhir/extension-servicerequest-questionnairerequest.html
To me it feels correct to use SR to request a questionnaire to be filled in.
Martin Grundberg (Feb 18 2020 at 15:57):
Lloyd McKenzie said:
Multiple categories allow you to classify the order in different ways. So you can do radiology vs. lab vs. surgery, but you can also do inpatient vs. outpatient or physician order vs. resident order or any number of other categorizations.
If you're ordering multiple things, each one is a distinct Request - because each one might be suspended, resumed, cancelled, completed, etc. independently. If you're actually in one of those rare situations where multiple activities are intrinsically linked and their states can't be manipulated independently, then set their
intentto "option" and use the RequestGroup resource to manage the collection of them.Multiple things ordered at the same time should be able to be grouped using the groupIdentifier element as defined in the Request pattern. However, it appears that ServiceRequest is missing this element. I've submitted FHIR#26316 to deal with this. (Eric Haas do you know why this element is missing?) In the interim, you may need to use an extension.
basedOndoesn't allow linking parent/child. It's about a fulfillment chain. E.g. lab filler order D is based on physician placer order C is being done based on care plan B which in turn was based on clinical decision support recommendation A.
That gave a lot of good input!
Regarding the groupIdentifier, why is the data type an Identifier and not a Reference? Wouldn’t that request also be resource of its own?
Lloyd McKenzie (Feb 18 2020 at 16:12):
There isn't a separate resource for the 'requisition' - there's no independent request with its own status. When you take a lab order form and tick of 15 of the 50+ tests listed on the form, in FHIR that results in 15 independent ServiceRequests that all share a common groupIdentifier that indicates they were all ticked off at once on a single form. There are no other resource instances created.
Vassil Peytchev (Feb 18 2020 at 17:41):
Martin Grundberg said:
There is even a standard extension on ServiceRequest for this use case: https://www.hl7.org/fhir/extension-servicerequest-questionnairerequest.html
To me it feels correct to use SR to request a questionnaire to be filled in.
I wasn't aware of that extension. As long as you don't lose the context that the questionnaire is related to an upcoming surgery, then a ServiceRequest should work.
Eric Haas (Feb 18 2020 at 17:58):
see http://build.fhir.org/servicerequest-definitions.html#ServiceRequest.requisition
Eric Haas (Feb 18 2020 at 18:00):
and the mapping here: http://build.fhir.org/servicerequest-mappings.html#workflow
Eric Haas (Feb 18 2020 at 18:00):
been there since DiagnosticRequest
Lloyd McKenzie (Feb 18 2020 at 18:01):
Ah. Missed because of the different name. Perfect. So no need for an extension.
Geoff Ramsay (Feb 18 2020 at 20:48):
Hi @Martin Grundberg! - What is the use case for the questionnaire request?
In our eReferral use cases, we're sending a ServiceRequest with an accompanying (supportingInfo) QuestionnaireResponse... but for us, the request to fill in the Questionnaire in the first place doesn't seem to be something that needs to be governed by a workflow.
Are your ServiceRequests inside an organization? or Inter-organization?
Thanks!!
Martin Grundberg (Feb 19 2020 at 07:11):
Hi @Geoff Ramsay
The use case is mainly driven by patient questionnaires. There are various scenarios where you want a patient to fill in a questionnaire prior to an appointment of some sort.
Here in Sweden we have a national patient portal to which healthcare organizations can request a patient to fill in a form. There is already today a Swedish proprietary way of posting this request for form completion. We (EHR vendors and national health IT infrastructure provider) are together looking into how we could implement this use case using FHIR instead. A ServiceRequest with an associated questionnaire feels like the right way to go. We also need to know whether the questionnaire has been completed, so there is workflow involved.
PROMs (Patient Recorded Outcome Measures) and lifestyle factor questionnaires are two important use cases. The former normally sent after eg a surgery, and the latter often prior to various appointments.
I haven’t thought much about whether there are use case between healthcare organizations/healthcare professionals for requesting questionnaire completion. Referrals is something else, and your approach sounds better. There the core service requested is not a form to be completed, but I guess instead the questionnaire acts as a template for the referrer to complete necessary information so the receiver can act accordingly.
Martin Grundberg (Feb 19 2020 at 09:00):
Lloyd McKenzie said:
There isn't a separate resource for the 'requisition' - there's no independent request with its own status. When you take a lab order form and tick of 15 of the 50+ tests listed on the form, in FHIR that results in 15 independent ServiceRequests that all share a common groupIdentifier that indicates they were all ticked off at once on a single form. There are no other resource instances created.
I must admit, I havent looked into this area too much in FHIR yet, so I might very well be wrong. But this sounds strange. I can see that you would need to keep track of the status of the requisition for multiple reasons. That is what is completed when all the individual tests are completed. You might get multiple results coming at various times. At some point the requisition is completed. This to me seems to also force business logic onto the client as they will need to aggregate all the individual ServiceRequests and interpret the status of the requisition. There would also be common information on the requisition level, like who authorized it/requester.
Or is RequestGroup intended to be used for this use case?
Lloyd McKenzie (Feb 19 2020 at 16:13):
There isn't an overall authorization for the requisition that has more information than the individual pieces. If you wished, you could search to see if all of the ServiceRequests for a particular requisition were complete. RequestGroup is used when the individual parts can't have their status manipulated independently. I.e. you can't suspend, abort or mark as 'complete' the individual pieces. Instead, the status only exists on the collective. E.g. You're administering a complex chemotherapy protocol where it's not appropriate/safe/effective to stop one part without stopping everything.
Lloyd McKenzie (Feb 19 2020 at 16:14):
Every individual request has to hold all of the common information because each request has to be able to stand on its own - so the requester, date, reason, etc. will be specified on (or pointed to by) every lab test created from that one requisition form.
Last updated: Apr 12 2022 at 19:14 UTC
