Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Tuesday

Q1 and Q2 = Plenary

Q3

Chair: Hans Buitendijk

Scribe: Riki Merrick

Review Agenda review for the week

  • Rooms have been changing quite a bit – so check the agenda
  • FOR V2+ (Tuesday) and V2 to FHIR mapping (Thursday tooling) use M102 for Q0
  • Friday AM overflow quarters possible, if needed – will check on Thursday
  • Using OO regular Free Conference call line when we need it

Attendance log https://confluence.hl7.org/display/OO/OO+WGM+201909+-+Attendance+Log?src=spaceshortcut  – please sign yourself in

Agenda for today

  • Report on breast cancer ballot result will do today (time permitting, else Tuesday Q3)
  • Follow up on Nutrition intake
  • Blood Administration
  • Se Referral PSS Co-Sponsorship
  • Self-Measured BP - need dial in for Corey

Additions:

  • Device Request / Parameter
  • Device Use Statement
  • ServiceRequest Order Detail
  • ServiceRequest order detail (CIMI/CQI)
  • DeviceRequest reason code and parameter use statement

Referral PSS:

  • Seth Blumenthal from AMA
    • Integrated Health Model initiative at AMA – now using HL7 for DAM
    • Get slides
    • ONC chairs of Interoperability taskforce suggested common data elements for patient referrals
    • Goal of this is the payload / content
    • Gravity is HL7 accelerator project for social determinants for health
    • SIREN is UCD research community project
    • UT is implementing social determinants for health
      • Unite us system for non-medical referrals
    • Which WG should have this project?
      • Patient Care as primary sponsor for content
      • OO as cosponsor (both content and process/transport)
      • Transport
        • Process would be PH WG – John Loonsk and AMS – have balloted referral FHIR IG
        • Non-FHIR in IHE using direct transport = 360x work
      • VA did a lot of work on knowledge artifacts for questionnaire and order sets will be on HRQ CDA connects
      • Is this like a patient summary? – specific to a use case would be better, so that we have the participants for connectathons
      • PSS for parent with multiple workstreams
        • Child PSS would be for the specific use cases
        • Publishing facilitator should know the HL7 process
        • Will have to collaborate with CIMI /CDA and CQI, so that the same data elements
      • Come back for vote of at least Co-sponsor
    • Self-measured Blood pressure PSS
      • Lorraine drafted a PSS from the prior presentation
      • Slides from Monique van Berkum, AMA
      • Already developed IGs based on FHIR STU3
      • Model was created outside of FHIR over the last 3 years
      • OO is already the primary sponsor
      • Goal is to take IHMI knowledge and align it with FHIR
      • Governance level question for the exchanged data = can we test if our definition is consistent across implementations globally? Idea is the common standard representation (from bottom up that needs to be coordinated for the different
      • CIMI has a vital signs PSS extending US core – working using ONLY LOINC – need to compare and come up with just 1 FHIR profile for bloodpressure – do not limit to US realm – should we sync that into one project
        • In experimental model used procedure in test = measurement of blood pressure instead of SCT observable or LOINC) – also use this same code in method / and as a goal
      • People are not implementing FHIR STU3 = should be STU4 instead
      • CIMI already has a PSS – which PC is sponsoring – OO owns the vital signs profile, so we need to work with PC and need to add OO – this has not gone through SD and TSC
        • CIMI will show their model in Tues Q3
        • Model is built on FHIR STU4
        • AMA is including more processes of how this data is used in clinical care, while CIMI has the model of a broader data (Vital signs profile includes self-measured blood-pressure)
        • Already presented to PC, OO and Mobile Health
          • Need to add CIMI as co-sponsor
        • Next step:
          • Define AMA objectives and compare to scope of existing PC PSS and decide which part is under the existing PSS for the overlap = Lorraine, Monique and CIMI
        • Breastcancer ballot
          • Lots of comments
          • Got a lot of ideas about what patterns and resources we should be using
          • So will result in significant changes for Jan2020 cycle
          • Connectathon May2020
          • Will add more clin content and terminology
          • Numerous choices for breast cancer report:
            • DiagnosticReport
              • Not enough sections for the current expected design
            • Composition
            • DocumentRef
              • Argonaut is working on first STORE operation for this resource, so we can get implementation in community
            • For the device topics find other quarters
            • Blood Administration
              • What resource to use for that? = no known resource yet
              • We have Tuesday Q1 for healthcareProduct process patterns
              • Can we have a resource for that for R5 – need a group of folks to work on that
                • First have to define what a biologicallyDerivedProduct is covering that – we don’t have a resource to describe the administration of the blood product
                • Clinical Quality measure for blood product administration
              • Looking for volunteers to draft something
            • Keep the same joint for Syndey

