OO WGM Attendance Log 202201

Tuesday January 18, 2022

ANSI Anti-Trust Policy:

Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Q1

Chair: JD Nolen

Scribe: Lorraine Constable

Agenda:

Scheduled to be joint with Health Care Devices

  • HCP Topics on Device R5 Normative candidates / DeviceDefinition / DeviceMetric
  • HCP topics related to software (IEEE)
    • Scope and boundary sections for Device and DeviceDefinition
    • Device.type expand example value set with software/hardware context
  • FHIR-32567 

Notes:

Quorum reached

Motion to approve recording

Kathy Walsh / Frieda Hall  8-0-1


Agenda review

Devices not available; reschedule. Postpone this agenda

Motion to adjourn – Marti Velesiz; Lorraine Constable 10-0-0

Q2

Chair: JD Nolen

Scribe: Riki Merrick

Agenda:

Notes:

Quorum reached

We are recording the meeting

Administrivia

Review the DMP

http://www.hl7.org/participate/decisionmaking.cfm

Reviewing the default: http://www.hl7.org/documentcenter/public/decisionmaking/DMP%20V5.3.pdf

Changes can be made to section 5 (Quorum) and 7 (electronic Voting)

Quorum = we have been operating under chair +4 for the main call, but per the default that would make it easier for the smaller projects

project calls without co-chairs have to have votes on main call

EVoting = How are we dealing with the “last conference call” if we have so many? – make it the conference call the motion topic originated from / or is expected to be targeting based on the list it is sent out to?

Let’s allow e-Votes only on the main list serve and use the main call quorum requirements


Motion to accept the default DMP and agree with the content – Lorraine, Ralf, further discussion: if we can say the last call had low quorum, would be worried that we may have quorum to low – drop this motion


Motion to create addendum to default DMP

  • A) for #5 update that for main call quorum is Chair + 4, all other project calls use the default quorum rules of Chair +2
  • B) for eVotes 7.2 second a) (make a note that the numbering is off in the default DMP) – must occur on the main OO listserve and use the attendee numbers of the main OO call to determine quorum requirements for the eVote
  • By Lorraine, Riki
  • Further discussion: should we mention the last WGM? no we don’t think so,
  • against:0, abstain: in favor: 18
  • Ulrike Merrick to create the addendum and send to TSC and also post the DMP addendum to the front page of confluence
Review the SWOT
  • Last done September 2017 per WG Health, per minutes we last reviewed in May 2019, but no changes made then
  • Create new page = OO SWOT Analysis 
    • Threats:
      • Heavy influence of ONC funded projects resulting in US realm focus
      • Volunteer workload expectations imposed by accelerators and other funded
      • We have had more international participation, so can remove
      • Continued handicap of virtual WGM due to the time-zone differences
      • OO and InM are the only remaining sources of V2 knowledge
      • Ongoing impact of lack analysis of appropriateness of FHIR for the behavior model for lab interactions (determining the state of something other than the resource – e.g. orders/results, for US realm CLIA compliance) as well as the focus on 80% rule for inclusion in core spec
    • Opportunities:
      • Remove bullet around CDA release 3
      • Monitor the evolution of HL7 restructuring and determine opportunities to collaborate with the new envrionment
      • update the v2 mapping from V3 to FHIR mappings
    • Weakness:
      • remove v3 related bullet
      • we still have a shortage, but it is no longer as severe
    • Motion to accept the updated SWOT Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 0, in favor:16
    • Riki will double-check if there is anything else we need to do
    • Ralf will update the main page to link to the new SWOT (done)
    • Patrick hasn’t renewed his membership, so he is no longer a Co-Chair
Ballot reconciliation
  • DME – voting has been done on the HCP calls as well as a dedicated DME call – send this out for review and will have a vote to approve the file for upload on the next main call (1/27) – Ulrike Merrick  to send this email
  • CMET withdrawl ballot in in Jan 2022 ballot cycle 
    • William Gossen and Helen Drijfhout-Wisse, both from the Netherlands posted negative votes
    • Need to follow up if ANSI accreditation is required – or something similar on the European side
    • If it is in use, then we should not withdraw it
    • Finland is also using this specification
    • What’s the next step?
      • We are not planning to do maintenance on these, but people are saying they are still using them
    • Reach out to William to find out why he need this to be re-affirmed – Lorraine Constable 
Project insight review
  • 1294 – LRI – next milestone is to publish as STU for 2 years – ideally end of January for WG review and publish in February – move milestone to May 2022 and project end date to 2024
  • 922– LOI – next milestone is to publish as STU for 2 years – ideally end of January for WG review and publish in February – move milestone to May 2022 and project end date to 2024
  • 1453 - Digital Pathology metadata requirements – this is IHE project and we created this just in case we need changes to underlying resources – have first profile published – push out by 2 more years
    • Will find another quarter to complete

Q3 

Chair: JD Nolen

Scribe: Riki Merrick

Agenda:

  • R5 JIRA Ticket Review / Prioritization
  • DocumentReference - Normative (question) 

Notes:

Quorum reached

Administrivia

    • We agreed to record the session

    • Reps to PE in Q4 – Ralf will go

