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 16 Next »

Tuesday

Q1

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

  • 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

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