Adjourned at 3:03 PM

Q4 = Joint with FHIR-I - see there for minutes <ADD LINK>


Tuesday

Q1

Chair:

Scribe:


DeviceUseStatement

  • Or Procedure
  • Or Observation
  • <resource>UseStatement is meant more from a consumer/patient, could be the clinician, but then not the prescriber/requester/administer.
  • For CQI it is important that it is "applied/administered", as reported by clinician.  Sounds like more the Procedure (when implanted/attached).  Still tbd for DME.

DeviceMetric

  • Or Observation
  • Reflects the state of the device.  Not to be mixed with observation which is the output of the device for a particular subject.
  • Observation.device(Device) is clear.
  • Observation.device(DeviceMetric) references the DeviceMetric that yielded the observation, which in turn points to the Device.
  • If you want to know the state of the Device (collection of all DeviceMetrics) at the time of the observation then that has to be resolved elsewhere.
  • Will create clarifying language in both DeviceMetric and Observation on what aspect of DeviceMetric is used by Observation.

gForges (Devices)


Tuesday

Q2

Chair:

Scribe:


  • Observation.valueAttachment?
    • Options
      • Observation.derivedFrom => Use case would not have Observation.value
      • Observation.valueAttachment => was in DSTU 2 and it is an actual result value.
      • DiagnosticReport.presentedFrom => Inconsistent placement of an observation.
      • Observation.extension-valueAttachment =>
    • Motion to propose in Q4:
      • Define Observation.extension-valueAttachment so it can be used with FHIR R4.
        • Requires determining where to post it. 
      • Include Observation.valueAttachment into FHIR R5 build as an STU item.
      • Document clearly when to use Observation.valueAttachment vs. Observation.derivedFrom vs. DiagnosticReport.presentedForm in
        • Observation introduction
        • Element definitions
      • Kathy Pickering, John Moehrke
        • Against: 0
        • Abstain: 1
        • In Favor: 10
  • Nutrition Connectahon Update
    • Unfortunately partners did not show, but will be in Sydney
    • Worked primarily on documentation and examples.


Q3

Chair:  Robert Hausam

Scribe:  David Burgess

Wednesday Q1

  • AMA - Referral PSS
    • CDS, CQI, FHIR-I, Vocab, Pt Care, Public Health
    • Overall good interest. 
    • Lot of work has already done (360X, eReferral), but mostly focused on mechanism, not content.
    • Would like to proceed.  Perhaps start with whitepaper to identify needs, gaps, etc. and then recruit.  Perhaps start with DAM.
    • Suggestions to start with whitepaper.
  • Device.status

Active - Remove "Note: For *implanted devices* this means that the device is implanted in the patient."

Inactive - Remove "Note: For *implanted devices* this means that the device has been removed from the patient."

OR

  • [operational]Status 0..* with active, inactive, implanted, explanted, dissolved/absorbed

OR

  • [operational]Status 0..* with active, inactive.
  • implantStatus 0..1 with implanted, explanted, dissolved/absorbed

OR

  • [operational]Status 0..1 with active, inactive.
  • association 0..1
    • association.patient (reference) 1..1
    • assocaition.level/status 0..1 with implanted, explanted, dissolved/absorbed
  • statusReason value set: malfunction, partially function


Wednesday Q2 <supplement with Riki's notes>

Chair: Lorraine Constable

Scribe: Riki Merrick / Lorraine Constable

  • Healthcare Product Recap
  • Cancer specifications for Genetics (M-codes, v2 IG, and FHIR)


  • Clinical Genomics
    • close to publishing Genomics reporting Implementation guide
    •  will replace current extensions in 
    • R5 deprecations 
    • technical correction on examples
    • questions about searching and computational observations


  • II
    • Specifics around DocumentReference and Media for tomorrow
    • co-sponsor updates


  • BR&R


Wednesday

Q4

  • v2-to-FHIR


Thursday

Q1

Agenda

  • Catalog/LIVD
  • DeviceStatus
  • LIVD gForge

