Q3:

European Lab Report in FHIR

View file
name 20230911-Q3-OO-EuLabRptIG.pdf height 250

• Discussion:
  • General approach / pre-adoption of the R5 rules
    • The guide is based on R4, with extension for new elements
    • Needs to support being a legally signed document
    • So will use FHIR document using the DR resource as required resource in the bundle
      • Reference is from DR to the composition, so that the composition provides the structure for the report – like in R5 (as long as the graph has the relationship explained)
      • But in R4 the reference MUST be from the composition – so we will not use that, but the validator is returning a warning (it is about having a resource in the bundle that is not reference from the composition) – we would be able to get an exception from FMG, if this was an HL7 International publication
      • For the other reference around is more complicated to ensure that all the data that is in the diagnosticReport and the composition contains ONLY that data
      • How bad would it be, if we add the reference from the composition?
      • Composition has links from the section level, but it has no link at the top level – which would put it on the section level – would have to add an extension at the root level, not sure that would be understood at that level - How easy it is for an R4 rendering engine understand the backreference from DR to the composition?
        • Not sure
        • Maybe create an invariant to ensure that the reference from the composition guarantees that the reference is to the correct DR
        • How would we know in a bundle that the DR is the anchor of this composition
          • Maybe need a specific bundletype or knowing that the root level extension has a the specific meaning
        • You could have multiple compositions pointing to the same DR
        • SD has approved the reference from DR to the composition – they own composition
        • Why is the bundle of type document?
          • To enforce the rules of composition, which is needed to support the signature of the authenticator
        • We could use the bundle type of collection to overcome the composition rule
        • You would have to persist the bundle to ensure the references are the same over time representing the signed report
      • What is the next step?
        • Ask FHIR-I if they allow to pre-adopt the R5 reference from DR to composition – re-invigorate the zulip thread and ask to get this on FHIR-I agenda via zulip @Giorgio
    • observation.device
      • How do you identify the calibrator?
        • Why is this desired – it is done once and then used on multiple tests
        • Does this mean devices used in specimen processing prior to the testing?
        • Do they really mean calibrator?
        • Also should ask devices how deviceMetric is expected to be used in the observation – they may need to update their description of deviceMetric.identifier

 Gender Harmony agree to publish by OO?

• Need to have more guidance around what reference ranges would be assigned – this does not hold up the publication, but an issue we should tackle afterwards during implementations
• Some typos have been reported in the V2 pages by Craig to Rob – those should be fixed prior to publication

Q4:

Extenstions on observation for qualifying data

• FHIR-31954 - Create list of agreed-upon, registered extensions to be used for qualifying data for Observation TRIAGED
  • Reviewed "consumed item type" and OO's guidance to use that to track consumption 

    • Floyd will take this guidance back to CQI to use consumed item type

    • OO will look to publish our nutrition value set in THO

    • Goal publish QI core by January

US Core Profile Question:

• • Modeling part-time/full-time occupation status in Observation

    • Components? 

    • Use a LOINC assessment? 

    • Asking for the future just in case

QI Core Observation Profile (predates US Core) 

• • Question on subjects. Do they have the right list? Device? Device Request? 

  • Will need an extension on R5 to add in what is missing 

  • Use case is a structural measurement about an organization 

  • Quality measure and measure mean the same in the eyes of Observation

  • Reviewed the types of statuses available in R4, R5, and R6 for device status 

  • For OO...how do we know if the device is not associated to the patient. Do the begin and end dates mean that? 

Q1:

V2.9.1 Ballot topics

• V2-25552 - Next of Kin releated GSP/GSR is not in a Next of Kin Group SUBMITTED
  • Motion find persuasive – will create a group - Riki, Yanick, no further discussion, against: 0, abstain: 2, in favor: 7
• V2-25553 - OML^O39 - GSC in Patient group deleted SUBMITTED
  • Motion find persuasive – will re-instate GSC segment – Riki, Yanick, no further discussion, against: 0, abstain: 1, in favor: 8
• V2-25566 - Not including GSC to dietary order SUBMITTED
  • Let’s tag Donna Pertel and get her input
• V2-25594 - Misapplied resolution for OML Shipment message SUBMITTED
  • Duplicate of V2-25553
