20171109 OO FHIR conCall
| HL7 OO on FHIR (for Orders and Observations) Call in details: |
Date: 2017/11/09 2015 - 02:00 PM (Eastern Time, GMT -04 DST) | |
| Quorum = chair + 4 yes | ||
| scope="col" | Co chairs | Chair | Notetaker |
|---|---|---|---|
| Riki Merrick | |||
| Rob Hausam | X | ||
| Lorraine Constable | |||
| Patrick Lloyd | |||
| KD Nolan | |||
| Hans Buitendijk | X |
| Attendees | |
|---|---|
| X | Eric Haas |
| X | Hans Buitendijk |
| Jose Costa-Teixeira | |
| Dan Rutz | |
| X | Rob Hausam |
| Andrea Pitkus | |
| Kirk Schaper | |
| X | Marti Velezis |
| X | Freida Hall |
| Elliot Silver | |
Contents
- Roll Call
Agenda
- Review of Type vs Instance Discussion for Device see Slides
Discussion:
3 options:
- add inline elements to indicate - (see slides)
- create pattern (assume would align resource with pattern)
- split in instance and kind resource so DeviceInstance would reference DeviceKind
Eric:
( note Medication is out of scope for OO )
prefer Substance/deviceInstance resource to point to Substance/deviceKind ( new resources ) like PractitionnerRole and Practitioner.
As long as DeviceKind could be used for Catalogues, Orders. What about DeviceComponent and Device Metric Could DeviceInstance could be used for both Device and DeviceComponent? DeviceMetric would point to Deviceinstance?
Challenge is socialize this idea and get broad approval. In particular Devices, Patient Care and Pharmacy as well a BRRRR project and UDI folk.
Who will do the legwork?
Need a Connectathon
Marti:
inline element- boolean can cause issues with ambiguity if flag and elements don't agree
Marti will look at options from regulatory perspective.
Other issue: The definition of UDI Carrier needs to be accurately represented in the based standards. FHIR may need to be updated to reflect a better representation of the data model - the UDI carrier - carries more than just the UDI - i.e., it contains the UDI and other information. Therefore the representation in FHIR where the carrierHRF and carrierAIDC are parented to the udi class maybe leading to the confusion. Need to discuss with Eric Haas.
Next step: review in context of clinical, inventory and regulatory contexts follow up with Jose
- First Looks at ObservationDefinition, CatalogEntry , and SpecimenDefinition
- ObservationDefinitoin not in build yet
- CatalogEntry: Introduction need content, needs terminology, better definitions of some elements and need some examples - will hold off comments until ballot.
- SpecimenDefinition : Introduction need content, some terminology missing, issue with name and cardinality of 'specimenToLab', need better definitions of some elements ( requirement vs handling seems redundant) and need some examples - will hold off comments until ballot.
- Trackers
Trackers sorted by topic
Vitals Profile
(reviewing with Argonaut Community as well since tied to USCore)
- 13801 Vital signs profiles - Body Height (Ardon Toonstra) None
- review with Argonaut/US Core Community
- 13652 Observation requires Vital Signs Profile support which requires LOINC%2C which is too strict (Erik Moll) Not Persuasive In Person
- outcome of LOINC/Device meeting - todo email Swapna
Workflow Related
- 11217 Thoughts on combining SupplyRequest%2C DeviceUseRequest and VisionPrescription - 2016-09 core %23371 (Riki Merrick) Considered for Future Use
- reached out to Lloyd for next steps :
"If we get SupplyRequest[sic] to the point where it can meet the need and we have an example, we can then suggest punting it to FM. If they disagree, we escalate to FMG" EH I think he meant DeviceRequest
New Profiles
- 12913 Create a profile for %22Patient characteristics%22 (Lloyd McKenzie) None
- Are we ready for this?
- 13938 Add phsyical activity profiles like vitals (Harri Honko) None
- See Harry's Finnish Profiles
Media Related
- 13562 DiagnosticReport.image incorrectly named (Elliot Silver) None
Observation
- 14126 Observation.related.type value set is closed, but not comprehensive (Mark Kramer) None
SeviceRequest
- 12966 ProcedureRequest - add DosageInstructions or Quantity (Jamie Hignite) None
- 14002 Support for codified ProcedureRequest.supportingInfo (Michelle Miller) Not Persuasive
- 14038 how to represent add-ons (Eric Haas) None
- Discussed - more an issue of using existing specimen or some existing thing since is a convenience for the client or practitioner rather than a reason as in a reflex or a follow-up based on earlier result. example: I forgot to order a Free T$ when ordering a bunch of tests. So I call ask to 'add-on" a free T4 so that a new sample does not have to be drawn. Hence reasonReference is not appropriate.
- Next Step Eric to create a scenario and walk through the options....
Other =
- 14142 ProcedureRequest -Harmonize DeviceUseStatement with MedicationStatement (Francois Marcary) None
QA
QA criteria link: http://wiki.hl7.org/index.php?title=FHIR_Conformance_QA_Criteria#StructureDefinition_-_Resource_definition
1. a) OK
1. b) Media is Imaging Study
1. c) don't use for other events such MedAdmin that been defined resources
1. d) Ask about where it should be defined have definition but not in introduction
2. a) add more component per tracker -add example for core characteristics and physical activity (steps or sleep)* note where overlap with condition - e.g Preg Obs
b) fix links from xml to html in example_csv
3. a) RIM Rob take a look - lower priority
b) review mappings
4. a) follow up with Lloyd on whether FHIR code systems need to be V3 for codeable as he asserted
also follow up on NINF and PINF definitions with devices for data absent reason. (check in IEEE spec Swapna?)
Back to OO_on_FHIR
