Monday Q1 Minutes

Agenda Review

• FHIR R5:
  • Feb 24 midnight is content freeze for R5 publication - ballot related first, important other resources after that
  • DocRef
    • has 6 extra jiras (that were originally assigned to SD)
      • help come up with good boundaries (4 tickets)
        • observation – images was in media (add that back in)
        • docRef to diagnosticReport
        • John Moehrke to send these to Hans, Rob, JD to wrap up on OO on FHIR
      • the others John Moehrke  to send to Marti and JD for Block-Vote by Thursda

Project Milestones

• 1238 – UDI implementation Guidance
  • Update milestone to May 2023 WGM; use 5/15/2023
  • Update end date to Jan 2024 WGM
  • Was put on hold
• 1067 – Lab Order Conceptual Model
  • Still in ballot reconciliation
  • Update project facilitator from Patrick to Lorraine
  • Update milestone to May 2023 WGM; use 5/15/2023
• 1335 – LIVD
  • Update project facilitators: Rob H, Hans and Ed
  • We should be done with resolutions soon, but the IG editors will be stuck in R5 work until end of March
  • Hope to have connectathon in May 2023
  • May have to go back to ballot
  • Update milestone to Sep 2023
• 1481 – V2-FHIR
  • Update milestone to Sept 2023
  • Tooling side should be ready by then – need to fix the spreadsheet to IG trans
  • Got some HL7 funding
• 1496 – DME
  • got renamed to US realm FHIR Orders and has updated PSS
  • TSC got it on the docket
  • Next milestone May 2023 for checking
  • Update the end date to May 2024
  • Add post-acute to the keywords
• 1539 – Lab Model Profiles
  • Need to add project need and some other parts from https://confluence.hl7.org/pages/viewpage.action?pageId=51226193
  • Draft IG is ready
  • Discuss today Mon Q4
• 1700 – IHE SDC on FHIR
  • Alex needs to apply the resolutions
  • Status still reconcile
    • Need to close ballot reconciliation
    • Publication request and QA review
    • 2 year STU period
  • Update milestone to May 2023 and 5/15/2023
  • Update end date to May 2025
• 1742 – At Home Test reporting
  • Working on publication
  • Is still under sponsor PH in project insight
  • Ulrike Merrick Riki to follow up with Dave Hamil
• 1782 – CMET withdrawal
  • Passed ballot
  • Update status to withdraw
  • Update milestone to May 2023 / 5/15/2023
• 1068 – Lab Order Logical Spec
  • FHIR Clinical Order Workflow - Universal
  • We want the referral workflow to align with that one
  • Update project facilitator from Eric to Ralf Herzog
  • Update the need based on the updated https://jira.hl7.org/browse/PSS-2101?src=confmacro
  • Earliest for ballot would be Sep 2023 – 9/15/2023
• 1115 – FHIR maintenance
  • Milestone is ok as May 2023
• 1292 – Specimen DAM update
  • Status is request for publication, there is no later status for informative – but pick comment – considering comments
  • Leave open in case we have feedback from FHIR
  • Next milestone date: May 2023 ok
• 1614 – FHIR nutrition care process
  • This included the DAM, which has been published
  • FHIR R5 artifacts have been pushed into core
  • We have not started IG work yet
  • Since Becky left academy – should update status to on hold awaiting resources
• 1634 – AOE – Cross Paradigm
  • Frieda sent word document changes for PSS (and project insight)
  • Update facilitator from Frieda to Riki
• 1686 – Cancer Pathology reporting
  • In connectathon Jan 2023
  • FMG voted for it to be published in Sept, but has not been published
    • Need follow up with Anne to see, if it made it to the eVote – publication request is not showing a date = https://confluence.hl7.org/pages/viewpage.action?pageId=139663966
    • Alex to check with Dave DeRoode
    • Sharing pathology data IG is in the registry
• 1294 – LRI
  • Was published Oct 2022
  • Update status to STU- accepting comments
  • Update milestone to Jan 2024
• 1292 – LOI
  • Was published Oct 2022
  • Update status to STU- accepting comments
  • Update milestone to Jan 2024
• 1973 – eDOS
  • Update facilitator from Freida to Riki
  • Was published Oct 2022
  • Update status to STU- accepting comments
  • Update milestone to Jan 2024
• Leave the rest

Mission/Vision/DMP

• Current

PBM Metrics

• Missing ballot reconciliation package
  • Catalog - Check with Francois/Rob Hausam on ballot reconciliation.  September 2020.  Hans to find that.
  • • Hans Buitendijk to check with Francois/Rob H.
  • Lab Order DAM - Work in progress
• Unpublished Ballots
  • DME - clear where they are at.
  • Cancer pathology - checking on publication
  • LIVD - clear where they are at
• Idle Ballots
  • LIVD - clear where they are at
  • v2-FHIR - clear where they are at
  • Test Compendium - 973 - Need to check why this was listed Hans to Lynn
  • • Hans Buitendijk to check with Lynn.
  • Lab DAM - clear where they are at
  • Order Catalog - clear where they are at
  • DME - clear where they are at
  • Cancer Pathology - clear where they are at
  • v3 Nutrition Domain - Lorraine to check
• Expired STU
  • Test Compendium - Should by extended. 
  • • Hans Buitendijk to check with Lynn.

Monday Q2 Minutes

Clinical Order Workflow (COW) on FHIR  + Ralf and Jose

