Difference between revisions of "20160421 OO FHIR conCall"
(Created page with "{|border="1" cellpadding="2" cellspacing="0" | width="0%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 OO on FHIR (for Orders and Observations)''' <br/> '''Cal...") |
m () |
||
Line 63: | Line 63: | ||
# [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 | #* 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 Supply-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 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 (the name may be conveyed for labeling purposes etc.) this could be Supply. | ||
+ | |||
xxxRequest | xxxRequest |
Revision as of 18:12, 21 April 2016
HL7 OO on FHIR (for Orders and Observations) Call in details: |
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 |
- Roll Call
- Agenda Check
- Minutes from
- Agenda
- Device
- Close out remaining Device Comments
- Review Device QA criteria for FMM proposal
- SupplyRequest and delivery SupplyDelivery
- Look at boundaries between SupplyRequest, DeviceUseRequest, and VisionPrescription Resources
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. 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 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 (the name may be conveyed for labeling purposes etc.) this could be Supply.
xxxRequest
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
| |
---|---|---|---|---|---|---|---|
|
|
category |
S |
1..1 |
CodeableConcept |
class
| |
orderedItem (reference to Medication|Substance|Device)
|
Device (reference) |
code |
S |
0..1 |
CodeableConcept |
what |
What’s being requested/ordered |
patient (use case examples: if custom item or need for labeling)
|
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) |
|
|
|
|
|
|
|
- Jose C-T proposals
- Review outstanding Trackers
- Connectathon review
Minutes
Next Steps
Actions (Include Owner, Action Item, and due date) | |||
Next Meeting/Preliminary Agenda Items |
Back to OO_on_FHIR