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

Difference between revisions of "Supply FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
Line 12: Line 12:
  
  
=Supply=
+
=SupplyRequest and SupplyDelivery (replacing Supply)=
  
 
<!-- Resource names should meet the following characteristics:
 
<!-- Resource names should meet the following characteristics:
Line 33: Line 33:
  
 
* Pharmacy
 
* Pharmacy
* Anatomic Pathology
+
* Devices
* Clinical Genomics
+
* Patient Care
* Imaging Integration
 
* Public Health and Emergency Response
 
  
 
==FHIR Resource Development Project Insight ID==
 
==FHIR Resource Development Project Insight ID==
  
952
+
952
  
 
==Scope of coverage==
 
==Scope of coverage==
Line 55: Line 53:
 
  -->
 
  -->
  
DEFINITION (SUPPLY):
+
DEFINITION (SupplyRequest and SupplyDelivery):
The supply resource covers information needed for the ordering and distribution of supplies within a healthcare facility or office.
+
Origiinally proposed as a single resource "Supply", the SupplyRequest and SupplyDelivery resources cover information needed for the ordering and distribution of supplies between healthcare organizations and external suppliers and within a healthcare organization
  
Scope Challenge: Should MedicationDispense use the supply resource?
 
  
 
==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. -->
*Role: Supply (classCode=SPLY, moodCode=EVN)
+
*Role: Supply (classCode=SPLY, moodCode=EVN) TODO: Review RIM mapping based upon udpate to SupplyRequest and SupplyDelivery
  
 
==Resource appropriateness==
 
==Resource appropriateness==
Line 79: Line 76:
 
* 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  
 
  -->
 
  -->
Supplies in healthcare are necessary for the tracking of delivery of materials to the patient's room, dispensing of medicinal products, etc.
+
Resource to record the request(order), delivery and dispense of materials, devices, medications etc to the patient's room, ward, central supply etc are necessary for the tracking of devices, substance and medications in healthcare.
  
 
==Expected implementations==
 
==Expected implementations==
  
 
<!-- For resources not deemed "key", what interest is there by implementers in using this particular resource.  (Should ideally have multiple independent implementations) -->
 
<!-- For resources not deemed "key", what interest is there by implementers in using this particular resource.  (Should ideally have multiple independent implementations) -->
Required for CCDA
+
*Required for CCDA
 +
*Record request and delivery of devices, substance and medications when context is generic -i.e. not specifically tied to  a patient record.
  
 
==Content sources==
 
==Content sources==
Line 95: Line 93:
 
*HL7 v2.x
 
*HL7 v2.x
 
*HL7 v3 Diet and Nutrition DAM
 
*HL7 v3 Diet and Nutrition DAM
 +
*IHE Pharmacy(PHARM) White Paper, Supply of Products for Healthcare
 +
  
 
==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.) -->
 +
 +
*Central supply at Acme Hospital is running low on widgets.  EMH orders a widgets  ‘XYZ’  for restock. 
 +
*Central supply at Acme Hospital resupply floor stock
 +
  
 
==Resource Relationships==
 
==Resource Relationships==
Line 104: Line 108:
 
<!-- What are the resources do you expect will reference this resource and in what context?
 
<!-- What are the resources do you expect will reference this resource and in what context?
  
What resources do you expect this resource reference and in what context?
+
What resources do you expect these resources reference and in what context?
  
 
Note: These may be existing resources or "expected" resource
 
Note: These may be existing resources or "expected" resource
Line 110: Line 114:
 
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)
 
  -->
 
  -->
*Order
+
*DiagnosticOrder
+
*Order/OrderResponse
*MedicationPrescription
+
*Contract
*ImagingStudy
+
*CarePlan
 +
*ClinicalImpression
 +
 
  
 
==Timelines==
 
==Timelines==
Line 119: Line 125:
 
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
 
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
  
*Vote by WG (Ready for ballot): July 2013
+
*Vote by WG (Ready for ballot): July 2015
*Ballot: September 2013
+
*Ballot: next ballot (October 2015?) 
  
 
==gForge Users==
 
==gForge Users==
  
 
<!-- 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.) -->
*Lorraine Constable
+
*Eric Haas
 
*Patrick Loyd
 
*Patrick Loyd
 +
*Jose Costa Teixeira
  
  
 
==Issues==
 
==Issues==
# Need to decide whether this gets merged with MedicationDispense. If not, need to define scope to explicitly exclude that (both scope & RIM mapping)
+
# Need to deterine boundaries and relationships with MedicationDispense and DeviceUseRequest.
# Need to expand the description a little bit.  Is this only for "supply to patient" or does it include any transfer of material within healthcare?  Can it include patient transport?  If not, where is that handled?
+
# RIM mappings need review
# Need relationships identified.  (Particularly confused by ImagingStudy)
+
# Need to expand the description a little bit.  Do the patient centric and bulk supply need different resources (current ballot comments)
 
# Should look at NCPDP, probably OpenEHR, jurisdictional specifications (e.g. Vision dispense for pan-Canadian claims)
 
# Should look at NCPDP, probably OpenEHR, jurisdictional specifications (e.g. Vision dispense for pan-Canadian claims)
# Need example scenarios
 

Revision as of 00:12, 16 July 2015



SupplyRequest and SupplyDelivery (replacing Supply)

Owning committee name

Orders & Observations WG

Interested Work Groups

  • Pharmacy
  • Devices
  • Patient Care

FHIR Resource Development Project Insight ID

952

Scope of coverage

DEFINITION (SupplyRequest and SupplyDelivery): Origiinally proposed as a single resource "Supply", the SupplyRequest and SupplyDelivery resources cover information needed for the ordering and distribution of supplies between healthcare organizations and external suppliers and within a healthcare organization


RIM scope

  • Role: Supply (classCode=SPLY, moodCode=EVN) TODO: Review RIM mapping based upon udpate to SupplyRequest and SupplyDelivery

Resource appropriateness

Resource to record the request(order), delivery and dispense of materials, devices, medications etc to the patient's room, ward, central supply etc are necessary for the tracking of devices, substance and medications in healthcare.

Expected implementations

  • Required for CCDA
  • Record request and delivery of devices, substance and medications when context is generic -i.e. not specifically tied to a patient record.

Content sources

  • HL7 v3 Pharmacy Standard
  • HL7 v2.x
  • HL7 v3 Diet and Nutrition DAM
  • IHE Pharmacy(PHARM) White Paper, Supply of Products for Healthcare


Example Scenarios

  • Central supply at Acme Hospital is running low on widgets. EMH orders a widgets ‘XYZ’ for restock.
  • Central supply at Acme Hospital resupply floor stock


Resource Relationships

  • Order/OrderResponse
  • Contract
  • CarePlan
  • ClinicalImpression


Timelines

  • Vote by WG (Ready for ballot): July 2015
  • Ballot: next ballot (October 2015?)

gForge Users

  • Eric Haas
  • Patrick Loyd
  • Jose Costa Teixeira


Issues

  1. Need to deterine boundaries and relationships with MedicationDispense and DeviceUseRequest.
  2. RIM mappings need review
  3. Need to expand the description a little bit. Do the patient centric and bulk supply need different resources (current ballot comments)
  4. Should look at NCPDP, probably OpenEHR, jurisdictional specifications (e.g. Vision dispense for pan-Canadian claims)