Versions Compared

Key

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

Table of Contents

Monday Sept 16, 2019

Q1 and Q2 = Plenary

Q3

Chair: Hans Buitendijk

...

  • 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

...

Joint with FHIR-I - see there for minutes https://confluence.hl7.org/pages/viewpage.action?pageId=66913703#FHIRInfrastructureMinutesWGM201909-MondayQ4


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)

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

Q4

Chair:  

Scribe:  

Hosting 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: Hans Buitendijk

Scribe: Lorraine Constable

Hosting BR&R

ValueAttachment

Should we add to Observation or just DiagnosticReport? That gives just one place, drives consistency. Other argument is when the blob/image is the actual result.

Comment – these are slightly different use cases

Kathy – use case is where there is a “result bucket” and the document is the actual result that may have been scanned and is the actual result. Implemented R2 where this exists, but in r4 does not exist

  • 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

 

Substance Definition – Substance

Reviewed the proposed Substance Definition entry; matched to Substance. Discussion of where Substance.code matches in SubstanceDefinition, which would go in SubstanceDefinition.code.code

Should we add a reference to SubstanceDefinition.

Action Create a gforge tracker to change code to definition which is a choice of Code|SubstanceDefinition. Also look at Device / DeviceDefinition to see if the pattern holds there.

Request to obtain the list of elements FDA thinks needs to be added to substance, so we can review and determine which resource it should go in, or both. Jean Duteau / Katherine <I missed her last name> To provide 

Follow up with Rik on Healthcare Product calls.

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

Q4

Chair:  Riki Merrick

Scribe:  Riki Merrick

  • Agenda review = II declined
  • valueAttachment
    • Cerner had implemented this for lab for referral studies to attach the lab report pdf for genomics reports or flowcytology studies
    • Are extensions version specific? It will probably propagate to later versions, for pre-adoption is allowed, but would be considered custom for those versions, but at least it is standardizes
    • If it is all transcribed would be diagnosticReport.presentedForm – what if only partial or no extraction; shouldn't it still be in the same spot, because you could manually abstract and add or the lab could already have sent you the discrete data
    • Example: https://files.labcorp.com/testmenu/480260.pdf
    • Normally diagnosticReport has several observations
    • Data absent reason – could we add a value to the valueset there to indicate to refer to presentedForm element
    • We may still need valueAttachment for graphs produced by instruments
    • Labs think of the pdf as a result – in V2.x this is ED datatype in OBX-5
    • Describe the use cases:
      • Graph off instrument
      • Pdf of referral lab test that ONLY has pdf scan
      • Pdf with additional discrete results that are also in the pdf, but are provided by the sender
      • Pdf has been sent without discrete result and it is being forwarded
    • Media/DocRef:
      • They have been merged – see report on OO Main Call Notes August 29, 2019
      • Align status between documentReference and diagnosticReport
      • Diag: ADD ALL Values here Registered / partial / prelim
      • DocStatus: is missing appended, registered (not sure that would apply to documents), partial, unknown, canceled / corrected
      • As a recipient of document how do you treat unknown status
      • Should documentReference be renamed, since it now objectReference
      • Do we want to rename docStatus
      • Difference in category value set between these 2 as well – is often used to decide routing; not comparable – LOINC being used here, but it seemed you cannot rely on the mapping to this code that was not specifically designed for this. Category repeats, so could create more than 1 hierarchy so you can identify the type as well as the domain where it is used
      • UScore DiagnosticReport extension – add the LINK?!?!
      • Examples diagnosticReport urinalysis JSON
        • Reference should be to the ID of the observation not the "organization/urine-color" and it should not have the display there
        • Reference display is just to help give an idea of what resources are being referenced in the example report - it would be nice to have an example that has ALL the parts of the diagnostic report available to better understand the relationship between all the referenced resources
        • Using the = negative as part of the display section is misleading that the reference could identify the test and display the result
      • Adjourned 4:51 PM EDT

Wednesday Sept 18, 2019

Q1

...

  • 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

...