Skip to end of metadata
Go to start of metadata

Table of Contents

Monday, January 14, 2019

Q1 - OO

Agenda

  • Agenda Review for the week
  • Introductions
  • Attendanc Log
  • IHE Specimen Tracking CR
  • LIVD

Minutes:

Chair: Riki Merrick

Scribe: Riki Merrick


Agenda Review

Introductions

Demo of OO WGM 201901 -Attendance Log use

IHE Specimen Event Tracking CR

Introductory slides for IHE SET 

  • Reviewed as options V3, FHIR and V2 - decided to use V2 for now, since most of the internal labs still use it
  • Reviewed existing V2 message structure for shipment and equipment communications, but neither quite fit right
  • Looking at the actual documents
    • CR 
    • Spreadsheet showing the mapping from data elements in SET use case to HL7 fields
  • Question about tracking container types in eDOS = is not part of the SET profile - this is for the instance on each specimen, so is a step before SET use cases
  • simple movement between labs may not need the SHP segment, hence 2 variations - example move container from one freezer to another
  • Question about timeline?
    • IHE is flexible = will pre-adopt message structures as long as the CR is approved, so may end up in V2+
  • Next Step:
    • ALL REVIEW THE CR - Ulrike Merrickto send to the main OO list serve and decide on a date to bring to the call

LIVD

Connectathon Update

  • Objective: Following feedback from the September 2018 Connectathon and ballot we need to progress improvements to the guide and complete the availability of a LIVD Bundle that is then successfully consumed through FHIR services and ultimately an application asynchronously.
  • Participants
    • Rob Hausam (lead)

    • Ed Heierman (lead)

    • Ralf Herzog

    • Nathan Davis

    • Francois Macary

    • Hans Buitendijk

  • Achievements
    • Saturday
      1. Created an Abbott LIVD FHIR definition for Abbott ARCHITECT c4000 instrument and applicable Glucose tests.

        1. Identified appropriate resources using GUIDs.

        2. Corrected resource references.

      2. Confirmed conformance of the Abbott LIVD Catalogue.

      3. Posted the catalogue to Rob Hausam’s FHIR server. The Catalogue posted correctly by changing the Bundle type from ‘collection’ to ‘document’.

      4. Reviewed LIVD Catalogue use cases with James Agnew

        1. Consumer that wants to retrieve the entire catalog

        2. Consumer that want to query the catalog for specific LOINC mappings

      1. Initiated creation of a Roche LIVD FHIR definition.

      2. Extended Abbott LIVD FHIR definition for two additional instruments.

    • Sunday
      1. Completed validation of the Roche LIVD FHIR definition.

      2. Discussed LIVD content with Nathan Davis of Intermountain Health Care.

      3. Investigated posting Abbott LIVD Catalogue to the Hausam FHIR server as a ‘transaction’ type bundle (rather than ‘document’).

        1. Include “Request” attribute to each entry

        2. Updated IG to support “Request”

        3. Updated Server to properly process a ‘transaction’ bundle.

