Table of Contents

Monday

Q1

Chair: JD Nolen

Scribe: Riki Merrick

• Specimen tracking:
  • Alessandro is on the OO line – may need to reconfigure when we discuss this topic
• LIVD ballot reconciliation:
  • Spreadsheet: https://confluence.hl7.org/download/attachments/20021943/FHIR_IG_LIVD_R1_D2_2021JAN_consolidated.xls?api=v2
  • IG link: http://hl7.org/fhir/uv/livd/
  • Filter by Neg:
    • #6 = https://jira.hl7.org/browse/FHIR-30420:
      • Data mapping for test result mapping (code, name and code system)
      • Motion to find persuasive – Hans Buitendijk, Riki Merrick,
        • Compatible, substantive
        • Correction
        • no further discussion
        • against: 0, abstain: 1, in favor: 16
    • #7 = https://jira.hl7.org/browse/FHIR-30421 :
      • • Motion find persuasive with mod and change:
          • IVD Test Result to IVD Test;
          • IVD Result Value to IVD Coded Result Value
          • IVD Test Code Map to IVD Test Map
          • IVD Result Value Map to IVD Coded Result Value Map
        • 
        • Hans Buitendijk, Ralf Herzog
        • No further discussion
        • Against: 0, abstain: 1, in favor: 16
        • Also applies to # FHIR
    • #8 = https://jira.hl7.org/browse/FHIR-30422 :
      • How to handle when a device is used in multiple tests?
        • Looking at slide 14 in this deck: https://confluence.hl7.org/download/attachments/20021943/LIVD_FHIR_Mapping.pptx?api=v2
        • 
        • If we need to capture the detail of the ITC, then we need to have a different means to create the ITC from device definition for instrument platform (IP) and test kit (TK) than the parent, because you can ONLY have 1 parent (which sounds right)
        • may need an extension for device definition to describe something like partOf – from the smaller to the larger or the other way around? Or create a backbone element called configuration and then you could add a role to include partOf (pointing up) or include (pointing down)
          • Could make a LIVD IG extension (here would only need include – from ITC to IP or TK)
          • DeviceDefinition extension for R5
          • What can this point to
            • Only to deviceDefinition
          • Device catalog also needs going down = includes / has member
          • Would it also be needed in device? – discuss separately
          • Or create 2 extensions on called partOf and one hasMember
          • IP is constructed from multiple parts, but the same IP can also include different test kits – so should be able to go both ways
          • Reviewing the options:
            • Option1:
              • backbone on deviceDefintion. configuration (0..*)
                • Reference (1.1) to deviceDefintion
                • Type (1.1) coded – current values hasMember | partOf or other types that may be needed (for example for consumable – but this may be on the device)
              • Option1a:
                • backbone on deviceDefintion. configuration (0..*)
                  • Reference (1.*) to deviceDefintion
                  • Type (1.1) coded – current values hasMember | part of
                  • This would require some way to ensure folks have ONLY 1 hasMember or partOf and any other type you add in
                • Option 2:
                  • partOf 0..* reference deviceDefintion
                  • (if you want to go the other way, then you can use the FHIR infrastructure search differently to get the other way)
                • Option 3:
                  • hasMember 0..* reference deviceDefintion
                  • (if you want to go the other way, then you can use the FHIR infrastructure search differently to get the other way)
                • Option 4:
                  • partOf 0..* reference deviceDefintion
                  • hasMember 0..* reference deviceDefintion
                • Next step:
                  • Create some examples before we vote
                  • Compare to medicationKnowledge is doing something similar by using type and relationship, but they have no codes for the types yet

Q2

Chair: Hans Buitendijk

Scribe: Riki Merrick

• Agenda review:
  • Update from the subgroups
  • Cancer Electronic Pathology Reporting Project
    • ( PSS-1682 - HL7 FHIR® Implementation Guide: Cancer Electronic Pathology Reporting IN REVIEW  with a draft of the PSS  Document)
    • PSS-1683 - IHE SDC/eCC on FHIR IN REVIEW  - related FHIR-IG for converting IHE SDC into FHIR