R5 JIRA

• FHIR-39062 What about the observations with status 'unknown' and 'cancelled'? 
  • The operation is trial use
  • Moved from Comment to Change Request
  • Motion to make Persuasive with Modification (see JIRA) 
    • Bas van den Heuvel / Yanick Gaudet : 9 - 0 - 0  
    • Assigned to Jose Costa-Teixeira 
• FHIR-38986 Why having an Instant data type for Observation.effective[x], when a DateTime is allowed as well?
  • This is normative content –
  • Need to determine why effective[x] valueInstant was added in the first place
    • The Instant is more specific than DateTime
    • Should guidance be provided when to use DateTime versus Instant datatypes for effective[x]?
  • Needs Follow-up

Monday Q3 Minutes

• PACIO = Advanced Directive Interoperability (ADI) - Portable Medical Order Update
  • Slides from Corey 
  • Discussion :
    • Used CDA spec as input for FHIR implementation
    • Reviewing the different state forms for content
    • Portable Medical Orders section to use ServiceRequest
    • Do we need to include ServiceRequest.basedOn to reference consent?
      • What is the temporal connection between ServiceRequest and consent, because the list of orders must be available before the consent can occur – but this is from a perspective of packaging these resources for the shared document, so all already exist
      • Or should this be the carePlan that is used in basedOn and the consent can then relate to that?
    • Goal will be changed to observation (or in addition?) in slide 5
    • Completion Information (related to completion of the form – is a section on the form) will also be observations – see slide 18
    • Similar discussions were had in nutrition around referrals that need to be mapped to procedures – that does not apply here – these are basically the standing orders by the patient for when they cannot voice those
    • How to translate the LOINC CPR.orders in CDA to ServiceRequest?
      • 100822-6 – put this into the ServiceRequest.Category
        • Use the LA-code for Yes CPR in ServiceRequest.Code and No CPR
      • But SNOMED CT also has codes for CPR - will provide the list of available codes for use
      • But we have ServiceRequest.doNotPerform – this may be easier to implement for CDS
      • EMS has DNR and also DNAR (do not attempt resuscitation)
      • Regardless of how we address this, we have to have the list of what are allowable
      • Can create a hierarchical code system, where you can negate at the high level meaning this and anything below, or can chose individual level if we have this
        • Where should this happen?
          • LOINC
          • SNOMED CT
          • Something new
        • Since the definitions can be state specific, you may need to include that in the resources
        • In the consent service model (SOA) addressed this (LAEP from ONC) – reference from serviceRequest back to consent – so should add consent reference to basedOn – or a separate element
      • Goal would be to have ALL variations included in this IG, so that the states can then properly constrain to what their rules supports
      • OO has no preference to the selection of doNotPerform (except then category should be the procedure / order – start with LOINC) or the code
      • Would this need to be included in IPS?
        • That would have to be discussed – it is not yet covered
    • USCore ServiceRequest requires ServiceRequest.occurrence, but this has a start point and is currently valid
      • Use just the date to indicate start time
• DeviceDefinition resource revisions
  • FHIR-39389 - DeviceDefinition should follow definitional resource modelling
    • We know that some patterns have changed for R5
    • assume we are using the pattern in the CU
    • these are missing:
      • url
        • if it is a canonical resource we need to add
      • version
        • this is the release version for the documentation about the device, but I have changed documentation about the device – like a new CE mark / new safety labeling (can this be covered in the meta section of the resource – no, because when this canonical resource gets added to a server that version goes to 1 – also it then tracks all tweaks to the resource regardless of the publication)
        • change deviceDefinition.version and device.version to a different name to align with the new name
        • add deviceDefinition.version to this resource
        • Or do we need to request a change in the pattern name for this element, if that is NOT the deviceDefinition.version
        • What are the terms to consider = revision
    • First discussion needs to be: Does this need to be canonical resource?
• R5 JIRA

Monday Q4 Minutes

• CIMI project proposal = http://Jira.hl7.org/browse/PSS-2154
  • Simplifier has list of profiles and extensions – exponential number of resources
  • Provide guidance to developers
    • on WHERE to search for profiles
    • review existing profiles to merge where there are overlaps
    • create process to allow definitions of NEW profiles ONLY when different use case requires new elements
  • so far talked to CIC – they support it
  • it is absolutely necessary, but very daunting
  • How to organize this?
    • First try to prevent NEW duplicates
      • Create tooling for review of delta between profiles
      • Add versioning to the resource profiles
      • Create categories of differences:
        • Structurally
        • Vocabulary binding
          • Depending on the concepts in the value set support mapping to different code systems
        • Then clean up existing
        • FHIR originally decided that they don’t want to require semantic interoperability
        • Intent was to have the registry and tooling to support limits to the variability of implementations
      • How does this compare to country specific core profiles?
        • Proposing to have variance project in Cross-Product WG for IPA content
        • IPS is harmonizing across countries
      • Figure out how to manage additional constraint for specific use cases for the country specific core work
      • Also look at V2-FHIR mapping to add in those elements that are already defined
      • This requires tools to
        • Identify the meaningful profiles in registries
      • Goal for today is to make sure we are not re-doing the same work and also looking for support
      • Need to be sure we indicate that these profiles are shareable and support a data model for
      • OO and CDS agree this would be a valuable project