R5 prioritization

    • have plan for device, deviceDefinition, biologicallyDerivedProduct

    • observation has 93 open trackers, but that is already normative

    • Is docRef staying on normative path?

      • FHIR-34282 – make cardinality for any multiple occurrence element

        • multiple subjects?

          • Patient and practitioner audio recording?

            • Practitioner would be the author more likely than the subject

            • use encounter and add in references to participant to describe all others in the recording?

          • need to may be create a contributor attribute?

          • If you have more than one patient in a session, this would be a group

          • what about a mother and baby?

          • In other resources we have mostly 0..1 for subject, but it is not consistent across resources

          • We think subject should remain 0..1

        • multiple classification for organization

          • we have similar things for other aspects that could be categorized differently

          • why does this have this as a separate element?

            • Because it is heavily used in IHE XDS specs

            • when you import an external document you may not have access to the encounter information

            • we don’t think for a single document that’s is very likely

        • LabCorp had some discussion about having a lab test result on more than one patient

        • Motion to find not persuasive – Rob Hausam, Riki Merrick, no further discussion, against: 1, abstain: 5, in favor: 9

      • FHIR-34043 – generate parameters

        • has zulip convo – may take more time

      • FHIR-32822 – Compositiontype binding different from document.type

        • these should be example binding

        • no one maintains C80 code system anymore – this came from HITSP work, so is US centric

        • Motion to accept the recommendation in the comment from John Moehrke, if we can figure out how to shorten the list – Marti Velezis, Riki Merrick

          • specifically the name should be doctype and remove the C80 from the URL and other corresponding references to C80

          • persuasive with mod

          • substantive vs non-substantive (it is not changing wire format, but we are making a change to the resource itself

          • vote: against: 0. Abstain: 2, in favor: 13

      • FHIR-32791 – Change requirement of content

        • this is in person

      • FHIR-32790 – Remove reference to composition

        • test change for clarification

        • motion to find persuasive with mod Lorraine Constable, Marti Velezis – further discussion: in text in documentReference should not use the term composition, since that is a separate resource to avoid confusion – this should really be called artifact reference? That is a different discussion

          • do we really want to rename the valueset?- no

          • The editor should review the attribute definitions for references to composition and make appropriate edits to clarify them.

          • Vote: against: 0, abstain: 4, in favor: 10

      • FHIR-32579 – Make event a codeable references

        • is in person

        • seems like a good idea to allow you to provide a code or a the specific instance

        • Motion to find persuasive – Lorraine Constable, Riki Merrick, no further discussion, against: 1, abstain: 4, in favor: 9

          • non-compatible

      • FHIR-32578 – binding for document type valueset is too narrow

        • request is to expand the listed examples to understand that this could be outside of the valuest

        • this is related to/has to be finished together with FHIR-32822

        • this is in person, too

        • put on agenda for Friday Q2

      • FHIR-32577 – binding for document category

        • this is in person, too

        • put on agenda for Friday Q2

      • FHIR-32576 – Make DocumentReference.subject ANY

        • maybe just enumerate more types, rather than making it any

          • should composition be allowed?

          • Are there others that fall into similar categories as composition?

      • FHIR-31581 – also related to FHIR-32577

        • also this applies the overall issue across resources how category and type interact

        • should have a larger discussion

        • take out of the blockVote

    • Lorraine to send a note to John Moehrke to attend Friday Q2 and ask if he has items to prioritize

    • Probably should also plan on a follow up call after the WGM where it fits into John and Lloyd's schedule

Q4

Chair: JD Nolen

Scribe: JD Nolen

Agenda:

Notes:

Quorum reached

CQI

Reviewed spreadsheet from Abdullah...levels of Measure Type

  • Action Item: CQI would review definitions and bring set to OO for approval to update UTG
  • Vote for OO to be a co-sponsor of the UTG proposal UP257   Rob / Abdullah     16 - 0 - 1

Chat copy: 

Abdullah Rafiqi to Everyone (3:38 PM)
https://chat.fhir.org/#narrow/stream/179202-terminology/topic/Adding.20new.20codes.20as.20children.20to.20a.20deprecated.20code
Me to Everyone (3:38 PM)
https://confluence.hl7.org/display/OO/OO+WGM+Attendance+Log+202201
Paul Denning to Everyone (3:39 PM)
https://jira.hl7.org/browse/UP-257
Paul Denning to Everyone (3:47 PM)
https://terminology.hl7.org/ValueSet-v3-ObservationMeasureType.html
Floyd Eisenberg to Everyone (3:48 PM)
The Agency for Healthcare Research and Quality (AHRQ) defines patient experience in the following way:

Patient experience encompasses the range of interactions that patients have with the health care system, including their care from health plans, and from doctors, nurses, and staff in hospitals, physician practices, and other health care facilities. As an integral component of health care quality, patient experience includes several aspects of health care delivery that patients value highly when they seek and receive care, such as getting timely appointments, easy access to information, and good communication with health care providers.

The Society of Hospital Medicine Patient Experience Committee defines patient experience as “everything we say and do that affects our patients’ thoughts, feelings, and well-being.”
Paul Denning to Everyone (3:49 PM)
"compose": {     "include": [       {         "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",         "filter": [           {             "property": "concept",             "op": "is-a",             "value": "_ObservationMeasureType"           }         ]       }     ]   }
Floyd Eisenberg to Everyone (3:50 PM)
"Patient engagement" is a broader concept that combines patient activation with interventions designed to increase activation and promote positive patient behavior, such as obtaining preventive care or exercising regularly.
https://www.healthaffairs.org/do/10.1377/hpb20130214.898775/full/
Floyd Eisenberg to Everyone (3:56 PM)
https://confluence.hl7.org/pages/viewpage.action?pageId=81027433
Paul Denning to Everyone (4:10 PM)
The quality measure community uses the ObservationMeasureType value set (created with the ObservationValue Code System). We are requesting the following changes: 1. Deprecate the EXPERIENCE code 2. Create two new codes of PATIENT EXPERIENCE and PATIENT ENGAGEMENT to replace deprecated EXPERIENCE code 3. Create three new codes of population health, access to care, care coordination


Home testing

  • HOLD for Riki if she shows for Q4

Device update 

  • Questions about the boundary between Device, Device use statement. When does the device use start? Who adds it? Looking for maturity if CQI can use it for measures, but it looks like Observation is still the best route. 
  • Reviewed US Core ValueSet and how to constrain that while keeping extensible 
  • OO items in QI-Core 4.1.0 MUST SUPPORT items with example value sets 
  • Specimen type code set? We are working to update/modernize it from V2 
  • Yes on joint meeting at next WGM Monday Q4 OO hosts 

Wednesday January 19, 2022

ANSI Anti-Trust Policy:

Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Q1

Chair: JD Nolen

Scribe:  Ralf Herzog

Agenda:

Transport resource 

Resource Proposal

  • Task and it's relation to the transport resource
  • Transport Resource is about moving of "stuff" Devices, Samples, etc.
  • Transport Resource has a relation to PA (moving Patients is quiet similar)
  • FHIR-I has questions regarding the Resource Boundaries
    • Should follow the Event Pattern
    • Transport "only" documents the physical movement
  • Resource Proposal is approved
  • There is a "home" missing.
  • We should try to get it into R5 in May (even a skeleton level 0 would help), deadline is March, 15th

Connectathon debrief

  • Cancer Electronic Pathology Reporting

    • Pathology Use case was successful
    • Using MedMorph Architecture was more challenging
      • Next Connectathon should be more closely aligned with MedMorph 
    • There are many physician and pathology reports sent about a given patient
      • it would be more convenient for registries if those reports are somehow linked, now a complicated patient matching needs to be performed
  • Next Catalog Connectathon,
    • intention to ballot and do a connectathon in May
    • IG is based on current snapshot of R5 (R5 Snapshot 1) 
    • Resources are all at least level 1
  • A Physical Connectathon is missed
    • virtual was great at first with more people, but we are getting fewer people doing hands on development 
    • sitting with peers on a table and solve a problem is gone

Lab results in FHIR:

We need to get together the different projects.

Notes:

Quorum reached

Q2

Chair: JD Nolen

Scribe: Riki Merrick

Agenda:

  • Review C-CDA to and from US Core Mapping work

Notes:

Quorum reached

  • Review C-CDA to and from US Core Mapping – where is the link?
  • Other topics:
  • Pull forward LabOrder Ballot from Q4
    • Review of the word document with Kathy's adjustments
      • We will accept all typos
      • Changing “Laboratory Technician” to “Laboratory Professional” will need to happen in many places, including diagrams
      • adding in QA in result review may change the process flow diagram slightly – seems like it applies to section 6.5 or 6.6 in the diagram, which is not granular enough, since we are
      • will accept adding QA’ed as needed.
      • This storyboard is universal, so should not point to just CDA
        • if we want to ensure we do a specific example just for CDA, then that should be in the title of the storyboard
        • change to “using realm-appropriate standards” in all places where “using CDA” is used
      • Changing the tense to be consistent in the storyboards
      • changing “follow up” to “any” is fine
      • Capitalize all parts of the name
    • Motion to accept all changes suggested by Kathy with the addition to the change JD documented in the referenced document below; Lorraine will then update the ballot spreadsheet accordingly– Lorriane Constable, Freida Hall, no further discussion: against:0, abstain: 1, in favor: 9
  • Ballot reconciliation in the spreadsheet referenced below:
    • #16: need to come up with definitions of fulfilled, resulted, reported and keep those with the transition diagram; may need Rob H’s input, so schedule for next week Friday – Lorraine check if these definitions are in the EA model
    • #18: belongs together with #16
    • #19: lines to and from “promised” – these are possible transitions, it doesn’t mean all need to always happen
      • from Friday discussion – we agreed to add a line from “Ordered” to “Accessioned” and the line from Collected to Accessioned should be in both directions.
      • Motion to find not persuasive – Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 3, in favor: 7
    • #20 - Motion to find persuasive – Lorraine Constable, Kathy Walsh, no further discussion, against: 0, abstain: 1, in favor: 9
    • #21 – This diagram is actually on page 6
      • these are not in order
      • these actions are re-used throughout the process and order would depend on the actor using them, e.g. an order would be read by specimen collector and Laboratory Professional
      • Motion to find not persuasive Riki Merrick, Lorraine Constable, no further discussion, against: 0, abstain: 4, in favor: 6
    • #22 – In the model we are differentiating between the name of the use case and the role of the actors in the use case
      • this is supposed to describe the process and the step is for managing orders on the patient (manage orders – subject) = this is an overarching action that is part of the use case which can be used at different points in the process by different actors
      • Motion to find not persuasive, Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 5, in favor: 5
    • What is a conceptual specification?
      • We are looking at the behavioral and static elements of steps that need to occur for the ordering process and whichever actor and system are involved and what elements
      • we started this work over 10 years ago – you can then use this to specify the requirements for specific standards like V3, CDA and FHIR artifacts
    • #23 – Motion to find persuasive Lorraine Constable, Kathy Walsh, no further discussion, against: 0, abstain: 1, in favor: 9
    • #24 – A dashed line in UML is a dependency, a solid line is an association with inheritance; consider question answers
    • #25 – Motion to find persuasive with mod – need to add a paragraph explaining the sub-use cases in the use case diagram – Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 8
    • #26 – Diagram around the event flow
      • when the bubble extends in the swim lane they are involved in that process in any role (even just receiving the result or documenting the specimen collection)
      • let’s review this one together with #16 and #18
      • We probably should have definition for all states in the state diagrams
    • #27 – also related to #16, #18, and #26
    • #28 - Motion to find persuasive Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 8
    • #29 – Find persuasive with mod – will review and adjust all other related state diagrams – similar to resolution in #17 Lorraine Constable, Kathy Walsh, no further discussion, against: 0, abstain: 1, in favor: 8
    • #30 - also related to #16, #18, #26, #27
    • #31 – find not persuasive – same as #19 Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 8
    • #32 – is the comment to remove the other 3 sub-state diagrams
      • these are looking at how the business states relate to V3 object statuses – i.e. what the state is of the information object – for example the order record vs the process
      • We should update the introductory paragraph in 3.3
    • Lab Order Conceptual Model Ballot Recon Files from Q2:



Q3 - Joint with CG

Chair: JD Nolen

Scribe: Lorraine Constable, Riki Merrick

Agenda:

Notes:

Quorum reached

  • Agenda review
  • Synergistic topic for CG Accelerator (5 min):
    • During the IHE PaLM call on 1/12/2022 we talked about creating sections in diagnostic reports - something very common in AP and CG
    • curently there are 2 approaches
      • Creating of group observations that use hasMember to point to the related observations inside DiagnosticReport
      • Using DiagnosticReport to report all, and then grouping with composition 
    • it would be good to harmonize those to just 1 internationally
    • Thinking this would be a good topic for the new GenomX accelerator
  • RBC Phenotyping IG
    • If we want to aim for Sept ballot cycle, we need to make the PMO deadline (sponsor approval) Feb 4, 2022.
    • Ensure the depth of the detail around the phenotyping which can e established during the projects
    • PSS-1871 - Extended RBC phenotyping-genotyping FHIR IG ACCEPTED
  • Update on Order Catalog?
    • Is order catalog going to be pulled from ballot?
      • If we can reference R5 content, we will go to ballot, else we’ll have to pull it
  • Old Business (last WGM)
    • Coded annotation
      • add note element into DX report 
        • FHIR-31663 - Add .note (0..*, Annotation) to DiagnosticReport APPLIED
      • action item for OO to log a JIRA to put a codable concept on Note
        • Proposed solution: Use an extension on Annotation to provide text (already there), an identifier/code, and a URI for lookup purposes. 
      • Talk about Grouper
        • Do we need this at the Dx report level? 
        • 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 
  • “Study-level” Observation proposal (https://docs.google.com/document/d/1N9JsMW3OXVO1VVipIYs-Cz6J0zpWEx51yvigMGlINOo/edit)
    • genetic test should have meta data assignment to help with result interpretation. It is useful to identify the test event and then add study level metadata
    • how do you represent a test level event in FHIR and looked at what II has done – which is to create the imageStudy resources
    • we presented this on the catalog meeting which we brought up the TORCH example
    • Procedure is owned by PA – ask FHIR-I?
    • This shows that a single imaging study can include metadata about a series of images in the study – the study then links off to the observations and both can be packaged into the DiagnosticReport
    • we need to differentiate meta data about the study, the actual observations and then the observation/interpretations that were made based on them
      • We have a profile on observation called RegionStudy
      • We need to include the definition of what the study aimed to study and what the test was able to study
      • in this diagram these would all be event resources, the definition could be referenced from the Study resource (using basedOn)
    • molecular resources – was originally Sequence resource, working on resources that describe the definitional nature of aspects of the genomics study
      • we are reliant on public data bases on getting information around genetic variation and its physiological impact
      • similar approaches have been taken in nutrition with references to products (patient agnostic)
    • Harder part is capturing the event metadata on the study (e.g. what regions were uncallable - and thus meaning the particular instance differs from the definition of the test - planned regions)
    • CG meeting with FHIR-I was around status of molecularSequence in R5 and what other elements should be promoted in R5
      • CG is working with Lloyd to address what we do with molecularSequence vs submitting new resources for R5 – since that is due in March 15, but otherwise it may take several years, unless FHIR-I agrees to R5B in order to add new reources
      • it might be easier to profile an existing resource than adding a brand new one
      • not sure a profile on procedure is the right approach, maybe better to profile imagingStudy – do we have a PSS this work can be under?
    • Consideration for implementers:
      • This needs to fit into the LIS first
      • EHR-s can chose if they want to include in their data, we should make sure we support the semantic meaning of our data that needs to be exchanged.
    • Summary: Overall approach seems good – using the same approach as ImagingStudy but creating a profile on procedure for a new resources
    • Next Steps: Need to get PA perspective
  • Biomarkers
    • Question is how to best represent this variety in FHIR
      • we would need the light-weight version for clinician consumption but also the super detailed version to retain the knowledge
    • Consider creating summary data elements that can be queried for to cover the light-weight use case?
    • Use of "positive" in the interpretation is problematic
      • LOINC is using positive / negative / indeterminate as example answers – should be updated to detected / not detected or presence / absence
    • Many different vendors can be mapped to the same LOINC, but their detailed targets are different, which may not exactly end up with the same interpretations
    • For population based research – see slide 6
      • where does this fit in
      • they want EVERYTHING = the superset
    • we want to try to capture the main information but MUST retain the context to not create misleading data in the EHR-s, but maybe we can do that via references to metadata
    • there are also tests that hides a lot of that detail, because it is proprietary
    • Can we create different profiles for biomarkers covering the different approaches to reporting biomarkers?
    • Some of the elements identified under derivedFrom are already in the panel (NOTE: I missed some of the detailed reference here)
    • they could find out more from the source (i.e the performing laboratory), if they need (misleading to call this source - compared to specimen source; shoudl update the words to use to performing laboratory!)
    • In cases where you have all the details, you can create the views for each user
    • when we are getting these results in the XML format, that have the details, but also sharing the reports, which don't have them
    • may need to create a harmonized observation and then have a different view for the vendor specific aspects?
    • We need to clarify the guidelines around interpretations – we need to make this more clear
    • Next Steps:
  • Administrivia – we will keep the same joint slot for May WGM!
  • From chat:
    • Does CG consider more statistical genomic measurements for one of their use cases? I am thinking of NIPS or microdeletion determination for example.
    • From Bret H to Everyone 12:29 PM
      • for me the methodology used should guide what is appropriate/possible in terms of best practice reporting. antibody test for the presence of a mutated protein would be interesting to discuss, in my opinion. versus a microarray versus NGS
    • From John C Spinosa MD, PhD to Everyone 12:31 PM
      • Fusion detection kind of overlaps between visual and sequencing.
    • From Bret H to Everyone 12:34 PM
      • Agree John
      • with something like an antibody test you've got an assumed/implied genetic sequence (definition) for what the test covers. so should a terminology code carry that genetic positional information? Or not? Current state in HL7v2 is yes - which makes collection of a comprehensive view of genetic information on a patient really hard
    • From Alex Mays to Everyone 12:35 PM
      • To add a wrinkle, even a simple test like an LDH level might drive a treatment plan. So a biomarker need not be genetic nor limited in its scope to just that use case (e.g. you can get an LDH for sepsis too).
    • From Bret H to Everyone 12:35 PM
      • totally it's a spectrum for sure
    • From Anand Kulanthaivel to Everyone 12:36 PM
      • Bret, great question -- An antibody variant result could signal upwards of 20 genomic variants. So without genomic validation, it's many-to-one.
      • If it's antibody-to-protein. If it's FISH, then it's 1 to 1
    • From Alex Mays to Everyone 12:48 PM
      • A thought. Would it be better to reference the underlying observation or diagnostic report? I see the value of something lightweight for people who just need the summary statement, and linking to the original observation would preserve detail in the original lab test report if needed
    • From Riki Merrick to Everyone 12:54 PM
      • I have a question about the element "source" - what is that referring to - if the specimen, it is NOT well enough defined
    • From Bret H to Everyone 12:57 PM
      • so, Observation.text can carry a PDF
    • From Riki Merrick to Everyone 12:59 PM
      • @Bret that should come in Observation.value using the attachment datatype, or in the DiagnosticReport use the presentedForm for pdf
    • From Bret H to Everyone 01:00 PM
      • if it represents the entire report - definite Diag Report. But observation.value, I am not so sure
    • From Me to Everyone 01:01 PM
      • a pdf should not be of datatype text
    • From Dan Rutz to Everyone 01:01 PM
      • This sounds like a valuable use case for GenomeX to tackle :-)
    • From Bret H to Everyone 01:01 PM
      • Narrative is the datatype
    • for observation.text
      • From Anand Kulanthaivel to Everyone 01:01 PM
      • PDF isn't a narrative per se though
    • From Me to Everyone 01:01 PM
      • that is still not the right dattype
    • From Anand Kulanthaivel to Everyone 01:01 PM
      • contains one
      • but isn't one by itself

Q4

Chair: Lorraine Constable

Scribe: Riki Merrick

Agenda:

Notes:

Quorum reached

  • May Virtual WGM will be US Eastern Time
  • Agenda Review
  • FHIR: Additional topic from Jose around dealing with orders where more than one person needs to sign that order using ServiceRequest
    • sometimes a supervisor needs to sign off – either because of authorization level (resident vs attending – in this case the real requrester is the attending) or because of funding (need approval from payor)
    • How to document in ServiceRequest – same resolution would be for MedicationRequest?
    • We would need more than one ServiceRequest.requester?
    • We can already capture the history using relevantHistory reference to provenance
    • We probably should add an extension?
    • A backbone for additionalRequester 0..* with role and reference to provider / person and move the person that starts the order from ServiceRequest.requester to this new extension, but is not authorized to actually submit the order – could also cover when a system creates a draft order
    • in V3 this would be the mood code of proposed
    • How to handle in FHIR workflow?
      • how to move the resources around between the people that need to sign the orders = use of task / provenance?
      • We will need provenance to anchor the documentation of the “chain of custody” and should consider creating an implementation guide around this part – or don’t do that in FHIR ;)
      • We have a PSS from 2014 on hold around developing on how to express the behavioral model for lab in FHIR = 1068 – we have no resources
      • This may overlap with the GenomX accelerator when they pick up result reporting...we should pick that up at that point
      • Lorraine may be able to get some VA contributions – bring back to the lab calls
    • Next Step:
      • Jose to write up some examples for the order entry use cases and mock up the involved FHIR resources and get feedback from FHIR-I and Pharmacy 
      •  find out when workflow discussions are meeting next
  • Flag Status = Observation status codes discussion
    • Mapping to FHIR: https://docs.google.com/spreadsheets/d/1RsA6SEYsjfrR6TbwY1JHBetrPyRED2RDzTa1jvHRvX0/edit#gid=0
    • V2 status codes are describing business statuses
      • (except maybe original posted as wrong)
    • while the observation-status codes in FHIR are describing the states of the documentation object
    • Comparing observation-status and diagnosticReport-status
    •  
      • Appended makes sense to be a the DiagnosticReport level – except when used in observations wth narrative results;
      • amended – when doc calls and provides new information about the patient (demographic) but the result does not change
      • we are trying to avoid crossmapping from OBX to diagnosticReport statuses
      • Appending is not officially limited to narrative / text based results, but it just makes sense
    • In CDA we replace the whole thing, so appended is not used there, so maybe we should not allow mapping – or just map it to amended, which is a broader concept
      • we are adding an extension to be able to preserve the original value, which we should be doing in this case, since we would be losing granularity with this mapping – see: https://jira.hl7.org/browse/FHIR-33270
    • Mapping for N = definition from v2: Not asked; used to affirmatively document that the observation identified in the OBX was not sought when the universal service ID in OBR-4 implies that it would be sought.
      • It means the lab didn’t try to get a result – compared to X, where the lab tried, but was unable to complete the test
      • Maybe we should update the display name to Not Attempted for this code?
      • For FHIR we should map to canceled and use the extension to preserve the distinction from v2 (https://jira.hl7.org/browse/FHIR-33270)
    • For more detailed changes to the mapping during this quarter see here: HL7 Concept Map_ ObservationStatus2022-01-19.xlsx

Thursday January 20, 2022

ANSI Anti-Trust Policy:

Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Q1

Chair: JD Nolen

Scribe: JD Nolen

Agenda:

Notes:

Quorum reached


FHIR-33076 - Getting issue details... STATUS - Persuasive with Mod Lorraine/Rob 15-1-3

Plan for Nutrition resources:

  • Motion to add examples and cleanup to get NutritionIntake and NutritionProduct to FMM1 by the R5 deadline.  Lorraine/Rob 15 - 0 - 2

Ballot Recon https://confluence.hl7.org/download/attachments/81015894/HL7_DAM_NUT_R3_D1_2021SEP_Amalgamated_20210922.xls?version=1&modificationDate=1642689965057&api=v2

Reviewed state of the State of Nutrition resources and handled Kathy's in-person request on the ballot. 


Q2 - Joint with II

Chair: JD Nolen

Scribe: Riki Merrick

Agenda:

  • DICOM structured reports

Notes:

Quorum reached

  • DICOM Structural Report to FHIR observation mapping IG

    • should this map to diagnosticReport? instead of observation

    • first step

      • looking at a single measurement template – used commonly in IHE AI results

      • at this point it is a group of observations, some of which may later be in a DiagnosticReport

    • IHE is doing an integration profile that will involve DiagnosticReport

    • we have a new resource for image collection that should be referenced from these observations

      • use case is measurement on images = observation) need to show which image(s) was/were used

      • Take a look at the new resource = https://build.fhir.org/imagingselection.html

        • Boundaries:

          • reference to this resource should come from observation

          • ImagingStudy is the view of images available for the patient – search result outcome , it does have the capability to reference a specific image, but it still expects it’s all the images available on that device – cannot distinguish regions, frame – didn’t want to merge into single resource to keep confusion by providers when they search for available images

          • could a documentReference reference an ImagingSelection?

            • Maybe – might need more research – we did look at using just documentReference, which didn’t work alone

              • when would you use documentReference before another FHIR resource?

                • Maybe if that FHIR resource defines the image group

              • Couldn’t documentReference point to a full series of images, frames or a region of an image? Because that may not be able to be accessible via documentReference:

              • Update the last sentence to SEE RECORDING @11:30 AM time slot

            • Should we consider using attachment in observation.value maybe?

              • no - that is not the right location

        • LINK to the mapping page: https://confluence.hl7.org/display/IMIN/DTID+1410+and+DTID+1411

          • considering using observation.DerivedFrom

            • linking to the overall report would not link here at observation level

            • this would link to the ImagingSelection resource, but is that the right business

            • the observation seems to be about is seen in the image identified in the ImagingSelection

        • ImagingSelection is always describing instances

          • do we need to include a reason for picking the images / regions selected?

            • May need to look at that for observation do not have this so far

            • may need something for CG (they are looking at creating GenomicStudy resource)

    • How to link ImagingSelection to observations

      • observation.subject?

        • Don’t think this should be used, as the image is still about the sample derived

      • observation.focus?

        • This is here to identify when you are making statements about something that does not have its own medical record (example is fetus)

        • That can reference ANY, so that should work

        • so using ImageSelection

      • observation.specimen

        • this is similar to digital slides?

        • In IHE DPIA profile we consider each new image a NEW specimen

        • but for MRI we don’t first create a specimen – but could we consider the image to be a specimen of some sort, because that is what we are doing

      • DICOM has a document URI, so you can identify different longitudinal observations of the same spot – tracking information – that would be linked to BodyStructure – see https://jira.hl7.org/browse/FHIR-33076

      • derivedFrom – do we need to add this to trace the image selection?

    • Goal of this IG is to get to May 2022 Connectathon and then ballot in Sep 2022

      • goal is to get this resource into the build as FMM1 for the R5 content deadline

  • Orders based imaging workflow is a project in the near future

  • Catalog project II is co-sponsor

    • so far have not looked at imaging requirements – still in the queue, but later

  • V2-FHIR mapping

    • II has done some review on a segment level

    • IHE DICOM mapping seems to be covered

    • IHE uses the OMI message – is that on the docket (assume yes, if they can provide the domain expertise)

  • Keep this joint for next WGM

  • Adminstrivia:

    • 1481 – V2-FHIR

      • next milestone May 2022

    • 1539 – Laboratory Model profiles = CIMI Lab Models

      • make next milestone Sep 2022 and ask Nathan about this one

    • 1541 – Vital Signs Profile = CIMI

      • next milestone May 2022

    • 1614 – Nutrition Care expanded scope to cover DAM and FHIR resources

      • still STU reconciling

      • next milestone May 2022

      • push end date to Sep 2022

    • 1686 – Cancer Pathology Reporting

      • still finishing STU reconciliation

      • next milestone May 2022

      • push end date to Sep 2022

    • 1700 – IHE SDC/eCC on FHIR

      • does not yet have TSC approval, had to go back to present to FHIR-I

      • next milestone May 2022

    • 1081 -FHIR resources for Nutrition Care

      • do we still need this, since we have 1614 that takes the DAM requirements and adds that into FHIR

      • Motion to archive this project and make sure that any products reference 1614 instead Riki, Lorraine, no further discussion, against: 0, abstain: 0, in favor: 10

    • 1115 – FHIR maintenance of OO resources

      • we added the transport resource under this projects

      • what status to pick for this? - multiple ballot levels seems to apply here

      • milestone date May 2022

    • 1068 – Lab Order Logical Model

      • this is currently on hold

      • Jose is prepping something here, so maybe we need to re-activate it when he brings things up

    • 1010 – Catalog

      • waiting for R5 to allow us to get the resources we need to point to in the IG, so adjust with R5

      • STU – preparing for ballot

      • next milestone date May 2022

    • 1067 – Lab Conceptual model

      • informative ballot reconciliation

      • next milestone May 2022

    • 1095 – EHR-S Funct Requirements for LRI

      • expired STU, so dings us twice (also for idle ballot)

      • request STU period extension

      • is mentioned in the ISA

      • last plan was to update to LRI latest release and do a peer review – but that may be quite a few changes.