Device Status

  • Device Status Options
    • Option 1a:
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..1  CodeableConcept on|off|standy|etc.
      • Add Device.operationalStatusReason 0..*
      • Add Device.associationStatus 0..1 CodeableConcept implanted|explanted|attached|etc.
      • Add Device.associationStatusReason 0..*
      • :
      • Add Device.etcStatus 0..1 CodeableConcept whatever
      • Add Device.etcStatusReason 0..*
    • Option 1b
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..1  Backbone Element
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
      • Add Device.associationStatus 0..1 BackboneElement
        • value CodeableConcept implanted|explanted|attached|etc.
        • reason 0..* CodeableConcept
      • :
      • Add Device.etcStatus 0..1 CodeableConcept whatever
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
    • Option 1c
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..1  Backbone Element
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
      • Add Device.associationStatus 0..1 Backbone Element 
        • value CodeableConcept implanted|explanted|attached|etc.
        • reason 0..* CodeableConcept
      • Add Device.otherStatus 0..* Backbone Element whatever
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
      • Like the use of BackboneElement
      • like use of associationStatus rather than just implantableStatus
      • tracking real world statuses
      • not easily extensible without effort
      • beneficial to be explicit about the first 2 attributes
      • this is also in line with FHIR-I, as they dislike the apporach of using name - value pairs
      • how will otherStatus be defined = using the valueSet content to describe the context
    • Option 2
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..* Backbone Element
        • value 1..1 CodeableConcept
          • on|off|standy|etc.
          • implanted|explanted|attached|etc.
        • reason 0..* CodeableConcept
    • Option 3
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.?name?Status 0..*
        • value 1..1 CodeableConcept
          • on|off|standy|etc.
          • implanted|explanted|attached|etc.
        • type 1..1 Coding operational|association|etc.
        • reason 0..* CodeableConcept
    • Option 4
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Update Device.property.type value set (needs to be fixed regardless) for operational and association 
        • seems to work for operational, but not for association that well.
      • Update Device.property.valueCode value set 
        • on|off|standy|etc.
        • implanted|explanted|attached|etc.
      • Add Device.property.reason 0..*
        • does not seem to fit.
      • Implanted is not the status of the device / not a property of it
    • Option 5
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Use DeviceMetric where DeviceMetric.parent links to the Device
      • Update DeviceMetric.type value set (needs to be fixed regardless) for operational and association
      • Change DeviceMetric.operationalStatus to Codeable Concept
        • on|off|standy|etc.
        • implanted|explanted|attached|etc.
      • Several people don;t like tis option of using a different resource for describing device statuses
    • Regardless
      • Add DeviceMetric.active
      • Drop entered-in-error from DeviceMetric.operationalStatus
    • Motion to accept option 1c except the first 3 bullets - confer with FHIR-I about the appropriate use of the participant pattern for device.status
      • Lorraine, Rob further discussion: Rob and Bob and Marti prefer the option 1b, unless we have a specific use case for the otherStatus;
      • change motion to use option 1b, excluding the first 3 bullets
      • against: 0, abstain: 0, in favor: 13

Q2

  • Value Attachment
    • Motion to:
      • Define Observation.extension-valueAttachment so it can be used with FHIR R4.
        • Requires determining where to post it. 
      • Include Observation.valueAttachment into FHIR R5 build as an STU item.
      • Document clearly when to use Observation.valueAttachment vs. Observation.derivedFrom vs. DiagnosticReport.presentedForm in
        • Observation introduction
        • Element definitions
      • Eric Haas, Lorraine Constable
        • Discussion
          • Needs 1..* gForges. GF#24693, GF#24695  ( need to complete)
          • May need more absentReason values for Observation.value[x]
        • Against: 0; Abstain: 0; In Favor: 15
  • Device
    • Motion to update the definitions and value sets of Device.status and Device.statusReason to make it clear they focus on the status of the record of the Device.
      • Hans, Riki
      • Against: 0; Abstain: 2; In Favor: 13
      • created GF#24696] ( need to complete )
  • FHIR Planning
    • New target of first FHIR R5 ballot for 2020 May.  Is that o.k.?
      • Intent to focus on FHIR survey to find out when a next release would be be adopted with current version of FHIR.
    • Is there value in interim milestone for resources that have enough change to be made available?
      • Approach would be SOMETHING LIKE (not clear) to take R4, fork, make the select updates, ballot, and publish an STU.
      • If it happens, we would consider:
        • Substance because of BR&R
        • Specimen
        • Catalog
        • Healthcare Product scope/boundary updates.
      • But O&O would not be pushing for this.  No urgency.
    • Need to commitment in Sydney to R5 Normative targets.
    • Discussion around the potential need to split Device, e.g., hardware vs. software? Implantables/etc. vs. tubes vs. diagnostic equipment/analyzers?  Method/algorithm vs. something "tangible".
    • What changes can be done to normative?  Still needs to be backward compatible.
    • Use: http://clinfhir.com/igAnalysis.html to find use of extensions beyond what is in the HL7 registry.  No guarantee they are actually in use or were just considered.
      • Looking at extension reviews.
    • Profile naming conventions?
  • DocumentReference/etc.
    • Name Change
    • Use of DocRef for XDS by IHE concern.
      • Not needed for FHIR resources that don't need to go through that.
    • Media has been replaced, we think.
  • No labels