• Lab subtypes IG
  • http://build.fhir.org/ig/HL7/cimi-labs/branches/master/index.html
  • One profile for each result scale, i.e. constraint based on datatype in observation.value
    • And all the LOINCs will match the scale
  • For documents
    • If the document is representing the full report, rather than just individual lab results need to represent content in composition for the order and present the individual results in DiagnosticReport.value, the DiagnosticReport.presentedForm is the pdf
  • Still to add NEW LOINC scale – semi-quantitative
    • This is different than ordinal, as they are actual quantities, but not continuous
  • How do you relate these to UScore profiles?
    • Could have base definition of UScore for these profiles
    • IPA fits that pattern – there is birds of a feather tonight 5 PM and over lunch Tuesday
  • Currently written on R4, but should update to R5?
    • May be better to base on R4 and do extension for the document profile to support attachment in observation.value
  • Argonaut pitched project around clinically relevant specific profiles – maybe consider that here, too
• Project insight updates: https://healthlevelseven.projectinsight.net/project/edit/e806340e5bc44938932af7e02d8e986f?rtn=%2Ffolder%2Ffolder-display%3FId%3Dacddd9fee0f142df89e926c35f07e616%26_sx%3D301%26_sy%3D236
  • Connectathon in May2023
  • Ballot Sep 2023
  • Set milestone Sep 2023
  • Update end date to May 2025
• Take over value set for body position
  • Copy link from agenda
  • This is related to bodyStructure
  • But it is for bodyPosition extension on observation – which does not have a valueset binding
  • Motion for OO to take over this value set: JD, Riki, further discussion: if you constrain an extension that has a valueset, where you want a sub-type of the valueset that didn’t work in the IG publisher – we would have to test the publisher, so we would need to fix it; once we do that we should define the binding in the extension – will do that separately against: 0, abstain: 2, in favor: 10
  • Apply this valueset to the bodyPosition extension
    • discuss if example vs preferred – certainly not required
    • currently list as US edition expansion, but we should use the international Edition – was as US edition, because QI core is US realm
    • URL includes CQI
      • so create a new valueset with the same logical definition and a new expansion based on international and add into THO
      • then deprecate this valueset
    • Motion to do the above Rob, Rafiki, no further discussion, against: 0, abstain: 3, in favor: 9
• Collaboration between LOINC and SNOMED CT update
  • Slides from Stan 
  • Discussion:
    • All LOINC content will be covered and have SNOMED CT representation
    • Includes documents, assessments
    • Includes LOINC answer (LA-) codes
    • SNOMED model will have to expand to accommodate support for value sets for the observables, including binding strength etc.
    • SNOMED CT currently does not include the information model for the exchange (codes for result record vs order record, where there are duplicate concepts in different hierarchies in SNOMED CT – observables vs procedures)

Tuesday Q1 Minutes

Inventory Resources

• We need to support four events:
  • Delivery Request
  • Shipment Notice
  • Transport Event
  • Shipment Delivery Notice
• We have four resources already available:
  • SupplyRequest - Delivery Request?
  • ServiceRequest - Delivery Request?
  • SupplyDelivery - Shipment Notice, Transport Event, Shipment Delivery?
  • Transport - Transport, Shipment Delivery?
• Have X12 inform choice as well, while GS1 recognizes different aspects as well.  Lorraine to connect Jose with Mary Kay Daniel to get X12 concepts.
• SupplyRequest - 
• ServiceRequest - Delivery Request?
• SupplyDelivery - Shipment Notice, Shipment Delivery?
• Transport - Transport

R5 JIRA

• FHIR-38818 - Clarify SupplyDelivery for shipment vs reception - Jose - To be discussed after scoping the resources involved.
• FHIR-39064 - Unclear sentence (re: Catalog reference in Observation resource)

  • Motion to replace the sentence with "Observation Definition resources can be used to describe observations which may need to be evaluated in order to determine whether a specific medicine can be administered or held (e.g., weight, lab value result) and provide guidance on the dose to be administered (e.g., sliding scale insulin dose). " - Lorraine Constable / Patrick Loyd:

  • persuasive with mod - clarification - non-substantive

  • no further discussion

  • against: 0, abstain: 0, in favor: 11

• FHIR-38865 - Agree with removal of DocumentManifest

  • Motion to remove the DocumentManifest. - Lorraine Constable / Yanick Gaudet

    • persuasive with mod - enhancement - non-compatible

    • no further discussion

    • against: 0, abstain: 0, in favor: 11

We will create a post-WGM block vote for DocumentReference JIRA Tickets

• FHIR-38966 - Media allowed for searchable references to bodyparts, DocumentReference does not
• FHIR-38950 - Include boundaries and relationship information from Media resource
• FHIR-38634 - Raise DocumentReference to FMM 4
• Also - need to check with John Moehrke if there are any other DocRef JIRA tickets that should be included

• • John D.L. Nolen to create the OO-WGM-Block-R5 with next block vote

Tuesday Q2 Minutes

Informational - US - USCDI v4 DRAFT: https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#draft-uscdi-v4 (comments are due by Monday, April 17, 2023 at 11:59 p.m. Eastern time)

• Specimen rejection criteria not there
  • Compare with LRI/LOI (v1?) 
    • v2 has a should be used
    • 21/24 are called out
  • SPM 21/24 segments are there if you use LRI v1 
  • How are we doing that in FHIR?
    • Specimen has condition but not rejection  
    • Observation has status and dataAbsentReason
    • Can be done using both if you look in each place together 