Q3 

Chair: JD Nolen / Rob Hausam

Scribe: Riki Merrick

Agenda:

Notes:

Quorum reached

  • SET Change Request was approved during this call - 2021-02-25 Main - so the pulication depends on when the next version of v2 will be pulished - if partof v2+ or as V2.9.1 - discussions around this will be help in the V2 Management Group

  • Specimen

    • container

      • representing the container as a device

      • JD to update the examples to use device references

      • nesting containers ijra – FHIR-22823

      • will need to develop the vocabulary for container to use in device.type

        • currently using SNOMED CT

        • copy the values from SpecimenContainer (http://build.fhir.org/valueset-specimen-container-type.html)

          • need to look if these are in the device hierarchy in SCT – yes they all have parent = container, which is in device hierarchy :)

          • should make sure some of the device.type list includes some of these – can we do that under this tracker? we think yes

        • we definitely need to do this in the examples

    • V2 change requests for SET profile

      • was approved https://confluence.hl7.org/display/OO/2021-02-25+Main in this tracker V2-25257

      • next steps is when to publish – in a v2.9.1 or when V2+ will come out

        • plan is to go into the next publication, if there is other content that needs to get published, then include in v2.9.1

        • Riki to add to V2 Management Agenda to request publication at the first possible moment

  • Scheduling of remaining quarters

    • JD can be in Q1 all the time, Rob H may be available, Ralf may be there

    • Q2 Rob H will try to be there, too

      • most important topic from FHIR-I is to resolve how to handle deprecated elements

        • exanples:

          • observation.bodystructure = FHIR-34894

          • multiple specimen/single observation = FHIR-34002

      • R5 plan

  • No CIMI representation, so not discussed CIMI FHIR Lab profiles

  • Brainstorming about the different lab initiatives and how they relate to each other

