Monday May 24, 2021

Q1 - OO

Chair: Hans Buitendijk

Scribe: Hans Buitendijk, Riki Merrick

Agenda

Micro/Reflex/Add-On

  • Reviewed slides: https://confluence.hl7.org/download/attachments/40731564/Parent-Child%20Structures.pptx?api=v2
  • How to organize lab results in FHIR for micro, add-on reflex
    • Rob’s slide (used the V2 Lab Model as a basis)
      • Do we need the connection from the susceptibility panel to isolate specimen?
        • In real life they are certainly there, do we need to represent that in the FHIR resources?
    • Questions:
      • How to do change history (culture work up)
        • Do we use the same observation with a tracking history?
        • 2 kinds of changes on the organism identification:
          • If you make updates to the resource
          • a chain of observations over time, since this particular observation is an interpretation of multiple different test (that may or may not be shared), but the old one should be replaced by newer content
          • in V2 we have status preliminary until we have final
          • the chain of results should be captured and recorded in the LIS, but ONLY the most recent is what is being shared
          • do we need to consider if this has been reported out
          • FHIR servers are not generically required to track version history – so would need to clearly declare that this use case servers MUST support history
          • Would the OBX-21 in V2 segment change from preliminary to final the same?
            • Assume yes – that would point to using change history
      • Do we ALWAYS want the Service Request for the susceptibility panel?
        • Having result structure stand on its own (channeling Lloyd) would be preferred => Alternative A
      • Should the susceptibility panel point to the derived specimen or can we rely just using the organism identified observation linkage?
        • In FHIR we don’t have explicit context conduction
        • What should be best practice?
          • Have direct linkage, so you link to the same isolate for all observations that have been made on it
          • As external system don’t want to deal with it – so keep it optional, so that the sending system can send, but not require the receiver to handle it
            • If you support this, think twice about making it “must support” for observations on derived specimen
          • Do we have to deal with versioned references in the diagnosticReport?
            • When references are sent that may update over time, we will get the most recent version of the referenced object
            • If it is important to have the situation at the time, need to create a bundle to include the version of the resources
      • Instead of using hasMember soud lwe use derivedFrom?
        • We currently define panel components as hasMember
        • Use the same here
        • derivedFrom is NOT an alternative to hasMember, but can be used in addition, when needed

TCC Criticality

  • Ralf will be entering a JIRA to then be voted on Wednesday Q1
  • Related to Chapter 13 open:
    • If they want to sequence – do we need to add a new field that has NM datatype
    • Remove the last two sentences in TCC-15, because we want to discourage use of CWE in this way – Ralf to create a jira trackers to discuss Wed Q1

IHE PaLM

    • This may have been left over from last time, but may be good to just give an update – moved to Wed Q2

Q2 - OO/CQI/CDS/CIMI

Chair: Hans Buitendijk

Scribe: Hans Buitendijk / Lorraine Constable

Agenda

  • Use case is ordering a specific lab, from a standards perspective we selected a generic SNOMED code (Urine Drug Screen), what is the most appropriate mechanism for mapping that to a local code, any efforts in this space? (Standardizing orderables as part of a ServiceRequest)
  • DeviceUseStatement (DeviceUsage in FHIR R5), Implantable versus non-Implantable Devices FHIR-26636
  • Differentiation between when to use US Core ObservationLab Vs Observation (example = Pap test result)
  • DiagnosticReport versus Observation for retrieve queries (eCQMs and CDS)

ServiceRequest.orderDetail Update

Discussed Service Request Order Definition – FHIR 31584

See ServiceRequest Parameters

Quick highlight on topic at hand.  Friday more detail.

Should DeviceRequest have similar order details?

Floyd – when to use ServiceRequest vs DeviceRequest

            Service request- get something done, may or may not need device, how to set

            Device request – assign this device to the patient meant to be used over time


DeviceUsage Update

Clarify difference between when to use DeviceUsage, Observation, and Procedure.  See JIRA in R5 on DeviceUsage (FHIR-32382).

Device Use statement

            Improved statement of scope and boundaries

            Renaming to device usage to be consistent with medication usage

            See device usage fhir resource proposal

            More general than device dispense (coming)

            Discussion re distinction between device usage and observation

            Reach out to PACIO on use or not of DeviceUsage. Suggestion that wheelchair usage is a good example

US Core ObservationLab vs. Observation / Path Report

At initial level it is "anything" lab, while work is in progress on cancer pathology reports, micro/reflex/add-on, that would yield more specific guidance on to report on certain lab tests/reports.

Discussion around Pathology reporting and current project on oncology related path reports (Project Insight 1686). US Core Lab observation fixed to general lab

Diagnostic Report /Observation / Composition

            If you want to have sections / entry structure to Diagnostic Report, then use composition. Have a DR.composition to point the composition that provides the structure

Report from CDS Work Group by Bryn

They have a community projects page that has active links to a lot of ongoing projects. Some of them are tooling related but there are also content projects

CDS Standards

            Each using observational data in some capacity

            Overlap with definitional resources from OO vs CDS definitional resources

                        Discussion about metadata elements in definitional pattern

                        In what was balloted for the quality measure IG proposing 2 broad capability statements related to content management

  • Terminology services
  • Authoring services

Measure repository service. Cast from the point of view of measure terminology, but could be generalized for broader use. Knowledge repository is a full lifecycle management

How do you manage a group of artifacts that share terminology. See the Measure Repository Service. Looked at the general problem of Knowledge Artifact Management

Artifact Manifest – can declare dependencies / override, etc

Q3 - OO

Chair: Hans Buitendijk

Scribe: Hans Buitendijk, Riki Merrick

Agenda

  • Order Catalog
  • Request Withholding Result
  • R5 Ballot Comments

Order Catalog

  • Working on JIRA tickets for ChargeItemDefinition, etc.
  • PA and BR&R looking for updates.
  • R5 update needs.  Set up a branch for R5.
  • Device use case coming up.  Could be wide.  E.g., medical devices available in country, recalling devices that are part of other devices, 
    • Perhaps DME/PAO may have an interest.  Bob Dieterle.

Request to Withhold Result

  • Data Withholding Request to Prevent Harm
  • Clarify Basic Approach and Enhanced Approach:
  • Specifically brought up for US rules, but could come up in other countries /regions, so this solution could also work elsewhere – should be universally usable
  • Next Steps:
    • In ORC approach describe how to do the revoke message and describe how to use the order control code
    • In enhanced approach add all elements used in ARV together
    • All review the basic approach of ORC-28 – especially if that is used for other se cases – what are they?
    • Do we need additions to ARV segment to explicitly declare who (person or organization) makes the assertion – would become effective in next version of V2?
    • Will update the LOI IG to include this information (along with other topics collected so far) to create a formal release – – most likely plan to point to this confluence page
    • Plan is to vote next week Thursday = June 3

