201709 ProcedureRequest

Return to Sept 2017 Proposals

R4 Clinical Requests

Submitting WG/Project/Implementer Group

OO

Justification

DiagnosticRequest and ProcedureRequest resources became a single resource in STU3, ReferralRequest was merged with ProcedureRequest in the curent (R4) version of FHIR . The merging of these three resources came about due to unclear boundaries between concepts such as referrals and invasive vs non-invasive orders.

The merging of these resources and subsequent reconciliation of data elements has seen very little connectathon input. This track will focus on calling attention to the three original resources’ original definitions and implementing/prototyping how they are represented in the single R4 version of ProcedureRequest resource today.

We are seeking input on:

1. How to represent whether a transfer of care is being requested
2. Which elements if any in the ProcedureRequest resource may not be applicable for a referral.
3. Whether to keep the resource name "ProcedureRequest" or change the name to reflect the expanded scope.

Proposed Track Lead

Danielle Friend

• Email: dfriend at epic dot com
• Zulip: Danielle Friend
• Skype: dkfriend07

See Connectathon_Track_Lead_Responsibilities

Expected participants

• Cerner
• Epic
• OO - Eric Haas

Roles

FHIR Server

The FHIR Server supports the ProcedureRequest resource and can share referrals as well as invasive and non-invasive orders with a client.

FHIR Client

The FHIR Client can request and consume the ProcedureRequest resource in the three main workflows, referrals, invasive orders and non-invasive orders.

Questions:

Outstanding questions to discuss during this track:

1. How to represent whether a transfer of care is being requested
2. Which elements if any in the ProcedureRequest resource may not be applicable for a referral.

Scenarios:

ProcedureRequest Search

Action: A client performs a search of the Server for a given patient’s ProcedureRequests.

Precondition: A patient exists and that patient has 1 or more procedureRequests.

Success Criteria: Client is able to execute and receive a response for each of the following queries.

ProcedureRequest?patient=[patient]

ProcedureRequest?subject=[patient]

Bonus point: The Server and Client can perform a read interaction (and search on _id) on ProcedureRequest.

ProcedureRequest/[ID]

ProcedureRequest?_id=[ID]

ProcedureRequest – Request for transfer of care (referrals)

Action: A client performs a search of the Server for a given patient’s ProcedureRequests.

Precondition: A patient exists and that patient has 1 or more referral type ProcedureRequests.

Success Criteria: Client is able to execute and receive a response for each of the following queries.

ProcedureRequest?patient=[patient]

ProcedureRequest?patient=[patient]&category=[category (of referral)]

Where the following data elements are returned for a ProcedureRequest representing a referral

Requester

Code (aka referralRequest.serviceRequested)

Performer (aka referralRequest.recipient)

Status

Intent

Subject

Bonus point: The Server and Client can perform a search for specific referral codes as:

ProcedureRequest?patient=[patient]&code=[code (of referral type)]

ProcedureRequest – Request for invasive care – Not the transfer of care

Action: A client performs a search of the Server for a given patient’s ProcedureRequests.

Precondition: A patient exists and that patient has 1 or more invasive procedure type ProcedureRequests.

Success Criteria: Client is able to execute and receive a response for each of the following queries.

ProcedureRequest?patient=[patient]

ProcedureRequest?patient=[patient]&category=[category (of procedure)]

Where the following data elements are returned for a ProcedureRequest representing an invasive procedure

Requester

Code (of an invasive procedure)

Performer

Status

Intent

Subject

Bonus point: The Server and Client can perform a search for specific procedure codes as:

ProcedureRequest?patient=[patient]&code=[code (of invasive procedure type)]

ProcedureRequest – Request for non-invasive care – Not the transfer of care

Action: A client performs a search of the Server for a given patient’s ProcedureRequests.

Precondition: A patient exists and that patient has 1 or more non-invasive procedure type ProcedureRequests..

Success Criteria: Client is able to execute and receive a response for each of the following queries.

ProcedureRequest?patient=[patient]

ProcedureRequest?patient=[patient]&category=[category (of procedure)]

Where the following data elements are returned for a ProcedureRequest representing a non-invasive procedure

Requester

Code (of a non-invasive procedure)

Performer

Status

Intent

Subject

Bonus point: The Server and Client can perform a search for specific procedure codes as:

ProcedureRequest?patient=[patient]&code=[code (of non-invasive procedure type)]