Difference between revisions of "201709 ProcedureRequest"
Line 3: | Line 3: | ||
[http://wiki.hl7.org/index.php?title=Category:201709_FHIR_Connectathon_Track_Proposals Return to Sept 2017 Proposals] | [http://wiki.hl7.org/index.php?title=Category:201709_FHIR_Connectathon_Track_Proposals Return to Sept 2017 Proposals] | ||
− | =R4 | + | =R4 Clinical Requests = |
==*****Note that the R4 ( actual version here) Version of ProcedureRequest is the focus for this track*****== | ==*****Note that the R4 ( actual version here) Version of ProcedureRequest is the focus for this track*****== |
Revision as of 21:28, 21 June 2017
Contents
R4 Clinical Requests
*****Note that the R4 ( actual version here) Version of ProcedureRequest is the focus for this track*****
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:
- How to represent whether a transfer of care is being requested
- Which elements if any in the ProcedureRequest resource may not be applicable for a referral.
- 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.
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)]