R5 Ballot Comments

  • The way to find ballot feedback in jira directly
    • See example #2 on this page: https://confluence.hl7.org/display/HL7/Specification+Feedback#SpecificationFeedback-Searchingandmonitoringissues
    • For OO:
      • project = FHIR AND issuetype in ("Change Request", Comment, Question, "Technical Correction") AND issueFunction in inBallot("2021-May - FHIR R5 Comment") AND "Work Group" in ("Orders & Observations [oo]")
      • 45 topics
      • 38/45 are Neg
      • FHIR-32575
        • This was added to support reports on production reviews (regulatory)  –  this was originally added in R4B per request by BR&R but not listed there
        • In person by Lloyd and Ron Parker – added comment
        • Assign to Lloyd
      • FHIR-32574
        • We agree to perform FMM 3 on QA on Device
        • Disposition
          • Motion to find persuasive - non-substantive (but it we find something then those will become individual jiras) – Riki Merrick, Rob Hausam, no further discussion, against:0, abstain: 2, in favor: 11
          • This really should have been a comment / suggestion, will update
      • FHIR-32573
        • Leave open – work is still ongoing
      • FHIR-32572
        • Since this is coming from device what other endpoint should this be besides url - not sure what the comment really means
        • Add comment to give clarification of what is meant as the description seems the ask is to create backbone element with url and function for that endpoint, while the header sounds like a choice of url or Endpoint datatype (which does not include an attribute “function”
        • Assign to Lloyd
      • FHIR-32571
        • Make the status values mandatory, leave reason optional; same comment for device.operationalStatus
        • The header sounds like he wants device.associationStatus mandatory, vs what is in the description
        • Motion to find persuasive with mod – enhancement, non-compatible – Rob / Riki, no further discussion, against: 0, abstain: 1, in favor: 11
        • Assign to Jose
      • FHIR-32569
        • Motion to find persuasive – enhancement, non-compatible – Rob / Riki, no further discussion, against: 0, abstain: 1, in favor: 11
        • Assign to Jose
      • FHIR-32570
        • Patient should be in the backbone of device.associationStatus, but the current codes are not
        • Bring this up with device group

Q4

Chair: JD

Scribe:  Lorraine/JD

Agenda

Lab Conceptual Model Recon

  • HL7_DAM_LABORD_R2_I1_2020FEB.pdf
  • Spread sheet as discussed: HL7_DAM_LABORD_R2_I1_2020FEB_consolidated.xls
  • Comment 15 - Motion to find Persuasive   Lorraine/Kathy    7-0-1
  • Comment 12 - Hold for more thought/discussion 
  • Question about bandwidth. Do we actually have the bandwidth to do significant rework on this, especially the re-modeling that will need to happen?
  • To aid in review, we took a high-level pass over those from Kathy Walsh 
    • Comment 16  - Can you accession a specimen before it arrives in the lab? Race case?
    • Comment 17 - Update Order diagram 
    • Comment 18  - Resulted vs. Reported?
    • Comment 19 - Promise of lab work vs. ordered 
    • Comment 21 - Use Case diagram on Ordering 
    • Comment 22 - Definition Diagram mismatch 
    • Comment 23 - Update Ordering Provider in Diagram 
    • Comment 26 - Span of result bar...get clear on definitions 
    • Comment 27 - Missing arrow from report to fulfillment 
    • Comment 28 - Remove "sometimes" 
    • Comment 29 - Similar to 16
    • Comment 30 - Similar to 16
    • Comment 31 - Similar to 16
    • Comment 32 - Remove some of the diagrams (need to check) 
    • Comment 33 - Phrasing change
    • Comment 34 - Phrasing change 
    • Comment 36 - Diagram update
    • Comment 37 - Both diagrams (and 38) may not be needed
    • Comment 38 - Both diagrams (and 37) may not be needed
  • Will Continue Thursday Q4

Tuesday May 25, 2021

Q1

Chair:  Rob Hausam

Scribe: Riki Merrick

Agenda

SOGI in V2, CDA and FHIR

  • Where to implement:
    • Should implement in R4, since more widely implemented
    • Get implementation guide into circulation, since this needs to get implemented as soon as possible
    • Should we implement in R5 and pre-adopt it – develop at the same time
    • Is this mostly about patient, or also about practitioner?
    • Goal should be to implement in R4 and where we need extensions, then we should think about how we would do that in R5, so that the shifting for folks later is not too big a lift
    • We already have extension for gender identity and name
    • Big problem is Sex for clinical use
    • How confident are we that these model will be normative by R5 – but R5 does not have to all normative, even in a normative resource – that should not be a problem
    • How many ballot rounds do we need for the implementation guide and how does that interact with balloting in R5?
  • Looking at Section 8.1.7: ADD LINK - are these descriptions ok?
  • Will people really build these as observations?
  • Problem will be: How do we get folks to agree with the concept model and align it to their built logical model, we need to make that easiest to adapt; folks need to understand that this attribute can change over time
    • Define the attributes and explain to use observation for “sex for clinical use” – would we do something different in R5?
  • This is a statement in time
  • It will be hard to get folks to use observation – they are first order and deserve their own element;
    • Can we create a pattern that we can apply to ANY person resource – that would make them more respected by implementers
    • Create an extension on observation that can then become a backbone element in R5?
  • Where would we place that in the context of patient / practitioner – and maybe order – biggest issue is the "sex for clinical use"
  • 3 ways to approach
    • Just observation, nothing in person specific resource
    • On patient add elemtn as codeableReference – the kind of concept that points to observation
    • Just attribute on the person resources
  • If it is something that changes over time and we need to track that – the first two choices enable the history and progression and who said it and in what context may also be important
  • If we don’t need to track the progression, then the third approach will work
  • Do we give it enough justice to simplify to make it a first level element, because they may have to set up their system with more complexity
  • Will need input from the gender harmony folks here!
  • Pointing to observation is doable, but should be easily discoverable
  • All the person resources this applies to:
    • Patient
    • Practitioner
    • ??
  • Next steps:
    • Identify the questions we need to answer
    • We need to figure out what we want to do in FHIR and V2 and CDA
    • Goal for today is to have a plan:
      • Weekly meetings
      • Need IG publisher
      • Need OO, PA, Vocab, FM participation
      • Gender Harmony PSS needs to get scope adjusted – Carol and Rob McClure to do
        • Vocab project with Cosponsor WGs = Patient Care (Formal content review), Payer/Provider (periodic updates), PA, (formal content review, periodic updates) and FM (periodic updates)
        • Need to add OO as this touches current and future use of observations (OBX, Observation).
        • Current project has 1.5 hours Mondays at 4 PM ET
        • Still working on ballot reconciliation – estimating we are 5 more meetings to get this done
      • Can we do September ballot?
        • Less concerned what ballot cycle than having but plan a connectathon around continuous build prior to the next ballot cycle after that
      • Let’s start with every other week of this meeting starting June 14
        • Need commitment from CDA (Lisa and will find another), V2 (Riki, Frank both will try), FHIR (Grahame) OO (Riki), PA (Cooper Thompson - will find another), need FM (MaryKay?, Linda Michaelson)
        • Need person that can write the IG
        • Need some funding for this project – ask HL7 to help with this – Grahame will also work on infrastructure support
        • Rob and Carol
          • create the skillset list
          • make changes to PSS and send to Co-Chair list
          • will set up a listserve / zulip chat for this project
        • Target will be in CI build by Sept connectathon and ballot by January 2022
        • Call Agenda:
          • Settle how much meta data we need around each of the data elements
          • Homework for each product family rep to provide suggestions for implementation
      • Get dedicated time with PA WG to get their input around execution
  • FHIR:
    • We need to get this into hands of implementers ASAP
    • Could we create the implementation guide for FHIR to publish as a cross paradigm IG for V2 and CDA to ensure we have continuity for the data across product families
      • Challenge of adding data to resource in FHIR is different than adding them in V2 or CDA
    • Publish implementation guide in R4 and then in R5 we revise the content based on the implementation guide for further explanation of the content to support practical implementations
    • Frank is also in favor of clarifying the semantics first and independently from a technical representation. Conveying it in a standard is much easier then.
    • We could make the IGs for the different product families that reference each other
    • Hans: If we can have better defined semantics, particularly on the aspects of relevant data to track, and assess the 3 methods to express, would be helpful. 1) attributes on the appropriate resources only as CodeableConcept, 2) Observation resources only, 3) attributes on the appropriate resources as CodeableReference(Observaton), 4) attributes on the appropriate resources as Reference(Observation).  V2 would be a choice between 1 and 3 where 2 would be the OBX after the PID/PD1.
    • We have to also be considerate that if we don't use observations that in v2 many implementations that have gotten used to that approach need to change.
    • Leverage the V2-FHIR mapping folks for this effort
  • Side comment:
    • There are a lot of projects that seem to be more hampered than supported by the HL7 organizational structure on the product and WG organization side rather than at the project level – suggest to reorganize the WG structure for the long term?
      • Still need to find the time to meet AND work on the right folks’ calendar
      • The accelerators are paying folks – which makes folks find time

