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

Difference between revisions of "20160421 OO FHIR conCall"

From HL7Wiki
Jump to navigation Jump to search
()
()
Line 62: Line 62:
 
#* Review Device QA criteria for FMM proposal - not done
 
#* Review Device QA criteria for FMM proposal - not done
 
# [http://hl7-fhir.github.io/supplyrequest.html SupplyRequest] and [http://hl7-fhir.github.io/device.html/supply delivery SupplyDelivery]
 
# [http://hl7-fhir.github.io/supplyrequest.html SupplyRequest] and [http://hl7-fhir.github.io/device.html/supply delivery SupplyDelivery]
#* Look at boundaries between SupplyRequest, [http://hl7-fhir.github.io/deviceuserequest.html  DeviceUseRequest], and [http://hl7-fhir.github.io/visionprescription.html VisionPrescription] Resources
 
  
As well as [http://hl7-fhir.github.io/device.html/supply delivery SupplyDelivery] and [http://hl7-fhir.github.io/device.html/medication dispense Medication Dispense]
 
  
The boundary Supply-DeviceUseRequest would be the same as Supply-medicationOrder (and others): The latter is for the patient-specific order, specifying part of a treatment.
+
'''Look at boundaries between SupplyRequest, [http://hl7-fhir.github.io/deviceuserequest.html  DeviceUseRequest], and [http://hl7-fhir.github.io/visionprescription.html VisionPrescription] Resources'''
 +
 
 +
 
 +
 
 +
The boundary Supply-DeviceUseRequest would be the same as between Supplyand medicationOrder (and others): The latter is for the patient-specific order, specifying part of a treatment.
 
If, to provide for that, any supply/resupply has to be done (e.g. bulk resupply of stock) then we use the SupplyRequest. Meaning that the Supply can be used to order a bunch of devices to refill stock, but not implying a treatment.
 
If, to provide for that, any supply/resupply has to be done (e.g. bulk resupply of stock) then we use the SupplyRequest. Meaning that the Supply can be used to order a bunch of devices to refill stock, but not implying a treatment.
  
 +
Patient-specific treatment-related -->DeviceUse
 +
Bulk supply, treatment-independent --> Supply.
 +
 +
There is a gray zone where both resources wculd work. e.g. from an order, the clinic purchasing department decides to order that device for that patient from the manufacturer. It's a patient-specific order, but may not contain the details for the treatment (for example: the name may be conveyed for labeling purposes) this could be Supply.
 +
 +
This leads to question Whether SupplyRequest should reference Patient element or just use the reason resource generically  [create trackers]
 +
 +
Likely need a special request comment/annotation on the resource as well. [create trackers]
 +
 +
VisionPrescription not needed the custom detail should be attribute of ordered item DeviceUseRequestdevice  (i.e. Device) but this is a Device specialization (Profile) or Resource or separate resource is an open question for FMG.
 +
 +
especially for common stuff like , glasses, hearing aid, teeth, and prothetics.
 +
 +
'''As well as [http://hl7-fhir.github.io/device.html/supply delivery SupplyDelivery] and [http://hl7-fhir.github.io/device.html/medication dispense Medication Dispense]''''
 +
 +
How is Delivery different from Dispense?
 +
 +
Workflow
 +
  | Requests: MedicationOrder, DeviceUseRequest, SupplyRequest
 +
  | Delivery: SupplyDelivery,
 +
  | Dispense:  MedDispense  (here is med - take this BID etc....),  '`no DeviceDispense``, SupplyDispense not needed?
 +
  |  Admin/Use:
 +
  V
 +
 +
NOTE: Inconsistent use of request resources between different WG. ( no DeviceDispense )  - Bring up at FMG
 +
 +
Wheelchair example :  delivery = dispense?  Delivery - act of sending not necessay of being received. vs Dispense Patient get it.
 +
 +
'''Other Notes'''
 +
 +
*From and to location missing in SupplyRequest
 +
 +
*From location missing in SupplyDelivery
 +
 +
 +
*There should be separate instances of SupplyDelivery for each way point
 +
**.destinations where supply sent to, this is like a rreport of something sent to location A which is either an intermediate or final destination.
 +
**Issue brought on whether SupplyDelivery's.destination changes the resource statuses meaning
 +
**Suggest that Task indicates fulfilment of request not the SupplyDelivery
  
patient-specific treatment-related -->DeviceUse
 
Bulk supply, treatment-independent --> Supply.
 
  
There is a gray zone where both resources would work. e.g. from the first order, the clinic purchasing department decides to order that device for that patient from the manufacturer. It's a patient-specific order, but may already not contain the details for the treatment (for example: the name may be conveyed for labeling purposes etc.) this could be Supply.
 
  
Should SupplyRequest include patient element or not (make an extension)?
 
Tracking information function in both resources or just in one?
 
  
  
===xxxRequest===
+
===xxxRequest comparison===
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 275: Line 311:
 
   patient  
 
   patient  
  
(use case examples: if custom item or need for labeling)
+
(Is this need for supply can use reason for this since not a patient specific resource)
  
  
Line 578: Line 614:
  
  
 +
|
  
 
+
From and to location missing in SupplyRequest need for logistics
  
  

Revision as of 20:07, 21 April 2016

HL7 OO on FHIR (for Orders and Observations)

Call in details:
Phone: +1 770-657-9270, Passcode: 398652

Join the meeting at:
https://join.me/vernetzt.us

Date: 2016/04/21
2015 - 02:00 PM (Eastern Time, GMT -04 DST)
Quorum = chair + 4 yes


Co chairs Chair Notetaker
Riki Merrick
Rob Hausam
Lorraine Constable
Patrick Lloyd
Ken McKaslin
Hans Buitendijk


Attendees
X Eric Haas
Riki M
X Hans Buitendijk
X Jose Costa-Teixicara
Dan R
X Jonathan Harber
Kamalini
Mark Jones
X Rob Hausam
Margaret D


    • Review Device QA criteria for FMM proposal - not done
  1. SupplyRequest and delivery SupplyDelivery


Look at boundaries between SupplyRequest, DeviceUseRequest, and VisionPrescription Resources


The boundary Supply-DeviceUseRequest would be the same as between Supplyand medicationOrder (and others): The latter is for the patient-specific order, specifying part of a treatment. If, to provide for that, any supply/resupply has to be done (e.g. bulk resupply of stock) then we use the SupplyRequest. Meaning that the Supply can be used to order a bunch of devices to refill stock, but not implying a treatment.

Patient-specific treatment-related -->DeviceUse Bulk supply, treatment-independent --> Supply.

There is a gray zone where both resources wculd work. e.g. from an order, the clinic purchasing department decides to order that device for that patient from the manufacturer. It's a patient-specific order, but may not contain the details for the treatment (for example: the name may be conveyed for labeling purposes) this could be Supply.

This leads to question Whether SupplyRequest should reference Patient element or just use the reason resource generically [create trackers]

Likely need a special request comment/annotation on the resource as well. [create trackers]

VisionPrescription not needed the custom detail should be attribute of ordered item DeviceUseRequestdevice (i.e. Device) but this is a Device specialization (Profile) or Resource or separate resource is an open question for FMG.

especially for common stuff like , glasses, hearing aid, teeth, and prothetics.

As well as delivery SupplyDelivery and dispense Medication Dispense'

How is Delivery different from Dispense?

Workflow

 |	Requests: MedicationOrder, DeviceUseRequest, SupplyRequest
 |	Delivery: SupplyDelivery,
 |	Dispense:  MedDispense  (here is med - take this BID etc....),  '`no DeviceDispense``, SupplyDispense not needed?
 |  	Admin/Use:
 V 

NOTE: Inconsistent use of request resources between different WG. ( no DeviceDispense ) - Bring up at FMG

Wheelchair example : delivery = dispense? Delivery - act of sending not necessay of being received. vs Dispense Patient get it.

Other Notes

  • From and to location missing in SupplyRequest
  • From location missing in SupplyDelivery


  • There should be separate instances of SupplyDelivery for each way point
    • .destinations where supply sent to, this is like a rreport of something sent to location A which is either an intermediate or final destination.
    • Issue brought on whether SupplyDelivery's.destination changes the resource statuses meaning
    • Suggest that Task indicates fulfilment of request not the SupplyDelivery



xxxRequest comparison

RequestResource

RequestResource

Template

SupplyRequest Inventory

DeviceUseRequestClinical Use

Name

Flags

Card.

Type

W5

Description & Constraints

identifier

identifier

identifier

S

0..*

Identifier

id

Business identifier for request/order



basedOn

S

0..*

Reference()


Request fulfilled by this request



parent

S

0..1

Identifier


Composite request this is part of

status

status

status

S

1..1

code

status


draft | active | suspended



category

S

1..1

CodeableConcept

class


proposal | plan | orig. order | encoded +

   orderedItem

(reference to Medication|Substance|Device)


Device (reference)

code

S

0..1

CodeableConcept

what

What’s being requested/ordered

  patient 

(Is this need for supply can use reason for this since not a patient specific resource)


Subject( should be Patient)

subject

S

1..1

Reference(Patient | Group? | ??)

who.focus

Individual the service is ordered for

(use cases? Billing?) 

encounter

context

S

0..1

Reference(Encounter | EpisodeOfCare)

context

Encounter or Episode during which request was created

when.code

when.schedule 


Priority,


timingTiming,


timingDateTime,


timingPeriod

occurrence[x]

S

0..1

dateTime| Period| Schedule?

when.planned

When service should occur

date

recordedOn

orderdedOn ( more of a Task thingy)

authored

S

0..1

dateTime

when.recorded

When the request transitioned to being actionable

source


requester

S

0..1

Reference(Device | Patient | Practitioner | RelatedPerson | Organization?)

who.author

Who/what is requesting service



performerType

S

0..1

CodeableConcept

who.performer

Desired type of performer for service

 supplier



performer

S

0..1

Reference(Practitioner | Organization | Patient | Device | RelatedPerson)

who.performer

Desired performer for service

 reasonCodeableConcept,reasonReference


Indication, PRNreason ( really more of a protocol thingy)

reason[x]

S

0..1

CodeableConcept | Reference(??)

why

Why is service necessary?




supportingInfo


0..*

Reference(Any)


Additional information to be used in fulfilling request


Notes

note


0..*

Annotation


Comments made about the service request

Kind (e.g. central stock, non-stock)








From and to location missing in SupplyRequest need for logistics














    • Jose C-T proposals
  1. Review outstanding Trackers
  2. Connectathon review

Minutes

Next Steps

Actions (Include Owner, Action Item, and due date)
Next Meeting/Preliminary Agenda Items

2015mmdd_OO_FHIR_concall


Back to OO_on_FHIR