• V2-25595 - Answer to Question to Balloters in Chapter 8 (OM1-58 SUBMITTED
  • Considered, no change required
• V2-25605 - Add OBX where new Gender Harmony segments were added. SUBMITTED
  • Add comment that we will remove the notes to balloters
  • Will group this with similar requests for addition of OBX segments for discussion on the main OO call, when submitter can be present
• V2-25607 - Still asking whether OBX or three new segments SUBMITTED
  • Motion to find persuasive – we will remove the notes to balloter section in all chapters – Riki, Yanick, no further discussion, against: 0, abstain: 0, in favor: 8
• V2-25618 - Add OBX where Gender Harmony Segments are added SUBMITTED
  • Will group this with similar requests for addition of OBX segments for discussion on the main OO call, when submitter can be present
• V2-25625 - Add OBX where Gender Harmony Segments are added SUBMITTED
  • Will group this with similar requests for addition of OBX segments for discussion on the main OO call, when submitter can be present
• V2-25626 - Add OBX where Gender Harmony Segments are added SUBMITTED
  • Will group this with similar requests for addition of OBX segments for discussion on the main OO call, when submitter can be present
• V2-25627 - Add OBX where Gender Harmony Segments are added SUBMITTED
  • Will group this with similar requests for addition of OBX segments for discussion on the main OO call, when submitter can be present

USCDI Feedback

• • https://confluence.hl7.org/display/OO/OO+Comments+for+USCDI+v5+draft+Consideration
  • We took notes in the confluence page

Q2:

Cancer pathology

• • Nothing specific to discuss here

Status codes in observation and diagnosticReport

• FHIR-33042 - to discuss but not make any final decisions
  • The comment is on this valueset: https://hl7.org/fhir/valueset-observation-status.html, as that is where the append status code exists in V2 (on OBX)
    • rather than adding appended here, could we just move corrected up in the level?
      • it would not change the wire-format, but we also would have to change the definition for amended by removing 'and corrected'
      • since observation resource is normative, we will need to seek community input
  • during prior discussions we felt like the append status might be better off at the DiagnosticReport level = https://hl7.org/fhir/valueset-diagnostic-report-status.html, where append already exists
    • we think we would want these concepts all at level 1:
      • amended
      • corrected
      • appended

LOI/LRI/ELR updates

• LRI NDBS:
  • V2-25568 - Update message structure requirements for NDBS panel reporting SUBMITTED
    • proposed message structure document (here for convenience only in the version pulled up during this call): 

      View file
      name ORU updates for DBS results - draft v2.docx height 250

    • Ulrike Merrick to send to Hans to bring to EHRA to get their feedback
    • Ulrike Merrick also to send to the NBS LIS vendors to get their feedback
    • ALL - please review the word document in the Jira (latest versions will be there) - we will vote on this on an OO main call
  • V2-25569 - Review the NDBS usage of X SUBMITTED
    • Similar to what we did in LOI - match what is in LOI
    • what do we need to do for local IGs when we want the receiver to indicate that they are NOT expecting data for a field, but they will not raise an error - Ulrike Merrick to check with conformance and V2 Managment on recomendations
• LRI PH
  • V2-25571 - Review usage for PH Profile for ORC-21 and ORC-24 SUBMITTED
    • Erin Holt will take this to the CSTE ELR group and provide feedback
  • V2-25572 - We created the new type of EI and HD datatypes that allow CLIA or OID - should we add NPI? SUBMITTED
    • Clarification that this would be type 2 NPI (for orgnaizations)
    • Concern was raised, that allowing organizations to be used instead of systems, there may still be overlap in identifiers, if the orgnaizations has more than one system that assigns ids - that problem already exists for CLIA, though; we all know having OIDs for all systems would be the best
    • Erin Holt will take this to the CSTE ELR group and provide feedback

LIVD

• < Ed Heierman ADD LINK to example LIVD file spreadsheet >
• < Ed Heierman ADD LINK to LIVD FHIR mapping spreadsheet >
• It would be good to add the mapping from the IICC excel file element to the FHIR elements in the specification (we have done that somewhat, but would be good to ensure we have ALL mappings)
• On the FHIR Mapping file
  • Review of composition tab
    • added section.title and section.code
  • Review of DeviceDefinition tab
    • is it ok to have the same .id value in multiple places?
    • Do we need to desrcibe how we are going to handle updates to identifiers, i.e. when the name based id gets updated with a UDI?
      • this is not currently tracked in the IICC file version
      • in the SARS-CoV-2 LIVD file we added a revision log to make that more evident
      • it may be important to have all identifiers for the same testkit available, as that might help locate it in inventory systems
      • that would also address the probelm of different branding for the same test
      • these updates in most cases would be additive
      • could we add a change tracking into the FHIR resource somehow?
      • List as OPEN ISSUE: How to track changes to identifiers (or any changes?)
      • in non EUA times the UDI should be available at time of the 510k approval
    • Where should we map the observationDefinition to?
      • only the ITC
      • ITC and device and test kit
      • ITC linking allows to have BOTH identifiers associated with the observationDefinition, which is what is mapped to LOINC
      • the ITC represents what is currently 1 row in the LIVD spreadsheet (For SARS-COV-2 at least)
      • ITC shoudl not be needed, if it doesn't affect the coding
      • If we want to allow only mapping to ITC, then we need to change cardinality for .capability to 0..*
      • if we keep cardinality as 1..*, then we need to map to all 3
      • DECISION: change cardinality of .capability to 0..*  and map only ITC (or testkit, if no equipment used)
• Next call 9/26/2023 2 PM ET

Q3:

OO Comments for USCDI v5 draft Consideration

• Reviewing the comments again
• Leave the comment about the required standards
• For result interpretation

  • Make HL7 ObservationInterpretation required and SNOMED CT optional

• SCT hierarchies:
  • Ok with result/values – may consider adding substance (for toxicology studies?) later
  • For resultInterpretation do we need to add organism (for isolate testing) / clinical finding for HLA interpretations / clinical genomics interpretations?
    • I think those would be additional observations, where those end up as result/values
  • Source site – leave body site at the high level for now
• Specimen Condition and Acceptability
  • Should break into two elements:
    • Specimen condition
    • Specimen Acceptability
  • so that the certification can work better on the representation in FHIR
  • Systems can represent how they want, but in the output for data exchange that is what is being certified for
  • condition is on specimen, acceptability is dependent on the test
  • We have these elements:
    • In V2
      • Specimen Condition (SPM-24)
      • Specimen Appropriateness (SPM-23)
      • Specimen Quality (SPM-22)
      • Specimen Reject Reason (SPM-21)
    • In FHIR we have specimen.condition, but don’t yet have an element for the acceptability yet
    • In C-CDA ???
  • USCDI data elements tend to be ambiguously defined
    • Trying to change the modeling to be more specific for each of the elements defined, specifically for the clinical context it defines to
    • Add: Is the reference to the submission is intended to be part of the definition?
      • Add this sentence: Various definitions do not include vocabulary references, e.g., Coverage type, while the submission has more clarity.  Yet in others, e.g., clinical experience preference, the submission would include much more than the definition implies.  It is important that the definition, including the applicable terminology, is clear without having to review the submission and trying to understand which part applies.
  • Outside this feedback maybe as HL7 we should identify the level of clarity around each data element definition to help ONC identify which elements are well defined and which might need further work
  • Motion to accept the comments as on the confluence page
    • Hans Buitendijk, Dan Rutz
    • no further discussion
    • against: 1 (see Kathy’s comment), abstain: 0, in favor: 15

Lab Orders Stale Ballot

• • Finished reconciliation last cycle, but several resolutions required changes that have not yet been applied – we will be working on applying these changes in Friday Q2 – might assign different folks to it

UDI Pattern / IG

• The reaffirmation PSS was sent to Anne – Hans is following up

Q4:

OO Hosting BR&R/DEV

BR&R topic updates

• Electronic SPL on FHIR
  • Took the V3 SPL spec content into FHIR
  • Cover all the use cases FDA uses for SPL, beyond labeling
    • First goal is to get same content as SPL
    • Then we can add in more elements
    • CDRH reviewing for their use case (UDI implementation and additional elements from IFU that cover device characterization
    • As part of the FHIR IG development created a transformation tooling for medications – which may be
    • For devices have safety indications / contraindications and warnings – could be using other codes – for GUUID not in structured format yet
  • Looking for a pathway for folks to migrate from V3 to FHIR
  • Electronic product information from AMA
  • This connectathon how close is SPL on FHIR (R4B) to the electronic product information IG (R5)
    • Just needed to updated structure from R4B to R5 to make this work
    • But vocabulary and some concepts of other countries / regions didn’t exist
    • Will do final testing if we can use the EPI resources into the FDA dB
    • We could have faster adoption if we can adopt EPI

Panel representations

• Link to zulip: https://chat.fhir.org/#narrow/stream/179256-Orders-and-Observation-WG/topic/Usage.20of.20panel.20of.20Observations
  • Started in May 2023
  • In June had 3 calls set up for discussion of this topic
  • AU had connectathon in August and talked to Epic with big footprint in EU and US
  • Option A:
    • DiagnosticReport has members, where the first observation is the top level name of the panel
      • And that observation has sub-members
      • This comes out of CDA pattern
      • HL7 AU profiles use diagnosticReport.code SHOULD match ???
    • Challenge with A:
      • Grouper observation has no other function than to create the group, but what else does it do?
  • Option B:
    • They do not use the parent observation but using DiagnosticReport.code for the parent panel
    • This comes out of V2 pattern more
    • This is what Epic wants to use
    • Challenge with B
      • If this full bloodcount is part of another higher level panel, then you need to look in 2 places to find it (in observation for that instance)
        • For this higher level order shouldn’t this be more than one DiagnosticReport?
        • You would need to make a rule that each panel creates a DiagnosticReport to avoid this problem in order to not
    • For searches do you include the panel?
      • Yes, for cancer patients you want to search for the panel, not just the individual value of the observations
  • How do EHR systems represent this data?
    • Depends on the background they have been working with as described above
  • What is the role of DiagnosticReport.code, when you combine 2 panels?
  • Consider LOINC categories
    • Order only or both – reserve for use in DiagnosticReport.code
    • Both or observation – reserve for use in observation.code
    • Should order only codes be used ONLY in serviceRequest.code?
  • Should we allow nested diagnosticReports for the single convenience order?
  • What is a lab report?
    • Bundle with multiple diagnosticReports?
  • What are the next steps?
    • Provide examples for each of the options and have a vote on the option that should be preferred
  • DiagnosticReport for hemoglobin would have
    • Do we need to provide a way for a FHIR server to declare which options to
  • Comingling visualization with interoperability
  • Fragmentation is the enemy of interoperability
  • Letting market forces decide on what happens with those that systems that cannot comply to the one option that is decided upon

Personalized Health Navigation (PHN)

• <ADD Slides from Todd>
• Looking for Co-sponsor Patient empowerment is sponsor
• There is interesting overlap with nutrition and the feedback cycle of remote patient monitoring (enrollment maybe) – sounds like there is also transport involved
• Motion to be interested party JD Nolen, Dan Rutz,
  • Further discussion: can you upgrade later? Yes we assume so
  • against: 0, abstain: 3, in favor: 20

Q1:

Q2:

Q3: 

BPM+ update for Ralf

• BPM+ looking for a meeting with Ralf and others around COW/FOE. Ralf will work with them to get a call set on the OO side (JD, Lorraine, etc.) 

COW/FOE efforts and aligning BsER and 360X, and to some extent Gravity

• Task/service request with BsER and 360X 
• Reviewed deck: 

  View file
  name 2023_09_BSeR_Update_O&O.pptx height 250

• Comments:
  • For the payload consideration – consider CDex and DTR also as supporting info for the referral request
  • It would be interested to compare the businessstatus state machine against the order model
    • Lab order conceptual model = in ballot recon – here is the older model: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=331
    • Ordering Service
  • How related to COW:
    • We are modeling how to place the order for a lab test and identify the data elements () the data part is easy) and the how to represent the workflow and how the workflow affects the updates to the underlying resources
      • Suggestion is to use BeSR as the starting point for the order side
    • Also working with the Netherlands and Canada for referral workflow

CG Items

• Modeling around sequence and variant
  • Now working on something more than a single point mutation
• New MolecularState concept.
  • Reviewed this topic at a high level. Supporting deck → 

    View file
    name HL7 CG WGM - IM-based FHIR overview 230913.pdf height 250

Risk Assessment and DiagnosticReport – how should they be linked

• The risk assessment is made by the lab in this case
• Currently added an extension to allow reference to riskAssessment from DiagnosticReport.result?
  • riskAssessment could also
    • be a core extension – could call it prognosisReference
    • considered a conclusion, but conclusion is currently only markdown or a code
  • the observations the riskAssessment is derived from is linked from there via.basis
  • riskAssessment is also referenced from clincialImpression via .prognosisReference
  • but the labs often just consider this a result and asserting some known facts related to results, not creating diagnosis
• FHIR-32714 suggested to switch from a profile of observation to use riskAssessment
• In the radiological world this might serve as a means to convey any additional findings separate from the reason the imaging procedure was performed, but something else with risk was found (R/O pneumonia – found mass on X-ray)
• In V2 this might be represented by adding a new type for observation Type (OBX-29) – separate from result
• Suggestion is to make this a standard extension as new element called: .prognosisReference
  • Should this also allow clinicalImpression as allowed referenced resource?
• Also ask II to take a look at this issue

Patient Characteristic

• Aka: anatomic inventory
• OO agreed to do the project, but have no bandwidth
  • We have a grad student = Kelly Davison and another person from Canada who volunteered to lead the project – Lorraine is organizing that

Administrivia

• We will keep joint for next WGM

Q1:

Q2:

Q3:

OO hosting PA

Transport update

• Patient related needs around transport
• Might be able to try out how this works for lab test ordering dealing with specimen transport – might be limited capabilities for connectathon testing
• On PA side have not have requests, so not a priority

encounterHistory

• • FMM0

Group family topic

• Context around who is receiving treatment
• Who is providing treatment
• Cultural aspects
• While TSC decided we have to be consistent, there are
  • TSC will create a taskforce to review this – looking for WG participation
  • OO will share the prep-work
• Looking at confluence page <ADD LINK>
• What is the boundary between organization and group resources?
  • FHIR-I needs to update the group resource and PA can then apply the
  • careTeam and organization boundary has been described
• <ADD link to zulip chat>
• Expanded scope to household, event, workplace
  • How to represent to the workplace depends on the context (employees – could also be organizations)
  • Any extensions for V2 to FHIR extensions – Cooper will review
  • Keep this joint session for next WGM

FHIR R6

• Definition of normative will have to change, if pretty much anything will be considered normative (those 2 resources above will most likely not have had any implementations
• All the big expected changes on PA list got implemented into R5

Jiras

• FHIR-33166
  • Still relevant
  • This may be an FMG question – who should be consistent with whom
  • This change came from applying event pattern
    • In this case maybe we should have changed the pattern?
  • episodeOfCare is important to be able to link to
    • when you don’t have an encounter, but an episodeOfCare
    • during pregnancy encounter as part of 1 episodeOfCare
    • not common would be to have one encounter that has many episodesOfCare and only one of these is applicable to the observation
  • Motion to find not persuasive with mod Marti Velezis, Dan Rutz
    • further discussion:
      • we should update the short display text on .encounter to let folks know that there is an extension out there for using the episodeOfCare
      • this does not mean that the episodeOfCare referenced here has to match those referenced in encounter
      • Comment: add the search parameter for this extension – that is a separate issue – this needs to be separate ticket for FHIR-I, once that is created, then
    • Clarification, non-substantive
    • Against: 0, abstain: 0, in favor: 18
• FHIR-264428
  • $lastn – does it relate to observation.effective or to lastUpdated
  • This can also be done by sorting descending and count the top one
  • effective is what we want (not the update for a result) – there is already a sentence to that effect
  • Since effective can be either a dateTime or period do we need to explain how to interpret period, especially when only one end of the period is provided?
    • Motion to update the sentence ‘… sorted from the most recent to the oldest …’ to ‘… sorted from the most recent effective time to the oldest effective time …’  .effective  – Alexander Henket, Riki Merrick
    • no further discussion
    • Clarification, non-substantive
    • Against: 0, abstain: 0, in favor: 19

Q4:

Cimi not present

Panel Representation (continued)

• Pulled up the notes from Tues Q4 to have the options on screen
• Clinical genomics uses the grouper observation (they also do that in their older V2 implementation, where they have OBR segments without OBX segments; in LRI we don't allow that)
• Use composition to organize the structure of the diagnosticReport
• When panels have more than 1 level of nesting
  • option A all panel codes will be in observation.code
  • option B they will be in both diagnosticReport.code and observation,code, so makes it harder for searches, unless we create 1 diagnosticReport for each panel
• What is the function of the diagnosticReport?
  • it represents the second part of the OBR segment in V2 - report status across observations that belong to a panel, release of results or updates related to the panel
  • it reporesents the logical model of observations / work that belongs together
  • if we dorpped use of diangosticReport, how would we indicate the status across all panel observations?
    • would we use observation.status in the grouper observation to take over that role
    • where would the report date go (observation only has observation.effective, which is the same as specimen collection date/time for lab results
    • also the code system and required valuesets between diagnosticReport.status and observation.status are different
• Should we split a serviceRequest for a higer level panel or orderset into separate serviceRequests, which would then result in 1 diagnosticReport per new serviceRequest?
  • that would work, if the panel group is created by the EHR-s, but not work so well, if the grouping of the panels is created by the labs and offered in their catalog as a single entity
• How would that look if you have a order for culture and sensitivty, but you also are doing a gram stain, which in itself producces a group of observations?
• If we are using the observation grouper (option A) do we need a way to identify it as a grouper more explicitly - equivalent to adding a new concept to the observation type in v2 (OBX-29) adn add that to the .dataAbsentReason or would we just do it by applying logic, that observation.result is empty AND hasMember is populated?
• Could a gouper observation have results?
  • maybe if there is an overall interpretation
• is EVERY observation that has hasMember entries automatically a grouper?
• the difference between FHIR and CDA and V2 is that FHIR resources are stored and then queried individually, compared to CDA, where the entire document is stored but also the sturctured elements are stored into the systems' database form where those get queried and V2 message content is prsed as well
• observation used as groupers do not really represent a result, so would potetnialy end up in the wrong bucket
• When we have more than one diagnosticReport (potentially option B) then can the same composition be referenced from multiple diangosticReports?
• The bundle with one composition represents the singe signed report
• How do we ensure everything that got ordered under the same serviceRequest is completed when using the grouper observation?
  •  that would be tracked via the status on serviceRequest - no difference between the options
• Since we are struggling with the right apporach, maybe we are missing an element?
• had some discussions around using the push vs pull paradigm for delivery (no impact on the different options)
• Next steps:
  • look at other diagnostic domains besides clinical lab like anatomic pathology, radiology, cardiology (stress test, where you have echo and nuclear medicine testing panels) - would have 2 different responsible observers (OBR-32 in V2)
  • reach out to implementers to see what is already built - in zulip and share the link to the thread via listserve for lab & main OO now and send a reminder to fill out 3 days prior (9/25) to the main call in 2 weeks (Thu 9/28 1-2 PM ET) whe we will discuss it again:
    • Australia
    • Germany
    • Belguim
    • Denmark
    • Euorpean Cross-border IG
    • Global Health implementations of OpenELIS

Conference Call Series

Co-Chairs to set up all call series in conference center - all starting this week except: 

HCP starting 9/25; OO on FHIR 9/26; V2-FHIR Hans Buitendijk to check Co-Chair email and enter accordingly

Q1:

FHIR R6 JIRA Backlog

• FHIR-40437: Appears corrected in R5. Propose: persuasive, pre-applied.
• FHIR-39388: Discussed desire to be able to express a range of quantity of component parts, but that capturing relationships such as "one of these or two of those" is beyond the base standard. We considered Range but could not identify a reasonable case where a non-integer non-count quantity made sense (1.5 mg of a device). Propose: to replace existing "count" element with minCount and maxCount elements (type integer).

Q2:

FHIR R6 JIRA Backlog

• FHIR-37812: Issues describes a problem with a search paramter that is no longer on Device, as patient has been removed. However, it makes sense to use the same clinical-patient search for DeviceAssociation. Also DeviceAssociation subject search has incorrect FHIRpath.
• FHIR-42766: Agree to remove where(resolve() is Patient) clause .
• FHIR-32565: Requested Ron G. Parker , or Lloyd McKenzie , or actual submitter to attend an HCP call to discuss. General discussion though tended towards finding this not persuasive.
• FHIR-32560: Unclear where to go with this in light of the potential plan of a normative R6. If the resource is not intended to be normative, then marking elements as STU is not needed as the entire resource is "STU".  Request submitter to identify particular fields that they have concern about and why they are concerned. Request to Lloyd McKenzie to provide guidance from FMG/FHIR-I for broader direction regarding possible normative resources in R6 and whether a general review of resources for this needs to be considered.

Lab Order Conceptual Model:

Lorraine identified a ballot comment (#12, to change "lab technician" to "lab professional" and to change "extracted" to "collected") that had been identified as persuasive as mod, but no vote could be found. Lorraine Constable/Yanick Gaudet motion to support the 2022-01-14 proposed disposition. Passed: 4-0-1.  Updated spreadsheet: HL7_DAM_LABORD_R2_I1_2020FEB_consolidated 20230917.xls