Q2

See Minutes from Patient Empowerment

Q3

Chair: JD Nolen

Scribe: JD Nolen

Agenda

Update on Dx report

  • JIRA applied that links Dx report to Composition so Composition can provide structure and sequence to the report. 
  • A lingering question around the need of one Dx Report being comprised of/linked to other Dx reports
    • Does this daisy chain it apart? Unmanagable? 
  • Role of the grouper that CG has for this? 
  • Need for thorough use case testing (bone marrow report, CG complex case) to test the Dx Report - Composition linkage and the need to relate to other Dx Reports. 
  • Could we use basedOn to hold this? Or summaryOf? 
    • summaryOf - points to subordinate target reports. 
    • The use case testing will explore this

Grouper 

  • CG profile to group related observations together to cluster (looks like OBX-4). 
  • Do we need this at the Dx report level? Waiting to see if we need this for Dx report based on use case testing
  • Another use case for grouper
    • Group related observations for a variant 
    • The context for related data 
  • Should a Dx report point to grouper or each individual observation?
    • Consensus thought to just point to top-level groupers 
  • https://emerge-fhir-spec.readthedocs.io/en/latest/design.html#rept-examples

Cancer Pathology IG

  • Scope is worldwide and not just the US 
  • Bundle for eCC data...
  • Has some biomarker coverage (eCC codes and SNOMED) 
  • Current IG work: Cancer ePathology Reporting 

Coded annotation 

  • JIRA for coded annotation (extension) into CG's IG 
  • add note element into DX report ( FHIR-31663 - Getting issue details... STATUS )
    • Motion Rob/Patrick       Ag: 0 Ab: 0 Fav: 24
  • status of putting a code on notes
    • action item for OO to log a JIRA to put a codeable concept on Note

Q4

Chair: JD Nolen

Scribe: Riki Merrick

Agenda

  • Pre-proposal thought about a FHIR IG for extended Red Blood Cell phenotyping (blood establishment computer systems (BECS) that produce regulated blood products and blood bank laboratory information systems (BBLIS))
  • Administrivia
  • LRI ballot recon

Red Blood Cell phenotyping FHIR IG

  • Powerpoint presentation: https://confluence.hl7.org/download/attachments/4489770/Lantana_Blood_Bank_HL7_Proposal.05232021.pdf?api=v2
  • Have been reaching out to blood banks, health systems, system vendors and professional associations
  • Clinical Genomics WG
  • AU has done some work on this topic
  • Requesting information on related efforts
  • IHE PaLM has a v2 based specification for the reporting of the completion of the transfusion (with or without adverse event)
    • Would need the meta data here as well to help deal with acute and delayed reactions
    • Advantages of having the nucleic acid markers is that these are a feature of the patient despite them having been transfused
    • Would like to get the data elements so we can add them on
    • Could you present this use case to the IHE PaLM as well – Riki to connect with John about that
  • When there is a need for a match the health systems would send the extended phenotype to the blood centers
  • John does have contact with one vendor that is interested in this use case

Administriva Questions

  • WGM schedule review – will still need to check on the Friday quarters
  • Everyone gets a Star for healthy WG!
  • Moved to Tues Q1

LRI Ballot reconciliation

  • #90: need to find the related vote an update row
  • #95&#96: Motion to find not persuasive – from prior discussion there was a desire to NOT support separate OBR groups for these kind of Epi related questions – Riki Merrick, Ralf Herzog, no further discussion, against: 0, abstain: 0, in favor: 8
  • #97: Motion to remove “race / sex / ethnicity and the line break” and make sure the “Reporting Device Identifier Information in Result messages” is the proper link - persuasive with mod – Ralf Herzog, Riki Merrick no further discussion, against: 0, abstain: 0, in favor: 8
  • #98, #99, #100: Motion to find persuasive Kathy Walsh, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 7
  • #101: Submitter withdraws the comment
    • Need to find out where the official “withdrawn” is
    • but in looking at the pdf: https://www.hhs.gov/sites/default/files/hhs-guidance-implementation.pdf
      • this does NOT require Patient State as a data element and only requires Patient County as alpha text – should tell HHS that they should change to FIPS codes to ensure they know where the patient lives, since county names can be the same across different states, but FIPS-6.4 codes include a code for the state and for the county, so are not ambiguous
      • We should maybe we should consider loosening up the PH_component to support alpha but make FIPS codes recommended?
  • #104: Add reference to HL70070 for those that use OBR-15.1 - Motion to find persuasive Kathy Walsh, Riki Merrick, no further discussion, against: 0, abstain: 2, in favor: 7
  • #109: This is more a comment on the HHS guidance, as it is using real test LOINCs to identify the type of test / result and date of prior test per the pdf – – we don’t think we will get any more clarification at this time, that would help with updating LRI, so withdrawn by submitter
  • #110: This is more a comment on the HHS guidance as they are not providing implementation guidance – we don’t think we will get any more clarification at this time, that would help with updating LRI, so withdrawn by submitter
  • #111: This is more a comment on the HHS guidance as they are not providing implementation guidance – we don’t think we will get any more clarification at this time, that would help with updating LRI, so withdrawn by submitter
  • #112: This is being discussed here https://confluence.hl7.org/display/OO/2021-05-21+LAB we already voted on it
  • Spreadsheet (we may be done!): ADD LINK ONCE MERGED with 5/12 content.

Wednesday May 26, 2021

Q1

Chair: Hans Buitendijk

Scribe: Hans Buitendijk, Riki Merrick

Agenda

  • v2.9 Chapter 13 updates - TCC-15

  • Administrivia

V2-25269 - TCC-15: Description is contradicting the Data Type SUBMITTED  related to: Outstanding Issues in V2 - Ask from V2 management group

  • This definition is not a real definition
  • Word smithed the first sentence
  • Motion to approve the new text – Ralf Herzog, Riki Merrick, no further discussion, against:0, abstain: 2, in favor: 8

