OO WGM 202305 - Attendance Log                                                                         

OO WGM 202305 - Agenda

Meeting Minutes

Monday, May 8, 2023

Notes

Monday - Q1


Did not meet due to WGM+ meetings

Monday - Q2

Chair: Hans Buitendijk

Scribe: Riki Merrick

Agenda:

Review WGM agenda topics for the week

Discuss the observation.category related Jiras:

Pt Care invited OO reps (3) - Lorraine represented OO Co-Chairs

Notes:

  • FHIR-14677
    • Observation is used for a lot of different things – so it has challenges
      • Don’t want to grant access to everything that can be sent as observation
        • Observation.category can help with that (for search also helpful)
        • When would we need to use security label vs something like category – or even specific observation.code?
        • While EHR-s is using FHIR as façade, but underlying dB is not, so want to use those more native structures for access
        • Attribute-based access control can use any attribute, but it would be helpful to use the meta security, so you don’t need to know which attribute is appropriate for the resource of choice
        • The security use is a convenient use for this attribute, but not explicitly
      • What is the set that everyone supports that we can use?
        • Current vocab binding: https://build.fhir.org/valueset-observation-category.html
        • Maybe create the valueset for specific purposes
        • The attribute is 0..*, so we can provide guidance for different purposes
        • We already are doing this with Vital Signs
          • We have created a profile on observation and the category is defined there
      • Can we define a pattern for category purposes?
        • For vendor specific categories – this may be local code system being used here
        • For access, that security can use these
        • Vital Signs
        • SDOH
          • They defined their own code system for this
        • There may be different code systems for the different slices at the moment, it would be helpful to use the same code system
        • Argonaut IG is considering working on finer grained codes for this attribute SMARTv2 granular access control
          • Security prefers OO is involved
        • Can we amalgamate all codes so far described for this attribute?
          • OO would be the owner of this code system
          • Maybe create the high level terms only and make each use case use their as additional occurrence per the IG, or create a hierarchical code system
            • This might mean we need to make that vocab required
          • When you are using an HL7 published IG then must use the HL7 defined codes at minimum
          • Allow layering of the category, so that you can have more detail for some use cases
            • If we have detail each jurisdiction can narrow what to be in or out
      • Use existing codes where they are applicable – or at least look at existing ontologies to help us with the finding of the hierarchy
      • When implementing the ClinicalNotes IG categorizing notes originally were based on LOINCs (in observation.code) – they eventually made a value set that everyone needed to support (least common denominator)
      • Gola should be for purposes of usability, not just for security / access control
      • Build the high level concepts for each purpose / IG / use case and then allow each use case to create the detailed list
      • If OO owns this, we should orchestrate the SMEs from the different use cases to accommodate the
        • Similar problems with these resources:
          • DiagnosticReport
          • ServiceRequest
          • Medication
          • Condition
      • Defining boundaries
        • We are not talking about the specific scenario of sharing HIV results with the patient
        • Also not identifying if this is related to metal health – this should be covered with meta-security tag and consent resources
        • This is trying to help inform the security labeling service what type of
          • Privacy and consent would cover those more granular tags – we have to use a combination of things
      • Interested people:
        • Person from Epic (Michael to name), Rob H for reality check, John M for security purposes, person from Oracle (Hans to name)
      • Next Step:
        • Write out the scope and boundaries around this
        • Create a list of the common values and send to Terminology Infrastructure WG for review of the current modeling and representation of the codes
          • Review big existing EHR-s values
          • Review national efforts values

Monday - Q3

Chair: Hans Buitendijk

Scribe: Riki Merrick

Agenda:

Notes:

Catalog Ballot Updates

  • Have been reviewing spreadsheet
  • Added vote for the item that was missing a vote, but then found 14 negatives that have no votes recorded
    • Had a motion to accept the ballot reconciliation spreadsheet with few affirmatives on November 2020
      • Items are from Kathy discuss on Friday calls, Riki maybe this week and Frieda – none of hers were in-person
    • Then we have to figure out which items were applied
  • Is healthcare Services in scope?
    • asking because Canada is working on catalog for this – running into difference between definition and instance resources

