Difference between revisions of "201709 ProcedureRequest"
Line 12: | Line 12: | ||
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 resource today. | 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 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== | ==Proposed Track Lead== |
Revision as of 22:26, 15 June 2017
Contents
ProcedureRequest
Submitting WG/Project/Implementer Group
OO
Justification
Over the last year, the ReferralRequest, DiagnosticRequest and ProcedureRequest resources have become a single resource, ProcedureRequest. 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 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)]