Administrivia

  • LRI Ballot Reconciliation
    • Motion to upload the spreadsheet to the ballot desktop contingent on the final clean up (adding motion dates) – Lorraine Constable, Rob Hausam
      • no further discussion
      • against:0, abstain: 3, in favor: 8
  • Reviewing the Health Metrics summary:
    • Reviewing the PBS metrics spreadsheet:
      • Expired STUs:
        • LRI Functional Requirements
          • What are the options?
            • Request another extension, if allowed
            • informative ballot
            • normative ballot
          • These are used in downstream spec and in interfaces, so we could look at how this profile is reflected in real systems; for this one there are IGs that use this functional profile
          • But this guide was used at the time to create the test profiles for NIST tooling
          • This should also be covering CLIA requirements and should hopefully reduce the burden of interface verification for each test set up
          • We are also missing the corresponding spec for the LIS side, so normative is not appropriate, since it cannot be upheld if not all partners have defined requirements; this was driven by lab requirements
          • Re-ballot as informative at least makes it better than being an expired STU
          • Situation has changed since we created it and it does not currently reflect the current state (e.g. the HHS AOEs for example)
          • Ballot as informative OR add in the LIS side and then take both normative (larger project)
          • Motion to request extension first and start the ballot as informative.  Lorraine Constable, Dan Rutz
            • no further discussion,
            • Against: 0; Abstain: 4; In Favor: 7
          • Ulrike Merrick to check with Lynn why 1095 is marked as idle when it is expired.
        • FHIR SDC (Project ID: 1104)
          • Ulrike Merrick will indicate to Lynn/Dave that the FHIR SDC is owned by FHIR-I and should be removed from our project list.
      • Idle ballots:
        • EHR-S functional model for LRI
        • SDC
        • Why are these listed under idle ballots and expired STUs? – Hans Buitendijk  to check with Lynn
      • Unpublished Ballots
        • LabOrder DAM is the only one older than 3 cycles
      • 5 year expirations
        • Clinical Statement CMET
          • Suggestion to withdraw ANSI approval.
          • If we do that, we don't have an "HL7 Normative" status.  Do we want to keep it as "HL7 Informative"?
          • There are also discussions on whether to completely withdraw V3 and not maintain it anymore.
          • Motion to withdraw from ANSI and work with HQ to get at least to Informative. If somebody needs it normative, then HL7 needs to provide a Normative status before we can complete that.  Dan Rutz, Rob Hausam
            • no further discussion
            • Against: 0; Abstain: 0; In Favor: 9
          • Hans to trace this down.
    • Rest of Project Insight review in co-chair call.

Q2

Chair:  Hans Buitendijk

Scribe: Hans Buitendijk, Riki Merrick

Agenda

  • II Update 
    • SR Mapping
    • Image Ordering Workflow
    • Imaging Selection
  • OO Update
    • ServiceRequest Parameter

  • IHE PaLM update

