This wiki has undergone a migration to Confluence found Here

Difference between revisions of "ProcedureRequest FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
 
(14 intermediate revisions by one other user not shown)
Line 3: Line 3:
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="background:#F0F0F0">
 
<div style="background:#F0F0F0">
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
+
This page documents a [[:category:Approved FHIR Resource Proposal|Approved]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
 
</div>
 
</div>
 
</div>
 
</div>
 
[[Category:FHIR Resource Proposal]]
 
[[Category:FHIR Resource Proposal]]
[[Category:Pending FHIR Resource Proposal]]
+
[[Category:Approved FHIR Resource Proposal]]
  
  
Line 40: Line 40:
  
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 +
 +
1125
  
 
==Scope of coverage==
 
==Scope of coverage==
Line 53: Line 55:
 
As a rule, resources should encompass all of these aspects.
 
As a rule, resources should encompass all of these aspects.
 
  -->
 
  -->
 +
 +
Procedure Request is a record of a request for a procedure to be performed. It can be used to represent a procedure that is planned, that is proposed, or that is ordered.
 +
 +
The procedure request may represent an order that is entered by a practitioner in a CPOE system as well as a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care. Planned procedures may also be represented by this resource.
 +
 +
* Subject: Human and non-human living and non-living (e.g., a human patient, a veterinary patient, ground water testing)
 +
* Disciplines: Cross discipline
 +
* Delivery environment: Clinical Decision Support
 +
* Locale: International Realm
  
 
==RIM scope==
 
==RIM scope==
  
 
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 +
 +
Lloyd to provide
  
 
==Resource appropriateness==
 
==Resource appropriateness==
Line 72: Line 85:
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document  
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document  
 
  -->
 
  -->
 +
 +
Must
 +
* Represents a request for a procedure and captures the following modalities: Recommended, Planned, Proposed, Ordered
 +
* ProcedureRequests can be tracked with distinct, reliable, unique ids
 +
* Procedure requests are common outputs to Clinical Decision Support systems and are also often included in care plans.
 +
 +
Should
 +
* In order to achieve interoperability of exchange of clinical knowledge artifacts or clinical guidance, a common core definition of ProcedureRequest is required.
  
 
==Expected implementations==
 
==Expected implementations==
  
 
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 +
 +
* Clinical Decision Support Systems
 +
* Quality Improvement Platforms
  
 
==Content sources==
 
==Content sources==
Line 82: Line 106:
  
 
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 +
 +
None
  
 
==Example Scenarios==
 
==Example Scenarios==
  
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 +
 +
A CDS system receives as input relevant information pertaining to the patient's medical record and context of care. Based on the input received by the CDS system recommends a particular procedure be performed.
  
 
==Resource Relationships==
 
==Resource Relationships==
Line 97: Line 125:
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
  -->
 
  -->
 +
 +
* Procedure (that resulted from the request)
 +
* Observation (pertinent to the decision to propose the procedure)
 +
* Condition (pertinent to the decision to propose the procedure)
 +
* Other relevant clinical statements pertinent to the decision to propose the procedure
 +
* BodySite
 +
* Performer of the procedure
 +
* Subject (generally the patient)
 +
 +
Please refer to proposed resource: http://hl7-fhir.github.io/procedurerequest.html
  
 
==Timelines==
 
==Timelines==
Line 107: Line 145:
  
 
<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
 
<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
 +
cnanjo

Latest revision as of 20:48, 8 April 2015



ProcedureRequest

Owning committee name

Clinical Quality Information Work Group

Contributing or Reviewing Work Groups

FHIR Resource Development Project Insight ID

1125

Scope of coverage

Procedure Request is a record of a request for a procedure to be performed. It can be used to represent a procedure that is planned, that is proposed, or that is ordered.

The procedure request may represent an order that is entered by a practitioner in a CPOE system as well as a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care. Planned procedures may also be represented by this resource.

  • Subject: Human and non-human living and non-living (e.g., a human patient, a veterinary patient, ground water testing)
  • Disciplines: Cross discipline
  • Delivery environment: Clinical Decision Support
  • Locale: International Realm

RIM scope

Lloyd to provide

Resource appropriateness

Must

  • Represents a request for a procedure and captures the following modalities: Recommended, Planned, Proposed, Ordered
  • ProcedureRequests can be tracked with distinct, reliable, unique ids
  • Procedure requests are common outputs to Clinical Decision Support systems and are also often included in care plans.

Should

  • In order to achieve interoperability of exchange of clinical knowledge artifacts or clinical guidance, a common core definition of ProcedureRequest is required.

Expected implementations

  • Clinical Decision Support Systems
  • Quality Improvement Platforms

Content sources

None

Example Scenarios

A CDS system receives as input relevant information pertaining to the patient's medical record and context of care. Based on the input received by the CDS system recommends a particular procedure be performed.

Resource Relationships

  • Procedure (that resulted from the request)
  • Observation (pertinent to the decision to propose the procedure)
  • Condition (pertinent to the decision to propose the procedure)
  • Other relevant clinical statements pertinent to the decision to propose the procedure
  • BodySite
  • Performer of the procedure
  • Subject (generally the patient)

Please refer to proposed resource: http://hl7-fhir.github.io/procedurerequest.html

Timelines

May 2015 DSTU

gForge Users

cnanjo