FHIR Chat · Model ServiceRequest + the service fulfilling the request · implementers

Stream: implementers

Topic: Model ServiceRequest + the service fulfilling the request

Floyd Eisenberg (Apr 07 2022 at 14:21):

Sorry for the length of this set of questions. I will appreciate guidance from implementers and FHIR modelers. I want to determine if the following modeling is appropriate for ServiceRequest and for identifying performance of services requested. Please advise:
ServiceRequest.code in FHIR 4.0.1 is a CodeableConcept with example binding to SNOMED procedure codes. And ServiceRequest.category can provide classification of the service (lab, imaging, counseling, education, surgical procedure.
ServiceRequest recommendations to a patient would use ServiceRequest.intent=plan; ServiceRequest orders to institute performance of the service would use ServiceRequest.intent=order. My assumption is that the “thing” that is ordered is the same “thing” that is expected to be performed; i.e., if expecting a procedure, the ServiceRequest.code would use the same codes (value set) as the resulting Procedure.code resulting from the request with Procedure.basedon ServiceRequest. So consider the following and indicate if my assumptions are correct or if one or more need adjustment:

1. ServiceRequest for a laboratory procedure: Reference the same LOINC code value set for the Request and for the Observation with a result to represent fulfillment of the request.
2. ServiceRequest for a patient visit: Reference the same SNOMED or perhaps CPT code for the Request and for the resulting Encounter and expect Encounter.status = completed to indicate fulfillment of the request.
3. ServiceRequest for a procedure: Reference the same procedure codes for the request and for the resulting procedure and expect Procedure.status = completed to indicate fulfillment of the request.
4. ServiceRequest for an intervention such as counseling and education: Reference the same codes for the request and consider the counseling and education to use the Procedure resource with Procedure.status = completed to indicate fulfillment of the request.
5. ServiceRequest for an intervention such as case management: Reference either Procedure for the specific intervention expected in a CarePlan, or directly reference a CarePlan.activity for which the CarePlan.activity.detail.code references a Procedure (using Procedure.code) and expect Procedure.status = completed to indicate fulfillmet of the request.
6. ServiceRequest for administration of an evaluation tool or questionnaire (e.g., PRAPARE): Reference the code or value set for the evaluation tool for the request and expect performance as:

• An Observation – i.e., I’m requesting an observation; Or
• A Procedure to capture such an Observation; hence the Procedure would need a different Procedure.code to generate the expected Observation with a result; OR
• Instead, should I consider using the Task resource to request a Task from the appropriate individual and see the observation result as the completion of the Task (I.e., for this use case is ServiceRequest the wrong way to model)?

Floyd Eisenberg (Apr 07 2022 at 14:22):

@Robert Dieterle @Rob Hausam @Robert McClure @Carmela Couderc Please review with respect to rationale on using same or different value sets / values for the request and the fulfillment activity.

Lloyd McKenzie (Apr 07 2022 at 16:25):

1. Definitely not true that the codes must match. First, one order could trigger multiple procedures and/or observations. Second, the level of detail provided might differ. Third, the system performing the services might leverage a different coding system. E.g. order is SNOMED, result is LOINC or CPT.
2. There could be multiple Encounters or none. And the status might not always be 'completed'. (The world can be messy and things don't always hit terminal state). See comment above with respect to codes won't necessarily match. Also, you might not get back encounter information - you could easily just get a DiagnosticReport or even a DocumentReference.
   Other ones - same comments as above

In short, you can't make any presumption about what types of resource(s) you'll get back (if any), nor how they'll be coded.

Task is a mechanism of seeking fulfillment of an order that allows tracking acceptance/refusal, progress towards completion, etc. The 'workflow' pages provide full details about the options for seeking fulfillment of an order. (Merely transmitting an order is not a safe way to initiate fulfillment.)

Floyd Eisenberg (Apr 08 2022 at 13:46):

Thanks @Lloyd McKenzie - I think you addressed my concern and some further discussion may help here. While the actions taken do not match the procedures or observations that fulfill the ServiceRequest, I think the example scenario may help: Nurse, or doctor enters ServiceRequest for home health evaluate and treat (basically, a referral to social worker). While this might be considered a Task that is fulfilled by specific Procedure(s) or Observation(s) being requested or completed, the next comment will provide suggestions for how it might be handled as a ServiceRequest - I.e., the resulting procedure or observation is actually a new Procedure or Observation referencing the ServiceRequest.

Floyd Eisenberg (Apr 08 2022 at 13:54):

1. Nurse or doctor requests a home evaluation for needs to support health (perhaps this might be a Task for the social worker, perhaps a ServiceRequest - using ServiceRequest in this scenario);
2. Social worker receives the request and processes it to determine what actions need to be taken, or what evaluation needs to specifically happen to address the home health situation. 1. Social worker receives the request and processes it to determine what actions need to be taken, or what evaluation needs to specifically happen to address the home health situation.

• Social worker performs:
  ** SDOHAssessment – multiple, some of which are panels, others of which are single item observables – modeling in US Core will support this post-ballot reconciliation. As a result of the SDOH Assessment responses (SDOHAssessment.result), Social worker determines which items require education, which require subsequent referrals, and which require other interventions or findings:

• Procedure – referral to faith-based support group

• Procedure – referral to shelter
• Procedure – referral to charitable organization to help patient find medications and food
• SDOHAssessment.result as finding

Lloyd McKenzie (Apr 08 2022 at 15:53):

1. I'd expect a ServiceRequest - if there's any chance of insurance coverage, you'll need a formal order. However, you might use a Task to seek fulfillment of the ServiceRequest by the social worker. The social worker might then spawn their own 'filler' ServiceRequest(s) and/or Tasks to track and manage what they need to have happen. The resources that capture the final information of information to the ordering clinician would be linked as 'outputs' to the original Task.

Floyd Eisenberg (Apr 09 2022 at 17:57):

@Lloyd McKenzie Thanks - that is my assumption - the ServiceRequest for a specific procedure code generates action by a social worker who then initiates their own ServiceRequest, Task, or Observation and each of those may use a different code than the original ServiceRequest. The main issue then, is there an example of a Procedure (code) that might be inappropriate for a ServiceRequest - I.e. might one assume that the possible codes (value set) for a Procedure might also be usable for a ServiceRequest? I'm trying to identify an instance of a procedure that cannot be ordered, planned, or proposed.

Lloyd McKenzie (Apr 09 2022 at 20:45):

There will certainly be procedures that aren't planned, ordered or proposed. And it's possible there'll be some procedure codes that have a level of granularity that is more specific than what is typical (or even appropriate) to order/plan with. It's sort of the same as medications and labs. Ordering is typically higher level, events are detailed. There remain exceptions on both sides though. You'd be hard-pressed to find a code that couldn't be used on both the order and event sides, though finding some that are unlikely to be used for both shouldn't be hard.

Last updated: Apr 12 2022 at 19:14 UTC