• Everything else looks ok
  • Reviewed the multiple specimen changes in Observation (not an issue now) 

JIRA Tickets

• FHIR-38732 - Guidance on Specimen Grouping
  • Added to WGM block
• FHIR-38733 - Should Specimen.parent be changed to Specimen.children?
  • Reviewed question in tracker about recursive search
  • Looking for getting a reference from parent to its children?
  • Default search parameter – already cover the recursive search You can find them using the link from parent to child – unlcear in practice how many systems support that and for how many levels...
  • If we keep pointing from children to parent, based on specimen are managed, can we at a later time find all the children – only those that are on your system – if we do it the other way, we might be getting everything, but those children may not be available on your system anyways
  • Next Step
    • proposed disposition will be not persuasive with mod
    • Asked question back to Alex Goel in tracker 
• FHIR-39050 - Getting issue details... STATUS
  • This is part of the jira spec configuration
  • Check with Bryn Rhodes if addition of deviceDispense will be sufficient to close tracker 
• FHIR-38936 - Getting issue details... STATUS
  • Add citation to DiagnosticReport
    • We already have DiagnosticReport.supportingInfo reference to citation
    • We should be careful to support user defined mark-down for security reason
    • Should this be a canonical instead of just reference – FHIR-I is working on new datatype for this – bring this up at joint session with FHIR-I Thursday Q2
    • For citation, would we need to add the context in which it is relevant?
      • Build a footnote table
  • Added to discussion with FHIR-I on supportingInfo reference issue
  • Ask Bas van den Heuvel to join the joint with FHIR-I (notes also left inside tracker)
  • For this tracker, it seems to be an issue for the system that is rendering the url into a hyperlink not the resource itself needing to be friendly to markdown
• FHIR-39796 - Getting issue details... STATUS
  • Updated bodyStructure to handle incorporation of the wound care IG
    • distanceFromLandmark
      • in the definition just change (e.g. in cm)
  • Motion to replace "The measured distance in cm a certain observation is made from a body landmark." with "The measured distance (e.g., in cm) from a body landmark."
  • Persuasive with mod– Clarification – non-substantive: JD Nolen / Patrick Loyd : 10-0-2
• FHIR-39795 - Getting issue details... STATUS
  • Use codeableReference to device instead of code, since we are handling devices the same way in other places
    • Do we need to reference deviceDefinition? - no
    • Should we just use reference and describe that if you just have the type, rather than using the code use device.type instead of changing the
    • If we use codeableReference – then we need to bind to a value set – yes, we should use the deviceType Valueset
    • Should we do that for all codeableReference datatype to indicate that the value set should be bound to the same value set as the .type component of the referenced resource
    • Change the attribute name from “measurementDevice” to “value”
    • Change the Distance device measured to “Distance measured from the bodysite landmark)
    • Should these be 0..1 and not 0..*
    • Rename the backbone element also
    • On a glass slide how would this be described – do we need more than one
    • JD will make another jira to rework the nomenclature for landmarkOrientation and distanceFromLandmark
  • Motion to:
    • change .distanceFromLandmark.device from CodeableConcept to   CodeableReference(Device) where the binding of the CodeableConcept is the same as Device.type.
    • change ".distanceFromLandmark.measurementDevice" to ".distanceFromLandmark.value"
    • change short display on .distanceFromLandmark.value (new name) from "Distance device measured" to "Distance from body landmark."
  • Persuasive with mod - Enhancement - compatible, substantive, assign to JD: JD Nolen / Yanick Gaudet : 7-0-4

Tuesday Q3 Minutes

• Lab Conceptual Model Ballot 
  • #16 - Motion to accept the updated language to clarify better how the process works, including the addition of the additional states to the diagram.  Lorraine Constable, Patrick Loyd.  Against: 0; Abstain: 1; In Favor: 7
  • #18 - Motion to find persuasive with mod adding clarification that fulfiled is applicable to what is requested.  Lorraine Constable, Patrick Loyd.  Against: 0; Abstain: 0; In Favor: 8
  • #19 - Motion to find not-persuasive with mod by making specimen collected - accessioned bidirectional, add specimen collected - resulted one directional, make specimen collected - promised bidirectional, and add text to indicated that interaction diagrams provide use cases for various valid paths.  Yanick Gaudet, Lorraine Constable  Against: 0; Abstain: 1; In Favor: 6
  • #21 - Motion to find not persuasive with mod as the diagram is overarching to the business functions so needs to include all, and add descriptive text to clarify context.  Lorraine Constable, Yanick Gaudet  Against: 0; Abstain: 0; In Favor: 7
• HL7_DAM_LABORD_R2_I1_2020FEB_consolidated 20230117.xls
• State Definitions 20230117.docx

Tuesday Q4 Minutes

JIRA Tickets