Q4 - Joint with CIMI

Chair: JD Nolen

Scribe: Riki Merrick

Agenda:

  • Update on CIMI projects:

    • 1539 – Laboratory Model profiles = CIMI Lab Models

    • 1541 – Vital Signs Profile = CIMI

Notes:

Quorum reached

  • Update on CIMI projects:

    • 1539 – Laboratory Model profiles = CIMI Lab Models

      • no published IG

      • do have FISH files

      • we are creating a top level parent model for a standard lab observation profiles based on US core

        • covering all CLIA elements

        • 7 or 8 children for the types of results

          • constrain value sets and units of measure depending on scale and property

          • does not include

            • pathology

            • microbiology

            • genomics

        • in STU had dictionary of the top 2000 – may do that again, but need to evaluate how to do that in R4/R5

    • 1541 – Vital Signs Profile = CIMI

      • link to the Vital Signs IG: http://build.fhir.org/ig/HL7/cimi-vital-signs/branches/master/index.html

        • ballot reconciliation has been completed - ballot spreadsheet was shared

        • had some issues with suppressing warnings, so migrated over to FISH

        • can now release STU 1 version

        • need to take to OO and FMG

        • and then convert to universal realm IG

      • Motion to complete reconciliation and upload to ballot desktop and request withdrawal of negatives – Nathan Davis, Riki Merrick, no further discussion, against:0, abstain: 0, in favor: 11

      • Next Steps:

        • share link to IG

        • Start publication request form – Nathan Davis to do

        • Vote on this next OO call 1/27/2022

  • Yes we are keeping this quarter Thursday Q4 with CIMI

  • Administrivia:

    • Calls next week?

      • Need to add on the main call and the Lab call to the conference call center for until the next WGM – Ralf to do

      • V2-FHIR is now only 1 call – Thursdays

