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

20171109 OO FHIR conCall

From HL7Wiki
Jump to navigation Jump to search
HL7 OO on FHIR (for Orders and Observations)

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

Join the meeting at:

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

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

  • Roll Call


  1. Review of Type vs Instance Discussion for Device see Slides


3 options:

  1. add inline elements to indicate - (see slides)
  2. create pattern (assume would align resource with pattern)
  3. split in instance and kind resource so DeviceInstance would reference DeviceKind


( 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


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

  1. First Looks at ObservationDefinition, CatalogEntry , and SpecimenDefinition
    1. ObservationDefinitoin not in build yet
    2. CatalogEntry: Introduction need content, needs terminology, better definitions of some elements and need some examples - will hold off comments until ballot.
    3. 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.
  2. 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
  • 14126 Observation.related.type value set is closed, but not comprehensive (Mark Kramer) None
  • 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 criteria link:

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