This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201709 ProcedureRequest"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "Justification Over the last year, the ReferralRequest, DiagnosticRequest and ProcedureRequest resources have become a single resource, ProcedureRequest. The merging of thes...")
 
Line 1: Line 1:
Justification
+
[[Category:201709_FHIR_Connectathon_Track_Proposals|Sept 2017 Proposals]]
+
 
 +
[http://wiki.hl7.org/index.php?title=Category:201709_FHIR_Connectathon_Track_Proposals Return to Sept 2017 Proposals]
 +
 
 +
=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.  
 
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.
 
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.
 +
 +
==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===
Proposed Track Lead: Danielle Friend (Email: dfriend@epic.com Skype: dkfriend07 Zulip: Danielle Friend)
+
: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..
Expected Participants:
+
:Success Criteria: Client is able to execute and receive a response for each of the following queries.
•        Eric Haas
+
::ProcedureRequest?patient=[patient]
•        Jenni Syed (tentative)
+
::ProcedureRequest?patient=[patient]&category=[category (of procedure)]
+
::Where the following data elements are returned for a ProcedureRequest representing a non-invasive procedure
Roles:
+
:::Requester
1.      FHIR Server
+
:::Code (of a non-invasive procedure)
a.      The FHIR Server supports the ProcedureRequest resource and can share referrals as well as invasive and non-invasive orders with a client.
+
:::Performer
2.      FHIR Client
+
:::Status
a.      The FHIR Client can request and consume the ProcedureRequest resource in the three main workflows, referrals, invasive orders and non-invasive orders.
+
:::Intent
+
:::Subject
+
:Bonus point: The Server and Client can perform a search for specific procedure codes as:
Scenarios:
+
::ProcedureRequest?patient=[patient]&code=[code (of non-invasive procedure type)]
1.      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 Points: The Server and Client can perform a read interaction (and search on _id) on ProcedureRequest.
 
-          ProcedureRequest/[ID]
 
-          ProcedureRequest?_id=[ID]
 
 
 
2.      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
 
o  Requester
 
o  Code (aka referralRequest.serviceRequested)
 
o  Performer (aka referralRequest.recipient)
 
o  Status
 
o  Intent
 
o  Subject
 
Bonus Point: The Server and Client can perform a search for specific referral codes as:
 
-          ProcedureRequest?patient=[patient]&code=[code (of referral type)]
 
 
3.      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
 
o  Requester
 
o  Code (of an invasive procedure)
 
o  Performer
 
o  Status
 
o  Intent
 
o  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)]
 
 
4.      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 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 non-invasive procedure type)]
 

Revision as of 17:10, 15 June 2017


Return to Sept 2017 Proposals

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.

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)]