Adjourned 3:49 PM CT

Friday January 21, 2022

ANSI Anti-Trust Policy:

Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Q1 - Joint with DEV / BRR / CQI

Chair:  JD Nolen

Scribe: Marti Velezis

Agenda and Notes:

Quorum reached

  • FHIR-33147 -  Linking ServiceRequest to ResearchStudy via Extension: researchStudy
    • Motion to OK the request on Service Request
    • Discussion: not all trial types need the extension
    • Rob Hausam/Andy Iverson  20- 0- 6
  • Device (DEV) 
    • DEV group is concerned about
      • Type 0..* was not previously accepted and specialization was created – that is all reversed now
      • Property 0..*  was changed?
      • Issues around BDP intersects are not fully understood by DEV group and implications on Devices 
        • This is in an effort to deal with the boundary products that may not be definitely the same across jurisdications
        • Also to align across the healthcare products – product pattern (to be discussed at Q3 Friday)
      • Communication between the groups has been an issue
        • There needs to be additional work on communication between the groups (utilizing meetings, listserves and/or zulip)
        • Major changes should be communicated between the group – if the changes are not acceptable then we need to evaluate options; we can minimize breaking changes but may not be able to completely avoid them.  
        • There are breaking changes with PHD IG and they want to update with R5, and would like to address the breaking changes currently introduced
    • DEV wants to create an additional resource for Communicating Device
      • Rob noted that this has been done for some other use cases - e.g., Immunization separate from medications
      • Several participants indicated that it may not be desirable to separate out communicating devices from all of the other devices.
      • Several suggestions for how to approach this issue around the changes that have been made to Device that are breaking for the PHD IG
        • A "communication protocol" resource could be created and referenced from Device to carve out the communication related elements/attributes
        • To revert some of the items (e.g., specialization) to their previous state
        • Next steps:
          • Conduct analysis of the options and discuss across the groups
          • HOLD all of the JIRA issues related to the changes (e.g., Device.type, Device.property.type and other narrative descriptions to Device.  Will revisit after the analysis and consensus on the accepted strategy for handing communicating devices.
            • HCP topics related to software (IEEE)
              • Scope and boundary sections for Device and DeviceDefinition
              • Device.type expand example value set with software/hardware context
              • Concerns with changes to Device/DeviceDefinition
            • FHIR-32567
    • May WGM Joint meeting with DEV will remain on Tuesday Q1

Device

  • HCP Topics on Device R5 Normative candidate, DeviceDefinition / DeviceMetric
    • Device and Device Definition Mappings
    • Should Device go Normative, and if so, which fields (TO BE DONE AFTER THE REST HAS BEEN RESOLVED).
    • Critical to Normative
      • Definition/Scope/Boundary
        • Device Scope-Boundary-Relationships  ---- HOLD for progress on other topics.
        • FHIR-32382 - Device Resource Scope and Usage and Boundaries and Relationships Clarification
        • FHIR-32277 - Update Boundaries and Relationship section prior to considering the content Normative
        • FHIR-32276 - Update the Device Scope and Usage text
        • FHIR-32408 - DeviceMetric resource listed as device related resource, but the Device resource does not reference it
        • FHIR-32681- Improve Device documentation for software use case

      • FHIR-31750 - Complement Valueset-identifier-type for Device identifiers 

        • Friday Q3 - need to address with other discussion topic for identifiers
      • Device.parent
        • FHIR-34310 - Device.parent should be (again) for hierarchical relation only  [Waiting for Change and QA]
      • Device.status [Discussed 01/21/22 (Q1) still pending resolution, see below]
        • FHIR-32557 -Is there a requirement that records be inactivated for devices that are disposed/destroyed/etc?
          • Refined the proposal.
          • Update: 11/01/21 - comment from Lloyd: Is it possible to have device records that are 'draft' - i.e. the record is at least partially in place but the device isn't ready for use yet?  I'm not clear that "not current" clearly covers that case.
          • Update: 01/21/22 
            • Discussion that the Device.status relates to the Device record status (and not the status of the Device itself)
            • Question about "draft" device record and whether or not that is rationale for "inactive" 
            • Do we still need "inactive" as a status on the Device record?  
            • Would we need to send a device record that is not current and/or is not appropriate for reference in new instances (as definition of inactive)?  If not, consider removal of "inactive" as a value.  Note this is a required value set if used.
            • A device record that is stored may have a status of inactive, but do we need FHIR to make that change to the record?  Is there a use case for it?
            • Needs further discussion 
      • Device.property.type  [HOLD until after discussion with DEV]
        • FHIR-32567 - Property.type needs a binding or examples
        • FHIR-32286 - Missing value set for Device.property.type

BiologicallyDerivedProduct

  • BDP should be up to date (see notes below) to finalize for R5 
  • We will review in HCP once the final changes are made
  • If there are any new issues to be included in R5, they should be submitted in time to be updated before the March deadlines.
  • See notes Kirt Schaper
    • FHIR-32999 - BiologicallyDerivedProduct example - Kirt will work on more complex example (visual diagram to show nesting), HOLD- Kirt are the comments the final version of the sample? 
    • FHIR-32992 - BiologicallyDerivedProduct example, HOLD - Kirt are the comments the final version of the sample?
    • FHIR-32993 - add collection procedure to BiologicallDerivedProduct.collection,  HOLD - waiting for response from Kirt
  • Reviewed status for other JIRA issues:
    • FHIR-31429 - add attribute where biologically derived product was transferred,  Handled by Transport Resource that was created, Remove from list 
    • FHIR-34298 - Update scope and usage, and the boundaries and relationships for BiologicallyDerivedProduct ASSIGNED TO JOHN D.L. NOLEN to QA and make sure all of the items were addressed.
    • FHIR-33078 - Finalize BiologicallyDerivedProduct resource proposal updates
      • Hans to trace back whether it was approved as the label indicates pending while the recollection is that FMG approved.
      • Pending changes to the resource - i.e., do last

Q2 - Joint with FHIR-I

Chair: JD Nolen

Scribe: Riki Merrick / Lorraine constable

Agenda:

  • DocRef stuff with Lloyd
    • FHIR-32584 - content.identifier seems like bad modelling TRIAGED
    • FHIR-32583 - content.format should be an extension RESOLVED - CHANGE REQUIRED
    • FHIR-32582 - sourcePatientInfo should be an extension TRIAGED
    • FHIR-32581 - Explain how DocumentReference.securityLabel relates to meta.security TRIAGED
    • FHIR-32580 - Drop facilityType and practiceSetting from DocumentReport TRIAGED
    • FHIR-32578 - Binding for Document type is too narrow TRIAGED
    • FHIR-32577 - Binding for Document category is too narrow TRIAGED
    • FHIR-32576 - Make DocumentReference.subject ANY TRIAGED
  • Status Flags
  • Multiple Specimens/Single Observation 
    • FHIR-34002 - Need to be able to specify multiple specimens for a single observation TRIAGED
  • How to handle deprecation of replaced elements in a normative resource 
    • FHIR-34894 - Add Observation.bodyStructure reference to BodyStructure SUBMITTED

Notes:

Quorum reached

Meeting was recorded - so we can go back and look for missing details

  • State of the state with FHIR:

    • what maturity levels are desired for resource for R5

    • R5 ballot in May 2022

      • updates can be made before ballot (ideally) or before publication

      • in FHIR-I we are using calls to apply trackers

      • deadline is March 15

        • include the approved changes for STU resources in text, if changes cannot be applied in time for the ballot

      • list of resources:

        • changes to normative – observation – see deprecation discussion

        • normative candidates:

          • documentReference

          • parts of device

        • move up levels:

          • BiologicallyDerivedProduct

          • nutrition

  • deprecation in normative resources

    • there is a reference to the deprecation process of elements in core FHIR – http://build.fhir.org/versions.html#deprecation

      • once elements have been marked as deprecated in ballot, can be withdrawn after 2 years

      • goal is to be fully backwards compatible, if possible – so if you can add the new element and the invariant would be better than a change in the datatype

    • FHIR-34894 - bodysite

      • will need to decide how we approach this

    • We have a challenge with increasing cardinality to reference specimen from observation – FHIR-34002

        • we could add a new element for mulitpleSpecimen and create invariant

        • add a new resource for specimenGroup (defined by enumerated members) and reference that in observation.specimen – which is allowed and not considered a breaking change

        • could we define a profile on group, but the tooling does not support this right now other than including an invariant that this resource needs to be conformant to that profile – don’t let tooling constraint define what you chose – we can deal with this one later, if needed

        • review ALL use cases where a collection of specimen may be needed and then decide if we can use group or need a new resource anyhow – for discussion on the specimen call next Monday

  • Llyod’s trackers

    • FHIR-32584 - content.identifier seems like bad modelling

      • documentReference can have multiple content, but they all have to be different rendering of the same content – they may or may not have different identifiers

        • if you are using documentRefernece to carry non-FHIR content like V3 based labresult pdf as 64encoded PLUS the CDA rendering – and both have their own identifier

          • in that case should use 2 documentReference resources

      • if you have multiple representations of the same content under the same identifier put them in documentReference.identifer

        • but we search on the identifier of documentRefernence or the identifier of the content

        • if 2 organizations create a documenReference for the same document, the content identifier should still be the same (exported CDA document for example) – should we then add an “indexIdentifer” to cover the 2 different documentReference identifiers

        • masterIdentifer originally was the business identifier of the blob (CDA)

        • https://build.fhir.org/search#token

        • MISSED SOME discussion – need to listen to the recording to add this in

      • Eliminate content.identifier and recommend any business identifier of the pointed to element should be using docRef.id – and we may add in identifierType to differentiate what the business identifier is for

        • what is the pain: it might tempt folks to do the same things two different ways:

          • different representations of the same thing - stick both into the same docRef and include the identifiers in content.identifier

          • or using 2 docRef entries – one for each identified object

      • discussed to the point where the group recorded a proposed disposition to eliminate the use of DocumentReference.content.identifer.

      • Also create a tracker to request MnM to create a new identifier type for DocumentUniqueId.  John Moerke to take back to IHE for review.

FHIR-32583  - content.format should be an extension

  • discussion - this is used for items such as CDA document template ids. Some content items have different format code between, eg CDA and FHIR.
  • What would this be for PDF? Would you simply not specify the content.format?  
  • Request from Lloyd - can we make this a uri?
    • John, they are not all URIs. The values are mostly URNs. In XDS, the element is a Codeable Concept.
  • Should this be 0..* coding | URI | canonical?
  • Suggest renaming from format to profile. Vote taken and recorded in Jira - motion passed.

Follow up on subsequent OO on FHIR calls - invite John Moerke and Lloyd McKenzie. John has conflict on the second and fourth Tuesday.

Q3 - Joint with PHARM/DEV/M&M

Chair: JD Nolen

Scribe: Ralf Herzog

Agenda:

  • Identifiers (UDI), product pattern, supply chain management, related search parameters

Initial Email:

There's 3 interwoven issues:
- some degree of consistency between the resources around how identifiers work in a supply chain management context  (complicated by UDI)
- however it's done, defining search parameters that can find common identifiers across all the 'product' resources (manufacturable)
- deciding whether the Product pattern should exist, and it should, who should own it and how tightly the applicable resources should follow it (and whether the resource+instance element is a pattern worth following, or it should be split per Device/DeviceDefinition - an incomplete split)

A terms of concrete suggestions, I was thinking about the following two possible approaches to be common across all those resources:

    • define a new Data Type "SupplyChainIdentifiers" or something that those resources have instead of simple 'identifier' that captures the kind of complexity the device identifier elements are getting at
    • make them all 0..* identifier, and define a section of the resource that clearly defines how (by both profile and pattern/logical model) how the various identifiers are presented. 

Follow-up emails

    • Product Pattern: 

      "if" we create a "product pattern" that it would follow the same approach as other patterns?  Meaning FHIR workflow creates the pattern based on various inputs, and then each resource needs to map their elements to the pattern or provide justification about why they won't use one of the pattern elements, etc.  

      to some degree, yes. Some 'patterns' are enforced ruthlessly, and we could choose to do that, but I expect that wouldn't be appropriate. Others are merely documenting differences. I suspect we'd want something in between here.

    • Search Parameters

> Does this search parameter issue only apply to the identifiers for Supply Chain products? 

well, we've already run into it and done something about it for other resources. if you look at  https://hl7.org/fhir/searchparameter-registry.html you'll see a set of 'common search parameters' that search across sets of resources. It would clearly be appropriate to have one for identifiers on this set of resources, though we do need to discuss the details 

  • FHIR-31750 - Complement Valueset-identifier-type for Device identifiers 
  • HCP topics 
    • Recalls - as it relates to the topics above and how to model in FHIR across resources
    • Overflow from Q1

Notes:

Quorum reached

  • Recalls - how to model it in FHIR.
    • Medication and supply side should work "similar"
    • implants are a special topic (need to recall "patients")
    • A tendency to an IG and profiles, not sure if a new resource is needed.
    • Resources which might work, but are not really fitting
      • Task
      • Communication
    • Goal is to harmonize the US/EU variantes on UDI 
    • If "destruction" is involved it might needs a new resource
    • There are major players involved:
      • Recall Authority (US: FDA, EU: MDR, UniMed, Manufacturer)
      • Clinical Documentation: (Surgical Staff, PCP, Clinic)
      • Recall Managers (Health Maintenance, patient/provider outreach)
      • inventory tracking (ERP/inventory Management System, inventory Availability, Substitutions, Order/re-order, accounting principles)
      • Inventory Analytics (Regulatory statistics, speed/efficiency)
    • Recall IG could be a "pattern", which would be implemented by different "product" IGs (implemented Devices, Medications, etc.)
    • Could be discussed in HCP, but the workload there is high.
    • Involved working groups could be:
      • Public health, pharmacy, OO (nutrition, devices)
  • MnM Meeting about Identifiers
    • a robust way to search 
    • there is a discrepancy for resources representing "stuff" to identify them
    • is there a pattern perspective for this?
      • servicerequest, devicerequest, ... ask for things to be done
      • which resources are affected by need to identify "stuff"?
    • code vs. identifier 
    • Identifier is a subset of FHIR-14766 - Getting issue details... STATUS - do we need to solve that also?
  • HCP Topics:
    • How to manage them? Needs to be discussed with the HCP "regulars".
  • FHIR-31750 - Getting issue details... STATUS
    • Will be taken back to catalog 
    • And afterwards to HCP


Q4

Chair: Riki Merrick

Scribe: Riki Merrick

Agenda:

  • LIVD/LAB topics (usual Friday stuff)
  • Administrivia (project review)

Notes:

Quorum reached

  • Recorded the call for note taking purposes
  • Lab Topics
    • Follow up on agenda item from Wed Q2 - at home testing:

    • LabOrder Conceptual Model

      • Lorraine not here

      • Need to finish the discussion around Status Flags and mapping from V2 to FHIR (discussion around business states vs. documentation states)

      • Marti had offered to help with diagrams – need to find the file (should be on-line) Lorraine Constable 

      • Also a topic for the Friday lab calls; maybe work on the diagrams at the same time as we are having the discussions

    • Goal for the next Friday lab call should be to schedule the different topics for the next couple of weeks

      • Andrea's email about US Core Lab FHIR examples:

In reviewing FHIR US Core in Jan 2022 ballot, I noticed the examples are missing basic/key info needed for real lab data.  One discussed on Specimen calls is Specimen info.  

I was a bit surprised by the response in that US Core does not reflect requirements for real world lab data as so many other IG/ballots reference/use/are based upon US Core.  

Realize due to resource constraints O&O hasn't taken a full review of lab examples to make sure all the needed data are contained there in, but aspects like reflexive tests are starting to be addressed.  

The other major aspect is in order to be used in the US, minimal CLIA requirements need to be met (which as we see with the V2 guides is not limited to the laboratory but extends to end users of lab data for some requirements)

I haven't been able to attend all meetings where this may have been discussed.  Is there additional insight/info either of you have.  Will the requirements be addressed elsewhere and US Core should be marked as NOT FOR USE in the US?  (That doesn't seem to pass the common sense test ;) )