R6 Planning 

  • FMG intends to be as much as possible normative (maybe 50% - 80%)
    • Why should something become normative?
      • FMM level progression
      • How much adoption will be in R6 and onwards, which is the push for making resources normative
        • Example task (so COW needs to provide any feedback NOW)
      • Some resources have been widely implemented, but it does not fits the FMM level metric (those might need to be updated) – currently does not measure the market share compared just numbers of organizations
      • Look at the likely implementation level across the market (either by choice or declaration in a regulatory statue
    • FMM levels
      • Example visionPrescription
        • Blend in with deviceRequest
      • Anything that is now FMM3 or above should be considered normative
    • R6 timeline
      • Proposed rule will have FHIR R4 as the base this year
      • 4-6 years will be the next opportunity to get another FHIR release into regulation / certification rules
      • Mostly seeing implementation of R4 with some extensions to grab some R5 functionality
      • Australia is based on R4
      • Germany , UK are also going to R4, so there next release will be out a few years
    • So by Jan 2026 what resources should we get to normative = priority work needed in each of the OO Resources:

Top Tier (sorted by level of effort and indicating the call time these resources will be discussed)

Second Tier

Parking Lot

Already Done

** denotes that the resource needs to have instantiated elements removed per FHIR-40499 - Getting issue details... STATUS

  • Other work:
    • Patterns
    • Category discussion from Q2
      • AnatomicalCharacteristic / organ inventory for Gender Harmony
    • DocReference is being used for clinical notes – should some of these have been observations that should be used in composition as summaries –
  • Make sure all project leads know that they need to do the QA – Hans Buitendijk  to add the reference to FMG confluence page
    • Working through the resource specific jiras
    • NEW resource requests – put those into second tier
    • should add a tag to indicate structural changes, so those can be prioitized
    • What are the criteria for prioritizing jiras?
      • needs to be described for all project leads
      • structural changes > vocab changes > text changes

Link to "Old JIRA Dashboard"

  • OO on FHIR is working through the old jiras against older versions
    • Trackers in "Waiting for input"
      • we are defining with fair effort of getting input from the submitter as 2 contacts 2 weeks apart, then add to block vote to close as vintage

Monday - Q4

Chair: Lorraine Constable

Scribe: Riki Merrick


Joint with CDS / CQI / CIMI

CIMI Topics

Update on Lab Subtypes IG

LOINC/SNOMED Coordination 

    • slides presented by Stan Huff:
    • Official agreement was signed in September 2022
    • Make LOINC content available in SCT extension under the LOINC use agreement copyright
    • Also involved is Jim Case and other modeling folks at SCT
    • For LOINC this will provide a computable ontology
    • All LOINCs will also have SCT codes – but LOINC will make them first
    • Having SCT for each LOINC part which will support the reasoning across the different parts
    • Starting with lab
    • Will include grouping concepts in SCT extension
    • Propose to make simple translation table
    • Will mean coordination of LOINC and SCT releases
      • International publishes monthly
      • Each national extension decides if they want to use it
    • Match existing codes
    • Make new SCT for LOINC only codes for now
    • Make new LOINC for each existing SCT
    • Will also map the LOINC answer codes – SCT is working on representing the relationship between the tests and results and also supporting the binding strength for result valuesets
    • For those elements that are not matching we will have to have editorial staff review and understand the meaning – and adjust the words (and support synonyms)
    • People want to get involved reach out to Stan so they can set up the community for feedback
    • General timeline:
      • Have done 100 concepts to cover a few types of lab tests and some other observations like APGAR
        • Could create stereotype pattern in lab data – target set of 27k for the next 6 month – that’s the low hanging fruit and also will look at the top LOINCs and add those in a well
        • Documents will be set up as a separate ontology – will create a new part of the machine-readable piece in SCT
        • Similar for the radiology to support RADLex folks – combination of image types and related features to be described
      • Copyright agreement is under LOINC for the observables
      • Met last week in Montreal
      • Still need to work out the logistics and looking for funding for the LOINC resources to do this work

CQI Topics

Characteristic FHIR Resource Proposal

  • Held connectathon under track cohort definition:
    • <ADD LINK>
    • Used the proposed resource and developed tooling to build a characteristic resource to enter the data and then visualize the entered data
    • that was successful
    • also had educational session
  • Structured expression of characteristic to define what is means to be a member of the group
  • Decided to make separate resource "characteristic", modeled after evidenceVariable.characteristic backbone
  • this topic is the main thing on OHS agenda tomorrow
  • also request from FMG is to provide feedback on what would it mean to adopt this as a profile on group resource
  • it is a definitional resource, or an instance resource?
    • Specific criteria can be combined to come up with a set used for a specific group
  • In CQL we create libraries of measures – it is similar to that
  • Example:
    • Defining this set of criteria and if a patient has all of these, then insurance will pay for this service; A1C results for > 8% for over 6 weeks
    • What is the boundary for observationDefinition and resources in the measure space, ClinicalUseDefinition?
      • These seem to be related, but not 100% overlapping
    • When I publish the results of the trial, then I can reuse the computable criteria for other trials to ensure that they are comparable
    • You could make one criteria be =>3 vaccinations
    • Get resource proposal link!
    • Mapped this to Vulcan RWD definition as example
    • I am not looking for things about patients, but criteria about situations / community / environments etc
    • May need to figure out a better name – may give confusion with deviceCharacteristic as well
      • This may mean we may have to replace a lot of the elements in device
      • This has not been reviewed by this group
    • We can sometimes use a code from a code system, but that does not always work for these criteria and that precludes the machine readable definition of the criterion
  • This resource defines the group = cohort that has a set of certain criteria
    • code and different datatypes for describing it, exclusion Boolean and time period in group resource
    • more options in evidence.charceristics backbone
  • this seems they have same requirements as decision support language like Arden syntax or CQL
    • have the definition in a FHIR resource that can then be shared
    • might want to have the CQL expression approved by a specific organization
  • could we create the attributes in the same order as the CQL resource
  • need to be careful with the work characteristic – there are other things that use that – just another word for attribute also
  • take into consideration how this will be integrated into tooling
  • in evidenceVariabe we describe the strada
    • the criterion does not describe what value you might get, when you observe that thing
  • How do people get involved?
    • see more at fevir.net owned by Health Evidence Knowledge accelerator (not an HL7 accelerator)
      • that group has 14 meetings/ week - then they bring their work to these HL7 WG calls:
        • BRR Tue and Thu
        • and CQI Wed

CDS Topics

  • No specific topics

OO Topics

Update on Catalog IG

  • Still doing reconciliation still has 14 open negatives
  • Several changes have already been made, and we will be doing QA work also
  • Goal is to have this published before the next WGM
  • Meetings are weekly Friday 12 – 1 PM ET

Other topics of interest

  • Will work on resources that point to bodysite for R6
    • suggest there is work to be done to use codeable reference using BodyStructure
    • There are several resources that have the attribute of bodysite
  • Decision support is under FDA guidance and regulation
  • observation.category discussion from Q2 earlier today (see above)
    • When observation.code is constrained to valueset that is restricted to just lab does category still need to be populated?
      • yes, becasue while for one use case it may be ok to just use the constarined vlaue set, across all use cases it would be helpful to not have to look in different places
      • also for US, id US Core says must support 0..1, then it must be populated
    • this work is expected to be universal realm

Administrivia

All agreed to keep the same session for September

Patient Engagement invited OO reps (2) for topic of Advance Directives - Hans represented OO Co-Chairs

Tuesday May 9, 2023

Notes

Tuesday - Q1 

Chair: 

Scribe: Riki Merrick

Did not meet due to WGM+ meetings

Tuesday - Q2

Chair: Lorraine Constable

Scribe: Riki Merrick

OO / PH

Agenda Review

  • Electronic Test Order And Result Reporting (ETOR) - PH not in the room

  • General FHIR Topics

General FHIR Topics

DiagnosticReport jiras

  • FHIR-26362
    • Is in triaged status, but shows as resolved = considered, question answered as of Aug 2022?
    • They are looking for a note that lists the date and what was changes on the prior report
    • There is an extension for DiagnosticReport for addendum that references the original report
    • There is also a “replaces” extension
      • This should not be an extension - it is core reporting functionality
    • Open a new tracker – this should be handled as part of the COW discussions = FHIR-41241
    • Document the addendum topics that are covered
    • We could create a profile on DiagnosticReport for lab results
  • We settled on using composition for properly structuring the DiagnosticReport resources to create the document structure
  • FHIR-40568
    • Related to FHIR-35810
      • Model AI as a practitioner was the suggestion from PA – this may become more feasible when AI makes decisions for patient care – but a person should ALWAYS be responsible for the decision
    • Device is what we think is currently appropriate and can provide all the details we need to know about the AI algorithm
    • Will need to as PA to re-open this ticket – put this in joint quarter with PA
    • Related zulip chat: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Can.20an.20AI.20be.20added.20as.20a.20Practitioner.20resource.3F
    • Add this comment:
      • Will put on agenda for joint with PA to reprise the discussion around modeling AI as practitioner and have discussion about using device, because of the attributes around software which are consistently modeled that way in device - and developing device-module content and examples
  • FHIR-40266
    • Change status to waiting for input – asking for some use cases
    • Not sure how to represent eCC
      • It is a specific questionnaire that is versioned
      • Need to look at the IHE SDC on FHIR IG, which is the programmatic approach to its conversion – tag Alex in the comments
      • Also should look at the FHIR Cancer Reporting IG
  • FHIR-38936
    • In person Bas van der Heuvel
    • Put on FHIR-I joint Thu Q2
  • FHIR-19362
    • This was not made for R5, so is now it will need to be made in R6 – requires coordination between OO, PA, SD
    • see if we can have SD join our joint session with PC Wed Q1 to discuss

Tuesday - Q3

Chair: JD Nolen

Scribe: Riki Merrick

OO

Agenda Review

Overall plan for trackers 

IG-related trackers

ONC NPRM Lab RFI Feedback

    • Reviewing the text:
      • This is for consideration for future rules
        • Current rules listed
        • In past times LRI was in rule, then it got dropped, LOI was considered, but were not in 2015 rules, which we regret
        • some improvements during COVID
    • Reviewed the specific questions and started collecting suggestions for reponses.
      1. Which implementation guides or other standards should ONC adopt in certification criteria for health IT supporting transmittal and receipt of laboratory orders, laboratory results and directory of services?
        1. Results - LRI R4
          1. back as not much advances made in consistent coverage and plug/play
          2. maybe R5 once available for SOGI and NBS.
          3. LRI includes ELR = PH_Component; so improved alignment with public health
          4. includes profiles for specific lab use cases – like clinical genomics and newborn screening, which
            1. would benefit from consistent reporting and become mainstay
            2. can be pre-adopted into older result messages
          5. Addressed COVID/Emergency Preparedness data. HOWEVER, not convinced that LRI (thus LOI) is appropriate for all added data important for PH, but not for Lab operations and that eCR would provide a better path for those.
        2. Consider ELR to go to LRI +PH_Component through SVAP if feasible. Would create a common base for others to move to LRI.
        3. Orders - LOI R4 would enable consistent order content.
        4. Test Catalog - overall this is a harder one to fit into the configuration workflow 
          1. options are eDOS (v2)- not proposed
          2. FHIR catalog - could consider FHIR Catalog, but
            1. not yet mature to adopt with clear benefits. Perhaps as price transparency becomes more mainstream it starts to have more value.
      2. The utility and maturity of existing HL7 v2 and C-CDA standards supporting laboratory interoperability and the impact of moving to FHIR-based laboratory data exchange.
        1. For provider-laboratory interactions HL7 v2 is the workhorse to communicate orders and results, BUT
          1. not as consistent and interchangeable, but established, so need ROI for upgrades
          2. maybe when new data elements / use case needs force updates
        2. For provider-provider/payer/research the HL7 C-CDA is well established, although HL7 v2 is widely used when sharing involves HIEs.
        3. While FHIR has promise, replacement of the main workflows between providers and laboratories in terms of volume would not yield sufficient benefits to shift.
          1. The focus need to be on green-field topics:
            1. genomic data sharing along with the order or the result
            2. DME orders requiring more data for prior authorization
            3. walk-in laboratories managing orders. i.e. ability to support “lab shopping” where one receives a QR code and can select the laboratory of choice which in turn requests an order to be forwarded.  That forward may be an HL7 v2 message, while a FHIR based approach becomes viable.
            4. Results of the more complex / complicated use cases like genomics and anatomic pathlology, where v2 interfaces do not currently yield good structured data
            5. storing results in FHIR resources for access by secondary data users like PH or research
          2. We note though, that the FHIR guides are in progress, e.g., DME/PAO, but not for the wide range of order/result flows. 
        4. As C-CDA documents move to FHIR Documents and Collections the opportunity to migrate is more imminent.
        5. As the FHIR knowledge base and capabilities expand that make easy migration from HL7 v2 realistic and/or v2 expertise starts to run out, such conversions will accelerate. We do note that where additional data is needed, it still may be most efficient and fastest by adding data to HL7 v2 than switching to FHIR.
      3. What barriers would additional health IT certification criteria for laboratory interoperability create for developers and other interested parties, and how might this affect adoption and use of such technology?
        1. LOI/LRI use of AOE data that is not relevant to lab testing would perpetuate data sharing using inappropriate data flows.  AOEs are meant to support lab testing, not as pass throughs that are better served by, e.g.,  eCR reporting.  Would require some guidance updates to LOI and LRI to reduce use of pass-through AOEs.
        2. Where labs do serve as the walk-in with effectively an “EHR” to support that, it would be reasonable that they support eCR for such additional data they capture directly as well. Requires that eCR and Lab triggers ensure that every reportable lab always yields an eCR.  Ulrike Merrick checking if that is the case.
        3. Currently system certification provides a higher level of assurance of consistency
          1. ideally both systems in a data exchange should be certified, but if that is not possible, or feadible at least the source system shoudl be certified, which means considering expanding certification to LIS and IVDs
        4. Might want to separate certification of semantic from syntax to support certification of systems using older syntax, but still could send better semantic qulity data
        5. Differentiate between providing certification requirements and tooling for it from enforcing / incenticizing users to actually do this.
        6. Focus on certification of options = profiles rather than full guides. LOI/LRI support that.
      4. Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers’ products?
        1. DID NOT GET TO THIS QUESTION
      5. Are there any other steps that ONC and HHS should consider taking to advance laboratory interoperability?
        1. SHIELD Semantic work
        2. LIVD mapping
    • The follow-up is to start to draft more specific responses and review on the next main call (5/18)
  • SVAP is out for comment also
    • Consider adding:  More automatic inclusion of HL7 published newer version of standards in ISA, so they are available for SVAP

Tuesday - Q4

Chair: JD Nolen

Scribe: Riki Merrick

Joint with BR&R and DEV (but they are not coming)

Agenda review

  • Product-related resources, profiles and IGs (e.g., labeling, SPL, ePI, etc) – not yet, since BR&R is not here
  • Product pattern discussions
  • DEV related topics – last 30 minutes
  • V2-25361 - Incorrect Ack Choreography SUBMITTED Ack sequencing – not the right people in the room

Review priority of resource work for R6 planning

  • Identifying the resources that should be stable from R6 onwards
  • See Mon Q3 for list
  • Priority is open jiras and QA criteria
  • Need to address product pattern in this work as well
  • documentReference and the work around category attributes will need to integrate with HTA requirements
  • Nutrition will need to review the vocab bindings
  • Need to sort out vocabulary around dispense
    • patient allocation (deviceDispense) vs actual move of the thing (like in medicationDispense)
  • we recognized that out of the 270+ jiras several of them are already resolved, BUT several were re-opened, because they didn’t make it into R5
  • DeviceUsage is in USCDI to cover implantable devices – and it is also going to be in IPS and used heavily in other countries
    • Implantable devices will be using device + deviceAssociation
    • Current definition is for patient declared use of a device – most important around this is the boundary discussion
    • Following the patterns of MedicationStatement
    • We may just stabilize this
  • In US realm SC discussed that adoption of R5 for use in greenfield areas – like catalog and inventory
  • Grahame is cool with the resources in the parking lot
    • SANER PH reporting would be interested on supply related resources
  • FHIR-I will bring this proposal to FMG
    • Create sections for publication sprints for ballot – this would not be a milestone release, but would be in build as snapshot like we do for connectathon or ballot
    • Considerations for OO:
      • Patterns
      • Device
      • workflow / lab
    • for R6 ballot expect more pressure to have better quality earlier – looking for input from editors to Grahame, for what publisher tooling could help

Product-related resources, profiles and IGs (e.g., labeling, SPL, ePI, etc)

  • SPL on FHIR is parked for funding reasons
  • CQMC is reaching into planDefinition and observationDefinition
    • observationDefinition still needs to be aligned with the definition pattern
  • want to have consistency around product related resources
    • EMA has been in production since Jan 2022
    • <Ask Rik> what he mentioned is in production
  • How do you link <ask Jose>??? to GTIN and lot numbers – can this be operationalized?

Where are we with product pattern definitions?

  • Align related resources to a pattern for R6
  • Search parameters for GTIN / lot numbers
  • Jose will be working on product resource and compare how those attributes will work with inventoryItem (to manage these resources as part of the inventory process e.g. deviceDefinition, medication, etc)
    • We need to have to write up clear boundary descriptions =
      • when to use inventoryItem alone vs when you have to reference other resources
    • Can inventoryItem reference things other than medications etc – like services?
    • So topic is more around boundary descriptions vs pattern
  • Have been discussing how BDP / nutrition products / medication are related
    • If we have a pattern definition, do we really need the product resource that then is specialized?
    • It is not in the pattern index – build.fhir.org/product.html
      • Jose created to ensure that the product pattern becomes findable on the pattern page = FHIR-41257 
    • Need to figure out when you are dealing with instances vs definitional resource without having to also query for context to make the distinction
      • Make clear what attributes need to be present in a resource that indicates the resource is representing an instance
      • Need to describe the ways in which way you use each of the resources to indicate this distinction
      • Hans Buitendijk  to create the jira <ADD LINK HERE> and assign to Jose Costa-Teixeira 
    • In BR&R have batch number on instance resources only
      • BUT for medication is where we have the problem of needing the context to know this and when that is not available, then we have a problem

FHIR trackers

  •  FHIR-28251
    • “Remove liquid syntax { bullet” – we could not find, so probably pre-applied
    • Product quantity description – this seems to have been pre-applied in the current build
    • instance should be 0..1 – also pre-applied
    • Subject definition also have been pre-applied
    • Motion to accept as pre-applied Lorraine Constable, Riki Merrick : 12-0-0
      • Persuasive
      • Enhancements
      • Compatible, substantive
      • Applied in R5, so update as applied – need Lynn to change them over to published
    • FHIR-35874
      • This could be used to include the boundary description by finding it not persuasive with mod
      • Motion to find not persuasive with mod Marti Velezis, Jose COsta-Teixiera : 12-0-0
        • We created the inventoryItem resource
        • We also have done work on harmonizing the search parameters across those related specialized resources
        • We will update / add clarification for inventoryItem when to use inventoryItem alone vs when you have to reference other resources
          • Enhancement
          • Compatible, substantive
          • Assign to Jose

Wednesday May 10, 2023

Notes

Wednesday - Q1 

Chair: JD Nolen

Scribe: Marti Velezis

OO / Pt Care

  • FHIR-37736 - What happens if the Observation.focus is a related person? WAITING FOR INPUT
    • Updated the disposition to address questions in the ticket
    • Need to quote the definition of isModifier
      1. We reviewed the definition together – "their definition SHALL explicitly declare how such divergence could occur and must be marked as a modifier element." supports the use of the isModifier
      2. Alter Observation.focus to include isModifier 
      3. Rationale: The meaning of the observation may shift its meaning if the subject and focus are not the same.
      4. Patient Care needs to re-evaluate the Procedure.focus and has created a JIRA ticket FHIR-41268; this is because they were following the pattern in Observation.
      5. Add to FHIR-I discussion on Thursday Q-2 to discuss the definition of isModifier 
    • Motion to find Persuasive with Modification
      • Marti Velezis / Dan Rutz : 8-0-0
      • Assigned to JD Nolen
  • What to do around Organ inventory (anatomical characteristics) - see 2022-12-08 Main
    • We needed to loop in Rob McClure into this discussion.
    • Need to document/link to what happened in WedQ0 – Gender Harmony
      • This needs to be a project proposal – with OO and Patient Care
      • Create a profile and maybe an implementation guide
      • See FHIR-12913 (next bullet)
  • FHIR-12913 - Getting issue details... STATUS
    • Part of the category discussion, and anatomical inventory discussion
    • Need to draw the boundaries between characteristic and conditions (e.g., genetic disorders)
    • Need to get a majority of the patient characteristics identified – and work on the edge cases
    • genetic mutations that may lead to a specific condition – but the observation of the mutation would be a characteristic
    • Need for clarity about what is included; OO and Patient Care agree to create a project to clarify how to communicate patient characteristic; and that the project team will address the concerns and use cases in this ticket.  The deliverable will be an IG from the project.

    • Drafted proposed disposition as Persuasive with Modification to be revisited later.

    • PSS-2205 - Getting issue details... STATUS  
      • Also we drafted a Project Proposal to address the two topic areas above (FHIR-12913 and Organ Inventory discussion in Tulip.
      • OO and Patient Care will work on this project together
      • Motion to approve
        • Lorraine Constable / Michelle Miller : 6-0-2
      • We submitted the proposal for review
      • This needs to be added to project planning activities
  • FHIR-19362 - Getting issue details... STATUS
    • Motion to find Not Persuasive
      • The recommendation from the commenter is a better design, but does not warrant the disruption to the implementer community.  
      • The group agrees that this shift may be too difficult to make and do not provide a great enough benefit.
      • Lorraine Constable / Michelle Miller : 7-0-1

    • Discussed that we should follow Dosage and Device Request

    • See changes to the proposed disposition in the ticket

    • Motion to find Persuasive with Modification

      • Marti Velezis / Dan Rutz : 6-0-1

      • Assigned to JD Nolen

Did not discuss the following (and moved to Wed Q4)

  • FHIR-34207 - Add attribute to document confirmationTRIAGED

Wednesday - Q2

Chair: JD Nolen

Scribe: Lorraine Constable

Introductions

Clinical Order Workflow (COW)

    • Ken summarized BPM+ Health community  bpm-plus.org 
    • Ralf walked through an overview of current state of the Clinical Order Workflow project 
      • FHIR to the LAB.pptx 
      • Ken - Authoring workgroup focuses on how to express this workflow at a high level. The data specificity is outside of the process other than binding to the required information
    • Motion to agree in principle to explore joint BPM+ and OO collaboration on Clinical Order Workflow project. Ken Rubin / Hans Buitendijk 7-0-1
    • Also looking for connectathon paths to demonstrate collaboration between the approaches
    • There was a Gemini BOF on Results on FHIR asking to create a Gemini project for IHE-XD Lab on FHIR for results
    • Question about the approach for the COW project - assertion is that you may miss details if you don't handle the whole cycle in a specific example. Plan to take the specific examples through the process  - suggestion is to build from the specifics rather the generalized
    • Current state of the project is orienting participants to how the concepts work together
    • Now need to take a single example through the process and then expand
    • Look at client managed workflow vs server managed workflow - dependent on policy / local jurisdictions

FHIR Order Entry (FOE) - US Realm ordering

    • Formerly known as Durable Medical Equipment (DME) or Post-Acute Orders (PAO)
    • Calls been re-instated - need to follow up on where this is gong

Other Topics

  • There was a Gemini BOF to begin discussions of XD-Lab on FHIR
  • FHIR-34207 - Getting issue details... STATUS Added a proposed disposition. Will circle back on this on a lab or main OO call

Wednesday - Q3

Chair: JD Nolen

Scribe: Riki Merrick

Joint with CG

R6 Planning

    • See Mon Q3 for tiering

Workflow

  • Had good chat with BPM+ folks around modeling
  • Goal is an IG-like
  • DiagnosticReport IG – may work together with IHE as Gemini project
  • Condition vs characteristics of a patient
    • Base observations, but then repackaged into a wrapper to support the use of the data
    • Boundary of core characteristics is that this is more of the raw information, not the interpretation of that
    • Phenopackets cover the raw phenotypic observations already – but codified
    • Would variance resource need to be profiled from this?
      • No, but needs to be compatible
    • Biomarkers could also be considered a patient’s characteristic
    • One of the boundaries may be who can create condition resource
    • This came out of gender harmony work lead to create support for organ inventory
    • This will be profile on observation
    • Will this be an R4 project?
      • CG R4 based IG leverages hierarchies
    • Brainstorm a list of concepts and talk to SMEs
    • Community level phenopackets IG might be a good candidate for getting input
    • Support for adding to lab orders that may be useful for certain

Specimen Update

  • Reviewing if we need to include some of the attributes from collection backbone to processing
    • Can this be covered just by creating a codableReference to procedure?
      • If need just code, then would not have the performer etc – though if that is needed having reference to the instance may be appropriate then
    • Does procedure also include non-clinical context?
      • What if used as part of research study – not a patient?
        • Ask BR&R what they consider subject
        • Bring this question up on the joint with FHIR-I
    • How much of this processing detail will leave the hospital?
      • For consultaton on slides (real and Whole slide images this kind of information is very important)
    • For fastingStatus – how did that get there?
      • weer trying to cover OBR-13, which in later versions of v2 became coded and restricted to fasting status
      • may want to consider adding something like patient charateristic at time of collection 

Information Model Update – Sequence etc

  • Link to the presentation on CG’s Tue Q2 page Page depicting future state
      • Observation now has attribute to b able to reference Sequence
      • Need to still work on molecular variation
      • Then those will require updates to DiagnosticReport and ??
    • Page listing complex use cases
    • Page listing the IM roadmap
      • Green checks are in R5
      • Molecular variation still needs resource proposal, once that is around, then we need to adjust observation reference to include this also in addition to sequence
    • Other slide deck 
      • Page of genomic Trio testing
      • genomicStudy is not in place of diagnosticReport, but rather in conjunction with it
    • Consider genericizing genomicStudy
      • To support anatomic pathology
      • Maybe include ImagingStudy here, too
      • Would need to make sure we find a better name – analyticStudy (rather than diagnosticStudy, which could create confusion with
        • diagosticReport
        • use of it in research

CodeEX update

  • Accelerator created mCODE IG directly from the genomics profile on DiagnosticReport
    • How do you get the lab result to the clinician = GenomX project <ADD LINK>
      • This will describe ordering and result reporting
      • Content = building the DiagnosticReport
      • Workflow of ordering
        • They implemented v2 genomics IG, but cannot go further
        • Use v2 for ordering and v2 with OBX with pointer to the FHIR diagnosticReport – this will go into live production soon (using https connections – did some testing at connectathon)
        • When COW has the workflow figured out in FHIR, then they will update to that
          • Hopefully we can use subscription
        • In ?? institute they have been getting genomic DiagnosticReports using post operation

Random topics

  • Concern that the Clinical Genomics IG is not aligned with v2 LRI
    • Their IG is universal, but LRI is US relam, so as long as there are no required elements in their IG, that are NOT in LRI, no problem
  • Need to get rid of several TBD codes – getting LOINC, but have this question: Using the same code value in observation.code and observation.component.code – is that legal?
    • yes legal, but not good practice – what is the use case?
      • For identifying the observation as overall order for predicted therapeutic implication, but then also listing one or more derived interpretations from the study that used one or more specified methods and references as the actual thing the clinician wants
      • after review these really are components, because those cannot be reported on their own
      • observation.code – acts like a panel code, so would request that way, with all codes in component.code as required children
      • would that cause confusion and folks might want to use the order only LOINC as a grouper and use observations?
        • Hopefully folks will use this LOINC in the context of the genomics resource, which describes how to use it
        • could add some guidance that ALL observations are required to be viewed together and cannot stand on their own
        • (Riki’s post meeting thought: it could fall into the qualifier vs component discussion a little – if we come up with a different solution for qualifiers, might want to revisit this one?)

Wednesday - Q4 

Chair: Hans Buitendijk

Scribe: Hans Buitendijk

no quorum - Hans was all by himself (sad)

Thursday May 11, 2023

Notes

Thursday - Q1 

Chair: JD Nolen

Scribe: Marti Velezis

Joint with DEV

  • RTLS - any updates from Balloted content re: Device? (is DeviceAssociation utilized?)
    • Continuing to reconcile the ballot in Patient Admin
    • Will publish if the ballot is accepted 
    • Will include DeviceAssociation in the next version of the IG (Sept 2023/Jan 2024)

The following discussion related to the Impact Assessment of the Device-related resources

  • Need to assess the impact on the DeviceAssociation
  • Need to   



  • FHIR-33695 - Observation.subject should not be mandatory
    • This is in the POCD IG and they need to some guidance here for Observation profiles in the IG
    • There are use cases where the subject is unknown; e.g., Fitbit is sending the observation to the app – and does not know the subject at the time – i.e., 
    • Patient bedside devices – device is just sending data about the observations – the aggregator is only sends the device related information and observation information - the association happens after the EHR gets the data 
    • Vital Signs profile requires a subject:
      • In cases where there is not a patient association to the device observation then the Vital Signs Profile is not appropriate to use in this scenario.
      • Only use the Vital Signs Profile when there is a clear patient association to the device observation from the recording device
      • The proposed disposition was updated to reflect the discussion and the DEV group will go back to the 
    • Create a new JIRA ticket
      • Vital Signs Profile page: 
        • Add some text to cover the use case where there are devices 
  • FHIR-40397
    • Align product code search parameters (see proposed disposition)
    • Motion to find Persuasive 
      • Marti Velezis / Elliot Silver : 8-0-2
      • Assigned to Marti Velezis
  • Device Module work
    • Module Organization - what can we do the organization of the module
      • Assigned Module/Breadcrumb/Index/Content
      • Need guidance for ownership
      • Frequency of Roadmap updates – should this be part of the snapshot updates?

Thursday - Q2

Chair: JD Nolen

Scribe: Marti Velezis

OO / FHIR-I / DEV

  • R6 plans
    • Normative Plans
    • Maturity Levels - Guidance will be considered - Product as a whole that needs to mature and processes will be updated as necessary - target for the end of the September meeting; How widely are resources used;
      • Record integrity - social records of families that puts the issues in front of the use
    • QA`s and Jiras
  • Module Discussion 
    • Module Organization - what can we do the organization of the module
      • Assigned Module/Breadcrumb/Index/Content
        • Only belongs in one module
        • FMG resolves disputes
        • Proposal to modify modules on the page 
      • Need guidance for ownership
      • Frequency of Roadmap updates – should this be part of the snapshot updates?
  • FHIR-40499 - Align with workflow patterns and remove instantiates[x]
    • Remove element in Observation as that element in 
  • Device.endpoint(Endpoint) vs. Device.gateway(Device)
  • V2-25384 - Getting issue details... STATUS new datatype for a datetime without a time zone (MSH-7 mapping to determine order of messages) 
    • V2 to FHIR 
      • How do we handle this in FHIR; needs to handle back at the project team to see if this was previously answered with FHIR-I
      • GG: Always have an explicit or Implied timeStamp where you know the time zones; Add narrative that you need a time zone
  • FHIR-38985 - Getting issue details... STATUS
    • With the removal of Instantiates[x] from Observation - this issue will be moved to the extension
    • Extension definition will need to be updated: 
      • If inconsistent - an error can be thrown
      • From OO resources - the deviation can be added as a rule/constraint
      • Review of Extensions - on the stats page – GG to send this out again
  • discuss FHIR-38936 - Getting issue details... STATUS  - citations in Diagnostic Report
    • Request is to change datatype to Markdown to do a formal citations - to handle the formatted citations;
    • The triple square brackets can be used in the IG Publisher
    • Datatype can be changed, and need to discuss if we want to make the change.
      • This makes more complex, and may not be compatible with current systems
      • Need to describe the guidance for citations
        • Context-specific 
        • Is this an extension or change in base resource
        • Discussion about options:
          • Presented form is a very specific format for the report (and context link for citations should be included if necessary)
          • DiagnosticReport.supportingInfo includes (Citation) reference
          • DiagnosticReport.note (Annotation) includes a markdown
  • FHIR-38633 - Getting issue details... STATUS
    • For R5 the proposal for an extension was to get some experience with the requirement; we should reconsider the proposed disposition 
    • Should this be "Communication" instead of a separate extension that was proposed for R5
      • Actual communication with the patient should use the Communication resource.
        • user (patient/clinician) acknowledges the communication by marking the action in a system
      • Flag that the awareness of the patient b/c that the information was presented to the patient but there is no systematic acknowledgment
      • Lesser fidelity communications – push the communication but receipt is unknown (e.g., "null" flavor)
      • Need to raise across resources on how to capture 
  • Discuss the definition of isModifier (re: follow-up from FHIR-37736)
    • There will not be a 
    • PC discussion - 
      • Procedure and Observation 
      • Discussion in Documentation around "focus" as a general issue
    • JIRA ticket to update the definition of Observation 
      • Link to the PC JIRA

Thursday - Q3

Chair: Rob Hausam

Scribe: Marti Velezis / Riki Merrick

Joint with PA (reps from DEV)

Device.endpoint(Endpoint) vs. Device.gateway(Device)

  • What is the use of endpoint = primary use for directory - in order to send them specific content and have a linkages 
  • 3 categories
    • how to connect to address (IP, website, email, etc.), where other information is required (e.g., configuration parameters, etc), Same endpoints for multiple things 
    • who is providing the service, who is managing
    • how to connect to what it is - e.g., discharge summary , xds. care planning hub, Fhir server. etc. 
  • What is the difference between endpoint and gateway?
    • PACs = device can have different modes of connecting, so can have more than one endpoint
      • The referenced imageStudy.endpoint references one of those
    • Many equipment in the market that are connected to a central server = gateway
      • Gateway = another device, that can have one or more endpoints
      • From the PACs you have a choice to connect to the endpoint on the gateway or the gateway of the device – in an IG we should decide which approach to use
      • A gateway is usually just a passthrough, but would still need to find the right endpoint to that
  • Will continue the convo in devices
  • We need to describe the various paths that can be taken to describe the device - its endpoint, its gateway (which may have one or more endpoints).  
  • Implementation guides will specify the exact path for any one scenario, but the definitions/descriptions, examples and use cases need to be clear enough to provide general guidance.

Machines as practitioners / AI Discussion

  • FHIR-35810
    • Joint discussion with PA/PC – 
      • Background and thoughts are that mostly devices (90%); majority of the information for AI were included in the device resource and not in the practitioner resource.
      • May need to use a different aspect / attributes when the device is actually doing the prescribing – i.e. have the legal right to prescribe
        • PractionerRole did not require any changes/updates
      • Motion to find Persuasive with Modification
        • Brian Postlehwaite / Dan Rutz: 17-0-1
        • Assigned to PA for resolution
      • Dev will review this ticket after we vote and work through additional tickets with other WGs to do the review and needed updates
      • Action Item: OO will need to evaluate the resources where 'Practitioner' is referenced to determine the impact of the reference to device in addition to the practitioner.  Note - Device implements the Participant pattern, and is listed as an actor in the Event pattern and a performer in the Request pattern. Some workgroups (incl PatientCare) have already updated their resources to allow references to Device in places when recording participants.  We suggest that each WG review their references and ensure that Device is listed as an allowed participant type if appropriate.
  • FHIR-40568 - AI models should be Devices TRIAGED
    • This is to negate the 35810 - and Elliot Silver agrees with removing this with the resolution on FHIR-35810.
    • Motion to Reject Request
      • Marti Velezis / Elliot Silver : 18-0-0
      • No changes needed.

Module Discussion

    • PA owns the Administration module where we have all of the healthcare product resources and they agreed that we can pull them out into our own module. We will coordinate the content with PA as we make changes in the build to manage the change and mitigate any duplication.

Transport/task

      • encounterHistory
      • OO has not done more work on transport
      • How to use task in lab workflow
      • Patient transport could that be
      • Deliverable – working with BPM+ might be an IG, but could end up being something else

V2 Topics

  • V2-25377
    • Mismatch between what is in THO vs in Chapter 2C for HL70311 = https://terminology.hl7.org/3.1.0/CodeSystem-v2-0311.html
      • used in NK1-34 – job status
      • related field called employment status = OH1-3
        • is using a different code system = HL70957 = 'employed', 'unemployed' and 'not in labor force'
          • this not in v2 tables, nor in THO as a code system / value set, in 2C has some typos, but also the link to the V3 valueset in THO, that does not exisit
          • Owner is PH - created this ticket: V2-25521
      • Motion to update the label in UTG to user defined
        • Brian Postlewaithe, Sonja Ziegler - 14-0-1
  • V2-FHIR project
    • What is the plan for balloting?
      • We are making progress with updating the spreadsheets
      • We don’t have the technical folks that can help getting the full build based on the updates from the spreadsheets
      • Just updating the text to point to just the spreadsheets also had a problem (Rob may take a look, if it’s something fixable)
      • People are using he existing spreadsheets

Other Topics

  • Keep the same joint for next time
  • Patient resource proposed changes
  • Jira metadata
    • Discussed an issue in JIRA for the "Resolved" date.  This is set when the Proposed Disposition is added instead of when the other workflow steps are taken to resolve the workflow (e.g., Will update Spec, Reject Request, Consider for Future Use, etc.)  and put into a resolved state (e.g., Resolved - Change Required, Resolved - No Change, Deferred, etc.).  Need to take this to Lloyd for discussion.

Thursday - Q4

Chair: JD Nolen

Scribe: Riki Merrick

  • From 2021-04-22 Main = Cimi Discussion around observation.component
    • When to use component vs extension
    • Clinical genomics and Vital signs are good use of component
    • FHIR-31954 = US Core O2Sat profile
      • Flow rate and concentration are modeled as components, but
        • they can be reported independently and still be meaningful
        • these are input values for the pulsoximeter result value interpretation - so more like AOE's (even if they are NOT questions that are answered - similar to patient weight or urine volume for other tests
        • the flow rate and concentration are on the ventilator, while the measurement for the Sat rate is done on the pulseOx – so different devices, which is why they cannot be components of the pulseOx observation
      • Nathan Davis  to attach the list of extensions for those related observations to the comments in this jira
      • Related to qualifier vs component discussions
        • FHIR-26071
        • we also have that as work item under R6 planning in Monday Q2 list
  • PSS-2205 = Patient characteristics project proposal
    • Some explicit examples like bloodtype
    • More broader use case, with the minimum requirements around some
    • Also cover who assigned this characteristic
    • will be fleshed out more and be topic for next WGM, if not sooner
  • Keep this joint for September

Asjourned 4:45 PM EDT

Friday May 12, 2023

Notes

Friday - Q1

Chair: Hans Buitendijk

Scribe: Marti Velezis

Discussion topics: 

  • VisionPrescription with FM reps (first topic of the Quarter)
    • FM transferred VisionPrescription to OO
    • Vision prescriptions has different characteristics that the other resources due to the nature of a vision prescription; it's an authorization; it has has a life time (duration of validity); typically 2 years.  The authorization is written by the a person whose scope it is to prescribe the vision prescription.  Prescribers and Dispensers have their own scope of practice.
      • how many times can it be used, and the duration of the validity
      • specification details that need to be conveyed 
    • Need to determine if this will stay as a separate resource, expand the scope and/or replace it with one of the other resource
    • Stable content for its use cases 
    • Volume of vision prescriptions is significant
    • Is this similar to hearing aid or sensors that we should expand the scope of these types of devices if it makes sense.  Need to look at this type of devices.  Orthotics, prosthetics are also similar to a vision prescription.
      • Need to document the use cases/requirements for these type.
    • Will there be a vision prescription dispense; could DeviceDispense be leverage to dispense the device (e.g., glasses or contacts)
    • Workflow does not drive the differences
      • Specifications need something more than available in DeviceRequest
      • Not all jurisdictions go through all of the steps in the workflow - i.e., some steps may not be necessary)
    • VisionPrescription has been in FHIR since STU2 and advanced through maturity since
  • FHIR-11217 - Thoughts on combining SupplyRequest, DeviceUseRequest and VisionPrescription - 2016-09 core #371 TRIAGED
    • Developed a proposed disposition with clarification with with the resources included in this ticket. 
      • Motion to find Not Persuasive with Modification 
        • Dan Rutz / Alexander Henket : 9-0-1
      • Amendment: Address where VisionPrescription should be referenced in DeviceRequest in a separate JIRA ticket; which will expand the discussion around custom devices
      • Action: In HCP we will work through the wording.
      • Assigned to Marti Velezis


Friday - Q2

Chair: Hans Buitendijk

Scribe: Marti Velezis

Discussion Topics: 

JIRA Tickets

  • V2-25376
    • Structured measurement and cardiologists want to flag out of range; and exam not abnormal - ability to mark entire assessment as normal even if there is some are not normal thresholds; system/implementation defined behavior.
    • Action Item: Need to create a JIRA for DiagnosticReport in FHIR and in CDA (Daniel Rutz )
    • How will the information flag that there is an abnormal component of the entire assessment; normal, but measurements may be of interest
    • See updated comments on the JIRA ticket directly.  Need to understand the requirements from Cardiologists.
    •  Added a proposed disposition. Will circle back on this on a lab or main OO call
  • FHIR-34207


  • FHIR-33043
    • Observation.status values
      • Clarify to use "final" with dataAbsentReason is "not asked"
      • Put it in a Block Vote with a proposed motion to find a Persuasive with Modification
      • Grouped as: May 2023  OO-FHIR-Block-Vote
  • FHIR-33042
    • Observation.status - appended
    • Put it in a Block Vote with a proposed motion to find a Persuasive with Modification
    • Grouped as: May 2023  OO-FHIR-Block-Vote
  • FHIR-32996
    • Observation.status - cancelled
      • Persuasive with modification 
      • Modification - indicate when the Observation.status is cancelled or aborted (due to an order or test having been cancelled or not completed).  The dataAbsentReason should be present.
      • Put it in a Block Vote with a proposed motion to find a Persuasive with Modification
      • Grouped as: May 2023  OO-FHIR-Block-Vote
  • FHIR-32051
    • Hans Buitendijk will check with experts on whether or not this ticket has been sufficiently addressed.
    • We discussed that both the Observation Vital Signs BP profile and  US Core profiles.
    • Assigned to Hans - waiting for input.

Administrative action items: 

------Adjourned the meeting at 12:30PM CDT---------------