• CIMI/CQI – (not on)/CDS
• Subgroup updates
  • CIMI:
    • Vital signs IG
      • Block votes were sent in a while ago – Hans will forward to the list
        • Aim for Friday Q1 or Q2 for vote
      • CIMI future
        • Have created the models for several use cases
        • Support of implementation is hard when we are using resources owned by different
        • Also have MnM as a WG – so may need to work in conjunction with that WG and others interested in that work
        • Looking for how CIMI can be useful to advance HL7 work in general and also help with projects that have energy and need for specific elements
          • University of UT and Intermountain are supporting data models as the basis for the data representations
        • Given the space CIMI is looking at and the resources used
          • Primary focus should be the topics coming up through the flow and then identify patterns and send that to CIMI
        • Coordination between IGs:
          • example adverseEvent is spread across multiple IGs just in BRR
          • Support cross project working group
          • re-factoring IGs with more re-usable elements
          • registries of profiles is not currently working well – find something better
          • maybe create principles that can be followed for creating re-usable elements across IGs, as there are so many different IGs are being worked on
          • Example: US core has made some assumptions with Must Support elements, so should US core create profiles without Must support and then build additional use case specific profiles, where Must Support is used?
          • Conformance has been working on binding and value sets and interpreting data absent values
          • When the value set binding is the only difference between profiles – how can we work on that?
          • Can we make valueset binding dynamic for specific resource instances – based on domains
            • Similar to lab IGs valueset companion guide?
            • Conditionality of the binding based on a resource element – then you still have the explosion for value sets
            • Maybe filtering an overarching valueset for elements that need to be used based on x?
            • We will need some input with FHIR-I?
              • To make sure the tooling will work on that
            • Can we create some tooling that can at least flag when profiles already exist and highlight all the differences between them
              • Bob D will start a group to work on that – email if interested: rdieterle@enablecare.us
            • Think about and bring thoughts for the Thursday Q4
              • Put thoughts in zulip or also email Stan
  • CDS:
    • Results from connectathon for Opioid IG
      • Artifacts to implement CDC OPIOD prescribing guidelines
      • Urine drug testing was piloted in several locations
        • Patient View can display the card that shows that this was not done
        • May want to send back a service request for patients, when that has not been done
        • Use activityDefinition to construct a service request
        • Chose a generic SNOMED CT code for high level urine test, but that didn’t work
      • Are folks building local mappings to catalogs?
        • We have FHIR IG for catalog in ballot http://hl7.org/fhir/uv/order-catalog/2020Sep/ – so making the catalog available may be
        • In the US using v2 for actual ordering
        • Jan2020 balloted the LIVD catalog (includes coded result value mapping from device manufacturer mapping to use in the LIS mapping that then can be used to create the catalog: http://hl7.org/fhir/uv/livd/2021Jan/
• Cancer Pathology Reporting:
  • https://jira.hl7.org/browse/PSS-1682
    • Explanation
      • Convey information in 6 most used CAP eCCs and migrate that into FHIR resources
      • From LIS to EHR-s in a provider office or hospital
      • Could use the same from LIS to cancer registry – this is the current focus of CDC work so far
      • https://www.cap.org/laboratory-improvement/proficiency-testing/cap-ecc
        • There is another project to convert IHE SDC into FHIR observations and diagnosticReport = https://jira.hl7.org/browse/PSS-1683
          • This is more appropriate to do for the pathology report
          • eCC is not a APSR, you need more for pathology reports
          • We have IHE profile APSR (CDA based) – generic profile
        • Have already tested in connectathons to use the IHE SDC to FHIR conversions
        • Flavor of a pathology report
        • Synoptic reporting has been translated into FHIR questionnaire
    • For PSS-1683: this should for sure be OO sponsored
    • For PSS-1682 – further specification for specific eCCs – but there should be feedback between 1682 as well
    • HL7 Germany has a project to translate IHE APSR into FHIR
      • Purpose?
        • To transmit content between the different universities for clinical care and research
        • So that also includes the workflow around that
      • Sponsoring WG for 1682?
        • OO also desired as sponsor. Specifically we also want to work closely with PSS-1683, so we should have both projects
      • What is the relationship to codex?
        • CodeX has a cancer use case and the team is working on that as well to provide good collaboration – CDC sponsoring that work
      • Other WGs:
        • PH wanted to be interested party
        • CIC
        • CIMI
        • CodeX
      • Proposal is accepted and then the ticket moved forward to the PSS
        • https://confluence.hl7.org/pages/viewpage.action?pageId=97479425
    • Motion for OO to be primary sponsor and work out with CIC to figure out the details – Riki Merrick Wendy Blumenthal, no further discussion, against: 0, abstain: 1, in favor: 50
    • Motion to have OO be the primary sponsor on PSS-1683 Riki Merrick, Alex Goel, no further discussion, against: 0, abstain: 1, in favor: 50
      • PSS-1683 = David Jones as main contact - Riki will reach out to coordinate with the project team

Q3

Chair: Hans Buitendijk/JD Nolen

Scribe: Riki Merrick

• V2+ Updates:
  • Had a for comment ballot in January: https://v2plus.hl7.org/2021Jan/index.html
  • It is not part of FHIR, but we are using FHIR structure definitions as the source of truth
  • There should be full blown editors not spreadsheets, so the editors do not need to interact with github
  • Goal is to support point specific updates, when needed –in addition to the yearly editions
  • Naming convention will have the name V2+_<month><YYYY> - and dot releases for errata, but If there is a NEW release then it would be the publication month
  • V2+ reconciliation call is Friday 1/29 9 – 10 AM ET = 6-7 AM ET
  • More info here:  Document
• LIVD ballot reconciliation
  • Pick back up #8 = https://jira.hl7.org/browse/FHIR-30422
    • Reviewing the options
      • Option 1 – this is similar for the medicationKnowledge
      • configuration 0..*
      • configuration.type 1..1  hasMember | partOf
      • configuration.reference 1..1 Reference(DeviceDefinition)
      • Subtype….
      • Option 1a – not really an optionDeviceDefinition.configuration .*
      • configuration.type 1..1  hasMember | partOf | XYZ
      • configuration.reference 1..* Reference(DeviceDefinition)
      • Option 2 – many instruments have modules that can be used on other platforms with the same tests, so will need partOf
      • partOf 0..*  Reference(DeviceDefinition)
      • And search the opposite if needed in the rare case
      • Option 3 – Francois had examples from the device catalog
      • hasMember 0…* Reference(DeviceDefinition)
      • And search the opposite if needed in the rare case
      • Option 4
      • partOf 0..*  Reference(DeviceDefinition)
      • hasMember 0…* Reference(DeviceDefinition)
      • XYZ 0…* Reference(DeviceDefinition)
    • Essentially option 1 and option 4 are just different ways of representing the same use cases for the current extension – no subtypes – and also that is the way it is done in medicationKnowledge and it will future proof, so that we are not stuck like we are with observation, when deviceDefintion becomes normative and then a change is needed
      • Motion to use Option 1 with the two types of hasMember and partOf (not subtype yet)
        • Hans Buitendijk, Riki Merrick
        • Further discussion:
          • have ruled out 2 and 3, because we already have examples for both
          • In option 4 if more things are needed the structure of the data would have to change, while in option 1 it is a logic change and that allows me to add on other descriptions of the relationship between the referenced resources – this allows future growth
          • What is the relationship between partOf and hasMember are those inverse of each other?
            • Is there a possibility of partOf definition where the other way it would not come out as hasMember?
              • Ralf thinks in device that might happen, but not fir sure
            • How would you decide which one to use, if they are the inverse?
              • Allows to use the common way an organization always wants to use- but these ways may be different between organizations or even for. use cases
              • Since FHIR does not allow for defining relationships as inverse of each other, then having just one solution, either option 2 or option 3
            • If you allow the flexibility you will have to support both ways of searching, so will this be good – for each IG you would decide on one of these approaches.
            • Would this be possible to expand to larger community discussion?
              • FHIR-I = we have Thursday Q2what about MnM?
            • PartOf is being used in MANY places, hasMember is only used in observation
            • Did not want to make deviceDefinition.parent MustSupport
            • hasMember – should we rename this to hasPart so the relationship is clearer that it is the inverse relationship to part of
            • would we need to be able to point in both directions for one instance (I am the top of all parts, I am the smallest part and part of many things, I am a middle part of the larger thing made of out of many parts: car with a motor that has one or multiple bolts, bolt that sis in several places of the car or even in a different
            • Mover has to leave – we will table until Thursday Q2
  • #9 – in example issuer for the UDI is in incorrect spot – FDA should be in jurisdiction
  • #10 – same error as described in #9 in the XML format
  • #11- same error as described in #9 in the JSON format
  • #12 – same error as described in #9 in the
  • #13 - same error as described in #9
    • Motion to find persuasive with mod – in the comment we have the OID for jurisdiction – per the used UDI = https://accessgudid.nlm.nih.gov/devices/00380740003746  (it was created by GS1) Riki Merrick, Ralf Herzog – no further discussion, against: 0, abstain: 0, in favor: 8
    • This was in person, so will need to check, if Mitra is ok with this
  • Have 4 negatives from Riki and Ralf
  • Have separate session for Marti’s session
  • PA not meeting next quarter – need to decide what to talk about
    • We will cancel – most will go to Vocab for Gender harmony

Q4 - CANCELED!

Tuesday

Q1

Chair : JD Nolen 

Scribe: shared

Specimen Update

• JD summarized the current state of the work around Task and Movement/transport Data
• Shared a spreadsheet comparing elements. Few gaps <get Spread sheet from JD>
• Conversation to continue Thursday Q2 with FHIR-I and Thursday Q3 with PA

IHE SET

• Alessandro walked through the current state of the SET recommendations
• Speadsheet: 
• ppt: 
• Change request: 
• Plan for a decision vote on an upcoming OO call

Q2

Chair: JD Nolen

Scribe: Riki Merrick

• Group updates
  • CG
    • IG for Genomic Reporting: http://build.fhir.org/ig/HL7/genomics-reporting/
      • Based on DiagnosticReport, observation in STU2 during the May 2021 ballot cycle
      • MolecularSequence resource is part of it: http://build.fhir.org/molecularsequence.html
        • Will probably refactor the “everything bag as a flattened structure” before getting to M2
    • OO
    • Movement of things
      • Specimen and patient – working with PA on that part
      • Use of task resource, or create a new resource to track (FHIR-I discussion)
      • Based on IHE SET profile for the specimen transport
      • Asking to move vs documenting the move activity as well as observations around the move
    • Specimen resource compared to DICOM
      • Identifying container as devices
    • LIVD in January 2021 ballot – workspace: https://confluence.hl7.org/display/OO/LIVD+Implementation+Guide+Draft
      • Tracking multiple parts of devices – modeling the tests
      • Should keep an eye out on how to describe the test that was done in CG they are using planDefinition
    • Device catalog now that lab catalog has been published
    • Working with BRR to expand observation to cover a study (not just on a patient)
• Cancer reporting project
  • PSS-1163 – has a simplifier IG that is using observation
  • PSS-1162 is mapping to mCODE
    • Using eCC as the basis to the describe the most common forms of cancer
    • We don’t want to create a profile for each question in the eCC at the level of answer type rather than content specific
    • Some questions in eCCs are not observations, but procedures or conditions
  • Sequence resource will need to get clearly defined the boundaries comparing to the observation profile
  • If we want to profile specific observations we should need to do it in
  • Why would we use observationDefintion over an observation profile
    • observationDefintion defines the kind of test
    • observation is the instance of the test
  • Project proposal PSS-1162 has been transformed into PSS: https://jira.hl7.org/browse/PSS-1688
    • Ballot cycle will be Sept 2021 – does not look like that is in the jira form – Lorraine will inform Josh that the dates are not visible easily
    • Motion for OO to approve sponsoring this project with addition of ballot plans into the description until this is in the form (it is in the form under product info, just not easily visible): Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 2, in favor: 25
• DiagnosticReport vs composition topic
• 
• Is there a way to add a way to structure the references – using a backbone element for that
• The DiagnosticReport is the content – the same observations can then be organized into sections using composition, so each observation is just there once
• All observations should be in DiagnosticReport that all need to be in the composition A? – do we want to enforce that?
  • Example of a final report with external content that is being pulled together (composition B)
• Should all content of the composition be reflected in the diagnosticReport?
  • There is danger that if the composition does not chose all the content of the diagnosticReport, then we may accidentally drop data
  • Would we create a separate diagnosticReport for the final pathology report
    • If you need signature, then need the diagnosticReport otherwise could pull in collection of other data
  • Should we use presentedForm to point to composition (vs use of pdf representation)?
    • presentedForm is what the viewer saw, so slightly different
    • also pdf and composition are very different things
  • Prefer a new attribute to reference the composition to represent the structure of the raw data
    • section.text is a great place for narrative that would have to live on all the associated Observations either in note or in extensions
  • Composition can only do grouping and ordinal relationships, but it cannot define tables
    • In CDA we can apply stylesheets for presentation of the XML
    • In composition is the text entry string or markdown so we can do something similar?
      • Narrative is div (xhtml)
    • if you use Composition.section.text how would that be part of the diagnostcReport - if that is the source of truth?
      • It wouldn’t be represented on the report except for being linked out (eg, as one of DR.[Composition-ref].section.text)
      • the source of truth at the moment is a pdf. we are extracting some features.
      • leaving the rest in the represented form
      • but i understand the potential problem.
      • Narrative section in DR would also help
• DiagnosticReport and nesting of DiagnosticReport vs DiagnosticReport pointing to composition for structure
• Motion to add attribute DiagnosticReport.composition references composition 0..1 for the purpose of providing structure to the content of the DiagnosticReport (only contains content of the DiagnosticReport – for instance to order the section of a anatomic pathology structured report. Hans, Dan, further discussion: name ok?- let’s start with that, against: 0, abstain: 4, in favor: 21
  • Updated FHIR-29258
• PC is requesting OO representation Thursday Q1, when they discuss symptopns with CIMI
• CG topics for later discussion:
  • Other entry management: should the service request reflect the same code in
  • Grouper observation resource to create this or should that be done using DiagnosticReport instead

Q3

Chair: Lorraine Constable

Scribe: Riki Merrick

• SOGI topic
  • CA senator reached out to PH WG Co-Chairs to discuss how to
  • Had a conversation with the senator and also have received a formal letter and there is discussion with PAC – on agenda for tomorrow
  • A lot of the question is NOT that this should be collected, it is more around where should it be collected and how it should be communicate it
  • Through COIVD timeline more information has been requested to be added to the lab reporting – which includes reporting this to the lab via order so it can ten go to PH
  • Should there be other venues to send to PH without impacting the worklflow for diagnostic or treatment
  • Also other information needed to better get the contextual understanding of health disparity
  • Healthcare system interaction is ONLY with the testing at first potentially and then comes up to PH follow up
  • In Europe there may be issues with exchanging this kind of information as that is protected information
    • So may need to be adjusted in the base but further defined in for the realm specific
  • CSTE is also looking at this issue as well and there are other states also collecting this information, CA’s letter just bumped it up to the top at HL7, though we have had the Gender Harmony project since
  • Rob’s slides around Gender Harmony project  Presentation
    • Had participation from NCPDP and DICOM and other SDOs
    • Slide 4
    • Why is datatype string: comment: so it is not just a value
      • This allows to capture the context for use of this – for example: “only use in work situation” – ideally this could be more structured ultimately, but this will be a big step to give
    • Did not yet discuss masking of this data, but need to, since it is sensitive
    • Recorded sex or gender should be what is used when healthcare interacts with the patient
    • Minimum valuesets
      • Gender identity – more can be included, but would have to be mapped to one of these minimum set
      • Sex for clinical use (SFCU)
        • This would be required binding
        • Could more than one be valid at the same time?
          • That would be covered by complex
        • This needs to take all data available in the system in addition to the data provided by the patient
        • Frank: these values don’t make sense in light of his research across many existing code systems: https://wiki.hl7.de/index.php?title=Geschlecht
          • we can have: administrative, biological, genetic, Hormonal, transgender, transsexual, genital, gender Transformation, gender identity, sexual orientation, different rules for recording
          • everything is a different Statement/observation
        • If complex is being sent to the lab that is not helpful – the lab would need to tell the lab, what values need to be used for reference ranges:
          • We had the discussion around using SFCU values of male and female in specific contexts rather than using complex
      • HRSA requirement:
      • Gender identity is different category than sex assigned at birth which is what HRSA uses
      • Sex assigned at birth is problematic
        • And some state allow you to change sex assigned at birth
        • In this model Sex assigned at birth is the first value of Recorded Sex or Gender
      • Can look at organ inventory to decide Administrative Gender
      • Gender Identity is ALWAYS patient reported
      • https://www.lgbtqiahealtheducation.org/wp-content/uploads/2018/03/TFIE-47_Updates-2020-to-Ready-Set-Go-publication_6.29.20.pdf
    • Alignment into FHIR patient: slides 7 and 8
    • How does this align with V2 and CDA?
      • More help needed and this should be a NEW project to adjust in ALL product families
      • Co-sponsors: PA, FM, InM, SD, FHIR-I, OO (for ELR), Patient Empowerment
      • Can we get Sexual Orientation into this? – no need to make separate project – this seems to fit more into the Social Determinants for health also – so include
      • For UDI we create a pattern document use the same approach here, too?
    • Meetings are currently Mondays 4 PM ET every other week – next is Feb 8
    • How does that work for PH – should this end up in Vital Statistics IGs also?
      • That would be US specific
    • Why slice sex at birth and not others?
      • Need to be clear about what you are recording explicitly here (link to the observation that was used to decide this)
      • It would be best not to model this as an attribute on patient – It should be modeled as an observation that is referenced by the resource you need to
    • Fenway Institute referenced ONC rules for documenting gender identity
    • Male/Female/Transgender Male to Female/Transgender Female to male etc.
    • Gender Identity should ALWAYS be visible – so the patient is properly addressed (that is what the minimum set provides) and it should not force them to include the transgender when that is NOT
      • Just for some context, our (Epic's) support for SfCU (which we've had for years) is a dynamically calculated property that uses an algorithm that checks things like OB history, organ inventory, and demographics.
  • Ballot report:
    • 200+ comments
    • Have about 30 negatives
  • How do we communicate SFCU to the IVDs (existing) when that information is needed for reference ranges?
    • Currently have only PID-8 as the field for that
    • Should have a separate field for that – or send as OBX, can already do that – BUT the IVDs do not use that at the moment
    • In the future make a rule to look for the OBX that has the SFCU information FIRST
    • Vocab listserve will send the meeting invites for this project
    • Confluence page for the project: http://hl7.me/GHP
• Next Steps:
  • Rob to get the project proposal out ASAP to get PSS approval by the deadline for Sept 2021 ballot
  • Are we going to issue guidance around how to report these data now?
    • Using ELR guidance to use AOEs, because the standard can support that
    • This is really not an HL7 decision, but for the folks that house the data and where it really should live in the long run
    • Should we work with HL7’s policy arm? – already on the agenda for Q3 tomorrow
  • Bring this up to the projects that work on pandemic prepardeness - what worked well / what didnt'?
  • If we had more integration with the orders in the beginning we would have been better of
  • Collect all the examples that we know we have from this pandemic and bring this back as a lesson – would be good to collect across the world to show what works: maybe at least a confluence page to start collecting - PH will discuss later this week.
    • There is an ONC and HL7 collaborative to assess the state of PH interoperability- Altarum is working on that

Q4

Chair: Hans Buitendijk

Scribe: Riki Merrick

• LIVD ballot reconciliation
  • Copy the votes from #9 – 13 in to the spreadsheet and review with Marti – ok as voted
  • #14: we created deviceDefintion.type as must support in order to describe the test-kit and the instrument and then instrument test combination- should include that in the example – check with  Ed to better understand which type is the correct one for the Abbott example and update he example with the proper type; based on deviceDefintion structure discussion support it for another example
    • Motion to find persuasive with mod to update existing example Riki Merrick, Marti Velezis, no further discussion, against:0, abstain: 1 in favor: 7
    • The cardinality is 0..1, so it’s ok to not have the deviceDefintion.type in all examples
    • Motion to reopen #14: Marti, Ralf, no further discussion, against:0, abstain: 1 in favor: 7
    • Motion to add example to show use of deviceDefintion.type – since must support show how it’s used, in existing examples shows the cardinality 0..1 Ralf Herzog, Marti Velizis – further discussion: should this now be persuasive? Yes
  • #15: same as FHIR-30420
  • #16: device vendor (term used in IICC spreadsheet) is mapped to device manufacturer in the mappings – Motion to add (aka device manufacturer) to the first occurrence of device vendor Marti Velezis / Riki Merrick: further discussion: does the vendor always manufactures the equipment? Not always – if we are not using device vendor in IICC, then we should change it to device manufacturer on this page; vendor is not the same as manufacturer functionally  - let’s change the motion to update the text on the introduction page clarifying that manufacturer and vendor are used interchangeably while outside the scope of LIVD there may be a need to distinguish these two terms – no further discussion, against: 0, abstain: 1, in favor: 7
  • #17: move result value mapping from “out of scope” to “in scope – Ralf Herzog, Riki Merrick, no further discussion, against:0, abstain: 0 in favor: 8
  • #18: Motion to update the text based on the updates agreed to in the diagram (FHIR-30421) Riki Merrick, Ralf Herzog , no further discussion, against:0, abstain: 0 in favor: 8
  • #19: Need to make sure we ensure that this part of the LIVD only applies to the result values, that are non-numeric results (wanted to make sure folks include string results here, but non-numeric result values could also mean longer text or images; use coded results
    • What is this for?
      • This is to help the laboratorian to help map the local test code to the IVD test code and the LOINC – this narrows the LOINC selection based on the knowledge from the manufacturer
    • Motion to use “…nor the respective IVD coded result values” Ralf Herzog, Rob Hausam, no further discussion, against:0, abstain: 1 in favor: 6
    • #20: Motion to use …”as well as corresponding Result Value Code to LOINC answer code and/or SNOMED, as available and needed Riki Merrick, Ralf Herzog, no further discussion, against:0, abstain: 0 in favor: 7
  • #22: the LOINC codes that are appropriate in the context of the LOINC parts that are known to the vendor – it does not mean all applicable LOINCs should be provided
    • Or the LOINC Answer codes, when addressing result value mappings
    • Keep appropriate – no need to explain how to actually find what is appropriate
    • Ralf Herzog, Riki Merrick, no further discussion, against:0, abstain: 1 in favor: 7
  • #25: if a fixed string value is used it is effectively a code – a test cannot be coded – non-quantitative test could have coded results, in the summary page remove the term non-quantitative before ,encoded – Hans will add as newly discovered item and fix the grammar to read: “.. used for the test result.” Motion to use the final language in the spreadsheet Rob Hausam, Riki Merrick, no further discussion, against:0, abstain: 0 in favor: 7

Wednesday

Q1

Chair:  Ralf Herzog

Scribe:  David Burgess

Catalog Update and related Jira trackers

• Slide presentation by Francois Macary:
  • 
  • Presentation Notes:
    • Slide 2:  Discussed project purpose and deliverables.
      • Oder Catalog FHIR IG link:  https://build.fhir.org/ig/HL7/fhir-order-catalog/ 
      • All related links ca be found at:  Catalog 
    • Slide 3:  Diagram of how Order Catalog can be used by:
      • Laboratory Compendium
      • Medication Formulary
      • Medical Devices
      • Order Set Library
    • Slide 4:  Status Update on FHIR IG:
      • Lab Compendium previously balloted and considered complete.
      • Group is working on preparing Device and Medication with the aim to balloting in an upcoming 2021 ballot.
    • Slide 5:  Definitional Resources contribute too via the Catalog Project:
      • Quick overview of listed resources and discuss which one still had Jira request that need to be addressed.
    • Slide 6:  CatalogEntry Resource background and status
      • Current Order Catalog IG has been built without referencing CatalogEntry. There is a Jira item 30632 to have CatalogEntry Removed.
      • Jose Costa Teixeira recommended we table the discussion to remove CatalogEntry until tomorrow Q1 when Simone Heckmann will be able to discuss how “Prescribable Health Apps” may be looking to leverage CatalogEntry. Ralf did reach out to Simone to verify that she does plan to attend Q1 meeting tomorrow.
• Discussion of open Jira items related to Order Catalog
  • Group reviewed and discussed three tracker items. We discussed how these items were related to one another, and to what extent the requested changes to Device should or shouldn’t be tightly coupled to changes to DeviceDefinition. Below are the Jira trackers with a description of the request, followed by the current status after our discussions.
    • FHIR-25036
      
      • Tracker request: Request to remove Device.manufacturere and replace with another term indicating who is providing the device, and not necessarily the “manufacturer”.
      • Discussion: This seemed to align with Jira tracker 29727 which was very similar, but was directed to DeviceDefinition instead of Device, and was a request for a new field as opposed to removing manufacturer. For certain regulatory issues it was determined that manufacturer need to remain in Device and DeviceDefinition. Some discussion was had on whether or not the newly added field should be “typed” to allow for different kinds organizational identifiers. The decision was to not add type field.
      • Resolution:  Motion to add Device.distributor as follows:
        • distributor 0..1 BackboneElement  – A distributor of the model of device, other than the manufacturer
          • name 0..1 string – the distributor's human-readable name
          • organizationReference 0..1 Reference(Organization) –  The distributor as an Organization resource
        • To clarify, we are leaving Device.manufacturer as-is.
        • Motioned by Lorraine Constable / Francois Macary : 11-0-1
    • FHIR-29727
      
      • Tracker request: Add backbone element “distributor” to DeviceDefinition
      • Discussion: We looked at how this related to the other Jira tracker listed here. This tracker influenced how we chose to address Device in Jira tracker 25036, but this tracker had been superseded by Jira tracker 30503.
      • Resolution: Francois Macary chose to withdraw this tracker in light of proceeding with Jira tracker 30503.
    • FHIR-30503
      
      • Tracker request: Add backbone element of packaging that includes identifier, type, count, distributor, distributor.name, distributor.organizationReference, and packaging (to allow for nesting packages within packages)
      • Discussion: With the presence of distributor within packaging there was no longer the need to add distributor as described in Jira ticket 29727. We did discuss the idea of creating a “Package” resource and referencing that here. The idea of a Package resource had come up previously for PackageProductDefinition which has a backbone element of “package”, but until now there was not a use case to justify breaking that out as a separate resource.
      • Resolution: This item remains open, but we will discuss it further this week, to see if we can come to a resolution.

Q2

Chair: JD Nolen

Scribe: Riki Merrick

With II

• Diagnostic Report/Composition - Final Decision:
  • This image is missing the lines between the DiagnosticReport to composition to represent DiagnosticReport.composition
  • Add element in DiagnosticReport that can reference the composition to order the observations in the diagnosticReport = https://jira.hl7.org/browse/FHIR-29258
    • Does DiagnosticReport need ability to incorporate another diagnosticReport?
      • Rob looked back at up to STU2, and has not found evidence that it ever did that
    • How to you deal with mark up in composition to be able to do with the = Jira number??
  • Does composition have to have ALL observations that are in the DiagnosticReport ?
    • Yes, when it is the referenced composition – (composition A in the slide) to avoid that the doctor misses an observation
    • No, when you are using a composition to group several resources together – for example to highlight the clinically important genes in a genomics report
  • Group updates
    • II
      • Plan is to review the V2-to FHIR mappings as to how well that work for II
      • Plan to make an IG for extracting DICOM elements from APSR
        • Mapping DICOM Structural report element to FHIR observations
          • There is an IHE project for AI use
          • Could also be input for DiagnosticReport
          • And also needed for AP reports, where needed
        • Having some issues with encounter based workflow and the order workflow in FHIR and how they are aligned
          • Tracking images that originate during encounters is imaging problem
          • Inside the lab workflow you may have to re-scan a slide, when the digitization didn’t work, but for general pathology you always have the overall workflow order
            • Maybe dipstick or pregnancy test in OBGYN visit
          • When you have results that need to be attached to the patient visit?
            • Example – picture of a wound in ED
          • In IHE we have created the encounter number to track the visit that we want to link to
          • Can you model this as a procedure and then link to a diagnosticReport from there?
            • serviceRequest orders it
            • procedure documents the procedure = doing = may not be recorded
            • imagingStudy is the output
          • If you want to get paid would have to have a serviceRequest (to show the authorization) or be part of a procedure – maybe document just in a note
          • Documenting a rash or a wound – that would be separate – ask patientcare?
    • OO
      • II co-sponsored projects:
        • 1010 – Order service interface
        • http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1010
        • 1453 - http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1453
          • The IHE whitepaper has been published, need
          • ADD link to whitepaper and to the mapping
          • Need to figure out what to do for the mapping- do we publish?
        • Same joint session same time
  • LIVD ballot reconciliation
    • JD will add his changes into the posted spreadsheet – if there are others besides Marti’s in person
    • #27: duplicate to FHIR-30420
    • #29: Add Marti to Acknowledgment: Motion to find persuasive Ralf Herzog / Riki Merrick, no further discussion, against: 0, abstain: 0, in favor: 13
    • #34 = FHIR-30232
      • On the Summary page adjust to use LOINC answer code when talking about the coding of result value – clarification, non-substantive Motion to find persuasive Riki Merrick/ Ralf Herzog, further discussion: why are we not identifying that these results are qualitative? It is true that it is for encoded qualitative result, but the point here is to make sure we are using LOINC answer code when we are talking about coded result values versus LOINC codes, when we are talking about the performed test, against: 0, abstain: 0, in favor: 12
    • #36 = FHIR-30234 Motion to find persuasive Riki Merrick/ Ralf Herzog, no further discussion, against: 0, abstain: 0, in favor: 12
    • #42 = FHIR-30242: Motion to find persuasive Riki Merrick/ Ralf Herzog, no further discussion, against: 0, abstain: 0, in favor: 12
    • #46 = FHIR-30284:
      • Was looking at this page: https://confluence.hl7.org/display/OO/Proposed+HHS+ELR+Submission+Guidance+using+HL7+v2+Messages Didn’t think that we needed to add EUA, as that is specific to what we are using in the LIVD file
      • add a new device type to represent a manual test; do we need to also identify this as a home test kit, i.e. a test where the specimen is collected at home and the test is also performed at home – and do we need to differentiate that from other manual tests? Or should this be represented as just a test kit?
      • Instrument platform can be used with different test kits, can this be further defined as POC / lab or home
      • For test kit could further differentiate into instrument based and manual?
      • EUA would be more appropriate for the UDI issuer and jurisdiction maybe?
      • If we add, we should add good definitions for all elements in that code table to provide better guidance on when to pick which code
      • Next step we need to get FDA input on what the definitions for these 4 elements are (how to pick which to use):
        • Testkit / reagent
        • Instrument platform
        • Manual kit

Q3

Chair: Ralf Herzog

Scribe: Ralf Herzog

• Nutrition:
  • Bigger update since Becky did not attend the last WGMs
    • Two new FHIR R5 resources:
      • Nutrition intake which is comparable to medication adminstration and Medication usage. Only one Nutrition resource because for nutrition the differenation between adminstration and usage is not needed
      • Nutrition product is comparable to the plain medication resource
    • Both are approved for FHIR R5.
    • Still work needed for aropriate examples and value sets
  • Start  to focusing on updating the domain analysis model since the old one (started ~2011 and published in 2017) was pureley focused on nutrition order. MCC care plan project asked if nutrition order could be used in outpatient setting, more like a diet prescription or diet suggestion from a documentation standpoint of view.
• Patient Care:
  • Ongoing discussions around the boundary between Observations and Conditions. This boundary is documented in the resource definitions, but there seem to be Implementers who don't agree (or maybe don't read) and so do not follow the guidance. 
    
    • CIMI's Pain Model uses conditon to model pain which seems to be appropriate since the level of detail recorded for the pain model and the fact that it does persist supports the usage of condition.
    • LOGICA COVID IG uses conditions to record covid related symptoms which are simple "yes/no", "present/absent" sort of symptoms which should be observations while the LOGICA COVID IG believe them to be conditions. Discussion about this continues tomorrow Q1.

Q4

CIMI updates on projects slides 

Thursday

Q1

Chair: JD Nolen

Scribe: Riki Merrick

Joint with BRR/HCD

• Substance
  • Resource ownership between OO and BRR – still listing OO, we were trying to locate the earlier vote
  • Motion for OO to turn over the maintenance of substance effective this WGM to BRR – Lorraine, Hugh, no further discussion, againt:0, abstain: 2, in favor: 24
  • Action Items:
    • Change the ownership in the FHIR build
    • Migrate any OPEN jira tickets from OO to BRR (looks like there are only 3)
    • Hugh Glover  to create a jira ticket for documentation sake of this vote and assign this to FMG  Done    FHIR-30796 - Getting issue details... STATUS
  • Jose has a set of resources around workflow and he will try to attend BRR calls, and maybe have someone attend the workflow calls to make sure the workflows are not too limited
  • Maturity level FMM2 is that ok
    • May need to review the requirements to decide where this resource is
  • We have not made a lot of changes lately
• SPL project status update = http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1339
  • This is for R9 has milestone date Jan 2018 (waiting for TSC approval) but listed as active project?
  • R8 is the current active version
  • This should be closed – Smita should clean this up
  • We are now using FHIR for this
• There is currently a system under development in Germany where CatalogEntry is used for a directory of prescribable HealthApps = https://simplifier.net/trustedhealthapps/~resources?category=Profile – this also has IG (it is in German)
  • Discuss and vote on FHIR-30632- Remove CatalogEntry resource?
    • This never got FMG approval – we tried for 2 years
    • There is no replacement for this resource
    • This resource was a linkage resource to conveniently assemble catalogs
    • For lab we have used planDefinition and other definitional resources pointing to each other
    • So we would need the use case to better understand what is in this
      • Apps are modeled as deviceDefinition
      • Have healthcare apps – covered under statutory insurance – one catalog
      • Organizations that provide quality assessment for the apps – another catalog
      • Each catalog is referencing the same deviceDefinition in these catalogs
      • This allowed us to identify the status for this particular catalog
      • We can add period of effective
      • Problem:
        • Used an extension for deviceDefinition reference
        • Could not create a reverse linkage to show which catalog each deviceDefinition belongs to
      • Need to link the charge code for the deviceDefintion in the specific context
        • In lab catalog we used chargeItemDefinition resource for billing codes
        • ChargeItem supports multiple prices
      • In the current design catalogs we have made them of ONLY of the same thing, but have not
        • Build: https://build.fhir.org/ig/HL7/fhir-order-catalog/
        • Confluence page: https://confluence.hl7.org/display/OO/Catalog
        • We need to ensure to have more references in the definitional resources to be able to link to all the types that you have to link to
      • Simone will check with implementers, will probably stick with catalogEntry
      • How should we handle this?
        • It will never be used, since FMG Is not for it
        • Should we put we a DO NOT USE note on it?
        • Add a note that says: There is intent to remove this in R5 – how would this impact implementers – make comments
        • Add a reference to the catalog IG from that resource
      • Motion to find persuasive with mod: do not remove, and add note at the top of the resource: There is intent to remove this in R5 – how would this impact implementers – make comments and add link to the catalog IG so folks have the idea that they can review what is in the current build – Francois, Freida Hall, no further discussion, against: 0, abstain: 0, in favor: 29
    • Product harmonization ("parking lot issues" )
      • FHIR-29800 – wording changes may have some option to get in for R4B
        • Ballot opens on Feb18, official content deadline is not listed on FHIR calendar
        • Reviewed the document – will keep in parking lot
      • Related to FHIR-29697
        • This should not be used but if we don’t have a good alternative to do this kind of thing instead
      • Check on overlapping medication resources – that is on BRR side
      • Need to look at ProductDefinition
      • Can we identify the specific parking lot issues?
        • Where would we have these discussions / is there a confluence page?
      • We have 2 issues:
        • Extending existing resources for non-clinical uses
        • changes that need to wait for R5
      • Trigger was a zulip: @Hugh ADD LINK?
      • Melva wanted a project for work around MedicationKnowledge
      • Action Item:
        • Hugh Glover  will create a confluence page to collect ALL items in the parking lot
        • Hugh Glover  will share doodle to find a better call time for a focused group to work on this before bringing them back to main BRR group
      • Device dispense (Jose)
        • Get file from Jose Costa-Teixeira
        • Requirements
          • Durable medical equipment IG
          • need to know which pharmacy
          • In Germany may want to be able to track which patient started using which app
        • category
          • In the medicationDispense this attribute is really describing the category of the medication rather than the dispense
          • This could be useful for the apps use case
        • Need to sort out the boundary to DeviceUseStatement
        • Who dispensed the device
          • performer backbone that has.function and actor – this is following event patterns
          • or should this be modeled using practitioner (name and address to get this) and practitionerRole (this has the credentials)– but maybe just use practitionerRole and force folks to check reference outside
            • should this be re-designed for R5?
          • PreparedDate
          • DeliveryDate
          • Receiver
            • How should we deal with the transport AFTER dispense – we have been having discussions around transport tracking for specimen/patient etc – this would need to go here
            • Need input from the DME team
            • Leave these here to just record it happened
          • For applications you differentiate when you can get the app, vs when it was installed
          • This discussion will be on the healthcare product calls Mondays 4 PM ET
          • Next step:
            • Jose Costa-Teixeira  to draft the resource in the new build working of the resource
• packaging (FHIR-30503) vs. PackagedProductDefinition
  • Could we model this after manufacturedItem definitions
    • We need to be able to describe how a device can be packaged
    • Should be part of the SPL in FHIR discussion
    • Need to be included in the PackagedProductDefintion
  • IHE working group that deals with supply chain and catalog work has defined a model similar to the nesting of the manufacturedItem resources
  • This is also similar to medicationKnowledge resource also
  • Action Item:
    • Set up a joint call for discussion of this topic
• Keep this session for next WGM – yes
• DeviceUseStatement Resource Proposal – not discussed

Q2

Chair: JD Nolen

Scribe: Lorraine Constable

Messages from FMG

Build process changes:

• During Connectathon Grahame put out an announcement that the means to commit has changed - no longer using spreadsheets. Place to look for how to commit for the new process. Documentation after R4B, not before. When you update to receive the newest release of core. Build will re-generate spreadsheet on local, make changes, run build - build will merge into the xml. 
• Link to the discussion in zulip:  https://chat.fhir.org/#narrow/stream/179165-committers/topic/retooling.20the.20core.20build/near/223352713
• Some format changes to make it easier to go back and forth
• Maintenance of code sets and value sets is via the xml. Can use UTG to manage these
• List resources that contain all the example instances

Comment from Hans - build process limits the number of people who can contribute to the standard.

Lloyd: A friendly GUI editor has a limited user base and would be custom to HL7. HL7 creating tool suites that are used only by HL7 is long term sustainable. May evolve to editing resources using FHIR short hand and there may be pretty editing support there. 

Tooling is available for logical models and profiles. Forge may be able to edit resources - Ward will follow up

Jose: Move to standard structure definitions will enable tooling innovations

Lloyd: now that the source of truth is standard structure definition xml that opens the door to other approaches.

Jose: does the tooling allow json? Lloyd - right now expect that it is xml only due to the way the tooling is working. Right now it is simpler for the tooling to be in one format. 

New process - watch for issues and holler if there are problems. (that is, post on zulip)

Reason for doing this is It will be much more straightforward to merge changes and technical corrections

Release timelines

• R4B target opening February 19
  • unclear whether we will hit that 
  • Grahame has validation and merge issues
  • What is the content deadline? Grahame will be wanting to migrate content as soon as possible
  • Scope is technical corrections and defining new extensions, adding additional targets to resources. Trying hard to not have to look at anything other than the Medication and EBM. May need to figure out how we actually capture those changes in the summary page. Need to land that wording soon to figure out how to represent.
  • Limiting scope on what you can comment on
  • Current plan is to use R4B as a Jira ballot test
  • aim for publishing Q2 2021
• For comment ballot on R5 
  • will be May cycle
  • Final content deadline is March 30 - QA start
  • Objective is principally around changes to normative content as well as any net new that are normative candidates
  • will be used to confirm that these are ready for normative and have flagged any elements that may be out of scope for normative
• STU / Normative September cycle
  • content deadline will be approximately mid July
  • QA deadline not landed yet
  • expectation is two ballots - may have all the normative content into one
  • expect a follow up normative ballot Nov/Dec to deal with substantive changes from the first one
  • Expect publishing Q2 2022

Note - OO and BR&R will send a ticket to document transfer of maintenance responsibility for Substance from OO to BR&R

Device Definition profile questions:

• Discussion regarding DeviceDefinition configuration ( FHIR-30422 - DeviceDefinition configuration TRIAGED ) 
  We have examples for hasMember and partOf 
  
  1. Option:
     • DeviceDefinition.configuration 0..*
       • DeviceDefinition.configuration.type 1..1 hasMember | partOf | ...
       • DeviceDefinition.configuration.reference 1..1 Reference(DeviceDefinition)
  2. Option:
     • DeviceDefinition.partOf 0..* Reference(DeviceDefinition)
  3. Option
     • DeviceDefinition.hasMember 0..* Reference(DeviceDefinition)
  4. Option:
     • DeviceDefinition.hasMember 0..* Reference(DeviceDefinition)
     • DeviceDefinition.partOf 0..* Reference(DeviceDefinition)

How do we do the grouping of device definitions - when to use hasMember vs partOf

Device definition is an entity rather than an action. Question what is the semantic distinction between hasMember and partOf. Do you point up or down? We don't want more than one way to navigate the hierarchy

The thing that exists second should point to the first. Other consideration is that the many points to the one

These design considerations are in conflict in this case.

On the definition side there are two types of relationships

• this component is always in this parent
• this sub-device can be in any of these parents

The second is the most common occurrence 

Where is the decision about where the device can appear? Is that at the larger composition level? 

Have both situations. eg test kits defined after that fact that the original composition does not know about. and you may recombine existing subcomponents into something new

Instrument / test kit relationships are the specific problem that LIVD is addressing

Where will maintenance of the relationships occur? There is also the notion of substitute parts. Where does that that live? This is an additional question to how we handle the member relations

Can have subcomponents that can be used in a device, and device that is designed for specific subcomponents.

This may be a case where we need the ability to point both ways. We would then need to be really clear about explaining when a user should use which relationship type

In that case, Option 1 may be better to give flexibility to be able to express the nuance of the type of relationship. Software devices may be easier to define with this approach

Lloyd reminds option 1 with a more specific code set (a component of, replacement part, etc). Whether you go with Preferred or Extensible will depend on what is achievable. Lloyd would lean to Codeable Concept to allow for text and translations. That will allow you to add explanation of exactly how this referenced thing fits

Take recommendation to LIVD team for decision regarding details. suggest DeviceDefinition.configuration.device so don't end up with configuration.reference.reference. Question about whether the reference could be something other than a device.

Jose - would this be extensible to constraint or different types of relations. Eg cleaning or sterilization methods?

FHIR Task with History (related to Sample Tracking)

We have been back and forth with PA whether we need a new resource or can extend Task to handle this. 

For our purposes, Task can handle most of this. There is however, a need to handle both the request and the event, including the history/current state of what happened(s) during the move.

Lloyd: Task does not represent an authorization. Task lets you represent an action against the authorization. ServiceRequest is likely to be the authorization. Explore whether it makes sense for this to be yet one more scope for ServiceRequest. This may be the place that these. Documentation of what happened in the world is typically not task. Get pairs like Referral / Procedure. 

Pairs like person was moved from site A to B. Would not expect this to live in Task. Current state of transition might be in Task. There might be a degree of information in the Event itself. Task is not normally expected to be part of the formal health record. There are some situations where you could use Procedure / Observation, etc. Question is do you need to capture the event resource - do you need a long term record, then you need some other event resource.

Link to the record of what occurred is not mandatory, but want the ability. Have a resource with a location A, that gets updated to location B.

question, how is information about transport typically captured in real systems? Do the nuance about what happened in the transition captured in a detailed record about what happened 

Started drafting Transport Event for this purpose

Jose - would like to link this to Supply Delivery. Would you have detailed linked events. May have a partOf relationship. Jose suggests we need TransportRequest and TransportEvent. would these replay SupplyRequest and Supply Delivery

Lloyd - may not have a one to one correspondence. The request might be ServiceRequest. If it makes sense that these requests are in similar systems as referrals, etc. if it is distinctly different, then may need a specific resource.

Jose - can one of Supply Request or Supply Delivery be a profile of something else.

Lloyd - you could have a transport that is a part of several different things. He sees transport as distinct from making a drug or product available.

Jose - need to be clear about the boundary between transport and delivery

Ralf - we came up with this from OO from the point of view of Specimen Event Tracking. IHE SET is just tracking the record of what happened to the specimen. 

Jose - delivery may or may not have request, but may have several components of events that happened as it moved.

Summary - task can be used to handle actioning an authorization (maybe ServiceRequest). If we need to track the details formally about what happened, then need an event resource, likely a new one. It is challenging to distinguish between different kinds of requests in existing systems.

Q3

Joint session with PA on Task/Transport resource. Minutes here

Q4

Chair: JD Nolen

Scribe: Riki Merrick

• Administrivia:
  • WG health:
    • Mission and Charter from 2019
    • SWAT from 2017
  • Expired STUs / Unpublished Ballots etc:
    • Unpublished ballots = 2
      • Diet nutrition on V2 nutrition orders – has been published in standards grid: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=317 and Pub request: https://confluence.hl7.org/pages/viewpage.action?pageId=91987595
      • LIVD – just re-balloted, so should be coming out soon
    • Idle ballots = 3
      • Functional Profile for LRI = this one was published http://www.hl7.org/implement/standards/product_brief.cfm?product_id=433
      • SDC FHIR IG SDC – I have R1 = has been published = http://www.hl7.org/implement/standards/product_brief.cfm?product_id=417 and R2 published in the standard grid http://www.hl7.org/implement/standards/product_brief.cfm?product_id=451
      • Ordering Service Interface
        • We agreed to make text updates in Sydney WGM
        • Lorraine to complete
        • Hans posted the recon package shortly after the WGM
    • Expired STUs = 3:
      • SDC FHIR IG SDC – I have R1 D2 with 2 expiration dates
      • Functional Profile for LRI

• Project insight review
  • #902 – V3 Nutrition Orders Clinical messages
    • Status = publication
    • Type = informative
    • Next milestone Sep 2025
  • #1009 – V3 Food Preferences
    • Status = publication
    • Type = informative
    • Next milestone = Sep 2025
  • #1010 – Ordering Service
    • Status = publication
    • Type = informative
    • Next milestone = May 2021
    • End date = May 2023
    • This covers catalog FHR work = which is STU to normative
    • Also balloting the model, which is informative
  • #1067 – Lab Order Conceptual Spec R2
    • Status = done with ballot – needs publication
    • Type = informative
    • Next milestone = May 2021
  • #1095 – Functional Requirements for LRI doc
    • Status = publication - expired
    • Type = STU
    • Next milestone = May2021
    • Motion to ballot in May 2021 as informative – NIB due Feb 12, 2021 – Riki Merrick, Lorraine Constable, further discussion: , against; 0, abstain: 0, in favor: 8
  • #1335 – LIVD
    • Status = STU reconcile
    • Type = STU to normative
    • Next milestone = May 2021
  • #1370 – Transplant, Transfusion and Graft on FHIR
    • Status = active
    • Type = STU to normative
    • Next milestone = May 2021
    • Note to check with Bob Milius – JD will do
  • #1496 – DME
    • Status = STU reconciliation
    • Type = STU to normative
    • Next milestone = May 2021
    • Notes: Had some block votes open, but no major changes anticipated to need to reballot
  • #1539 – Lab Model Ballots
    • Status = active
    • Type = normative?
    • Next milestone = May 2021
    • Note : CIMI project – we need to follow up with Susan, Nathan Stan on the status Lorraine to do; also consider the creation of patterns here instead of specific profiles
  • #1541 – Vial Signs
    • No permission to edit
    • Status = STU reconcile
    • Type = STU to normative
    • Next milestone = make it May2021
    • Notes; need to ask Dave to let us make changes
    • Also have asked about dealing with project proposals
  • #1634 – AOE Cross Paradigm
    • Status = active
    • Type = informative
    • Next milestone = Sep 2021
    • Make end date = May2023
    • Notes: Need to add the FHIR datatypes (can look at the FHIR mapping for that) and need to also find someone to do the CDA portion
  • #1672 – V3 CMET – Clinical Statement
    • Status = approaching expiration
    • Type = Normative
    • Next milestone = May 2021
    • Note: Ask Rik and SD Co-Chairs if we should drop it – Hans to follow up
    • Need answer before Feb 12, in case we need a NIB for re-affirmation
      • CDA uses Clinical statement, but not the CMETs
      • Rik not aware of need for these
      • Can we ballot as informative instead – withdrawn is ANSI term – for HL7 it should be called retired, still in grid, but not by default
      • Motion to submit NIB for Withdrawl Ballot Hans Buitendijk, Rob Hausam, no further discussion, against:0, abstain: 0, in favor: 6
    • #1068 – Lab Order Logical Model R1
      • Status = STU accepting comments – moved to hold
      • Type = STU to normative
      • Next milestone = May2023
      • Notes: We think this is a useful project and we used the LOI guide to make the R1 IG – would need to
      • Motion to put on hold and move milestone date out 2 years – Lorraine Constable, Riki Merrick, no further discussion: , against; 0, abstain: 0, in favor: 8
    • #1238 – UDI IG
      • Status = informative reconcile
      • Type = Informative
      • Next milestone = May2021
      • Notes: IG needs more work – pattern (DAM) will be
    • #1453 – IHE DICOM elements to specimen DAM mapping
      • Status = informative
      • Type = STU to normative
      • Next milestone = May2021
      • Make end date = Sept2022
      • Notes: Riki to check if the IHE whitepaper has these published – if not, figure out how to publish and what updates are needed for the specimen DAM
    • #1481 – V2-FHIR
      • Status = STU reconcile
      • Type = STU to normative
      • Next milestone = Sep2021
      • Notes: plan is to re-ballot in May2021 – should have better idea where we are in Sep
    • #1294 – LRI
      • Status = STU - reconcile
      • Type = STU to normative
      • Next milestone = May2021
      • Notes: Did ballot in Sept – need to finish recon and publish
• Call schedules for the next cycle - all listed in ET
  • Main Call weekly Thursdays 1 - 2 PM
  • Specimen weekly Mondays 2 -3 PM
  • Healthcare Product weekly Mondays 3 - 4 PM
  • V2-FHIR weekly Mondays 1 - 2 PM
  • V2-FHIR weekly Tuesdays 11 AM - 12 PM
  • DME weekly Mondays 12 -1 PM
  • Catalog weekly Fridays 12 - 1 PM
  • LIVD/Lab weekly Fridays 1 -2 PM
  • Nuturition bi-monthly  Wednesdays 2 - 3 PM Lorraine to find out start date from Becky
  • Placeholder for OO on FHIR weekly Tuesdays 2 - 3 PM (will decide EVERY preceding main call)
• OO resources in FHIR
  • availabel technicnal editors are Rob Hausam and Jose Teixera
  • R4B changes needed are not so many
    • Rob has a few for vocab and OO for this

Friday

Qminus1

See V2 Management Notes: 2021-01-29 v2MG call

Q0

Chair: Rob Hausam

Scribe: Riki Merrick

Question around length for PID-3.1 in ELR, LRI and LOI

ELR R1 has a length restriction for PID-3.1 of 15 characters, but several of the labs we work with have PID-3.1 values that are longer than that AND they may not be the ones that assign those patient IDs.

One of the PHAs is not able to accommodate longer patient IDs than 15 (and technically they are correct, as ELR R1 didn’t document the 15 as conformance length but rather as length, making it normative max length.

Here is the current state:

In ELR R1 NIST tool:

This is what is listed in LRI NIST tool:

In LRI pdf there is only reference to the ST datatype, which length is 199

From the underlying V2.5.1 base CX datatype (which is what was used in NIST tool):

However, both ELR R1 and LRI reference use of conformance length:

ELRR1:

 and  and in 2.7 referenced section: 

LRI:

 and in 2.7 referenced sections:   

Making me think the intent was to have these be conformance lengths

Feedback from the group:

• LabCorp supports 20
• Freida will check with Quest
• ONC has been having the listening session around patient identifier – ADD LINK????
• suggest AOE with LOINC for this = https://loinc.org/76435-7/

Next Steps:

• Bring this to PA, since this for PID as well
• STU comment on LRI and LOI – to include guidance on what to do when receiving a PID-3.1 that is too long
• Also bring up to IHE – since IHE LAW profile has PID-3.1 limit of 20 – also for SPM-2

Q1

Chair: Hans Buitendijk

Scribe: Riki Merrick

Joint with HCD/BRR

• CIMI Block Vote.  Those marked in bold red have been pulled.

Pull requests from Eric and Mark highlighted.

Motion to accept the block vote minus pulls (.  Susan Matney, Nathan Davis

Discussion: 

• One of the pulled items referenced an item by Mrocca around extensions = FHIR-29252 should also have been pulled (by Eric) and these are also related FHIR-2953 and FHIR-29251
• missing some other pulled items: FHIR-29273, FHIR-29283, FHIR-29287, FHIR-29088, FHIR-29103, – marking these now in BOLD RED
• what about the items around the magic values: also pull FHIR-29085 and FHIR-29306 

All pulls now in red italic bold.

Against: 0 Abstain: 8; In Favor: 19

• SPL/CPM into FHIR Update
  • IBM/FDA (note - not all FDA Centers/regulated products are included when referencing FDA below) project proof of concept
  • Providing high level framework that can support receiving both SPL and FHIR submission
  • BRR project, approved by FMG
    • Ballot HL7 IG for mappings from current SPL into FHIR resources
      • Have some profiles
      • Have underlying model
      • Broad framework of the IG
      • Some images for use cases etc
      • Need to still figure out how best to display the mappings
        • have used ALTOVA tool for performing the mapping and also in a spreadsheet
        • from SPL to FHIR and back
        • creates XML and javascript
        • have tried to use the structureMap resource, but that gives only table, looking for graphical representation
      • Use case is medicinal product submissions
        • medicinalProductDefinition
        • Organizations for the entities needed for registration as part of the product submission
      • LINK: http://build.fhir.org/ig/HL7/fhir-spl/branches/main/index.html
      • Goal: connectathon in Jan 2022 and ballot in May2022
    • Is there a dependency on OO resource for the FHIR version of this?
      • So far only BRR resources
      • Once we look at devices, may need OO
    • Mappings?
      • So far all mappings are on structural elements – so far FHIR has only example bindings, so not yet needed to look at concept maps
      • How do you take a complex mapping from one spec to another without overwhelming the users with the complexities
        • Tech folks
        • Implantation side users
        • This shows SPL elements on the left and FHIR resources on the right
        • 
    • How does this related to the GUDID?
    • Only relates to devices - and there is no active project for the GUDID SPL implementation to transition to FHIR
    • Trying to stay out of the architecture
      • The diagrams have FDA listed as example of regulator and FDA documents were used to describe the data elements
      • This is not replacing the existing mechanism, just proof of concept of how to use FHIR in addition
    • This is not taking the SPL RMIM classes and mapping that to FHIR, just reducing the scope to user requirements (FDA)
      • CPM is supposed to be the equalizer that should be used to support mappings from all the model classes
      • Not sure we will get to a full CPM/SPL mappings to FHIR< but the mappings are generic enough to use them as a springboard – these are NOT FDA specific (even if we are using the FDA known names)
    • In the future we should review the naming of the IG – it is misleading
    • Can Jean share the mapping spreadsheet?
    • Premature, as those are still being confirmed
    • • We will set up a project call /confluence page for this and will share there
    • Please share any tooling used for mapping representations
  • CPM future?
    • For existing work product as reference
    • So far there is no need for CPM updates
    • Unclear if we will need it once migration to FHIR is completed, but may need to reference for that work in the future
    • Decision: Will keep CPM parked and wait for SPL on FHIR for input on product resource updates.

• packaging (FHIR-30503) vs. PackagedProductDefinition
  • DeviceDefinition looks from a different level at the packaging than what is used in PackagedProductDefinition
  • 
  • Goal is to see, if we can come up with a representation of packaging that can be used from both directions
    • Product has a 3 layer level (on the left)
    • Device is a combination of the top layer = product that can be listed in the catalog also a physical entity
  • Aligning definition and names for elements in both resources
  • Working in the IHE catalog of products came up with a simpler approach
    • Create a better representation of that model, so that we can see them for comparison
  • NEXT STEP:
    • Set up the call and share the constructs needed for the common representation before the call and set up a confluence page for collecting the documentation
    • Francois from the catalog work has several images as well to share

• DeviceUseStatement Resource Proposal
  • Link to the proposal: DeviceUsage FHIR Resource Proposal 
  • Link to the confluence page shared: Hans Buitendijk
  • Comparing to MedicationUseStatement vs MedicationAdministration
  • Phillips has been generating use cases related to device assignment and device usage: - slides: 
    • Terms slide:
      • Assigned seems to relate more to DeviceDispense
      • Device use on – related to observation and procedures
      • Device use by more related to the DeviceUseStatemtns
      • Unassigned – TBD
        • From whose perspective is this unassigned (by the manufacturer?)
      • Discussion:
        • Inventory of devices as well as clinical
        • If a wheelchair is provided to a person, are there other activities in play that show the patient has obtained that wheelchair and is using it vs a patient tells you they are using a wheelchair, or an observation by a doc that a patient is sitting in a wheelchair – we want to provide guidance around all of these use cases
        • We are trying to collect the landscape around this in order to provide the answers
    • Use case 1 slide
    • #4 – turn the direction of assignment around, so it is the device assigned to the patient
    • Do you want to record the act of assignment – DeviceDispense use for that
    • Patient reports on use of a device – DeviceUseStatement
  • Continue discussion on Healthcare Product call Mondays 3 -4 PM ET

END OF WGM