The other aspect is as far as we know there aren't LISs in the US with FHIR functionality so production/real live data is in V2 currently.  In SHIELD and across vendors we know there's still a lot of lab data that is not LOINC encoded (i.e most all of pathology).  I suspect folks wanting to access the data in FHIR will use the V2 to FHIR transformations (assuming it's done correctly, with no omissions, mismaps, etc.).  If these data are the what folks are trying to search upon downstream and they lack LOINC, how would they even be able to use US Core when it lacks the lab test name (even though US Core allows for a LOINC code, which may or may not be the one for how the specific RBC result is reported, etc.)  

For example in Problem Concept Maps (my day job) we provide multiple LOINCs each for RBC, Hgb, Hct, as we all know they can be done manually, automated, reported with different units, etc.  All are considerations if you want a search to function correctly and retrieve all Hgbs, Hcts on a patient or for Clinical Quality Measures as Floyd asked about awhile ago.  Further if you are searching for CBC results, hopefully you can search by an order LOINC to get all the results/observations produced or search across all Hgbs (value set) to get all done whether individual order, CBC, H&H, etc.  

In short, there appears to be a significant disconnect with the FHIR needs with lab data in US Core.  Even if we start with the RBC result and get examples from V2 to model them in FHIR US Core so the example is accurate, it would be good for Fri O&O Lab calls. I'm not ready yet, but wanted to get your thoughts?

[FHIR-34907] Specimen Information for RBC Observation is Missing - Jira (hl7.org)   

[FHIR-34909] Discordant/Missing info in US Core lab examples - Jira (hl7.org)

      • ISA does not list CLIA – should it?
        • CLIA was written for paper, but it has the elements listed
        • LOI and LRI have those elements listed
        • We should submit all CLIA required element to UCSDI
          • USCDI V3 comment period is open until April 30, 2022- we need to look at the lab elements!
        • The FDA UDI requirement is listed in ISA, maybe we should add CLIA there to make folks more aware of what is a regulation for the lab side of the data exchange?
          • Add to ISA comments – comments open till MAY
          • Marti will take this to the FDA USCDI advisory committee
          • Goal of ISA is to provide federal agencies a place to learn what standards are there to be used
        • more topics for Friday calls!
  • Administrivia:
    • John D.L. Nolen  will add OO on FHIR calls back on
    • Marti uploaded the minutes for Q1 - thank you!
    • Marti updated the HCP page with the zoom cooridnates :)
    • HCP call on this Monday?
      • Will have it
      • JD will chair
      • Marti can prep debrief
    • For specimen call this Monday:
      • Discuss the multiple specimen reference
    • OO needs to cooridnate with PH WG on Recall topics (any kind of product) – find a set time (Marti Velezis  will send a reminder email)

Call adjourned 4:30 PM CT




1 Comment

  1. Nathan Davis

    Here is the link to the Vital Signs with Qualifying Elements IG, as requested from the Thursday Q3 ntoes.  http://build.fhir.org/ig/HL7/cimi-vital-signs/branches/master/index.html