• Diagnostic Report JIRAs
  • https://jira.hl7.org/browse/FHIR-39654 – string resources in observation / DiagnosticReport – convert / add to markdown
    • referenceRange is change text to markdown – question for FHIR-I on Thursday Q2 (characters are the same, BUT handling will be different and security implications)
    • Some of this will be covered by https://jira.hl7.org/browse/FHIR-39570
  • https://jira.hl7.org/browse/FHIR-39570 – use markdown in DiagnosticReport.conclusion
    • Find persuasive – enhancement – compatible, substantive - Yanick Gaudet, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 4
    • Assigned ot JD
  • https://jira.hl7.org/browse/FHIR-39168 – update guidance on parent-child relationships
    • Motion to find persusasive with mod and add description to observation and also link the examples to the observation example page - on how to do parent-child linking based on the powerpoint – Riki Merrick, Yanick Gaudet, no further discussion, against: 0, abstain: 2, in favor: 3
    • Assigned to Hans
  • https://jira.hl7.org/browse/FHIR-34194 BusinessEvent extension to DiagnosticReport and SerivceRequest
    • mapping ORC-9 to FHIR
    • This date changes where it should be mapped to based on the ORC-1 used
    • Mapping of ORC depends on the division of ORC elements into ServiceRequest vs task for workflow handling, so should wait for that
    • ORC-37 (added in V2.9 – not yet on the mapping sheet) needs to use this businessevent extension
  • https://jira.hl7.org/browse/FHIR-33990 – DiagnosticReport.imagingStudy Search parameter
    • Applies to DiagnosticReport.study
      • If we can technically create search parameter for study, where you specify which of the resource choices allowable for this element, then that would be more flexible, if references are added
      • If we can’t we should add 2 search parameters to cover both currently allowable resource reference
      • Ping Elliot Silver , John Moehrke or Robert Hausam  for input
  • https://jira.hl7.org/browse/FHIR-32986 – Value set for status in both observation and DiagnosticReport
    • In V2 – we have HL70085 for OBX and HL70123 for OBR
    • In V2 we created M = modified to use, when we corrected a result in a panel that has not been finalized – this was done, because in v2 corrected is ONLY after final
    • In observation.status the value set is required – in V2 we do not have modified as a value
    • Motion to add the new value of ‘modified’ – modified report – a change was made to an observation in the report that was previously reported, but the report hadn’t been finalized to the valueset used in DiagnosticReport – Yanick Gaudet, Lorriane Constable, no further discussion, against: 0, abstain: 1, in favor: 3
  • https://jira.hl7.org/browse/FHIR-32860 – FHIR profiles for micro report representation
    • Related to https://jira.hl7.org/browse/FHIR-39168
    • Assign to Hans Buitendijk  and see if this one then is addressed, or still needs to be done
  • https://jira.hl7.org/browse/FHIR-32754 – DiagnosticReport.code include all LOINC
    • For Lab could use class = lab
    • Should we exclude class = doc (since those are the document section)? – but we have projects that use these codes to identify which type of pathology report is being sent / what section is used in observation.code
    • Exclude any code with type = obs only
    • Need further evaluation – maybe ask LOINC (Majorie) if there are ANY LOINC classes that they feel are NOT appropriate for DiagnosticReport – also ask if there are other attributes we could use to exclude codes that are not appropriate for diagnosticReports Ulrike Merrick 
  • https://jira.hl7.org/browse/FHIR-32575
    • Procedure was added here to support the use case for research, where the manufacturing of a product is what is being reported on
    • Motion to find not persuasive – Riki Merrick, Yanick Gaudet, no further discussion, against: 0, abstain: 1, in favor: 3
    • Missed that this is in-person – so motion to re-open: Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 0, in favor: 4
    • Put on Thursday Q1 to get re-affirmation from BR&R
  • https://jira.hl7.org/browse/FHIR-32154
    • Different definitions for preliminary between observation and diagnosticReport in the FHIR value set – and neither match the definition with V2
      • Observation status – is normative – need to figure out how to deal with this as the definition for preliminary is inconsistent with the definition in V2 for the same concept
      • DiagnosticReport status:
        • Partial is not a parent of preliminary – so change the level from 1 to 0
        • Update definition for Partial to exclude preliminary in the e.g. list
        • Ulrike Merrick  to draft resolution and post to the comment before 1/25
      • Should review BOTH status value sets and compare to the statuses in v2

Wednesday Q1 Minutes

• DiagnosticReport - See notes in JIRA on next step and copy here.
• XYZ distances
  • will be discussed in OO/II and awareness for Pt Care.
  • Eyes-on-FHIR have an interest too: 

    http://build.fhir.org/ig/HL7/fhir-eyecare-ig/StructureDefinition-body-structure-eye.html

• Raised the interest in awareness where Condition and Observation need to move together.  R6.
• Negation
  
  • Not consistently handled across resources.
  • What are business cases what is not like.
  • May need to include family members to understand absence/presence certain conditions
  • Proposal with two options, JIRA will contain the proposal.  
  • FHIR-38899 - Getting issue details... STATUS
  • Pt Care talked about negation in family history/members (reference FHIR-32901)
  • Will discuss Feb 2, 5-6:30pm on the Patient Care call.
• Device Association
  • Concern primarily around data of multiple unrelated patients in a device over time.
  • General understanding to move forward with creating a new resource.
  • General understanding that we don't want to tackle other associations/aspects at this time.
  • May want to keep .subject for implantable device, but rather all in DeviceAssociation.
  • Preferably done by R5, but certainly by R6.
  • This requires:
    • There are 63 references.
    • Need to inform all owners that they need to change the reference to Device if they are trying to connect to the patient as one would have to point to the specific patient-device association in DeviceAssociation
  • OO will discuss further with Dev and then progress.  Patient Care is o.k. with the intent, but concerned with the coordination that everybody applies the change at the same time.