II Update

  • DICOM Structured Report (SR) Mapping
    • Working on IG on how to map DICOM Structured Report to FHIR
    • Mapping of DICOM SR to FHIR
    • OrderPlacer identifier = use the id type PLAC (will align with the V2-FHIR mappings = see here: https://docs.google.com/spreadsheets/d/1PaFYPSSq4oplTvw_4OgOn6h2Bs_CMvCAU9CqC4tPBgk/edit#gid=1930219638)
    • IG proposal is in progress maybe Sep2021 or Jan2022
    • SR is used for structured reporting, not need to be preserved as a specific grouping
    • Clin Genomics has an ObservationGrouper profile to do the equivalent of OBX-4, Sub Identifier.
      • http://hl7.org/fhir/uv/genomics-reporting/2021May/StructureDefinition-grouper.html
      • May have value for II
      • Definitely want to look at what aspect should be OO generally.  If there are variations, need to consider naming convention.
      • Dealing with measurements that depend on other results; observations on the descriptions
      • If this is of interest to imaging and when V2-FHIR mapping gets to OBX-4, we may need to elevate to more generic resource
      • Could also use composition as a grouper instead of the observation grouper?
      • component is unbreakable linkage
      • hasMember is tighter than composition or diagnosticReport, but not as tight as component
      • diagnosticReport groups observations that are being reported on together – like a panel, without organization; it does have a representedFrom element, where you can upload the pdf for example to provide the visual representation (immutable version)
      • composition adds the structure around the contents of the diagnosticReport and it can also pull in other elements (similar to CDA) that can then be organized by the sender of how it was intended to be viewed – there is a jira out to add representedForm to composition, so that you can structure a set of diagnosticReports
      • this genomics grouper describes the entire variant so creates an entire conceptual level in the hierarchy
        • maybe they should use observation.component instead?
      • ould we use the groupers for a section in a structured report?
        • Would use composition for this type of thing to provide the ordering of the sections - where specific sections are displayed
        • From implementation standpoint it would make sense to use observation as the grouper for the sections
        • Also in DR – grouping together, but no order
      • Need to compare how GC structured report and AP will work with the grouper and the composition (seems we will need both probably)
      • Discuss naming convention for this grouper resource – should we have use case specific grouper that supports each domains specific requirement (to explain the dot notation currently used in OBX-4)
      • V2-FHIR may be requesting a datatype that can represent the generic OBX-4 grouping functionality
      • May need to have requirement to point to the group of attributes = clinical genomics grouper – this would be good for Bob Framus information model group calls (Thursdays 10 AM ET and Wed Q3 discuss roadmap between model vs IG) to work on
    • The FHIR cancer reporting/eCC project(s) might be worth aligning with as well, given the similarity of textual reporting + structured documentation
    • Get common meeting with OO/CG/II on Friday on structures that use .component and .hasMember vs. DiagnosticReport vs. Composition and determine whether there is a general approach to "OBX-4 dot notations".
    • Does this scope include observations derived from modality (evidence producers) using inferencing from the images?
      • This is what the IHE PaLM group is working on with their Digital Pathology profile (but not in FHIR)
  • Imaging Ordering Workflow
    • Have not worked much on that yet.  In early progress.
    • What would it look like as they change the HL7 v2 and DICOM workflow to FHIR.
    • Will use the V2-to –FHIR mapping work as starting point
    • proposed IHE work item for next cycle
    • scope:
      • radiology work transitions from v2 to FHIR, do we need to request changes to current resources
      • IHE digital workflow currently (in v2) is from device to the PACs
      • Includes what was ordered vs.
      • on is not specific enough why it is linked
        • Generic order that then results in specific orders, so what then is the DiagnosticReport
        • Is that different from “per protocol” vs reflex testing because of specific findings s not covered
        • The current v2 workflow doesn’t go into this level of detail right now either (as to the why) – only track the same accession number – would just do add-on to the study
      • IHE Digital Pathology is also working on ordering
      • We do have jira around serviceRequest question: at time of ordering how do I communicate what kind of settings should be done (discussing with devices) = scanner protocol in DICOM – OO Friday Q1 discussion
  • ImagingSelection (ImagingReference before)
    • ImagingSelection resource draft
    • Approved as resource to be able to reference specific frames in DICOM – allows for references to parts of SR elements
    • Reviewing the draft
      • For subject add reference to specimen
      • For reference to regions will be working with DICOM WG around finding the right balance on when to create a FHIR attribute, when to just leave it in DICOM
      • Reference to observationUID – that is the DICOM observation ID – will have to look at how to
      • DerivedFrom – has endpoint only, would you need to have to point to the device it is from (using UDI) as there is increased interest in understanding what device was involved in the creation of the observation
        • The intent here is where the image is available now – not the producing device
        • We have a performerDevice to track the producer

OO Updates

  • ServiceRequest Parameter – more discussion is on Friday Q1
    • Related to device parameters:
      • Include AOEs and how that relates to orderDetail.
      • Attributes that are sitting at order detail (supporting clinical information etc)

IHE Palm Update

Other Topics

  • Where does this come from: http://build.fhir.org/inventoryreport
    • Also related to deviceDispense – resource proposal in the works
    • Jose is working on a supply chain related FHIR proposal
    • What is the PSS for this?
      • FHIR R5
    • Will be keeping joint quarter for next WGM

Q3

Chair:  Ralf Herzog

Scribe:  Becky Gradl

Agenda

OO/Pt Care

  • Update on Nutrition 
  • FHIR-31383 - Specify semantic model bindings for Observation WAITING FOR INPUT

Nutrition 

  • Working on updating the DAM to be broader to Nutrition Care
    • Previous DAM specific to Nutrition and Dietary Orders
    • Nutrition and dietary orders work will be left in as an appendix
    • Broader nutrition care encompasses the nutrition care process of assessment, (nutrition) diagnosis, interventions, and monitoring/evaluation
    • Monitoring other projects such as MCC eCare Plan, PACIO, Care Team DAM, and Care Plan 2.0 to ensure alignment and incorporation of their work
    • DAM introduction planned to be stand-alone to describe what a dietitian does at a high level (if the reader does not read the rest of the DAM)
  • FHIR Resources
    • Nutrition Product was moved up to FHIR R4B with last ballot
    • Nutrition Intake still in FHIR R5
    • Will look to have Nutrition Product and Nutrition Intake to FMM 1 prior to FHIR R5 ballot
    • Both resources need more examples and clean-up of text

FHIR-31383 - Specify semantic model bindings for Observation

  • The issue came from the Patient Care WG
  • Slides were attached to the issue as an attempt to convey what people assume
  • There is no repeatable distinction between condition and observation
    • Do signs and symptoms belong in observation or condition?
    • As an example with lung cancer and coughing up blood, lung cancer is condition; coughing up blood might start as observation, but if persistent would be a condition
    • It's likely an observation until it rises to the level of a problem (condition)

    • Certain conditions have both an underlying etiology and multiple body system manifestations due to the underlying etiology. For such conditions, the ICD10-CM has a coding convention that requires the underlying condition be sequenced first, if applicable, followed by the manifestation

    • SNOMED could help disambiguate conditions and observations, if used correctly

  • A possible resolution could be to finish the mappings tab in the observation resource

  • A "problem" is the highest level of the current "diagnosis": https://histalk2.com/2017/09/27/readers-write-the-problem-list-is-the-problem/

  • There is wording in the observation resource to express that it is not used to capture clinical diagnosis because condition resource should be used

  • Motion: To update the boundaries section to better align guidance to describe the difference between the use of the observation resource and condition resource, particularly around signs and symptoms. Rob Hausam, Jay Lyle, no further discussion, against: 0, abstain: 1, in favor: 10

Q4

Chair: JD Nolen

Scribe: Riki Merrick

Agenda

Joint with CIMI

  • FHIR-31355 - Body position should be a component, not an extension WAITING FOR INPUT
  • FHIR-31383 - Specify semantic model bindings for Observation WAITING FOR INPUT  (if not discussed in Q3)
  • Probability codes used in condition - get feedback from both OO and PC
  • Creating STU1 version of Vital Signs IG

Dealing with probability ratings of codes used in condition

  • Stan Huff  - Reference LINK to document shared
  • There is some order to these, but not absolute
  • This also relates to presence and absence findings
    • Can use observation.code = finding
    • And observation.value = present = probability = certain or absent = probability = never
  • Discussion:
    • How to deal with systems provide a numeric percentage calculated from observations it has, vs. stated by a person
    • Seems different from the attribute we have for confirmed vs refuted
    • EvidenceResource work should inform this (looking at review of research papers)
      • It has a backbone of certainty with many attributes
    • How will this data be used?
      • In clinical decision support use either of these levels
        • Risk calculators for pulmonary embolism provide a level of probability, decision support provides the recommendation for diagnostic tests list
        • Physicians make these assessments after review of the data
      • Lab results and CT scans may already provide probability (you have reference ranges and standard deviation, but that is NOT what this is – rather how likely is anemia given this Hb result)
    • Stan will create a value set and look at evidenceResource as well – will start a tracker

Creating STU1 version of Vital Signs IG

  • Reason is to take it international to collaborate with affiliates who are working on their own profiles – so change project from US realm to universal – that should not be a problem
  • We will need to resolve negatives and publish
  • Depending on the scope of the change we can ballot or do STU update (depending on the impact of the scope changes)
  • The vital signs IG is based on core profile, so we could change the realm on the PSS and add in the participants
  • Ballot comment against USCore VitalSigns will apply to this IG – Lorraine to forward the tracker
  • Ballot reconciliation is completed in the IG – need to update jiras and then do the export to the spreadsheet to upload to the desktop – will review on June 10

FHIR-31355 - Body position should be a component, not an extension WAITING FOR INPUT

  • Originally observation.component was designed to cover composite results
    • They cannot stand alone
  • Observation is the only resource that does not use extensions to add qualifying information
    • Prior discussions:
    • this seems to indicate that there is a need to be able to add qualifying data to the observation result
    • we do need to sort out when to use observation.component, observation.hasMember, extension as well as diagnosticReport (a little broader for grouping)
    • Main question is Can component be used for qualifiers?
    • Using hasMember for qualifiers also is problematic, as we have used that for grouping individual observations
    • Should panels be handled in DiagnosticReport rather than using hasMember, like we are doing in the susceptibility panel example
    • Do we need to add a backbone element “qualifier” to handle these
    • So for each order we should expect a DiagnosticReport – Labcorp is creating a bundle of DiagnosticReports?
    • But we do need to support nested observations, would we then need to nest diagnosticReport?
    • hasMember will not work for qualifiers, as it is a reference to an observation – too much metadata

Thursday

Q1

Chair: Hans Buitendijk

Scribe: Hans Buitendijk, Riki Merrick

Agenda

OO/Devices/BR&R

  • FHIR-26830 - add risk extension for entity resources TRIAGED 

  • Proposal to absorb Statistic Datatype into Evidence Resource  FHIR-31866 - OrderedDistribution and Statistic shouldn't be data types TRIAGED

  • Concurrent session with FHIR-I – this is a report out (Rob H is doing this), but we are meeting with them next quarter

FHIR-26830 - add risk extension for entity resources TRIAGED 

  • Discussion:

    • Applies to specimen, substance, device, biologicalProduct, Procedure
      • Using HL70489
      • For device we have property of safety – could that cover – is similar to warning and precautions (Francois working on this) = FHIR-32064
      • This deals with the catalog of devices to indicate clinicalUse – what to pay attention to in clinicalUse it is used for devices, procedure, substance, but it does not have a warning
      • Will add warning as another choice
      • Seems to denote a property of the “thing” that gives you an idea that you should be doing something different than normal
      • Naming risk vs warning for the extension
      • If warning is a part of ClinicalUseIssue, could we create a profile to constrain ClinicalUseIssue.type to “warning” for use in specimen and other resources that don’t need the full ClinicalUseIssue (so that we don’t have to maintain the extension and this part of ClinicalUseIssue)
      • Need to check if creating a profile is too much to do, just use extension and use the same code system in both, but not trying to keep them in sync
      • Do this profile ONLY to specimen

  • Option 1

    • Use ClinicalUseIssue generally, but create core profile for just warning aspect for Specimen (and Patient, Group if needed)

  • Option 2

    • Create extension for warning only for Specimen (and Patient, Group if needed), and share vocabulary with the warning aspect in ClinicalUseIssue.

  • Put in JIRA Comment and on Zulip, and list serve.

  • Tie it to FHIR-31866.

  • Considering widening the name of ClinicalUseIssue has concern from BR&R

Proposal to absorb Statistic Datatype into Evidence Resource  FHIR-31866 - OrderedDistribution and Statistic shouldn't be data types TRIAGED

  • Extension of FHIR use into evidence based medicine: https://docs.google.com/presentation/d/1stAoPMFfkjRKX3B7bgOIBnhpdaTQRUCI
  • Discussion:
    • The statistics datatype could be used in observation or DiagnosticReport, but it would need more information to make the statistic datatype meaningful
    • If you wanted to include confidence interval around the result
    • If the lab report includes a summary of the average / mean / distribution you might need these
    • Currently no reference to these datatypes in observation.value
    • If need is found later, can we present the value in observation.value and then add a reference to evidence as a qualifier? – probably will have to use diagnosticReport to support this use case – where the diagnosticReport is grouping ALL results related to that evidence adding a new element called analysis
    • Review the lab example and see how this would work
      • Use HLA DQB1*06:02 and HLA DQA1*01:02 are associated statistically with narcolepsy and are sometimes used as tests in support of that diagnosis.
      • Order Code      Order Code Name        Order Loinc            Result Code      Result Code Name       UofM            Result LOINC
      • 167139 Narcolepsy Evaluation              167140            DQA1*01:02                 53737-3
      • 167139 Narcolepsy Evaluation              167141            DQB1*06:02                 63558-1
      • 167139 Narcolepsy Evaluation              167085            Comment:                    49549-9
      • 167139 Narcolepsy Evaluation              167086 QC                        N/A
      • 167139 Narcolepsy Evaluation              167149 Please Note:                77202-0
        • Use
        • Fluphenazine is a phenothiazine derivative (piperazine) used in the treatment of psychotic disorders. Its dose in milligrams equivalent to 100 mg of chlorpromazine is 0.6−1.2 mg. A statistical evaluation1 of clinical studies found the near maximal effective dose of oral fluphenazine to be <6.9 mg/day. For the decanoate, the near-maximal effective dose was 25 mg/two weeks. As a high potency antipsychotic, it may have a high potential for causing extrapyramidal side effects. This would be in addition to the usual adverse effects of antipsychotic drugs (neurologic, anticholinergic, hypotension). Elderly patients should be observed for these occurrences. The half-life of fluphenazine is formulation-dependent. (The decanoate is 5 to 12 days; the hydrochloride 12 to 60 hours.) Fluphenazine is also used to alleviate pain and in childhood development disorders.
        • Methodology
          • The copy number of SMN1 exon 7 is assessed relative to internal standard reference genes by quantitative polymerase chain reaction (qPCR). A mathematical algorithm calculates 0, 1, 2 or 3 copies with statistical confidence. When no copies of SMN1 are detected, the primer and probe binding sites are sequenced to rule out variants that could interfere with copy number analysis and SMN2 copy number is assessed by digital droplet PCR analysis relative to an internal standard reference gene. Individuals with one copy of SMN1 are predicted to be carriers of SMA; those with two or more copies have a reduced carrier risk. For carrier screening, when two copies of SMN1 are detected, allelic discrimination qPCR targeting c.*3+80T>G in SMN1 is performed. The presence or absence of c.*3+80T>G correlates with an increased or decreased risk, respectively, of being a silent carrier (2+0).1,2
    • Current implementation is use of DiagnosticReport
    • Keep analysis separate from result in diagnosticReport
    • When you reference the evidence resource as additional qualifier would you have the same value in observation.value and evidence.statistics.quantity and evidence.statistics.type
    • Next Steps:
      • Summarize the choices
      • Discuss on next week’ s OO call on Thursday at 1 PM ET

V2-FHIR mapping updates for ORU

  • Did not get discussed, but Regular calls are Mondays 1 - 2 PM ET and Thursdays 11 AM - 12 PM ET

  • Have V2-FHIR topics related to PA in Q3 today

  • Other topics of interest will also discuss on Friday Q1:
    • Taking Device normative in R5
    • UDI
    • DeviceDefinition
    • supply chain management (time permitting)

Q2 - OO/FHIR-I

Chair: Hans Buitendijk

Scribe: Hans Buitendijk, Riki Merrick

Agenda

  • R5 FMM Plans
  • Observation need for Statistics Data Type
  • JIRA - ObservationDefinition
  • Vital Signs

R5/FMM Plans

  • R5 STU Ballot is Jan2022
  • R5 Normative Resources
    • DocumentReference
      • Target normative
      • There are trackers to clean it up.
      • FMM5 requirements of being in production and used in many countries - for example: IHE uses all of the elements.  http://build.fhir.org/ig/IHE/ITI.MHD/branches/master/StructureDefinition-IHE.MHD.Comprehensive.DocumentReference-mappings.html#mappings-for-xds-and-mhd-mapping-xds
      • Support for making it normative: [FHIR-32789] DocumentReference should be promoted to Normative - Jira (hl7.org) (do we have others we can add here?)
      • Could still make a name change, but would need implementer input change.
        • Those already using it is not as big an issue to not change - bigger issue if we changed.
        • But more to help new users find it as an appropriate resource for media etc
        • Proposed names:
          • ArtifactReference, DocumentationReference, 
            • Definitions:
              • doc·u·ment
                • noun /ˈdäkyəmənt/
                  • a piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record.
                  • Similar: official paper, legal paper, paper, form, certificate, deed, charter, contract, legal agreement, record, report, instrument, indenture, acquittance, paperwork, documentation, treeware
                • verb / /ˈdäkyəˌment/
                  • record (something) in written, photographic, or other form.
                  • "the photographer spent years documenting the lives of miners"
              • ar·ti·fact / noun / ˈärdəfakt/
                • an object made by a human being, typically an item of cultural or historical interest.
                • "gold and silver artifacts"
                • something observed in a scientific investigation or experiment that is not naturally present but occurs as a result of the preparative or investigative procedure.
                • "widespread tissue infection may be a technical artifact"
          • Would need to announce via Zulip, Blog, Resource Definition Alert in current build
        • The name would need to be in the ballot, thus in the build (single Git commit).  Early November.
        • Sequence then is 1-2 Alternative Names to put forth, Zulip/Blog, September WGM discussion, November update if decided.
      • Provide hints/aliases (see Condition(Problem) as example) to make it easier to find
    • Device
      • Used very widely.
      • There is opportunity to go with some of the data elements going normative.
      • There are concerns with only going partly normative, but FMG is o.k. with part going normative.
      • Target R5
      • Work with Dev to identify a target list to get feedback on for attributes to include and put them in the current build
  • DiagnosticReport => FMM4
    • Needs more work on structuring/grouping/organization to clarify boundaries.
    • Not likely normative in R5.
  • Specimen
    • May not have enough implementation (PoC or Prod), since a lot of the real world use cases folks are still using v2 here to go to FMM 4.
    • Zulip/etc. follow -up to validate
    • Not normative in R5
  • Task
    • Has PoCs and IGs.  So validate FMM4 as that should fit.
    • Not normative in R5
  • DeviceRequest vs. VisionPrescription
    • Need to get that resolved for R5.
    • Consider that the parameter discussion can help resolve.
    • Another example for alias as well.
    • Related note:
      • Having discussion on parameters on ServiceRequest – which could then be ported over to DeviceRequest
      • Request for image settings on the device related to the ServiceRequest
  • Other items
    • FMM0 should all be FMM1 (check if resource proposals are done to accomplish that)
    • Keep on top of the tracker items and update the current build – looking for help!
      • FMG may be able to help

JIRA - ObservationDefinition

  • FHIR-31747 - ObservationDefinition should use ElementDefinition or StructureDefinition to define value constraints TRIAGED
    • Debate on listserve in summer 2016 around use of elementDefinition instead
      • Con:
        • observationDefinition is heavily used in catalog and the lab catalog IG we have built, if we change that would break everything
      • Pros:
        • will add several attributes that are currently missing from ObservationDefinition
        • full scope of bindings
        • minValueSet / maxValueSet
        • Questionaire currently points to ElementDefinition, if ObservationDefinition changes, then we would have to change and also add in the extensions that are not currently in observationDefinition
      • Do we want to create an operation to create the questionnaire?
        • That only applies to a single question not the entire questionaire
      • is the ask to make observationDefintion a profile on elementDefinition or StructureDefinition?
        • No – adjust the attributes around value definition that references elementDefinition
      • Will move to Catalog discussions. on Fridays 12 - 1 PM ET

Observation / Statistics Data Type

  • FHIR-31866 - Getting issue details... STATUS
  • Eliminate statistics datatype
    • How will this impact observation (and DiagnosticReport), as this would limit the option to add valueStatistics in the future to Observation.value?
    • Will send out a summary to listserve / zulip and make a comment on the jira
    • Final discussion will be next week’s OO main call on Thursday, June 3 at 1 – 1:30 PM ET

Vital Signs

  • Extensions for qualifiers vs. components.
  • Ideal to have an additional attribute Observation.qualifiers.
    • From modeling perspective that would be good
    • There are a lot of folks that would not understand that, as all of these things are currently OBX segments in v2 – so if source systems don’t know the difference they would not know which field to populate, so what about adding a typecode to component so you can tell if it is a qualifier or composite result part – that way when the source system doesn’t know the difference the value at least would be in the same place
      • Can we educate the source systems to better understand the data and properly label that.
  • Intended use for observation.component was to accommodate repeating OBX-5 in V2
  • Check on earlier decisions.  Will discuss in Tuesday.

Q3

Chair: 

Scribe: 

Agenda

Q4

Chair: Ralf Herzog

Scribe: Riki Merrick

Agenda

  • Lab Order Conceptual Model Ballot Recon

Specimen call on Memorial Day

  • Let’s cancel and start up on 6/7/2021 – Ulrike Merrick to set up the call series

Lab Order Conceptual Model Ballot Recon

  • HL7_DAM_LABORD_R2_I1_2020FEB_consolidated.xls
  • Had 70 comments, several negatives with in person resolution request by Kathy
  • Started on Monday Q4, need to decide how much refactoring we should be doing, since we just migrating STU to Informative Ballot to have it available as a reference model, specifically to have functional requirements as a basis for figuring out the FHIR workflows
  • If we make changes, we need to figure out how that will affect the Ordering Service Specification we have already published
  • Reviewing the rest of the negatives
    • #37 and #38:
      • Diagrams describing fulfillment management workflows, one with the full set (5 situations) and a lightweight version just supporting 3
      • Proposed resolution – provide more rationale as to why we have 2
    • #39: Looking at the interaction diagram on page 27 - one is a push result and one is pull result; in the US lab results are push in most cases in the moment
      • It is push in messaging, but may become pull in FHIR, but this document is silent on implementations
      • This diagram shows only Finalized result – others are possible – can we add e.g. in the box, or add text to explain that the result status can change and finalized is only the example
    • #40 – we will add the page number
    • #41 – "alt" is part of UML – it means one or the other of the alternatives will be used
    • #42 – for change orders would not have finalized results – take out the comment in the diagram
      • Would you use a result message for the specimen received?
      • Discussion if result transactions should be included in this document / diagram?
        • In the front part describing the workflow – can we add a comment there, that in diagrams may include the result transactions to complete the circle, but is NOT completely describing the full options around the resulting workflow
        • In the result flow remove the word results finalized
    • #43 – Missing Use case for Change request requested
      • Add as new use case and diagram separately
    • #44 – similar to #39
    • #45 and #46 – same comment on 2 diagrams –
      • If you have a specimen may affect
      • FOUND ITEM:
        • The promise transaction is described in the text, but is missing in the transaction diagram
      • FOUND ITEM: In the transaction diagram should the arrow for the change order go from order management to Specimen Collector Profile?
        • No we should create 2 boxes in this diagram and then cover the text above this diagram
  • After review we need to decide how many changes we want to make
    • Clarifications in the diagrams and text are easy enough to make
    • But reviewing the business process would require a new project to pull I the business side of this:
      • State transition changes is what we need to decide on
  • Reviewing the Affirmatives:
    • #54 and #67 also touch on state machine
    • Motion to let editor assess the typos – Lorraine Constable, Kathy Walsh
      • no further discussion
      • against: 0, abstain: 0, in favor: 7
  • Next steps:
    • Lorraine Constable to create proposed dispositions and bring back to the lab call on Fridays

Friday

Q1 - OO/Devices

Chair: Rob Hausam

Scribe: Lorraine Constable

Agenda

  • FHIR-31584 - Getting issue details... STATUS
  • Other ServiceRequest.orderDetails
  • Device Normative Track
  • DeviceDefinition
  • UDI Update
  • Supply Chain
  • DeviceRequest - VisionPrescription
  • v2-to-FHIR

Service Request Parameters - Jira 3154

  • Reviewed the ticket and Service Parameter page alternatives
  • Discussion of why this is not being done with Device Request
    • Lloyd - eg in a Procedure request for anesthesia would use a Medication Request as a sub part of Service Request
    • Is the construction of multiple service requests with multi parts would this turn into a Care plan
    • Hans does not think that is what we are trying to do here
    • Lloyd struggling with adding name value pairs to Service Request when these could be handled by a child resource that handles this
    • Baas  Ordering provider wants to indicate what he thinks should be used
    • Lloyd - no difference based on the strength of the order - fulfiller may make changes to instructions
    • Hans - thinks we are forcing creating an "acts definition" that forces the performance of an act that is not implied
      • eg performing an X-ray that has a device with settings - do I really create a device that perscribes a device prescription. Does not understand extra complexity
    • Lloyd trying to understand where the boundaries are. When you get into the complexity will need the detailed resources and request group to handle that
      • What is the boundary between the complex solution and the simple solution. At what point in the middle  do change. Two different ways to do things
    • Hans - where do you specify requested settings? 
    • Previous discussions indicated the device properties were not about request
    • Lloyd concern is complexity / conditionality, how do these respond to other requests. How do we normally specify expected settings for devices
      • need criteria for where we move into complexity
    • Jose that does not void the need for these parameters
    • Hans does this mean we need the same kind of structure in Device Request
    • You could specify anything with parameters. You could say "walk 100 m with assistance" could do thet with procedure and request group
      • understands that this can be overkill for simple order. 
      • this overlaps with the complex structure, so will need boundaries
    • intent - for he performance of this activity, need some parameters, or need to specify how a device is used
    • 3 questions - do we need, if so, how do we structure, if we create what are the boundaries 
    • Lloyd- wants to acknowledge that this could be done today with more complex structures
    • Jose - how do we put ability to include additional requests inside a service request
    • Two types of "inside" - Request group can point to different pieces stored as separate, or you can use request group with contained resources 
      • request group indicates these behave as one rather than as separate pieces
    • saying 10 things done together, or I want this 1 thing with details. A service request as a focal? Is request group a flavour of a service request. Does this get into a flavour of a care plan?
    • Request group for a set of interrelated actions that you want to create as inseparable. Main difference between request group and care plan is that care plan does not give you any abilities to define dependencies between things. Request group lets you define dependencies and temporal relations
    • when someone orders can order with a full blown request group or simpler. Depends on how much detail and control they want to have downstream. Eg just a code, a reference to a protocol, or specify definitions of instructions. What makes sense depends on situation and preference
    • Dan service request does not have parameters in a useful way - these are basically AOE
    • Hans - we need parameters regardless. Do we also need order detail - is that bypassing using the more specific resources . In the context of this service request with for this order need these specific setting, rather than the device request for general association with this patient. In device request there is no clue as to what this device is being used for
    • Request group says these instructions are not independent, and if you toast the order, these all go poof along with order
    • If you use device request there are specific structures for what settings are allowed. Same for nutrition or medication
    • suggest defining parameters by saying "this is equivalent to ...." to map with the complex request
    • Hans - difference between Medication and device. with Medication Request it is expected to be administered to the patient. device request the device is intended to be used by the patient
      • if point to a device request where the intent is that the device is being used by the patient. In service request this is to be used as part of the procedure . 
      • Lloyd does not think there is anything intrinsic with device request that this must be used by the patient
    • Jose - request group if you cancel one you cancel the other. Just because you cancel one you may not cancel the other
    • Lloyd - you can have nested request groups 
    • Hans - the parameters are sitting on the relationship between the activity and the device. the parameters on the device are specific to the overall device request. How I know that the parameters on the device request relate to this service request and nothing else. Lloyd - that comes from the request group with options
  • time check re other items from the Device list

General updates

Agenda check regarding the other items from the list regarding other updates for shared quarter

Switch briefly to the update topic

v2 to FHIR we have 2 meetings a week and we can deal with those there

Supply chain - current status is that we have a way to say "please supply this" "this has been delivered" where "this " is a product. Have not finished discussions on transport. Recently have a draft suggestion for InventoryReport. Two uses - snapshot mode, or differential changes to the inventory

Device Definition - update is that there is a Jira queue that needs to be applied to Device Definition . 

UDI - can discuss later. Marti - working on a UDI IG to address FHIR and other product families

In the movement of device to normative are there outstanding issues. Current build is not up to date with all the approved updates. Some attributes are normative candidates, have opportunity to keep some elements as STU. On a Monday call will run through a review of those elements. Jose will attempt to apply currently approved tickets next week

Back to ServiceRequest Parameters

Next steps

Review Option E. Is orderDetail.focus needed. If you point to Device Request if you reference there, is the intent that device request is set to option. 

Need to do this in a simple way and define the boundaries.

There are formal ways that should be used when appropriate. Many times clinicians do not want to specify the detail. Need to add simple comments that are matching interpretable

Difference between user interface and exchange syntax

Distinguish between formal and complex approach. Define when it is more appropriate to go to a more complex approach. For the typical, most common use cases, we will not be that complex

What are the common use case? and do the ones on the page express those.

Another consideration is that request group was created because of known hypothetical requirements. Not necessarily reflective of real world. As we get into how real systems cover this, we may need to adjust approach

Some analysis on the approach of real systems might be useful

Will Lloyd be doing this for request group? This came out of workflow. So far primarily leveraged by CDS in terms of protocols. The analysis is more likely to come out of OO or PC than FHIR-I.

This discussion is coming from we are starting with a need, and what is the least amount of information needed to communicate vs the analytical requirements from CDS

There is probably a need for both, but need the simple case.

Currently tackling a low to intermediate level of complexity by the parameters mechanisms. Do some analysis of how do systems handle the more complex cases, and what triggers the boundary crossing

This will be continued on Monday calls regarding how this relates to Device on the Health Care Product call

Q2 - OO

Chair: Hans Buitendijk

Scribe: 

Agenda

  • v2+ Tooling

v2+ Tooling

  • Summarized v2+ Tooling status goals
  • Needs:
    • Deal with smaller updates as less change is expected.
    • View changes since the last updates: What's New?
    • Rapid review and updates without impacting areas not touched.
  • Questions
    • Do we want to have annual updates? (or less frequent)
    • Do we want to have continuous updates against a superset?
  • Thoughts:
    • Could we have same progression as FHIR having a build and publication.
      • Would need insight into stability.  E.g., today anything pre-workgroup vote is subject to change.  Once workgroup votes, it is considered stable to go into a ballot.  Still may change through ballot, but much lower risk.  How can we achieve that same level of awareness to enable pre-adoptions?
    • We need to be concerned with ANSI processes.  Continuous maintenance has challenges and higher requirements than periodic publications.
    • Do we need to stick with ANSI accreditation?  Key is the process to gain consensus.  A standard being normative is not necessarily the measure to adoption (see wide adoption of STUs in regulation).  The industry consensus according to ANSI criteria is though.
    • Is the business need met by building on what we have vs building something new to solve the business need – so we need to make sure we can make changes to V2, If that will solve he need
    • How would IGs work in the new tooling world?
      • The NIST tool will update NEW content and that tool allows export to html as word (that can then be edited prior to pdf publication) or XML (for downstream tooling) – will have to see how to migrate that over later
    • V2 tooling is meeting every Friday at 8 - 10 AM ET, every other week V2 Management will have topics from 9 AM – all are welcome
  • V2+ ballot recon:
    • #22: navigation with the HL7 table vocabulary has been a problem
      • Several aspects:
        • Are we going to migrate to use concept domain, code system or value set or stick with the “table concept”
        • UTG has to maintain the additional table concepts, but we should still support the table number navigation
      • Where are we going to maintain vocabulary long term?
      • We have to convert the HL7 V2 tables into true code systems
    • The main concern is that
      • We support a way to get back to the V2+ specification page you clicked from (nice to have, as we can use the browser back button)
      • Go to the V2 specific vocabulary – at this time we go to FHIR page – should point to terminology (THO) pages – will have to find out how that is organized and which one is the best landing page for it
    • The comment about the links from transport and datatype flavors is a work in progress
    • Motion to find persuasive with mod as written in the spreadsheet – Riki Merrick, Amit Popat
      • no further discussion
      • against: 0, abstain: 1, in favor: 19
    • #36: use concept domains and appropriate names and we need to also provide the table numbers
      • people should have choice to organize by name or by table number, since that is how v2 references the vocabulary at the moment with a long term goal to change over to actually use code system name in the messages, which the IG can then decide what to do
  • See updates here: https://confluence.hl7.org/download/attachments/5996929/ballotcomments_V2_v2plus_R1_O1_2021JAN%20-%20consolidated.xls?api=v2 for 2021-05-27.

Adjourned for the WGM