Identified a HAPI FHIR server bug that prevented posting of a valid ConceptMap resource included in the LIVD ‘transaction’ type bundle.  Were able to work with James Agnew to get this bug fixed and posted to the HAPI Git repository so that we could rebuild Rob Hausam’s FHIR server and successfully process and post the LIVD transaction bundle.

        1. Updated sourceURI in ConceptMap to use the fully qualified LIVD URL for Object Definition

        1. Updated Abbott LIVD Catalogue to include tests with Vendor Comments, so made this change:.

          1. Added “other” as a DependsOn property in the IG.

        2. Updated the LIVD ObservationDefinition profile to allow multiple DeviceDefinition reference extensions.

        3. Updated the LIVD DeviceDefinition profile to place the capability extension reference to ObservationDefinition resource(s) in the proper location under the DeviceDefinition.capability element.

        4. Discussed Value Set Mappings

          1. Structure will be similar to LIVD mapping

          2. Can maintain consistency with the LIVD object model

        5. Worked through the remaining bugs in Ralf Herzog’s script to generate the Roche catalog FHIR bundle directly from the Excel spreadsheet format.

        6. Successfully posted the Roche LIVD FHIR catalogue.

          1. Performed some initial queries of the FHIR server for returning the Abbott LIVD Catalogue.

            1. Query

              1. Composition GUID

            2. Query

            3. Abbott Diagnostics

            4. ARCHITECT CC v0.9.0

        7. Hans provided updates to the “General” page to be included in the LIVD IG build.

    • Outputs
      • Attached is the zip file that contains the latest spreadsheet and JSON of the test data used, as well as the general.md file containing the updates to date to the LIVD IG, as of the end of the connectathon.
    • Now what?
      • These two days were amazingly productive for the LIVD team and project.  
      • We will continue to progress the FHIR LIVD specification toward publication.  
      • A published (or at least nearly ready to be published) specification should be available for the next Connectathon in Montreal.
      • Link to report: https://docs.google.com/document/d/1Z9JDmZZYncNKDM6Q7ja10-Yw8c3Mz-tCVHJunxBYhEw/edit#
      • Would be good to build a tool that can convert the IICC LIVD spreadsheet or JSON representation to the FHIR resources to enable manufacturers to populate these resources easier
      • Will compare approach in LIVD to current approach in order catalog and create CRs, if needed
      • Finish the ObservationDefinition resource proposal
      • Plan out the work for all the definitional resources (ObservationDefinition, SpecimenDefinition) and CatalogEntry
    • Lessons Learned:
      • ObservationDefinition is different in order catalog than what the lab instantiates based on their performed tests
    • Other thoughts
      • Decide between bundle transaction vs collection?
        • transaction is one choice to exchange the content, which is the collection - need to flesh out the use case for entity to retrieve everything at once vs looking for specific details
      • Workflow would be that lab get LIVD then uses it to help build its own order catalog - the functional model supports import (and export)
      • In LIVD have one expression, but not requirement on how it is exchanged - so far have not worked on search parameters in LIVD to allow looking for just a single mapping in the collection, can currently only search on GUID for publisher and version
      • we need validation of content in LIVD IIC format is the same as in the FHIR resources - tooling rather than eyeballing (build a reference implementation?)
      • Will be workign more on IG this cycle - still have open ballot comments from last round
      • shoudl have 1 more connectathon for LIVD before the STU ballot
      • Step1 = data from IIC format to LIVD FHIR format
      • Step 2 = can we get specific data back out
      • Add more vendors besides Roche, Abbott and Biomerieux
      • Report progress to SHIELD () to have help in getting implementers to the May 2019 Connectathon
      • package additional tooling (spreadsheet to FHIR resource conversion and validation prior to connectathon
      • Question: Names for the LOINC codes:
        • FHIR allows 2 choices: Longname and shortname, but LOINC also now has display name (is only in beta) and Longname is best for mapping
        • Do we have a FHIR representation of fully defined LOINC content? = Regenstrief has LOINC on FHIR - need to follow up on details; but we think we have all we need
        • may want the fully specified name included also, might help to determine in some jurisdictions what needs to be reported
        • Is there a LOINC definitional resource - Robert Hausamto check on Vocab effort

Ballot Reconciliation

  • GF18268:
    • Data definition as section title?
      • this is really conceptual data definitions - not just elements, so not sure we can find a better name
      • Motion to find not persuasive
        • Hans Buitendijk, Riki Merrick
        • no further discussion
        • against:0, abstain: 3, in favor: 13

Election emails should have come out - voting is open till 5 PM ET on January 17

Q2 - OO/FHIR-I

Agenda

Minutes:

Chair: 

Scribe: 

Q3 - OO/CQI/CDS/CIMI

Agenda

  • Order Catalog
  • CIMI workgroup approach
  • Questions from CQI
  • Summarize OO FHIR planning (if time permits) – see here: FHIR

Minutes:

Chair: Lorraine Constable

Scribe: Riki Merrick

Joint with CDS (not here), CQI, CIMI

Agenda review

  • Order Catalog
    • Set of FHIR resources to share catalogs of shareable services or product
    • Observationdefinition, specimenDefinintion activityDefinition, profile on composition, catalog entry
    • Have tested at 4 connectathons for lab tests and lab panels, including what specimen, expected results
      • In the future Medication, devices services
      • All these resources are MM0 – need to get resource definition approved after these connectathons
      • Also plan to build profiles on activityDefinition for different services – first up lab tests
      • Would the observationDefintion be what is ordered
      • The request would be used for the instance and would not have all the allowable variations
      • We used the eDOS lab compendium as basis for developing these resources
    • ObservationDefinition
      • Used to define the tests as well as Ask at order Entry questions and these
      • Will be working on this in more detail Thursday Q2
  • CIMI workgroup approach
    • CIMI is working on modeling clinical data to standardize how data is represented
    • Structural part should be consistent with what OO is defining
    • Content part will be based on clinical experts within HL7 as well as clinical professional associations
      • Example quantitative lab tests
    • Option to get collaboration between OO and CIMI:
      • Have CIMI join OO call on a regular basis – potentially 20 minutes every week = 1 – 2 PM ET = first hour of CIMI 2 hour calls
  • Questions from CQI
    • Working on CDC opioid prescribing recommendation for opioids:
      • Prescribing opioids for chronic pain, do you have a treatment plan (will ask PC to find out what that is and if carePlan can be used – it would need to be specific for he opioid) is that is periodically reviewed (does that review involve the patient = procedure or internally = task) (e.g. every 3 weeks)– we want to avoid observations that just ask these as questions for the measure
      • Check for completion of task of creation of treatment plan and task of review of treatment plan, if internally, else procedure similar to med reconciliation
      • Reviewed could also be a status – it is not part of the status value set at the moment, and there is precedence with other status values that have a history
      • Task is a worklist, so I can create a task to review the carePlan, carePlan status remains active / or would the carePlan status change, even if no changes have been made to indicate it has been reviewed
      • Check the meta data attributes for resources and see, if that
      • Procedures are actions that are intended to change physically or mentally the subject
      • Observation does not expects changes
      • Store the snapshot of the resource when the review happens
      • What are next step to get input from clinical community on this type of question; maybe CIC
      • For immunization CDC is working on HIMMSS and AERA collaboration
      • In other FHIR situations they did investigative project to get best practice for specific use case
      • Task is on the OO work plan for the next quarter, Durable Medical Equipment (DME) ordering might help get clarity (CMS project) – would be good to test in connectathon
      • What happens when CDS hooks create a requirement to do something, how does that flow into FHIR workflow -
    • Using ratios in structured data:
      • Example lab result: 1:4
      • How can you create a calculation to show a change in ratio – e.g. 4 fold rise in the titer
      • Could use the interpretation element, but those would be for each individual titer based on the reference range for the specific test from the lab
      • Would have to be additional observation by the medical officer to append the report
      • Also need to know how the observation is stored in the LIS (text vs structured number) – don’t think it is in computable format
      • You should be able to say for titer to define thresholds:
        • <=
        • =
        • >=
      • CQL is planning to go to ballot
  • Summarize OO FHIR planning (if time permits) – see here: FHIR
    • Please review and comment on the page
    • DeviceStatement was created by CDS a long time ago – is it still needed
    • Green colored resources all fall into healthcare product discussion
      • What is breastmilk – biologicallyDerivedProduct (used in IPS), substance, product = that includes plasma and other blood products – discussion is Tue Q1 and Q2
    • DiagnosticReport
      • UScore requires it for panels in lab vs use as observation
    • ObservationDefinition
      • Why not create a profile on observation
        • Because definition can provide all allowable information on the observation attributes
        • Special use cases need to define kinds and options
        • Reference range dependent definitions

Q4 - FHIR-I/OO/InM/MnM


Agenda

  • FHIR Workflow (Lloyd McKenzie)

Minutes: - see FHIR-I - NEED LINK!!!

Tuesday, January 15, 2019

Q1 - OO/HCD+Rx+BR&R

Agenda

  • HealthcareProduct

Minutes:

Chair: 

Scribe: 


Slide Deck .pptx

Slide 1

Slide 2

Slide 3


Uploaded deck with proposed use cases and diagram. 

Q2 - OO/PH + Rx + BR&R + FHIR-I + HCD

Agenda:

  • HealthcareProduct
  • Order Catalog
  • Various WG Updates

Minutes:

Chair: Hans Buitendijk

Scribe: Riki Merrick

Have representation from Rx, BR, FHIR-I, Not PH, HCD

  • Agenda review
  • HealthcareProduct update
    • Diagrams from Hans see prior quarter
      • Review OO owned resources (green) that are related to other existing resources (purple) and new / proposed resources (orange)
      • Medicinal Product = IDMP
      • MedicationKnowledge = Formulary
      • NutritionOrder will use substance
      • BiologicallyDerivedProduct (taken from person, processed of some kind before re-use) vs Device, Substance (compounds to create medication, nutrition), MedicationKnowledge
        • Person or manufacturer originally
    • BiologicallyDerivedProduct – already captures tissue, bloodProduct and organ, but not yet fluid, cells, agent
    • Device can have components hence the recurring error (existing)
    • Substance can be comprised of other substances – also recurring error (to be created)
    • For all of this we need to track supply / inventory etc – can combine these types for these purposes
    • What is the boundary of device vs medication – example EpiPen; may need guidance for these, stent with medication embedded other examples
    • Hoe does specimen relate to these resources? Can be obtained from any of these
    • These are the topics we will progress this discussion on the Monday calls 1 – 2 PM ET start date TBD
    • Difference between device or medication:
      • When ordering a medication MUST have medicationRequest but can add definitional context type data by using medication resource and/or medicinalProduct and/or medicationKnowledge
      • Same for administering and dispensing medication and statement
      • So use medication for argument’s sake
      • Examples:
        • EpiPen: delivery device for the medication, so more of medication
        • stent with embedded medication?
        • Sponges for anticoagulation – is considered either depending on the jurisdiction, so hard to draw the line
      • Maybe if the “thing” is individually identifiable, then device, else mediation?
      • Original purpose of the thing
      • Persistence of the thing
      • HealthcareProduct could combine all the attributes we need for each of these resources – for the organization they can then use healthcareProdcut to combine the reference together parts together, while not being impeded by regulatory differences in different countries; medicinalProduct already has medication that has devices included – original use case was for regulatory submission, but could be used for other uses, too
      • http://build.fhir.org/device.html
      • Make statements that device or medicine would be interchangeable in catalog or lists
      • HealthcareProduct could be made so generic that it could be either medication only, device only, combination of medication and device
      • If the combination product is implanted in a patient and the product is treated differently in the 2 countries where the patient lives
      • How to query for the same thing, when they are classified as something different – medicationStatement or deviceUseStatement and the differences in administration / dispense
      • You always have to look at both devices and medication
      • If this is structured as device, currently cannot get to medication from that site
      • Do we need to add optional device that is part of the MedicationStatement (example implanted insulin pump) – add reference to the deviceUseStatement
      • Do we need a reference in device to m
      • MedicinalProduct or the medication (code at the minimum)
      • MedicinalProduct may need to review if they need to change the reference to deviceDefinitions
      • DME discussion – have no specific time at WGM yet

  • Order catalog update
    • Connectathon report
      • Had catalog track tested PHAST server of catalog and Quest mock up client (still need to add AOEs) – 4th in a row = eDOS on FHIR
      • The catalog from Quest fit into the designed order catalog resources, so may upload that into PHAST server for the next connectathon to allow accessResources used:
        • Profile on composition
        • catalogEntry
        • ActivityDefinition
        • observationDefinition (AOE and output of test service)
        • specimenDefinition (describes sample(s) required to perform the service
    • Project calls are weekly on Wednesdays 1 – 2 PM ET
    • Next steps
      • Define activityDefinition profile for lab catalog – constrain out all the elements that are not needed and add extensions that are needed
      • Build an implementation guide for lab catalog
      • Discuss differences between LIVD and order catalog:
        • LIVD is more of a catalog of devices
        • LIVD created extensions to observationDefinition, consider adding those into the draft resources now
      • Does Rx have discussions about use of catalog for formulary by using medicationKnowledge as entries in Q1 today in Rx had discussion about use of medication v medicationKnowledge (there are several common elements between these resources, boundaries are not very well defined) – should we rename medicationKnowledge to medicationDefinition?– Rx WG is reviewing and will update the
      • Medication is more the representation of an instance of the kind of medication, while medicationKnowledge is the definition, so there is data that is the same – similar to specimen and specimenDefinition: definition lists all the allowed options, while the specimen is the instance; there may be elements that are pure copies for convenience sake when using medication from medicationKnowledge (definitional) there is also overlap with medicinalProduct (regulatory)- both of these may need to be used for definition (medicationKnowledge is around the pricing, ways it can be obtained, while the medicinalProduct describes the manufacturer, packaging etc)
      • catalogEntry resource proposal = need to determine if we need it in order to allow ordering of the items in the catalog
        • and there are a few metadata about the service in this resource, that does not belong into the original resource – e.g. orderable flag and who validated the entry, when it is valid in the catalog
        • so it makes it easier to support profiling, so that the resource to point to can always be the same regardless of the items in the catalog
        • or add these meta data attributes to composition.entry
        • planDefinition is a similar resource and it has a flexible set up – has same resource for list and ??
        • allows the creation of groups of entries in the catalog, that is re-used within the same catalog, rather than having to re-create it from all its components every time – unsure about re-use across different catalogs
        • Next step: draft up what each of the solutions would look like and discuss on the call – resolve by end of February and bring resource proposal to FMG

 

Q3 - OO

Agenda:

  • Administrivia & Projects
    • Mission/Charter Review
    • Re-Affirmation PSS
    • Close project 1238?
  • V2.9 Ballot Reconcilliation
  • V2-to-FHIR?
  • FHIR Resources?

Minutes:

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • · Agenda review
  • · Updating the main confluence page= Orders and Observations
  • · Draft Mission and Charter: OO Mission and Charter - Pre-Publication
    • Background:
    • Edit last sentence to say the OO-developed standards and implementation guides are now being used for such content across the globe.
  • · Mission:
    • No change
  • · Charter:
    • … is to support the ongoing of HL7 Version 2, HL7 Version 3, and HL7 FHIR, This includes harmonizing standards across product families where appropriate and necessary.
    • Work Products:
      • List general topic areas first and then list some of the work products
      • Lab:
        • Lab Automation
        • Anatomic Pathology
        • Specimen Mangement
        • Excluding Clinical Genomics
        • Bloodbank, Transfusions and Donations
        • Radiology orders and results
          • Excluding images
          • Pharmacy
            • Med prescriptions, management and administration for V2
          • Nutrition
            • Dietary order
          • Materials Management
            • Supply
            • Logistics
          • Healthcare devices
            • Orders
            • Observations
            • Excluding internal device management
          • Clinical Trials for V2
          • Product Experience for V2
          • Alphabetize the list
          • Then list the base standard parts we own for V2, V3 and FHIR and update Version 2 chapters to include parts of chapter 10.
          • Update the overlap sentence to highlight just OO for V2.
          • Version 3: Clinical Statement Common Product Model
    • Formal HL7 relationship:
      • At SD had discussion about this section and requests that TSC to review to drop this section overall – as all the relationships are really defined in the respective PSS:
      • Add for coordination of project scope the FHIR and V2 Management groups, US Realm Steering Committee and Administrative Steering Division – remove these, because we cannot do work without these.
    • Will have to have this voted on by ASD.
    • Motion to approve
      • Freida Hall, Jim Harrison (or JD or Lorraine)
      • no further discussion
      • against: 0, abstain: 0, in favor: 11

 

  • · Project insight:
    • #1238 = UDI –
    • Motion to archive
      • Lorraine Constable, Riki Merrick
      • further discussion:
      • question about UDI: there are several projects:
        • UDI pattern owned by OO – how to express UDI in the different standards, that is normative for V2 and V3 and STU for FHIR, but now that R4 has been published, we need to update the UDI pattern document to match F4, then re-ballot with that content based on R4; this will be done on Monday calls 1 – 2 PM ET;
        • UDI in C-CDA template for UDI information owned by SD
        • UDI DAM work that was started before the pattern document was completed – it was an appendix in the UDI DAM, but we cannot find it as published – need to find out what we want to do for that – for discussion on the Monday calls; FDA is looking for a way to enlarge the scope of that DAM to include non-implantable devices; if the decision is made to publish the DAM as part of the discussion, then we may still need this = ballot cycle informative in Jan 2018 was under #1238
        • #1238 was superseded by #1369, if we want to progress the DAM, then we should write a new document
    • Table this motion until that discussion can be had and the Monday group has a recommendation about publication of the balloted UDI DAM.
    • Who do we need on FDA side (Fed and contractors) for UDI DAM and the pattern work – maybe set up a smaller group to understand that – Lindsay to let Hans know
    • Hans is coordinating the Monday calls – includes HCD and RX WGs, so would need to work off agenda topics for the participation
    • If we expand the DAM, can then may need to review the existing products
    • #1369 = Cross paradigm, this is what we used on publication

Q4 - OO/II

Agenda:

Minutes:

Chair: 

Scribe: 

Option 1: Dissolve Media into DocRef and Attachment DT and add Attachment as valueAttachment. Elliot, Jonathan

Option 2:  Keep Media and DocRef, and add Attachment as valueAttachment to Obsv.  Revert Media to DSTU 2/3-ish (less eventish).  Eric Haas, David Burgess

Option 3:  Keep as-is and clarify how to query and get data expressed either in Obsv or DxRpt. JD Nolen, Dan Rutz, Grahame Grieve


Use case clarification, Boundaries are not clear, Attachment is the observation, Patient Wound, Questionnaire, Endoscopy - JD Nolen, Dan Rutz, Grahame Grieve



Initial discussion Jan 29.



Workspace to progress work.

Wednesday, January 16, 2019

QO - Birds of a Feather - AUC Update

Meeting notes:

Chair: Hans Buitendijk

Reviewed the attached slide deck.

Q1 - OO/HCD

Agenda:

  • HealthcareProduct

Meeting notes:

Chair: JD Nolen

Scribe: Ken McCaslin

Device definitions: Continues conversation from Q3, Q4 on Tuesday

Bio-banks – need to determine how best to identify this effort in the medical product, supply, so on

Need to have clarity about regarding vaccine and other items if they are a product, derived component  and how best to drive the relationships – See the Immunization Boundaries and Relationships for some clarity

Might consider building a comment only ballot for May to request input on the many ways to manage issues around Biological, derived, blood (packed, or other), vaccines or other products how best to represent them. How best to group the concepts and how do they transition from components collect to products in either derived, manufacture or some other process to become a supply component. Need to build a light weigh model to drive the map of how to bring all these together.

  • Need a pattern for the work follow of how products be recognized as something that can become a product to be applied to the patient
    • Need to sequence the process to see the work flow and what data points are necessary to be captured in the process
    • Need a supply work flow –
    • Is it a device or bio-product
    • What is the healthcare product outcome and process and is there a reliable process for all situations
    • Need to see the pharmacy operations process to see how this should be tied into the data that should be collected
    • How does the catalog get updated and when does something go from biological thing to product for a patient
    • See the diagram that JD created for HealthCareProductLandscape
    • Deadline for ballot content – is 17 February to gather comments about the concepts
      • Comment only ballot to get feedback on the many concepts that might define the process to see if there is anything the WG has missed.
      •  Will align this with Project Insight project # 952
      • Believe we need to have a meeting every week to gather the data for the project.
      • Need to consider a doodle poll to determine best time for scheduling a meeting needs to be aligned with those in Europe to be engaged. It is proposed that the best place to discuss is Monday 1-2pm ET with the Derived Bio product call to build this for comment ballot project.

Motion: Expand the current working draft and the healthcare landscape into a white paper that defines open questions for health products:  Lorraine Constable/Ken McCaslin

  • Against: 0, Abstain: 2 For: 9
  • Use cases: Blood bank, Breast milk, formula, Supplemental Nutritional items, lab, organ, TPN, IVF, Medicated Stent, pacemaker,  (lab, Nutrition, pharmacy or transplant).
    • Look at specimen collection process to see how well the models used for collecting specimen might also work with derived products.

Q2 - OO/II/CG

Agenda

  • Project Updates
    • II
    • CG
    • OO
  • Media/Attachment DT/DocumentReference/DiagnosticReport/Clinical Notes

Minutes:

Chair: Hans Buitendijk

Scribe: Riki Merrick

CG /II / no one from BRR

Project Updates

  • II:

    • Missed something?

    • Going to ballot – replacement for CCOW – synchronization, browers friedlye, cross- device and platform – aim for May2019 /Sep2019 – Co-Sponsors; FHIR-I, Security – INM is responsible for CCOW, so should check with them

    • FHIR R5: Imaging resource FMM increase, add resource to be able to call out a specific imaging instance from the imaging study (had one previously that allowed for a collection of things and not clear in the meaning)

  • CG:

    • Updated Genomic Reporting FHIR IG was in ballot – passed quorum and approval – have 3 Negatives and a few affirmatives, working through recon now, publish by spring

    • BiologicallyDerivedProduct work is on the docket

    • CG has profiles based on observation and diagnosticReport are being moved into the Genomic Reporting FHIR IG

  • OO:

    • V2.9 ballot had about 40+ comments on OO owned chapters, nothing related to II and CG

    • Plan for FHIR R5 (2 year plan) – FHIR

      • Items in green are related to healthcareProduct discussion, listed alphabetically, OO has set up on calls Mondays 1 -2 PM ET to progress these closely together for R5 targets – how they relate to each other, work with HDC, Rx and CG, goal is at minimum to get resource proposals approved by May 2019

      • Items in brown related to the observation/media/attachments and also diagnosticReport – calls are Tuesdays 2 -3 PM ET

      • Definition resources are being discussed in catalog calls Wednesdays 1 – 2 PM ET

Healthcare Product Updates


  • Had 2 quarters of discussion already: LINK to the quarters
  • Create a for comment ballot around the landscape around these related resources
  • calls are Mondays 1 -2 PM ET
  • have reviewed based on these questions:
    • what is the source
      • some deviation in data elements
      • what are the process steps
          • a lot of overlap
          • how to supply = a lot of same
    Would software be device – possibly, but we have not yet modeled it


Media/Attachment DT/DocumentReference/DiagnosticReport/Clinical Notes

  • Had discussion Tuesday Q4 – ADD link to it
  • Decided to collect specific use cases
  • Use the same space for all the options here as well as the primary collection space
  • Decided to create examples to show how the solutions would look and pros / cons for the respective option
    • Option 1: Dissolve Media into DocReference and Attachment datatype and add Attachment as valueAttachment
    • Option 2: Keep Media, but revert to DSTU2/3 (less event like) and DocRef add Attachment as valueAttachment
    • Option 3:Keep as is and clarify how to query and get data expressed either in Observation vs DagnosticReport

Goal to have this resolved by Sep 2019 WGM

Ongoing discussions will be on OO on FHIR calls Tuesdays 2 -3 PM ET

What does it mean “add valueAttachment to observation”

  • in observation.value allow attachment datatype to be used
  • Can only have a single value in observation.value, but you can have derivedFrom attribute

Looking at January 9th call:

  • Summarized boundary between observation and media and boundary between DocumentRef and media
  • Boundary between ClinicalNote an DiagnosticReport is discussion for Wed Q3 joint with PC also
    • Problem statement:
      • ClinicalNote is very variable, many clinical notes are written on paper, rtf or other format, v2 segments from lab reports
        • Clinical Note definition: text paragraph of a note authored by clinician
        • In a document several parts of the paragraphs there
        • NOT a discharge summary
        • NOT a compilation of multiple reports / results etc, though it may include a reference to a single result or so
        • Not a CDA, not a complied unsigned report
        • Clinical notes does have sections, where others data may be pulled in = lab results, medication list, summary of DiagnosticReports
        • Informal message from clinician: example something the radiologist technician noticed during the imaging = chartable comment = nursing notes and technologist notes
        • What is not a clinical note = anything administrative
        • DiagnosticReport:
          • Lab Report
          • Anatomic Pathology report
    • Do we need to include DocRef or composition in this discussion in FHIR
    • Current FHIR interpretation:
      • Can use different resources, for example create observation or composition and set the “.category” attribute to “clinical note”, but use the DocReference with the category of clinicalNote to point to those resources
        • Hans slide
        • Separate publication vs discovery side / search
        • Are we imposing constraints on DiagnosticReport by calling it “Diagnostic” – potentially rename that resource
        • Currently we are co-mingling these constructs in working systems
    • When should you use DiagnosticReport vs Composition?
    • When is either one of these a clinicalNote?
    • Do we need a ClinicalNote resource? = there is not really a new resource, but rather a profile on Composition
    • Why not just look for a code in the LOINC document ontology – that is the valueset that is used for the type attribute, which is required in USCore; in USCore profile DocRef.class (R3) = DocRef.category (R4) = clinical-note
    • USCore approach seems reasonable to cover the different resources that could be decided to be a clinical note (Jay Lyle)
    • Option to expand this solution to adding a category attribute to any resource that is understood to be a clinical note – that attribute would need to be 1..*
    • Discussion if category is the right attribute for this use (or type and limit the LOINCs that apply to it) – that was not the request
      • Similar to status in condition, that ended up getting split into verificationStatus and clinicalStatus
    • Do we need to provide guidance on what should be a clinical note
      • Answering a question (DiagnosticReport)
      • Describing a process (procedure note / Op-Note)
      • Including Therapeutic information
      • Summary of a Diagnostic report used in clinical care decisions
      • DiagnosticReports are based on orders, clinical notes are not (though they could be result of a referral)
    • In IHE had discussion for XDS:
      • Class is singular (which in FHIR got renamed to class)
      • Type can have multiples
      • Then regions can define what LOINCs belong to what class, but at the time of publication would have to pick ONE
      • IHE dictionary get link from @John Moehrke
    • For the difference between composition and DiagnosticReport – does the order help make that distinction?
      • A composition can contain a DiagnosticReport
      • If you have an order you normally expect either a DiagnosticReport or observation
      • What about a structured DICOM report – since we mapped that to CDA in V3 – so would expect a composition to be returned
      • What about a cath-lab procedure? MISSED ANSWER
      • Should DiagnosticReport be a profile on composition
      • DiagnosticReport was structured close to ORU v2 message, where the structure is focused on panels and results
      • Composition is used to create sections – it supports patient and authentication
      • Still Open when to use which one
      • Also possibly rename the DiagnosticReport or create a reportDocument profile on composition – at that point need to reach out to Structured Doc

Next WGM keep same joint quarter – Ulrike Merrick will double check if BRR wants to join or not

Q3 - OO/FHIR/PC/CQI/CDS

Agenda:

ePayer Data Exchange (ePDx)

ePDx Overview

ServiceRequest Trackers

  • GF#19782 apply QA changes to Specimen, ServiceRequest, DiagnosticReport, Task, BodyStructure, Device Medium
    GF#19610 ServiceRequest intro sentence is misleading
    GF#19516 Substantive workflow changes for OO resources
    GF#19443 Add DetectedIssue as reference type for ServiceRequest.reasonReference Medium Nobody
    GF#18838 Add support for instructional
    GF#15726 add unit and total cost to ServiceRequest

 DiagnosticReport/DocumentReference?

Minutes:

Chair: Lorraine Constable, Hans Buitendijk

Scribe: Riki Merrick

ePDx Overview

  • using FHIR R4 PLUS will backport to FHIR R3 (Argonaut) – evaluating if UScore will work
  • building a mapping from ?? interchange format to FHIR profiles on clinical resources
  • should be considered a data dictionary
  • seems to be taking clinical information from claims / payers?
  • PSS review:
    • Timeline for request for comment ballot in May 2019; there will be demo of this flow in sandbox at HIMMSS with synthetic data and also had connectathon track Jan 2019, and connectathon in May 2019 in parallel to the
    • STU in Sep 2019
    • Question about the data feed quality = how will that work? This is supposed to be indicators that there was some process performed to do more research to get to the medical record – also have record of existing meds that have been paid for
    • Need to be sure we have a good understanding the provenance of the data and how the data is fit for purpose and deduplication
    • PC is co-Cosponsor already
    • What about asking Structured docs, since a lot of this data is CDA based
    • Motion for OO to be co-sponsor with periodic updates
      • Hans, David
      • no further discussion
      • against: 0, abstain: 5, in favor: 21

HealthcareProduct update:

  • Sharing image around the Diagnostic Report vs clinical notes
    • Orange elements does not exist
    • Blue items exist
      • OO looking to provide guidance on when to use DiagnosticReport vs when it is considered a clinical note – we have no specific rule there
      • OO looking to provide guidance on when to use DiagnosticReport vs composition – still needs more work
      • FHIR UScore decision was not controversial
        • In the IG we required to expose the attachment in the DiagnosticReort as well as in the DocReference
        • Still need to look at the attributes and how they are represented in the base
      • There is a difference between a report and a clinical note – some diagnosticReports can be
  • LINK to workspace
  • Scope of DiagnosticReport – should it be genericized? Is planned for the Tuesday’s call
  • Michelle will email the trackers from the last WGM to Hans to add here!!!!
  • Calls going forward are Tues 2 – 3 PM ET

FHIR Trackers:

link to slides; https://docs.google.com/presentation/d/167TrBxa4_zhtoN95D5v87jGPpixCoEoftaVO6z4pFWU/edit?usp=sharing

 

GF#19610 ServiceRequest intro sentence is misleading

  • link to servicerequest resource in current build:
  • Change the rest of the sentence from “” to “on or for a patient”
  • Motion to find persuasive with mod
    • Eric Haas, MichelleMiller
    • further discussion:
      • Are we opening up the issue about the difference between order and request? We should be using different words for describing what it is, so order is ok – remove the () so that order, plan or proposal are at the same level
      • Final changed text:

ServiceRequest represents an order or proposal or plan, as distinguished by ServiceRequest.intent

 to perform a diagnostic or other service on or for a patient.

ServiceRequest represents a proposal or plan or order for a service to be performed that would result in

Against: 0, abstain: 5, in favor: 19

GF#19443 Add DetectedIssue as reference type for ServiceRequest.reasonReference Medium 

  • ServciceRequest.reasonReference = justification for the service
  • Requesting additional resources – would like to add detectedIssue resource in order to use gap in care as a reason
  • Motion to find persuasive
    • Eric Haas, Dan Rutz
    • further discussion:
      • ImmunizationRecommendation would that be another addition, since he brings that up as a use case = should that go under based.On?
      • when do you use either one is more discussion, so do we need a new tracker to at least discuss the difference in usage when to use reasonReference vs basedOn?
      • also make a tracker to add in ImmunizationRecommendation here as well
      • Against: 0, abstain: 3, in favor: 21
  • GF#18838 Add support for instructional
    • ServiceRequest: Looking for a way to provide patient instructions – is that a new serviceRequest
    • supportingInfo has reference to any, but that would not fit here
    • CommunicationRequest – this seems to be widely used – has a “basedOn” that can point back to the ServiceRequest that spawned the instructions / educational material
    • patientInstruction: is a string = this is intended to give the patient instruction for this specific request, but the kind of instruction the submitter is looking for is covering a larger aspect
    • could this be covered by task to arrive at the delivery of the educational material to the patient
    • zulip chat– differentiate between educational material = education is a service:

Zulip chat text

Hi,

I am implementing encounter FHIR resource from CCD.

In my CCD, i have an Emergency Department Visit encounter. That Encounter also contains discharge instructions but I am not sure where to map discharge instructions in Encounter FHIR resource.

Hospitalization in Encounter resource doesn't have any text or instructions field.

Thank you for the help !

 

MM response: FYI - This question has come up before within Patient Care since we own the Communication and Procedure resources. I don't recall any decisions, but here were some of the discussion points:

Education is within the scope of Procedure.

Communication and Procedure resources. I don't recall any decisions, but here were some of the discussion points:

Education is within the scope of Procedure.

Is instruction the same as education? If not, how should the boundaries be determined? The closest we got was:

** Instruction is intended to have the patient or family take some action, like self management or make a follow up appointment.

** Education is to inform the patient, like the risk of disease or the risk of side effects or adverse outcome of a medication or procedure, then it is education.

A lot of things are labeled as instructions, but have no similarities except that they are a communication with a patient or family member.

Communication.catrgory has an example "instruction" code, per http://build.fhir.org/valueset-communication-category.html , but we never landed if the Communication.payload.content would be a string or another resource.

Oh, and Hospital Discharge Instructions is also an example Composition.section.code per http://build.fhir.org/valueset-doc-section-codes.html

Valueset-communication-category - FHIR v4.0.0

http://build.fhir.org

http://build.fhir.org/valueset-communication-category.html

Valueset-doc-section-codes - FHIR v4.0.0

http://build.fhir.org

 

instruction is intended to have someone take action

CommunicationRequests requires someone in the healthcare realm to do something, while the instructions for a procedure is often not part of a tracked workflow at this time

The text itself should live independently form the CommunicationRequest, so it can be re-used etc – already taken care, since CommunicationRequest has means to reference outside resources or attachments

Communication has about / part of and basedOn

Adjust the datatype for patientInstructions from string to markdown / attachment or DocRef

  • Performer instruction and patient instruction should be separate
  • Adding cost information to ServiceRequest – need to work with FM on that to give proper use case
  • Next Steps:
    • Create a use case – this should not be considered a workflow at this time, only when it MUST be tracked
    • Also reach out to Emma to get her input on a PC call Thursdays 4 – 5 PM ET, Eric will see, if PC folks can attend OO on FHIR call Tuesdays 2 – 3 PM ET
    • Also ask Rx WG to see what works for them

DiagnosticReport/Clinical Notes/DocumentReference

Reviewed Wednesday Q2 discussion.

See GF#19249 to address the topic of putting category and type on relevant resources (along with guidance).  This also includes:

  1. DiagnosticReport.category - GF#19252
  2. DiagnosticReport.code for procedure - GF#19253

Q4 - OO/FHIR/PC/CQI/CDS

Agenda:

V2-to-FHIR

FHIR Resources?

V2.9 Ballot Reconciliation https://docs.google.com/spreadsheets/d/1rhHG41AUUPnAhWcHjtcUFp77wrRzrpKXMTDYYD2AjOo/edit?usp=sharing

Minutes:

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • 2-To-FHIR
    • Where would content end up?
    • Have not thought about that for now confluence for workspace
    • Mapping is from v2 to FHIR, with latest published version, because that presents the superset of all data elements, will add on new changes in mapping going forward
    • If interested sign up for v2toFHIR listserve
    • Content track
    • Tooling track
      • Have Thu Q0 starting at 7 AM in Chula Vista Boardroom
      • Had started with mapping datatypes, but sometimes they map to resources, sometimes to multiple different resources
      • Will map segments and fields
        • We may need message types for some of these as well
        • Fields will be mapped to the lowest possible level
        • Will make note of where the gaps are in the FHIR resources and will review if it is used those are the ones to aim for, based on what people are using (how do we do that)
    • What about the table mapping and FHIR valueset mapping?
      • There is already a harmonization effort between v2 and FHIR, so let vocab WG work on that for now
      • Known issues:
        • HL70001 and FHIR admin gender – there is a discussion on
        • Observation.status is mandatory and the values are not mapping 1:1 from HL70085
      • So we will create a page to note these issues and may consider updating the PSS for the critically required elements (e.g. required elements in FHIR, that have valuesets associated with that) – so we can at least create a list of priorities – get input from existing mapping for example in UK
    • Update the names in the Confluence page
    • Datatype mapping page
      • AD to review the format:
        • Left HL7 V2, right FHIR, comments
        • Complex datatypes are broken up in the tables
        • Entries in the FHIR side are first strawman drafts – all open for discussion
      • Tooling track is about how to make the official HL7 tool
        • It should be consumable in FHIR to help populate the mapping tab as source of truth
        • It should be consumable in v2+
        • For review and for maintenance
      • Have folks used the FHIR mapping tabs? As informative = Keith has done this abstraction and can share
      • What goes into the mapping rules
        • If here, then use this, else somewhere else
        • If we already know specific places have specific rules, then we make different datatype flavors
      • Would it be helpful to include example snippets of both v2 and FHIR – we for sure like to have this for the tool for verification and at a later point in time
    • Timeline?
      • Not a hard deadline, will work as we progress and update PSS, when needed
      • Keith has ORU for measured results and ADT message conversion to FHIR done
    • Call schedule:
      • Every two weeks at the moment COPY may change to Mondays only, if NZ is not interested – Hans will check
      • NEXT call 1/22/2019
  • 2.9 ballot recon = https://docs.google.com/spreadsheets/d/1rhHG41AUUPnAhWcHjtcUFp77wrRzrpKXMTDYYD2AjOo/edit?usp=sharing
    • #99 = Erin in person comment related to ORC-21
      • During ballot recon on LOI or LRI we had discussion about the importance of knowing the original provider that collected the specimen / facility from where it originated for PH; so they need to call back to find out where the patient was located for infection control – in v2.9 we are moving to use PRT for fields like ORC-12/OBR-16, we could be able to indicate more than just the ordering provider.
      • Looking at ORC-12 – this is for backwards compatibility, should we make the comment here, or at the PRT?
      • We should make this clarification in V2.6 as an errata and do that there rather than here
      • Propose in PRT section in chapter 7
        • Can be as part of the introduction of PRT – we are not currently doing ANY explanation of how to use PRT for any f the elements now being used for backwards compatibly and point to IGs for further explanation
        • Create examples for use in that section instead
        • Consider, if this is not related for this ballot round, since it was not changed this ballot round – though these changes are NOT substantive that would require re-balloting
          • Motion to
            1.            Find considered for future use / not related if for future use in not allowed by ANSI
            2.            proceed with harmonization to get the correct participation codes in HL70912 to support this use case (and others we already know about)
            3.            update the base standard in future release in the PRT segment section
            4.            put in a STU comment for LOI/LRI to be updated to include that as additional PRT for the original ordering provider (or physician at place of specimen collection)
          • Erin Holt, Riki Merrick
          • Further discussion:
            • Who is the person PH is most interested in – the person that ordered the specimen collection, not so much the person that actually performs the specimen collection
          • Against: 0, abstain: 4, in favor: 8
      • # for all AT in chapters 4, 4A, 7, 13, 17 and OO content in 8
        • Motion to have editor review the AT and fix and bring back any that are not AT, David, JD, no further discussion, against: 0, abstain: 0, in favor: 1
    • Update from Vocab
      • Harmonization proposal to extend HL70001 to include an extension for non-binary administrative sex


Thursday

Q0 - OO

Agenda:

V2-to-FHIR Tooling

Minutes:

Chair: Hans Buitendijk?

Scribe: Hans Buitendijk?

V2-to-FHIR Tooling

Challenges raised

Identifier mapping.  E.g., mapping NK1s into Patient contacts.  If you don't take that into account, could get stuck.

  • So far we separated between matching and translation.

Mappings are not straightforward.  Are we driving humans or machines?

Grahame will be trying to stop converting V2 messages to FHIR messages directly (key 2019 message).  The resulting FHIR messages are ending up being too complex.

  • However, there is a strong interest in portable mapping specs.

We all agree that any mapping specification can only be a start (informational and technical) as individual V2 messages may have wide variations on data placement and use of z-segments.  However, this would provide a great step forward and reference.

We all agree that our plan is not to map every V2 element/component to a FHIR core resource component or existing/new extension, but focus on what is actually used (which may not exist yet in FHIR).

There is an need for vocabulary mapping.  That is still out of scope of the PSS, but there is growing interest to focus at least on certain sticky mapping areas.

Various tooling considerations:

  • There is interest to start and show by way of examples/snippets.
  • Confluence is at the moment a starting point in the absence of an agreed to tool.
    • All pages are available in spreadsheet format for at least the left V2 columns.
    • Good collaboration capabilities.
  • FHIR ConceptMap could be used for most mappings, but not all the context/conditional variations that may be in play.
  • FHIR StructureDefinition and FHIR Mapping Language can get into the remaining conditions/context statements.
  • We need to recognize "business analyst" use and "developer" use of the tools.
    • It must be easy to maintain the mappings without having to know/read/edit XML/JSON/etc.
    • The content must be easily accessible by tools to ingest into their capabilities.
  • The content should be able to be "included" in FHIR tabs for mapping, V2+ tabs for mapping, and "independent/other" access.

The question is raised how we come up with a "final" answer to what HL7 will use.

  • A suggestion for a bake-off at some point time is not very appetizing.
  • We need to work through various alternative approaches.
  • There is need/opportunity to sync with other mapping approaches.
  • Need to work with Grahame as most tooling/mapping discussions are moving to be FHIR based in some fashion or another.

There is interest to have a V2-to-FHIR Mapping Tooling track at the next FHIR Connectathon in Montreal.  About 4-5 parties in the room showed interest already and have not reached out yet.

  • We should not just have 1-2 prep meetings before then, rather have a tooling conference call track.
  • We agreed that Sean Muir will establish a conference call track  focused on tooling to progress that discussion.
  • Hans and Sean will get the track on the Montreal Connectathon list.

As the tooling discussion progresses, we'll use the content discussions to validate/review how/when we can enhance/flip the Confluence pages to the agreed to target tool (once ready).


Q1 - OO

Agenda:

update of Specimen Conceptual Model

Minutes:

Chair: Lorraine Constable

Scribe: Riki Merrick

  • We should reach out to CG Co-Chairs to check on the work they did for specimen Ulrike Merrick
  • Specimen DAM EA model work:
    • Need to simplify the associations between classes and make them bi-directional
      • SpecimenContainer and ContainerParameter 
        • 0..* on SpecimenContainer side, because a parameter can describe more than one container instance
        • 0..1 on the ContainerParameter side
      • Container and holder (anything else that is not directly touching the specimen, but not storage equipment)
        • 0..* on SpecimenContainer side
        • 0..1 on Holder side
      • Product and SpecimenProcessingActivity
        • 0..* on Product side
        • 0..* on pSpecimenProcessingActivity side
      • SpecimenProcessingActivity and Specimen
        • 0..* on Specimen side
        • 0..* on SpecimenProcessingActivity side
      • Holder and StorageEquipment
        • 0..* on Holder side
        • 0..1 on StorageEquipment side
      • StorageEquipment and StorageEquipmentParameter
        • 0..1 on StorageEquipment side
        • 0..* on StorageEquipmentParameter side
      • SpecimenMoveActivity has references to
        • Performer
          • Need to update definition of performer - THAT was ballot comment #14, that did not get applied tot he latest document Ulrike Merrickto do AND check the ballot spreadsheet to make sure ALL OTHER comments have been applied!
            • 1..* on Performer side
            • 0..* on SpecimenMoveActivity side
        • SpecimenContainer - is that true
          • 0..* on SpecimenContainer side
          • 0..* on SpecimenMoveActivity side
          • isn't moving a speicmen between containers a processing step? = for discussion on a specimen call
        • Holder
          • 0..* on Holder side
          • 0..* on SpecimenMoveActivity side
        • specimen - is that true?
          • when a specimen is split across multiple containers, is that one or two specimen - example 24 hour urine collection - is still one sample
          • that is different from taking a specimen and aliquoting it = that would be a derived specimen
          • Does a move create a NEW specimen, or only processing?
            • what constitutes a new specimen - we said last time, yes, becasue it could be a move that results in the assignment of a NEW specimenID as resolution to ballot comment #51
            • consider re-opening this to remove this relationship and resolve representing the addition of a new identifier differently
            • this needs to be discussed on the specimen call Ulrike Merrick to send note about this to the listserve and schedule a specific call - make sure Raj Dash, JD Nolen and Kathy Walsh among others can be there

Changes were done in EA file, latest version is here: Specimen DAM model

  • Note HL7 has a license for folks that are ONLY using it for HL7 work - can comment on the cloud stored documents, but need client version to model

Latest version of the Specimen DAM document: http://www.hl7.org/documentcenter/public/wg/orders/V3_DAM_Specimen_R2_INFORM_2018JUN.docx

Latest version of the DAM as image (end of the quarter):

Q2 - OO

Agenda:

FHIR Resources

ObservationDefinition

Order Catalog

Dental Interop (#1482) Update

Minutes:

Chair: Hans Buitendijk

Scribe: Riki Merrick

FHIR planning update for the next 2 years

  • HealthProduct:
    • How do the brown items relate to each other
    • Describe boundaries
    • Do we need healthcareProduct pattern?
    • UDI related
    • Monday call for all of these related topics
    • High priority is getting ALL resource proposals done
  • DiagnosticReport / Media / Observation etc on Tuesday calls 2 – 3 PM ET
  • Observation and ObservationDefinition on Wednesday call
  • Service request and Task
    • Durable Medical Equipment IG (want per CMS) my drive this
  • Specimen and SpecimenDefinition on Tuesday calls 3 – 4 PM ET
  • At bottom have some IGs listed
  • Like to see these resources go normative:
    • DiagnosticReport
      • can have composition or DocRef
      • issue is where would the AnatomicPathology end up
      • Also consider renaming – because the name implies Diagnosis….which may be viewed as limiting
      • Working on providing good examples for AP and micro
        • Grahame can share his AP examples with the group
        • Folks with this interest are on the specimen call
        • Could wrap the DiagonsticReport into a composition to create a document
        • DiagnosticReport could be a domain specific profile on composition when looked at from the simplification perspective
        • FHIR-I is working with Structured Docs on getting more structure into composition
    • Device
      • It came back from something, so not as hard as going from
      • There are formal criteria that define normative status
      • In identifying these resources we signal to the market that we are working on these criteria
      • There is interest in US government and vendors in this resource and it is already part of the clinical core data elements (CCDS) list in the US
      • Also it is used in very many places

Order Catalog:

  • Background
    • Bundle for LIVD was originally a collection, now it could be either type = document or type = transaction
  • ObservationDefinition
    • In current resource:
    • This allows more than one datatype, so would we need different reference range – how to tie these to the correct datatype, but the qualifiedInterval is also 0..*, so can adjust accordingly
    • LIVD created 2 extensions:
    • Reference a deviceDefinition
      • Propose to integrate this as new attribute 0..*
      • And update the example to the richer type
      • Add serach parameters
      • Francois, Lorraine
      • Further discussion:
        • We also have extension from DeviceDefinition to observationDefinition in LIVD – do we need that there?
        • We added this to be able to state what observations can be done by this device (Manufacturer wants to publish catalog of devices)
        • It would be better to just have one added and follow the reference in reverse, when needed, by searching for devices that reference this observationDefinition
        • Catalog point makes more sense device to observationDefinition
        • But we also may need to state these observations can be done by all of these devices (for example in a more detailed eDOS)
        • At observation link observationDefinition and deviceDefinition when that
        • Defer the motion for now; but progress b) and c), as that is normal work on a draft resource
  • CatalogEntry
    • Attributes on CatalogEntry:
    • Orderable attribute may not apply to every catalog (not needed in LIVD< that’s why LIVD did not use it)
    • Effective period may be beneficial
    • Slide 9 shows how CatalogEntry was tested in Baltimore
    • ActivityDefinition has been enhanced, so it can now reference ALL the related elements needed to define it
    • Currently the catalog reproduced the way masterfiles include ALL the components individually accessible and then also referenced per the orderable panels, where those are built
    • Slide 10 shows dropping use of catalogEntry for any ancillary information objects, if they are not orderable – but only use activityDefintion for CatalogEntry
    • Having more than 2 links you can get out of sync very quickly
    • If we move these 2 attributes to entry in composition, then we could remove CatalogEntry:
      • Orderable
      • EffectivePeriod
      • Status
      • Could also be extension on datatype reference? – that sounds harder to do
      • Intent is to have catalogEntry belong to a single catalog, not independently referenceable outside the catalog
      • What about cost – would be a property of the activityDefinition?
      • Would still be beneficial to have an explicit resource to show that there is a different use of the entry
        • When implementing may create a class anyway, but this would be a better understood business object
        • Allow use of either entry or CatalogEntry in catalog profile
        • CatalogEntry has fewer attributes now, but it may need to be expanded and that is easier in a resource than to the more generic attribute in composition
        • Still need to figure out where cost goes
    • Next steps:
      • Define all possible attributes needed to CatalogEntry
      • Pick up discussion
      • Goal to bring back to OO call in February, so we can
      • Next call is Wednesday 1 – 2 PM ET next week e.g. January 23, 2019

Dental Interoperability update #1482:

  • Value for exchanging dental information and where helpful = investigative project
  • Have a dozen use cases collected so far for the whitepaper to give idea on what to
  • Landscape of who works where
  • Dental InterOp confluence page to create the white paper = Dental Interop Home
  • Goal to complete end by end of JanuarySponsor: PC
    • First part in Feb to review the whitepaper to be distributed
    • OO folks to review and provide comments back on obvious next projects
    High demand to be integrated in to the patient’s care plan
    • Dentists want to have med list, problem list and allergy information
    • When dentist finds non-dental issues, how to share back to PC
    • PCs to refer to dentists not developed
    • Being able to generate orders with details
    • Access to decision support for more personalized patient
    • Dental pathology results are not easily delivered to PC
    • Creation of specimen for submission to pathologyIntegration with imaging
      • In VA dental images are housed in same place as radiology
      • Imaging is localized to ONLY the practice, where care is obtained

Q3 - OO

Agenda:

V2-FHIR Mapping

Minutes:

Chair: Hans Buitendijk

Scribe: Riki Merrick

2-To-FHIR Project

VXU message mapping page

  • Goal was to build the message structure
  • For datatypes, where the normal datatype mapping will work,  Craig enters “see datatype”- can be exploded out later
  • Mapping rules need to point out some vocabulary requirements for other fields – example home phone vs business phone
  • NK1 has contact phone number when NK1 is organization and also related
    • Birthplace has zulip chat – there is an extension for patient to handle birthplace, but not for next of in – potential use case in PH for minor, where there is interest in knowing the parent’s birthplace – do we draft the desired location of where the extension should live?
      • Use # # around new FHIR attribute proposals (attribute, extension etc) that may need to be added to FHIR – here we have option of extension for relatedPerson.birthplace / patient.contact in addition to the existing patient.birthplace, vs creating a different address type for birthplace, that could be used for  people
    • Set ID will in many segments – indicate that mapping is not warranted
    • Include guidance on why we created these 2 mappings, and when to use which
    • NK1 segment may have 2 potential maps
      • Patient.contact is minimal information about that person
        • Patient.contact.relationship in FHIR is more like NK1 = role, so will need to start a zulip chat about the need for relationship in addition to these roles
        • There are several NK1 elements that have no FHIR mapping, like job title and job code
          • Should we create extensions for these?
            • Depends on usage in existing V2 interfaces (in room, polling larger community)
            • Also may have a higher threshold to add into the core resource, depending on the weight of the usage
      • Patient.relatedPerson
        • relatedPerson in FHIR points back to the patient – we need to identify what a VXU message is used for and applies to, so need to
        • relatedPerson does not allow an organization
          • hard to deal with ward of court
          • in ELR guidance is to use Contact phone when NK1 is about an organization that has a relationship to the patient
          • relatedPerson FHIR resource has a few attributes that are MUST SUPPORT but not part of V2 – add those in as rows in addition to the mapping rows
    • As part of creating a FHIR representation of the message, will also need to address how to link the parts of the bundle together
    • Add column for each V2 and FHIR to track cardinality
    • Consider locking the page, when copying tables out to manipulate them in excel and re-pasting back (temporary)
    • Because v2 content can be transformed into FHIR, that does not mean the FHIR record can be queried because there is no FHIR API on the data originator’s system, may need to add a paragraph that this is a communication ONLY – still need partner agreement in regards to access storage
    • Mapping ACK message
      • may not be able to map that to FHIR, as it is functional and may be dependent on FHIR connection method
      • If you start with LRI message, where an application ACK is expected, need to be sure the recipient of the original intent can communicate the application ACK
    • Create a table of contents that includes a section for general expectations
    • Coloring schema shows the segment groups that belong together – so maybe update using the {[]} or another approach, since indentation does not work
      • ORC mapping
        • Can Map to different ServiceRequest, NutritionOrder etc, but these this will map to immunization resource, except, where the immunization is
        • So far have not considered task to deal with the control code elements – ORC-1 and ORC-5 (tracking if everything is completed) – this discussion does not apply here, because ORC-1 is RE here
        • ORC-5 in the US is not used, because that is done in other segments
        • ORC-2 / ORC-3 maps to ID representation, where the type codes are specified, so we need to add a row to show the FHIR attribute needed here for respective type codes
        • ORC-4 – probably maps to immunization.identifier, but have not TypeCode for this kind; since this is not unique, can it map to identifier? (equivalent to lot number, which is allowed in FHIR)
          • This would not
          • ORC-4 datatype changed from Placer group number from EI to EIP – that is NOT backwards compatible, because this creates sub components out of components = TO BE NOTED AS AN ISSUE for V2 review, unclear if it is fixable now
    • Did we figure out mapping between value set codes?
      • Not yet, except in a few cases like in RXA segment – when RXA-20 is = “D” equated that to “entered in error”
      • Did not do OBX for obvious reason
  • Next Steps:
    • PID, PV1, AO1 message mapping from Hans soon
    • Map MDM
      • How would the document in OBX be handled? Attachment, or DocRef
      • TXA has metadata about the document included in the message = may be DocRef?
      • How would you handle multiple OBX under the TXA?
        • Bundle?
        • Multiple attachments?
      • Ask PC to review once we have mapping
    • Map OML
    • Pick a segment to map – can reference already existing datatypes in the higher level row, if decide to map the datatype we could use that to populate the datatype also, if not already mapped – please do NOT delete these rows

Q4 - OO/CIMI

Agenda:

Review Vital Signs Profile

Review Lab Models

Discuss Next WG joints

Minutes:

Chair: Riki Merrick

Scribe: Riki Merrick

Quantitative Lab Models are ready to validate

Conversation with Dan Vreeman = Could we enhance RELMA to link CIMI lab profiles to their respoective LOINCs

Models.openCIMI.org/IG

General process:

  • Get content, create CIMI logical model and then transform to FHIR resources
  • In the FHIR resource we constrain out, if it makes sense to constrain out – so do it where it SHALL NOT occur ever
  • The observation resource has 40 data elements, most of which were being removed

Vital Signs profile

  • Specific LOINC chosen = matches C-CDA, but has more qualifiers than C-CDA
  • RelatedObservation is used to include all observations
  • Reference range in the FHIR observation resource for clinical resources is being constraint out more often than not, would only be instantiated for data that exists – example skin and wound
  • Cannot put a qualifier easily with condition resource, but works for observation
    • Examples, where that may be needed: Heart murmur and heart murmur sound
  • Looking at PulseOx
    • Added extensions for delta flag and sensor description
    • LOINC does not have a code that includes O2 Sat and sensor description
    • Bodysite for pulse Ox – have preferred value set, but need to add wrist, neonatal body site, there may be other, so this need review
  • CIMI blood pressure
    • Several extensions:
    • Components: diastolic, systolic, mean arterial pressure
    • Base definition is the FHIR base profile
    • May need to add in additional attributes that could come from a device (for example the UDI)
      • For device extension use reference to device resource
  • Valuesets are created in SOLOR and then export them into VSAC
  • What is SOLOR?
    • Linking of SNOMED RX Norm and LOINC to deal with overlap between those, create SNOMED CT refset for valuesets, create observations in LOINC and as SNOMED observable, create extension codes, working with SNOMED international in order to compare across
    • SOLOR assigns SNOMED observables and then submits to Regenstrief, does not create observables, when in

Quant Lab Models

  • Examples built from top 2000 lab tests in LOINC
  • Meeting with ASC next week Wednesday to have them review these
  • FHIM has some great models that were used as basis in CIMI
  • Identifier was sliced:
    • Filler
    • Placer
  • Accession number = ambiguous name – needs clear definition of what is meant here and may need adjustment of name
  • Performer was sliced:
    • Responsible observer
    • Performing lab
    • Performing lab med director

How to create an IG for all labs?

  • Need to create a template that we can have a consistent representation of
  • LOINC crosswalk between the CIMI models in the implementation guide
    • Process for FHIR profile validation
      • Template
      • Tooling for validation / for example checking for broken links etc
      • Goal of figuring out how to do the QA better
  • Could create a query group of LOINCs and create equivalency groups based on analyte and property to catch titers, timing, and specimen
  • Review the template in general and may be create sub-templates
    • For quantitative:
      • Create titer and numeric and ranges
      • Review if we have interpretation:
        • Numeric result pluse interpretation = Example Flu A PCR with Ct value (might matter to EPI and other lab folks) and interpretation (matters to the doc)
        • Vs some inherently quantitative, that is never reported, where the expected results are JUST the interpretation – overlap to qualitative tests
        • Include continual data use (rather than just secondary, like PH, QC criteria) for consideration
        • We should create guidance on what to use in what use case (as best practice)
      • For qualitative types in the value sets – include definitions of what the concept means
  • These start as CIMI logical models, that can be transformed to other data representations:
    • FHIR (This has been working off UScore observation (the older version, not the one balloted right now we assume  Susan to check)
    • DICOM or others
  • Community LOINC mapping contributing to the data source might need review
  • Start with LOINC tables for Labs, but Stan and Nathan will ask what we will be building off
  • What will happen, when labs that are not as involved in FHIR and these template don’t get as much review?
  • Quest is working on Apple health record  - (based on Argonaut and FHIR R2) = this may need synchronization
  • ACLA pools resources of national labs – would be good to give a presentation to them and involve them in the review process
  • Also make a presentation to LabMCoP to reach CAP
  • Sned notice out to IHE PaLM

How will this be operationalized?

  • First place is expected to be LIVD and the messages out of the instruments (those use CLSI AUTO 16 (hopefully in 2019)/ IHE LAW)

Next joint with CIMI will be Mon Q1 with only CIMI and keep the existing joint with CDS and CQI on Monday Q3

OO will be meeting next week

CIMI will be meeting next week

Adjourned 4:47 PM CT


Friday, January 18, 2019

Q1 - OO

Agenda

Until quorum runs out, wrap-up topics.

Minutes:

Chair: 

Scribe: David Burgess

Quorum was not obtained. 

Adjourned 9:30 AM CT