• Need to address the other Patient Care Update requests.
  • Device Association to Thursday Q1
  • Intake/Admin/Procedure - needs conference call.
  • Specimen topic to Wednesday Q3

Wednesday Q2 Minutes

• XYZ distances 2023-01-09 OO - Specimen
  • Possibly relevant: https://build.fhir.org/imagingselection.html (R5 resource)
  • BodyStructure.includedStructure.spatialReference 0..* (reference(ImagingSelection), with an invariant that either includedStructure.bodyLandmarkOrientation or .includedStructure.spatialReference may be present.
    • FHIR-40275 
    • Will get this in to R5
  • II would add ImagingSelection.derivedFrom(reference(DocumentReference)
    • FHIR-40272
    • FHIR-40273

• Imaging ServiceRequest Profile IG PSS: PSS-2135 - Imaging ServiceRequest Profile Implementation Guide DRAFT
  • Motion to co-sponsor with periodic updates
  • Lorraine Constable / Dan Rutz : 9 - 0 - 0

• DICOM SR to FHIR Observation IG (https://build.fhir.org/ig/HL7/dicom-sr/)
  • Planning for May 2023 Ballot (R5)
  • Enhance with FHIR Mapping Language 
  • re: Observation, BodyStructure

• We will meet again with II next WGM Wednesday/Q2

• ObservationDefinition
  • FHIR-38953 quantitativeDetails is not flexible enough, incomplete and overly complex (see comments for discussion)
  • FHIR-38949 Given that ObservationDefinition is maturity level 0, shouldn't 'instantiates' be marked as TU? 
    • Can a Normative resource element reference a non-normative resource and still be normative (as an element)?
• Observation
  • FHIR-39061  Not all value[x] options are covered 
    • Can a search parameter be created by FHIR-I to query any of the choices instead of having to create a search parameter for each of the options in the choice list?
    • Need to assess Observation for which search parameters currently exist for Observation.value[x] and Observation.component.value{x]
    • Add this to discussion with FHIR-I

Wednesday Q3 Minutes

Workflow

• CG working on workflow around reporting.  How does that fit in with ServiceRequest and Task discussion.
• During clinician's review the report and then make decisions about what to do next.  Could be recommendations, suggestions, or immediately do so.
• Is it immediately ServiceRequest?  A Plan?  A task to have somebody else do something as alert to consider something?
• Suggest to draw the boundary around the completion of the reporting, not any next steps.
• However, if the report is to include suggestions, it would not likely be Task, but rather a collection of CarePlan, ServiceRequest, etc. as a recommendation/plan.  Then need to look at packaging the DiagnosticReport (plus its Composition perhaps) with those other resources that represent suggestions, etc., into a larger Composition/FHIR Document.

Genomics Future State

• See slides
• Interested to start to definitional molecular sequences that can be referenced as the result/observed sequence as an Observation.value[x]
• Options:
  • valueCodeableConcept - there is no code system available, while a resource is needed to fully express the molecular sequence.  
    • Could consider resource with a code to a code system and then Observation can reference in the Observation.value.
  • valueReference(Any) - that construct does not exist per-se so want to check with FHIR-I on Thursday.

Repeating Component

• Need to have the ability to have sub-components to group components.  Additionally need to keep track of logical sequence n

Wednesday Q4 Minutes

Discussed Device JIRAs to prepare recommended dispositions to the following topics:

Device - Device Definition Parent/HasPart

• Discussed option 3 and option 4
  • Option 3 - Current State with DeviceDefinition.hasPart and DeviceDefinition.parentDevice (no change to Device)
    • We would have to disambiguate each description/definition to clearly state when to use each
  • Option 4 - Keep DeviceDefinition.hasPart and remove DeviceDefinition.parentDevice (no change to Device)
    • When describing the definition of the device - the top level device and its parts should be known when describing the kind of the device and most likely is the thing that will be queried 
    • We would need to allow parentDevice to have 0..* as it may be defined in more than one parent (i.e., interchangeable device components)
  • Group determined to propose Option 4 to the larger group Thurs Q1 for JIRA FHIR-32271 

Device/Definition Specialization

• We agreed to take the recommendations forward to change the name of specialization to conformsTo
• Added text to ensure the "specialization" was in the definition for recognition by the 11073 uses
• Add to Thurs Q1 for further discussion and resolution of the group of related tickets on this element

Device Association

• Discussed with PatientCare in Wed Q1 (see previous notes)
  • Still need to evaluate the references to device (63+ references)
• Drafted proposed DeviceAssociation resource
  • pulled the Device.association and Device.operation out of Device resource since they contain patient references and some devices can be used on more than one patient (need to keep device association patient/group specific)
  • Preference is to use this to also capture the implantable devices (even though they are single-use/single-patient devices)
  • Need to create new elements and decided to hold off on example value sets (if value set is not currently available) in R5 publication and add the value sets during STU
  • Will review mock-up of new resource Thurs Q1 

Follow-up from Patient Care discussion:

PT Care on Procedure-DiagnosticReport reference direction.

• • use relatedArtifact data type instead reference on basedOn or something like that.
  • could add resultOf and not remove .result keeping it for backwards comfortable and keep a note.
    • rather keep the same than create alternate, thus ambiguous paths.
  • no clear sense in the group between doing it or not with concerns about benefits.

Thursday Q1 Minutes

PatientCare related JIRAs for discussion with DEV

• FHIR-32575 - Procedure shouldn't be a subject (InPerson)
  • Note: Lloyd should be in next quarter if others don't show up 
• Device Association https://jira.hl7.org/browse/FHIR-33389 - How to store parameters related to devices when executing a procedure

Device/HCP-related JIRAs

The following topics have pending proposed dispositions:

• • Device/Definition Specialization 
  • Device Association
  • Device - Device Definition Parent/HasPart
  • Device Settings
    • See FHIR-39322 for proposed disposition
  • FHIR-38711 - Update DeviceDefinition Scope and Boundary sections
    
    • Move Scope from Device to DeviceDefinition
  • FHIR-39501 - Clarify whether others can create Device setting observations
    • See FHIR-39322 for proposed disposition
  • FHIR-39049 - DeviceDispense should allow dispensing devices to Practioners and RelatedPerson
  • FHIR-38951 - SaMD & DTx Resource?

Thursday Q2 Minutes

Updates from FHIR-I

Deadlines for FHIR

• Due date for FHIR R5 is February 24, 2023
  • 2 weeks after will be QA
  • 1 week after will be applying changes
  • Goes to Grahame for finalization (changes are subject to his discretion)
• 291 JIRA Tickets
  • 65 Unapplied
  • Must have resolution to all R5 ballot comments 
  • FMG will do a block vote to consider for future use on any outstanding R5 ballot comments
  • Focus on substantive issues (higher priority)
  • Anything that is terminology (not tied to code element) requires going through UTG and approved by February 12, 2023
• Timelines allow IGs to ballot in R5 

Questions for FHIR-I

• FHIR-38949 Given that ObservationDefinition is maturity level 0, shouldn't 'instantiates' be marked as TU? 
  • Can a Normative resource element reference a non-normative resource and still be normative (as an element)?
    • Answer - Not an issue to point to non-normative and does not need to be marked as trial use
    • Question Answered - see JIRA (Resolved - No Change)
• FHIR-39061  Not all value[x] options are covered 
  • Can a search parameter be created by FHIR-I to query any of the choices instead of having to create a search parameter for each of the options in the choice list?
    • We need a search type for each data type - you may be able to group some of them
      • Observation has a lot of value[x] options
      • Search for Attachment - may not be needed 
      • Prioritize the addition with search parameters that are needed
      • Implementers can define their own search parameters
    • Add to Block Vote with recommendation that this is not persuasive for R5, the working group will prioritize the addition of search parameters as use cases are submitted and work to create them over time.
• FHIR-39634 - Consider whether to add intendedUse or instructionsForUse elements to Device, DeviceDefinition
  • We have elements pointing to ClinicalUseDefinition (e.g., DeviceDefinition.guideline.indication) and ClinicalUseDefinition.subject points back to Device.  Need to discuss with FHIR-I
    • Change datatype from CodeableReference to CodeableConcept on the guideline.warning, guideline.contraindication, guideline.indication
    • Comments should indicate you can also have ClinicalUseDefinition that points to the DeviceDefinition if you need more structured data
    • No changes to Device resource (as it is noted in the original description
    • Add to Block Vote 
• FHIR-38936 - Reference to Citation and Citation Lists from text
  • Added to discussion with FHIR-I on supportingInfo reference issue
  • How to enable a canonical reference in .supportingInfo and how to provide guidance and possible enhancements to reference any supporting information in markdown. 
    • Is a list of footnotes to other material - this should a core extension
    • how do you render narrative? needs additional discussion, this has not been done in core because it is context specific (typically addressed in IGs)
    • Added a comment to the JIRA ticket with the response above.  No action for OO (i.e, it was not included in the Block Vote.)
• FHIR-39654 - Getting issue details... STATUS (text to markdown)
  • All of the following are allowed to Observation (N): 

    • Change Observation.referenceRange.text to markdown (if allowed based on normative rules) or alternative

    • Add Observation.value[x].valueMarkdown with type markdown

    • Add Observation.component.value[x].valueMarkdown with type markdown

    • Add to  Block Vote
• valueReference(Any)
  • that construct does not exist per-se so want to check with FHIR-I on Thursday.
    • RE: molecularSequence 
  • CG - profile on Observation 
    • Need to make valueReference and valueCanonical to Definitional resource (pointer to a resource)
      • Need to add explanation - do not point to instance resources
      • Definitional resource should be canonical
      • Need both a reference to a canonical and regular

• • • John D.L. Nolen Need to create a JIRA ticket 

• (sub-)components and sequence
  • R6 Discussion points
  • extension on component for the interim
    • need discussion and impact assessment even for an IG extension

• • • John D.L. Nolenwill take this back and discuss with CG

• FHIR-32575 - Procedure shouldn't be a subject (InPerson)
  • Similar to  the pattern on Observation with .subject and .focus  If the facility is the subject of the report (i.e, site being inspected), then the focus is each of the processes/procedures that have been evaluated.
  • Proposal is to find persuasive with modification
    • Remove reference to procedure on DiagnosticReport.subject
    • Add core extension for focus 0..* Reference (Any)
      • Short Display: This is not the subject of the report, but the various focal components that make up the report (e.g., Procedure or process evaluated during a Quality inspection of a manufacturing facility)
  • Add to Block Vote

Thursday Q3 Minutes

Transport update

• Review present state of the resource
• PA needs (focused more on the administrative side, not physical side yet)
• Intersection with supply chain needs. SupplyShipment (the act of shipping) potential resource similar to Transport
• X12 crosswalk
  • Focused on the orders of things not so much the physical transport

       TODO: Crosswalk Transport with Jose Costa-Teixeira  around supply shipment

• Mental model: Transport/Task live in the middle between the request and the delivery of the thing
• encounterHistory will be in R5. No immediate need for a direct link between Transport and encounterHistory.
• Potential adopters/connectathon types
  • Mobile phlebotomy
  • Lab specimen transport
  • EMS (EPCR documentation)
    • Paramedicine Care Summary IHE profile
    • Acute vs non-acute transport differences
      • differences between end of encounter and end of the transport (Location reference)

Thursday Q4 Minutes

• FHIR-39448 - 
  
  • This ticket is not critical for R5 (i.e., not a R5  ballot comment), but would like to get them in if possible.
  • See JIRA for current changes.  These were the identified topics discussed, but the JIRA is the authoritative source for the current changes proposed.
    • http://build.fhir.org/observation.html#core
      • Section 10.1.1.1 - Trial Use indicator to Core Profiles for Observation
        • This allows additional changes to the Vital Sign Profiles (see next page)
        • Change: The following core profiles for the Observation resource have been defined as well. If implementations use this Resource when expressing the profile-specific concepts as structured data, they SHALL conform to the following profiles:
          • To: The following set of core profiles for the Observation resource have been defined. If implementations use this Resource when expressing the profile-specific concepts as structured data, they SHALL conform to the specified profiles:
        • Fix table to label column 1 as "Profiles"
    • http://build.fhir.org/observation-vitalsigns.html -
      • Update the title of 
      • This page is currently "Informative"

• • • • Robert Hausam Need to continue identifying changes to the vital signs profiles.  

R5 JIRA Updates

• Observation
  • FHIR-38985 What happens if the definition deviates from the Observation?
    • Consider for future use
      • This is a pattern that should be handled across FHIR resources definition-instance resource pairs.
      • This is too large to consider for the R5 release
      • Will raise after R5 publication
      • Add to Block Vote
  • FHIR-38984 Suggest to add text explaining relation to ObservationDefinition 
    • Boundaries and Relationships 
      • Include text at author's discretion
      • Add to Block Vote
  • FHIR-38971  observation-precondition should be a modifier extension 
    • Should the modifier extension be used with the observation-precondition extension? what does "ability to safely process" mean in the modifier definition 
    • Look at other modifier extensions in OO
    • Everything would need to be modifier extension
    • Need to look at OO extensions as well (post R5)

• • • Robert Hausam to raise this topic on Friday in Clinicians on FHIR 

• • FHIR-38956  Unclear statement
  • FHIR-38955 A constraint expression is not specifically enough defined 
  • FHIR-38924 observation-replaces extension: expected behavior not clear 

Friday Q1 Minutes

JIRA Review

• FHIR-32271- Parent/hasPart
  • Reviewed with the group the previous discussions
  • Reviewed the proposed disposition drafted

  • Motion to:

    • Remove parentDevice from DeviceDefinition resource
    • No change to hasPart backbone in DeviceDefinition resource
      • Explain why this is done differently as it points up with a couple of examples in a Notes section on device hierarchy.
    • No change to Device resource
    • Ensure search parameters are updated appropriately.
  • Vote:  Marti Velezis / Yanick Gaudet: 11-0-0
  • Assigned to Jose Costa-Teixeira

• FHIR-38904 - DeviceAssociation
  • Reviewed DeviceAssociation proposed elements
  • The group decided to revert the move of the following .operation attributes
    • mode
    • cycle
    • duration
  • Motion to accept the proposed disposition – see JIRA for details (includes new resource element table)
    • Marti Velezis / Elliot Silver : 8-0-2
    • Assigned to Jose Costa-Teixeira
  • Resume draft of DeviceAssociation FHIR Resource Proposal in next quarter
• Note – we will be decommissioning the Confluence pages that were used to discuss the following topics once we are certain all related JIRA tickets have been resolved.

Each of the pages have a “status” block that will be used to indicate the discussion topic has been resolved by the working group.  We will reference the JIRA ticket with the final disposition.  Many of the topics have multiple tickets – some of which are only links to an existing JIRA ticket.

Friday Q2 Minutes

JIRA Review:

• FHIR-38056- DeviceDefinition classification valueset misleading
  • Depending on the code system, a device may be classified by its type and/or its risk class. Therefore, it is important to allow these two concepts to be similar enough to include in one concept.  In order to demonstrate this – the following valueSets can be added:
    • Class I
    • Class IIa
    • Class IIb
    • Class III
  • Motion to update the classification.type value set as follows:
    • Include value sets for risk class (OUS)
    • Keep the binding to an example
    • Add description on classification definition to explain why the concept of device type and risk class fit under classification
    • Elliot Silver / Yanick Gaudet : 5 - 0 – 0
    • Assigned to Jose Costa-Teixeira
• Completed Administrative JIRAs for the following tickets that were completed in the DEV group for DeviceDefinition:
  • • FHIR-38652- DeviceDefinition UML needs fixing
    • FHIR-40282- Review summary elements in DeviceDefinition
  • These were ballot comments, but the proposed resolution was not changed. The Working Group was changed and votes were taken in the correct forum.