Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Seth Blumenthal from AMA
    • Integrated Health Model initiative at AMA – now using HL7 for DAM
    • Get slides
      View file
      nameAMA patient referral CDEs to HL7 9-16-19.pdf
      height250
    • 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

...

Tuesday Sept 17, 2019

Q1

Chair: Hans Buitendijk

Scribe: Lorraine Constable

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)

Joint with HCD

Summary of Health Care Product

  • See powerpoint on OO Product Pages Healthcare Product
    • Need to fix boundaries and scope between the related resources and progress them in the maturity model 
    • Review of the diagram. Dark green OO owns, light green are related. Light orange are items we think we need, but do not yet have resource proposals
    • Eg – we may need a BiologicallyDerivedProductRequest similar to a MedicationRequest.
    • Also need to relate to pharmacy resources and definitional resources
  • Question – what do we do with DeviceMetric 
    • Document being developed to describe the details of the definitions. Once agreed they will be added to gforge and applied.
  • Reviewing Device Use Statement and related use cases, and the definitional corollaries to the entities.
  • Settled on the agreement that SupplyRequest is not patient specific – moves of materials / drugs out of band to the patient. DeviceRequest and MedicationRequest still exist as patient specific
  • Reviewed the path that starts with a specimen or procedure to create a bioligicallyDerivedProject to then ultimately be administered. Still walking through the use case for BloodAdministration
  • Nutrition on FHIR group is progressing the nutrition use case. Still need volunteers to progress the BloodAdministration use case.
  • Meeting on this topic – Monday afternoons 3 PM ET. Discussion on how to get this done and moved forward

DeviceUseStatement

Question for documenting device use or why device not used in measures. Do we use DeviceUseStatement, Procedure, or Observation. MedicationUse drifting to merge with Medication.

Drifting to documentation of what is there, not the prescription, administration or request.

Ie – patient is using a wheelchair. Not the request for the wheelchair

For CQI, it is important that it is “applied/administered”, as reported by clinician. Sounds like more the Procedure. Still tbd for DME (Durable Medical Equipment)

 

DeviceMetric

Description about difference between the two. DeviceMetric is about state: Calibrated? Attached to the patient at body site X

Comment about observation usually about the patient

  • properties about the type – attribute set and then only changed based on reference
  • Not to be mixed with observation which is the output of the device for a particular subject

Observation can point to the device that created the observation (0..1). How do we express the device metrics as appropriate

Discussed the reference in Observation to Device and DeviceMetric – is the definition consistent with using DeviceMetric for the definitions 

Need to enhance the definitions to clarify when / why you would use DeviceMetric here.  Need a Gforge tracker to track the work.

Action: OO will create a tracker to ask HCD for clarification on DeviceMetric / source and parent definitions, plus to make parent 0..1

 

Gforge tickets

23845 – Brian supplied 3 examples , one with UDI, one with multiple specializations, other does not

Motion to accept the examples, with the proviso that Brian will fix the UDI DI value, for inclusion in the build.  Lorraine Constable / John Rhoads Against 0 Abstain 0 In favour 25

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.

...

  • 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

...