Skip to end of metadata
Go to start of metadata

Tuesday Feb 4, 2020

Q1

Chair: Hans Buitendijk

Scribe: Riki Merrick


  • Introductions
  • Attendance log review
  • Review of Agenda for the week
    • Tues Q4 – FHIR-I canceled – update to just OO
    • OO/II
      • Diagnostic report
      • Imaging reference
      • DocumentReference – change name still?
  • Project insight review:
    • Idle ballots
      • LOI, LRI and eDOS have all been published
      • Ulrike Merrick to find Lynn's email
    • 1339 – SPL:
      • Just Co-sponsor – not reviewed
    • 682 - Specimen CMET
      • Motion to close this project Lorraine Constable, Patrick Lloyd, no further discussion, against: 0, abstain: 1, in favor: 9
    • 902 – V3 Nutrition Order Clinical messages
      • Update status to ballot comment reconciliation
    • 1009 – V3 Food and Med preferences
      • Update status to ballot comment reconciliation
    • 1067 – Lab Order Conceptual Model
      • Did I miss discussion on this one?
    • 1095 - EHR-S FR for LRI
      • Important for the LRI guide, still valid
      • Riki to check if we can extend, else we need to figure out what ballot type
    • 1238 – UDI DAM
      • Ballot reconciliation
      • Need to check with Marti on other updates prior to - Hans Buitendijk to reach out
      • Update milestone dates to May 2020
    • 1333 – OO FHIR lab order profile
      • 3 year plan item
      • This should be revived, if there is interest for lab orders on FHIR
      • As part of the workflow discussion, will need to create examples using task resource
      • Also apply the LabOrder conceptual model to this project
      • Leave as plan item for now – looking for resources
    • 1362 - Re-affirm the cardiac devices in V3
      • Needs SD approval it says, but we went to ballot – need to check with Anne about why that is – Lorraine Constable to check
      • This spec had issues with publication of the content during ballot
      • Looking at ballot answers
        • this passed, no negatives, empty comment spreadsheet uploaded on abstain from Epic – reach out to Dan and ask if there was supposed to be a comment (Hans)
        • so move to preparing for publication? – Check with Lynn, if we need to submit a publication request for re-affirmation – Lorraine Constable
        • changed status to notify ANSI
        • Update milestone dates to May2020
    • 1481 - V2-FHIR - Mapping
      • Move to later milestone Sept 2020
      • Want out of cycle peer review in the next few month
      • Ballot round for STU in May2020 – preparing for ballot = status
      • Ultimately want to go normative
    • 1512 - UDI Pattern R2
      • Went out for re-circulation
      • So set status to normative balloting
      • Milestone May2020
    • 1539 – Lab Model
      • Update to May2020
      • Passed Admin SD on 1/2/2020
      • MUST have TSC by April 1 – Hans Buitendijk to check with Anne
    • 1568 – Physician Blood pressure
      • AMA sponsored project – this is different from the CIMI Vital signs (1541) – check with them one more time – Hans Buitendijk to check with project team (Corey, Stan, Susan, Seth)
    • 1541 – Vital Signs (CIMI)
      • Talk during the WGM – Hans Buitendijk to check where that is for approval
      • Update milestone date to May2020
      • Is listed in project insight under PC, but they didn't take it – Hans Buitendijk to check with Dave on that
    • 1330 - Lab Functional Model – LRI focused
      • 3 year plan item
      • Motion to archive Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 3, in favor: 7
    • 1331 - Lab Functional Model – LOI focused
      • 3 year plan item
      • Motion to archive Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 3, in favor: 7
    • 1332 – Lab Functional Model – overarching
      • 3 year plan item
      • Motion to archive Lorraine Constable, Riki Merrick, no further discussion, against: 0, abstain: 3, in favor: 7
    • 1068 - Lab Order Logical Specification
      • Is STU to cover the FHIR workflow for LOI – Eric did some work in early FHIR Releases on this
      • This is similar to 1333 – do we need both?
      • Need to figure out what the status is – Ulrike Merrick
    • 1081 - Nutrition FHIR resources
      • This includes anticipation of writing an IG for nutrition
      • Aiming for May2020 connectathon
      • Review the scope, but currently we have a mix going on – the description is listing the work steps – check with Becky if we need an IG specific PSS? – next quarter
    • 1115 - OO FHIR core resources
      • Review again in May2020
    • 1335 - LIVD
      • Leave as is
      • Rob and Hans to publish based on the ballot comments
    • 1370 - Transplant 
      • working on getting the biologicallyDerivedProduct made available in other resources like procedure, specimen etc
      • need to prepare for connectathons
    • 1496 - DME
      • Need to check where the SD approval date is – was SD approved on 2/28/2019
      • Meeting with CMS project team on Mondays, HL7 project calls on Fridays
      • Want to go to ballot in May2020
      • Have done connectathons
    • 922 - LOI
    • 1294 - LRI
    • 973 - eDOS
      • eDOS STU will expire in June – can we extend - Ulrike Merrick to check
    • 1096 – EHR-S for LOI
      • Motion to archive this project Riki Merrick, Ralf Herzog, no further discussion, against: 0, abstain: 2, in favor: 7
    • 1097 – overarching EHR-F FR project
      • Motion to archive this project Riki Merrick, Ralf Herzog, no further discussion, against: 0, abstain: 2, in favor: 7
    • 1453 - IHE mapping to Specimen DAM
      • Riki to decide if we want to publish this
    • 1292 - Specimen DAM
      • has been published
      • We are currently working on applying the DAM attributes to specimen FHIR resource, so may need updates to the DAM later
      • Leave this open so we get requests for updates – can we get a status for informative to reflect that? – Ulrike Merrick to check
    • 1450 - Reaffirmation V3 Lab result
      • Need to update the description to reflect new date – Lorraine Constable  to check with Dave

Q2

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • Reviewing the ballot outcome Nutrition V3 Order ballot
  • passed
    • Comments from Becky
      • #? – AT: Motion let editor address Typos – Patrick Lloyd, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 5
      • #? - AQ: Is the reference still accurate to page 4-98 in V2.5.1, or should it be V2.9? – Maybe change the text to use e.g., since there are other versions that folks can look at. The context is semantic, so maybe ODS-3 is the dietary preference code, but the table is not defined, only examples – in V2.9 using HL70628, but still no entries in that table either. Suggestion is to drop this reference – there may be code sets in VSAC for oral diet-types = OID of the value set ? – just point to the resolution of AS = #1
      • #? = AQ: Should there be reference to the current DAM? Motion to add reference to the current DAM as helpful reading Riki Merrick, Patrick Lloyd, no further discussion, against: 0, abstain: 0, in favor: 7
      • #1 = AS: Change the paragraph to just point to the DAM and drop the reference to V2.5.1 etc – Becky Gradl, Patrick Lloyd, no further discussion, against: 0, abstain: 0, in favor: 6
    • Blank spreadsheet added by Christopher (EPIC) – no need to address
    • Motion to accept the ballot reconciliation, upload to ballot site (Hans Buitendijk ), begin publication request (Hans Buitendijk ) – Becky Gradl, Patrick Lloyd, no further discussion, against: 0, abstain: 1, in favor: 5


  • Reviewing ballot outcome for Nutrition and medication preferences
    • Passed
    • Comments from Ruth Berge:
      • #1 - Motion to let editor fix the typos – Patrick Lloyd, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 6
    • Empty spreadsheet uploaded - ignore
    • No other comments
    • Motion to complete reconciliation, upload spreadsheet (Hans Buitendijk ) and prepare publication request (Hans Buitendijk ), Patrick Lloyd, Ralf Herzog, no further discussion, against: 0, abstain: 1, in favor: 6


  • Reviewing Lab Order Service ballot
    • Passed
    • Comments from Becky
      • #1 and #3 (AT): Motion to let editor address typos Patrick Lloyd, Ralf Herzog, no further discussion, against: 0, abstain: 0, in favor: 7
      • #2 (AS): Does not match practice: The order is entered in the EHR-S, and is then sent to the nutrition system; a dietician does not need to make assessment prior to getting a diet assigned (what is currently stated is the exception not the rule – can draft the suggestion and get larger group to review on OO and nutrition list serve – Becky to draft:
        • A hospitalist orders a consistent carbohydrate, diabetic diet for a patient typically using an EHR/EMR which then transmits the data to the system that maintains the diet orders. The system provides the physician with detailed information regarding requirements that must be satisfied before the order can be filled (e.g., a hospital policy requiring a nutritional assessment)
          • Updated the EHR/EMR usage
          • leave the example, since that's all it is
        • Motion to accept the new text Riki Merrick, Patrick Lloyd, no further discussion, against: 0, abstain: 1, in favor: 6
      • #4 (AS): Motion to find persuasive Riki Merrick, Patrick Lloyd, no further discussion, against: 0, abstain: 1, in favor: 6
      • #5 (AS): Remove parental nutrition from this paragraph and change solid to oral Becky Gradl, Patrick Lloyd, no further discussion, against: 0, abstain: 1, in favor: 6
    • Motion close the ballot, upload to the ballot desktop (Hans Buitendijk ) and prepare publication request (Hans Buitendijk ), Riki Merrick, Patrick Lloyd, no further discussion, against: 0, abstain: 1, in favor: 6


  • Reaffirmation on Cardiac Device V3:
    • Passed
    • Uploaded a blank spreadsheet
    • Dan Rutz had email questions about it being used anywhere, but he submitted no ballot comments
    • Motion to close out reconciliation, upload and ask HQ to take necessary steps needed for re-affirmation (Lorraine Constable ): Patrick Lloyd, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 6


  • 1081 - Nutrition FHIR resources
    • Additions to the FHIR core have been done – those can otherwise be done under the core FHIR work, by creating resource proposals
    • Planning on making a separate PSS for IG
    • Hans Buitendijk will double check that creation of new resource proposals does not have to have a dedicated PSS – if yes, will archive this one, else we will update the description on next plans and keep this one open for that kind of work
    • PSS for IG to go to ballot MUST be approved before the prior WGM – so for Sep2020 would have to be by April 2020
    • January2021 is more likely, since that requires Connectathon testing prior to ballot
  • Becky back on Wed Q2 for Nutrition update
  • Adjourned 12:52 PM AU time

Q3

Chair: Lorraine Constable

Scribe: Ralf Herzog

Agenda from CQI (https://confluence.hl7.org/pages/viewpage.action?pageId=66913826):

Review and Discussion FHIR resources/topics owned by OO

  • ServiceRequest priority 22786
  • Nutrition intake resource
  • Blood Administration
  • DeviceRequestnotDoneReasonCode
  • DeviceUseStatement notDoneReasonCode
  • Use of DeviceUseStatement - what represents appropriate usage
  • Discuss use of DiagnosticReport-Lab, DiagnosticReport-Note, and any other DiagnosticReport vs just Observation for reference in CDS or eCQM expressions


Lorraine pointed to "Nutrition on FHIR" - OO Call (Wednesday, 2pm)

  • ServiceRequest priority 22786
    • Priority Value Set
      "Elective" to be added to Priority since "elective" and "routine" are not the same ("elective" in "routine" but not vise versa)

  • Nutrition intake resource (Healthcare Product)
  • Either Wednesday Q2 or Thursday Q2
    Breast milk is it biological derived or not?
    Modeled around Blood Administration?
  • Use of DeviceUseStatement - what represents appropriate usage?
  • Should be discussed with Device People of OO
  • Implantable Device
  • DeviceRequestnotDoneReasonCode & DeviceUseStatement notDoneReasonCode
  • Why a Request was not done?
  • Use Observation?
  • US Core has
    • Diagnostic Report,
    • Diagnostic Report Note,
    • Diagnostic Report
  • To find an observation what to use. Use observation?
  • Should be talked with CQI


CIMI Topics:

  • Slides (already shown at OO main Call)
    • Pre vs post coordinated have different LOINC Codes
    • Argonaut profiles vs CIMI profiles
    • Explanation how Qantitative Lab Profiles are
    • Preferred: Most reasonable post coordinated code.
    • For ANF
      • Turn Spreadsheet to concept map
      • Connectathon Topic for San Antonio ?

Discussion: around a new slot for another Quarter

Q4

canceled


Wednesday Feb 5, 2020

Q1

Chair: Hans Buitendijk

Scribe: 

Hosting HCD

Topics:

  • FHIR-25034
  • We need to support EEG, time-based, and frequency based examples.

    OO and HCD recommend to:

    update the SampledData.period to clarify it reflects the distance between samples, e.g., time between samples or frequency.

    change the SampledData.period data type from decimal to quantity to get the unit of measure with the value.

    update the introductory and related descriptions to include and reference this attribute

    Additionally the name SampledData.period is not sufficiently reflective of the concept, but not yet clear what an alternative name would be.  Potentials include domainInterval, cycle, x-axis, distance, measurementInterval, samplingInterval, other?

    We note that this sampledData data type is not well defined for use beyond two-dimensions with a linear x-axis scale.  We are opening another JIRA on how to address multi-dimensional arrays in a practical way when needed, including how that then relates to the .dimensions element (which in itself needs more clarity/definition as the description makes sense but the name conflicts with the use above).

    Motion by Lorraine Constable, Michael Faughn to move this to FHIR-I.  Against: 0; Abstain: 3; In Favor: 11.

  • Block Vote Pulled
  • Blood Adminstration backdrop
  • Lines, drainage, airways - Device? Procedure? Device Use Statement? DeviceDispense
  • Healthcare Product - resource/pattern/other
    • Product Patterns for Device/Medication/Supply/BiologicallyDerivedProduct/Nutrition, [nnn]Request, [nnn]Dispense, [nnn]Administration/Procedure, and [nnn]UseStatement.
    • The Workflow Patterns and Product Patterns intersect to yield a DeviceRequest, or SupplyRequest, etc.
  • Device/Software
  • Nutrition

Q2

Chair: Hans Buitendijk

Scribe: Ralf Herzog

Hosting OO +PH + BR&R + Rx + FHIR-I + HCD

Topics:

  • Nutrition Update - Becky
    • Have been creating newFHIR resources
      • NutritionIntake
        • Fluid or food or enteral nutrition
      • NutritionProduct
    • Create resource proposals and test at connectathon
    • Create an IG to help dietician document the workflow around nutrition
    • CQI had questions around nutrition (Becky to reach out to Floyd)
    • Discussed to take nutritional use cases to update the DAM
    • 2 work streams
      • One NutrionIntake NutritionDevice - covered by OO
      • Domain Analyses Model is done in addititon 
  • Lines, drainage, airways - Emma
    • How to describe these
      • Procedures (input and removal potentially, but how to identify that this is the same line)
      • Observation
      • ine is a device → Device Use Statement
      • Need to be able to record how long a line was used for a patient
      • Can use procedure for documenting who performed the line attachment and describing how it was set up
      • We use serviceRequest to order the procedure (example intubation needed)
      • Procedure:
        • When intubation is performed = start time of procedure
        • How do we record the tube has been set?
        • How do we check, that the tube is still in place?
          • Can tie substeps of procedures together using "partOf)
          • Use observation to describe the line?
          • Would he completion time of the extubation then be used to populate the end-time of the overarching procedure?
          • What about calibrations etc. that need to happen while tube is in place?
        • Need to be clear in the code of procedure – intubation, vs inserting breathing tube?
        • What if tube is being replaced – is that still part of the overall intubation, or new procedure
        • Create an umbrella procedure to tie together all related procedures – need to write up guidance on when to use umbrella, vs when to us lots of individual procedures not tied together
          • When different people perform the steps it may be complicated to tie them all together without an umbrella – maybe require umbrella procedure
        • As long as the umbrella exists you can figure out which intubation / extubation is the initial vs the replacement procedures
        • Performer does not capture timeframe, so if extubation is done by different person than intubation, replace does not clearly document who did what in that replacement procedure
        • If 2 systems use either of these paths how would the data look for systems that have to aggregate different paths
      • DeviceStatement:
        • Walking into the care situation with a drain already in place
          • Use deviceUseStatement for this
          • May have a start date (precision may vary)
          • Will have a documentation date "recordedOn"
          • Encounter will need to link to deviceUseStatement
          • Would you update the deviceUseStatement, when extubation occurs in hospital? Not expected
          • Add new procedures for anything done at the hospital
          • Incubation procedure now starts with extubation of the existing tube
          • Does procedure have supportingInformation reference? = that would be a way to link to the deviceUseStatement maybe
          • Procedure can only point to parent, not down
          • Umbrella could be retroactively created, when intubation is decided upon to cover the original
      • Still open:
        • How to tie in observations into this documentation?
        • How to tie into encounter?
        • Workflow for this?
          • That needs task resources (FHIR-I) – we are only talking about reporting of the procedure – there is no workflow here, maybe a state diagram could be applied?
        • Next steps:
          • PC owns procedure
          • OO owns deviceUseStatement
          • Discussion on Monday 3 – 4 PM ET or Thur 1 – 2 PM ET
    • As a procedure 
      • Is it an observation or an procedure
      • Procedure has a problem regarding someone starts and another one stops (linkage)
        • Procedures pointing to partOf Umbrella
          • Intubation Procedure contains an Intubate and Extubate Procedure (as partOf Procedure) potential Tube Replace Procedure (Path A) or Intubate and Extubate Procedure (which is the replace procedure) (Path B and C) 
          • Choice of Path is implementer depended, Umbrella is a MUST. 
    • As a DeviceUseStatement
      • Time when the device is applied is not precise or even unknown
      • Time when it was recorded is precise
      • Comments might be there
      • There might be an Replacement Procedure (incl. Intubation and Extubation) and finally an Extubation
      • There might be an Extubation Procedure
      • Question open: How the Umbrella is created and when what is belonging to the umbrella (since procedure partOf is pointing up this could be done when a new procedure is resulting of the procedure being done)

Q3

Chair: Hans Buitendijk

Scribe: Ralf Herzog

  • Agenda review
    • Pulled block votes from HCD
    • FHIR jira
    • Order history – starting at 3 PM AU time
    • V2-to FHIR RXO questions
    • V2 leftover planning
  •  OO/CIMI - Joint Meeting
    • Request for FHIR BodySite Datatype (see https://docs.google.com/document/d/1Ansm-NcC6RhJkEvVGUw97R-NOmd0ZAx1aH9uD1C1ZpE/edit#)
      • Currently no reusable Datatype for BodySite is in FHIR
      • Existing is:
        • Codeable Concept
          • Advantage:
            • see document
          • Disadvantage:
            • see document
        • BodyStructure resource 
          • Advantage:
            • see document
          • Disadvantage:
            • Semantics are beyond BodySite
            • see document
        • User defined extension in a profile
          • Advantage
            •  see document
          • Disadvantage
            • see document
            • interop concerns
      • Why: Have a common concept around everything where a BodySite is included in serveral resources
      • Discussion:
        • Good examples where we have no pre-coordination, when post-coordination is needed
          • Location of breast lesions – mass of 2 cm at 2 o clock
          • Reference to a body landmark: ulcer 3 inches medial to big toe
          • Autopsy: gunshot entry point 3 inches lateral of median line at level of the 4th rib
        • We could update the bodyStructure resource to resolve the qualifier usage
        • bodyStructure has patient reference required – so it is an instance, not a type, so cannot be used for definitional resources
        • had discussion around resource vs datatype
          • reason for going with resource was that we wanted to track a specific element over time – for example a specific mole
          • would need to figure out, if condition will work to represent what we currently use bodyStructure for
        • Do we need to couple the deprecation of bodyStructure from creation of the dataytype?
          • Use case of forensics: have only a body part like a hand?
            • Use specimen?
          • Agree to separate these two topics – need to give
        • Datatype creation needs to go to FHIR-I
        • We need a common structure across all contexts, need standard framework for reasoning that can come up in observation, specimen, diagnosticReport etc
        • While this may not occur a large percentage of the time, it is very common in certain domains
        • This affects some normative resources, how to handle this?
          • Deprecate the existing attribute and add new element to normative resource: choice type of codeableConcept / new datatype
          • Make the codeableConcept mandatory and optionally allow use of the new attribute?
          • Call new datatype AnatomicLocation, and use that inside bodySite attributes and maybe even within the BodyStructure resource
      • Motion to recommend to FHIR-I create an Anatomical Location Data Type that enables post coordinated body locations documentation an establish an approach that enables consistent use of pre- and post-coordinated strategies given observation is normative by Stan Huff, Loraine Constable
        • Against: 0 Abstain: 1 In Favor: 8
      • Next steps:
        • Reach out to Patient Care and CDS to add it to procedure, Condition, etc. to the list.
  • MedicationRequest and ServiceRequest History - Emma
    • Changes, Dosage instruction history
    • Since it happens that MedicationRequest and ServiceRequest are changed without creating a new resource and versioning is not mandatory
    • Options 
      • resource versioning
      • specific attributes like encounter.statusHistory
      • new resource that is linked 
    • With resources are created on the fly and choices clients have a hard time to reconstructing the proper history
    • Need to raise to FMG on how to get guidance that can reduce variability and can predict the history by the client.
    • One approach is to more of what Encore does for certain fields that matter most. That is misleading if not done for all. 
  • CIMI
    • Motion that OO and CIMI recommend to FHIR-I to create an anatomical site data type that enables post coordination of representation of body locations and establish an approach that enables consistent use of pre-and post-coordinated strategies given Observation is normative.  Stan, Lorraine  Against: 0, Abstain: 1, In Favor: 8
    • Reach out to Pt Care, CQI, and CDS to add Procedure, Condition, etc. to the list.
  • Vital PSS update that may cover the AMA project piece, then we will archive the AMA specific PSS – Susan to double-check on that with AMA


  • Order History
    • Capturing MedicationRequest and ServiceRequest history
    • Changes (status, provider etc), dosageInstruction history.
    • As data changes on a resource you create a new version of the resource = current version of the same resource creates the history why is that not enough?
      • Refills create new medicationRequest that is tied to the prior medicationRequest
      • So when would I need to cancel vs update an existing request – that would be part of business rules
    • We are currently supporting snapshot, so you need to compare to all the versions of the same resource, but sometimes folks create resources on the fly
    • Three techniques to track changes:
      • resource versioning per metadata.version
      • specific attributes such as Encounter.statusHistory
      • new resource that is linked (even if not necessary per policies)
    • Need to provide guidance on how to best handle due to the variability
    • With FHIR resources developed on the fly, and choices how to do this, clients have a hard time reconstructing the proper history of changes to, e.g., order.
    • Use case to have complete copy of the record when you have to provide evidence why decisions were made based on the information at the record at the time the decision was made – so create a copy of each of the resources and retain those
    • Need to raise with FMG on how to get guidance that can reduce variability and can predictably establish the history by the client.
    • One approach is to do more of what Encounter does for certain fields that matter most.  That gets misleading if not done for all.

Q4

Chair: Hans Buitendijk

Scribe: Ralf Herzog

 OO/II - Joint Meeting

  • Updates from other quarters
    • Introducing new datatype for body site and approach to deal with changes to normative resources
    • Dealing with order history – or in general resource history guidance from FMG
    • Device, deviceDefintion and other healthcare product related resources
      • Profiles or separate resources and how to apply patterns to those


  • DiagnosticReport - DocumentReference
    • FHIR-19249 ( FHIR-19249 - Getting issue details... STATUS )  
      • Boundary clarification to documentReference
        • Need to provide guidance when to use diagnosticReport or documentReference for a scanned imaging or pathology report
        • diagnosticReport includes the structured data vs just scanned document
        • need to also discuss getting nested sections into diagnosticReport – or should we move that into composition
        • documentReference is ONLY the index to the scanned document, it should not be the source
        • if it is not FHIR based, should be diagnosticReport, if not FHIR-based may need to use just documentReference, since not enough information around the scanned document is available to create a diagnosticReport
        • do not use documentReference when pointing to a FHIR resource, exception would be ClinicalNotes
        • looking at UScore Guidance for ClinicalNotes ADD LINK!
        • when there was a serviceRequest then MUST return a DiagnosticReport, for other elements use documentReference for non-FHIR resources
        • In diagnosticReport can use observation.result can use valueAttachment for images and scans etc, also have presentedForm.url for pdf of the entire report
        • When you are not the creator of the data, use the documentReference
        • UScore requires to use documentReference for ANY scanned element (so that searching by documentReference will find all of them)
        • Prefer to have all diagnosticReports, even if scanned from other places in this fomat
      • Final conclusion:
        • DiagnosticReport is response to ServiceRequest
        • DocumentReference is used to 
          • reference non-FHIR artifacts
          • FHIR artifacts with the following added value: - This needs to be defined
        • Create a JIRA that DiagnosticReport.media should  be just datatype attachment Eric Haas
  • Pulled BlockVotes
    • FHIR-15865 ( FHIR-15865 - Getting issue details... STATUS ) discussion to find not persuasive to be consistent with ServiceRequest,
      • supportingInformation definition should not influence order instructions
        • intended is prior results, height/weight, or gender etc.
      • concern is that some of the supporting information may still affect the order, because certain tests may not be done in certain situations
        • may influence if the order is appropriate, so Kathy does not like
        • in other resources that have supportingInformation – supports the ordering of medication – sounds similar to that it still could affect the request; ServiceRequest has reasonReference
      • At this point this is consistent with ServiceRequest
      • Motion to find not persuasive as other request resources definition of the supportingInformation attributes include influence on the request fulfillment; whether the information is attached or not, or later retrieved will still influence fulfillment - Riki Merrick, Kathy Pickering
        • Against:  0 Abstain:  2 In Favor: 8
      • Create a new JIRA to have "Add a DeviceRequest.patientInstruction 0..1 string" in a separate tracker. 

Adjourned 5:36 PM AU time

Thursday Feb 6, 2020

Q1

Chair:  Hans Buitendijk

Scribe: Riki Merrick

  • Update from prior quarters:
    • Jira#25797:
      • For discussion on diagnosticReport – reached out to John Moehrke, Eric Haas and Rob Hausam to review prior to sending to zulip chat
  • Pulled block votes
    • 20913: ADD LINK!!!
      • Suggestion is to use status, which is how Rx is doing this on medicationStatement
      • Request is to be able to record "I am not using this device"
      • Status on resources are related to the resource
      • Should not mix the status of the resource and the status of the use statement content
      • That needs to be escalated to the event pattern = FHIR-I
      • Should useStatement be following event pattern?
        • status should not use "not-taken" and "stopped"
        • It could make the
      • Motion to find persuasive with mod - add a new fields
        • usageStatus 0..1, CodeableConcept example values: used, not used, what about usually, most of the time, but not right now? => always, sometimes, never,
        • usageReason 0..1, CodeableConcept or should that be free text?, examples: lost, broken, does not fit, stolen, the dog ate it
        • Riki Merrick, Ralf Herzog, no further discussion, against: 0, abstain: 0, in favor: 6
    • Support adding new attributes for the use status and use status reason rather than conflating the status of the resource to the event pattern – will make that another jira => #25798 ADD LINK!!!
      • Kathy is still thinking about better name than usageStatus – frequency maybe?
    • Writing a new jira / this will supersede an existing jira for allowing reference of deviceDefinition in addition to device for deviceUseStatement.device and also to figure out how to say "I am using lenses."
      • The fuzziness of the device being described and the need to make a statement about use or non-use should change deviceUseStatement.device datatype to codeableReference datatype, so that we can use codable concept or reference to either device or deviceDefinition => #25799 ADD LINK!!!
      • Motion to find persuasive Jose Costa Teixeira, Riki Merrick no further discussion, against:0, abstain:0, in favor: 6 – need to figure out how to update Jira with this vote!
  • In Europe there is a need to record who/which pharmacy provided device to the patient – similar to medication
    • Discussion to use MedicationDispense for that, but that does not seem quite right
    • Does dispense include patient instructions? – yes
    • Dispense = Act of associating the device to a specific patient
    • When you dispense you give to patient or to doc to administer – is that needed? We could use procedure for that and indicate the device that is being used, so that is not needed separately
    • Options:
      • Create new resource called DeviceDispense
      • use supplyDelivery and mark this with the specific patient (this does not follow the model we currently have)
        • Jose may be behind in updating, as supplyDelivery currently has patient as optional reference, but we were very clear in supplyRequest
        • We may have instances of shi[ments, wehre some items going to the same location are assigned to patients and others are not – those should not need different treatment – separate discussion
    • Have Jose Costa-Teixeira draft jira and resource proposal for deviceDispense resource

Q2

Chair:  Hans Buitendijk

Scribe: Riki Merrick

  • Joint with CG/BRR

CG update:

  • FHIR IG was published in November 2019
  • Focus here was what is in the lab report
  • Harmonized with MCode folks to use this IG as much as possible
    • May need to update some items for better semantic responses
      • For variant can test if it exits
      • Can declare what variant actually exist at a specific location
    • Working on roadmap to R2 for that IG
      • Have list of new items for consideration
      • Decision to use underlying
    • biologicallyDerivedProduct
      • Bob Milius organization is using this internally for tracking administration for outcome reporting, once workflow for transfusions and transplants there is more established will reach out to this WG
      • Add to other resources like procedure, specimen, diagnosticReport
      • This resource is describing the thing itself
      • How to deal with administration of biologicalDerivedPRodcut
        • Google health is currently using medicationAdministration for blood administration
        • Could use procedure also
        • Had discussion with CQI that they need to have something specific for that
        • ADD Hans ppt
        • Need to start group to document requirements for any blood administration:
        • Decision of using procedure with extensions or creating a new resource
      • 20560 and 16063
        • Part of the blockvote – has not yet been applied
      • 16065
        • Manipulation backbone should match elements in processing backbone
        • His jira asks only for procedure as codeable concept, so if there is need to add additive would need a new jira
        • Should procedure here be codeableReference, which is code and/or reference to a resource (which then would have specific details, including devices, additives etc)
        • Motion to find persuasive with mod:
          • change datatype of biologicallyDerivedProduct.processing.procedure to codeableReference
          • add new attribute biologicallyDerivedProduct.manipulation.procedure as codeableReference 0..1
          • Bob Milius, Riki Merrick, no further discussion, against: 0, abstain: 1, in favor: 4
        • Assigned to Jose
      • 14766 – need Jose - not discussed
  • 16488
    • This is a request for a generic extension across different resources owned by different workgroup – how to handle
    • May need a draft of this extension – Simone Heckman
    • Check with Rik about ownership of substance resource
  • 15922
    • Add reference to Q1 discussion on creating DeviceDispense as a new resource
    • Create a more generic delivery resource that can be the response to supplyDelivery as well as the DeviceRequest, so it can deal with items being shipped that are or are not associated with a patient (productDelivery) – path to the patient should be via the resource that requested it or could be delivered to a patient
    • Jose will check with PC as they are discussing transport resource – need to differentiate between transport of patients vs items for use somewhere
    • Need further discussion with Jose, Eric, Rick
  • Jira issues to report:
    • Intermittent issues filtering in jira:
      • on WG
      • on related artifacts
      • it seems clicking "all types" hindered, while clicking
    • Some trackers do not allow proposed dispositions

Q3

Chair:  Hans Buitendijk

Scribe: Riki Merrick

Joint with FHIR-I / SD

No CDS, no CQI, PC

  • Upcoming topics for FHIR-I
    • DeviceUseStatement to declare when something is not used, so added 2 new attributes for that, that will affect event pattern – so discuss the scope of status in the event resources
    • Resource proposal for deviceDispense
    • Making SupplyDelivery more generic, so it can address both response to deviceRequest or SupplyRequest
    • When to use diagnosticReport vs when to use documentReference
      • This may help clarifying what the name for documentReference should be
      • When do you use composition, diagnosticReport, documentReference
        • Need to have nested sections in diagnosticReport – or should we profile composition to cover diagnosticReport
    • Request for new datatype for anatomical location
      • Use of observation.bodysite – need to define the way on how to make this change for normative elements
        • Update the name
        • Deprecate and add new
    • Dealing with history of resources (order history question)
      • Rules for the data producers and the data consumers
      • When to add specific elements to resources to capture history (like in encounter)
  • Negation
    • How do we model when a clinician or patient asserts that something is not there
    • How to convert negation use in CDA into FHIR
    • Jay Lyle's project = need to follow up where that ended up – Rick Geimer
    • Level of negation (sometimes/always/never)
    • Need to be sure to not conflate the business status and the record status
    • Describe it as part of the underlying pattern
    • No known allergies – that is codeable; but saying not allergic to Penicillin is hard to code
    • medicationUsage -not for full history of the patient's medication (UScore no longer supports this)
  • Product pattern
    • Device/Medication/Supply/BiologicallyDerivedProduct/Nutrition/Substance – get consistency for these resources
      • Boundary around what is product transport (OO) vs patient transport (PC or PA?)
      • Request for any of these
      • Dispense
      • Administration vs use of procedure
      • Use statement (medicationUsage/deviceUseStatement/NutritionIntake)
  • Device/software
    • Physical thing used in patient care
    • Software that is part of the devices
    • Is that really the same, or should it be its own thing?
      • Value of keeping it the same:
        • it is globally regulated that way
        • Devices can be nested to include the components of all of the parts (version for pacemaker and software)
          • currently only point from child to parent, we may need to add component as an attribute in device to point the other way, when someone has a use case
        • device here is for ANY device – not just regulated devices (that line is realm specific anyway)
      • We need to update the definition of device to include software and also include software in the index, so folks can find it
      • When you are using a software as the author may be specific to the instance or more generic
      • When we split will have to deal with boundary description
      • Smartclient app with a particular capability
        • capability, but not in device, since the instance can point to the deviceDefinition to know the capabilities
        • to know what has been turned on device.property
        • capabilty (type or description) should change datatype to codeableReference, so you can use the codeable concept as well as a specific capability statement Jose Costa-Teixeira to write jira – also review datatype for capability.description – should it really be codeableConcept?
      • Follow up with Grahame on his point of view Hans Buitendijk
      • Then create a jira to summarize what changes will need to happen

Q4

Chair:  Hans Buitendijk

Scribe: Riki Merrick

  • V2-FHIR Mapping
    • Project page: https://confluence.hl7.org/display/OO/2-To-FHIR+Project
    • Mapping worksheets: https://docs.google.com/spreadsheets/d/1PaFYPSSq4oplTvw_4OgOn6h2Bs_CMvCAU9CqC4tPBgk/edit#gid=1930219638
      • Message shows status – ready for ballot / under construction
        • Review levels:
          • Project team (project listserve)
          • Community (larger listserve and zulip)
          • Ballot
        • Segments
          • Use of [] to explain the context
        • Datatype
          • May go to datatype or resource
          • Use of [] to explain the context
        • CodeSystem
          • Until the vocabulary is harmonized we have mappings for now to compare between V2 – FHIR
      • Reason for using spreadsheets is maintenance for now and for review
      • Working on generating conceptMap to make content more computable
      • Also hope to use V2+ tooling in the future
        • Reviewing ADT:
          • Sort Group keeps message structure when re-sorting is used for other reasons and will help pointing to specific locations in the message structure (might switch to use to XML tag representation going forward)
          • Primary Target lists the FHIR resource [] creates the reference to the right resource instance
          • MSH content maps to FHIRmessageHeader and Provenance
          • Columns G (computable) H (computable different representation) and I (descriptive, not yet computable at standard level) lists the mapping conditions based on one row at a time
          • Some elements in FHIR resolve context issues different, hence the
          • Working on examples is still work in progress
        • Reviewing PID
          • Extensions
            • Proposed = one column over from FHIR attribute until approved
            • Existing = in FHIR attribute column
          • Blank mappings (PID-37) = no idea if anyone uses it; leave it open until we learn someone is using it
        • Looking at datatype mapping
        • Looking at vocabulary mapping
      • Anyone can enter comments / suggestions to add more mappings on blank rows now
      • Intent is to have a peer review of this as IG by end of Februrary in preparation for May 2020 ballot
    • Implementation in conceptMap: https://confluence.hl7.org/display/OO/v2-to-FHIR+IG
      • Use conceptMap.narrative to embed the original spreadsheet
      • For source want to point to V2 content in structureDefinition
        • Need to figure out what to point to
      • Need to figure out, if we need more than one group – or if use of the XML tags is precise enough
      • Need a way to express sequence – this is an extension at the moment
      • Need indicator for proposal during construction
      • Use dependsOn to describe the conditions
      • conceptMap will be stored in github
      • when we create editors for the V2+ content we hope this will become the place to edit on the conceptMap
    • Reviewing comments:
      • RXO segment
        • How to deal with RXO-2, RXO-3 and RXO-4 – how to deal with minimum and maximum and units?
          • Dosage datatype:
            • DoseRange uses simple quantity datatype
              • the restriction only means that you cannot use the comparator element of quantity, but units is still part of simple quantity
              • this should be better displayed as a profile on quantity to show the diff
  • Should we reach out to integration vendors to review these?
    • Some are involved, some are sitting on the side lines, happy to get input from all anytime
    • David Hay can reach out to Lyniate (Corepoint & Rhapsody) to give them Craig's and Hans contacts
  • Currently using message structure as base of mapping, not yet the trigger event
    • Message structure was not required in older versions of the standard, so that may be a challenge how to handle that part
    • In data you may have certain codes that apply for this message structure
    • We are trying to define the cumulative superset of all V2 elements – deprecated as well the latest versions of segments, datatypes
    • Most importantly to have good examples for visualizations – ideally we could show V2 content and how that morphs to the FHIR representation and then you click to get you to the IG – David Hay will give it a try, when we have an first draft
      • conceptMaps will be linked from the message
      • 1 conceptMap per version of the segment / datatype etc
      • Using a maximally populated V2 message and create the maximally populated FHIR message from that
  • V2_FhirMapping tooling discussion tomorrow Q0
    • Recap work / discussions from earlier this week
    • Working on conceptMap representation
    • Craig and Robert will most likely call in


Friday February 7, 2020

Q0

Chair:  Hans Buitendijk

Scribe: 


Q1

Chair:  Lorraine Constable

Scribe: Riki Merrick

  • Topics
  • OrderCatalog
    • Not enough of the right folks in the room to make decisions, but can take a look at what is currently in the build
      no longer using catalogEntry
    • Are using specimenDefinition, planDefinition, deviceDefinition etc building a profile on composition for catalogHeader
    • Will have to bring this back to OO to ensure all the changes are still ok with the main WG to review the IG proposal, resource proposals (retire catalogEntry)
    • Planning connectathon for San Antonio
    • Discussion around having overarching catalog IG for scope with segments for individual domains like lab, devices etc.
    • 2 ways to get to the items: 
      • Catalog points to the item (Method 1) – makes it very long, even if you just reference every item in the catalog will create a maintenance challenge, especially when an item is in more than one catalog
      • Item points to the catalog (Method 2) – this allows for each item to know which catalog(s) it belongs to, so only the item needs to be updated and then the catalog
      • How do you get all items in one catalog using Method 2 – search through list of items that reference the catalogHeader you are interested in -  this part should be included in the connectathon track
    • Should start to get co-sponsoring WG Pharmacy and II acquainted with this content
    • Where does catalog specific data go? Item holds that
    • How do planDefinition and activityDefinition work together?
    • specimenDefinition and observationDefinition define the details of the results and specimen around the activityDefinition, that represents the test – we are now using planDefinition to represent the ordered item (can be a test or a panel) – in many cases the planDefinition will reference just 1 activityDefinition
    • planDefinition replaced the functionality of catalogEntry, but it can do much more:
    • Reach out to CDS to get their input, since they are currently working on creating ordersSets using planDefiniton – calls are Wednesday ADD TIME
    • Balloting aim for Sep2020, though May2020 is possible
      • go through the FHIR IG QA checks and see where we are
      • check with Francois for the final timeline
  • LIVD:
    • Reviewing the slides: https://confluence.hl7.org/download/attachments/20021943/LIVD_FHIR_Mapping.pptx?api=v2
    • LOINC to IVD code mapping – IVD vendors can provide the list of suggested LOINCs applicable to the tests available with rules for when to apply which ones
    • Phase 1 has been balloted and is in process of being published (green boxes)
    • Phase 2: Result values for non-quantitative results will map to value sets using SNOMED CT or LOINCanswer codes
      • Needed support to allow mix of vendors
      • conceptMap can be re-used within the LIVD catalog
      • conceptMap is using observationDefinition as source (has always been allowed, but is not often used)
      • using another conceptMap to map the result values – using intensional or extensional valueset definitons = ObservationDefinition.codedValueValueSet? – check name???
      • we created a resultValueSuperset that can be used
      • all LOINCanswercodes are grouped together into one conceptMap and a different one for SCT
      • users still need SCT licenses for use, but we think we can create a subset similar to the LOINCs we know will be in use for the respective codes
      • balloting timeframe – goal is after publication of phase 1 – include feedback from use of published artifacts and then add on phase 2 content. Expect publication request before San Antonio
      • Is there a reference implementation?
      • We currently don’t have a user representation for this, hard to check that – we can produce the data, but we don’t have consumers – best use for now will be for "secondary data use" like Population health
      • We could make this content visible and actionable easily to perform the mapping from the LIVD
      • Check with JD Nolen, if we can get them to help improve data consistency and show value of this project – need carrot/stick (CLIA / CDC / FDA)
  • Substance – is still owned by OO – at WGM in May 2018 OO voted to transfer to BRR - Hans brought this up to FMG the next day – dropped off FMG agenda end of 2018 – so Hans will bring this back up on next FMG meeting


Q2

Chair:  Hans Buitedijk

Scribe: Riki Merrick

Joint with FHIR-I

  • FHIR-Planning
    • R5 planning
      • Timeline
        • CMS rule timeline is up in the air, but we assume it either points to R4 or nothing, but there is work of interest in R5:
          • Subscription
          • IDMP
        • First ballot in Sep 2020
      • What normative?
        • diagnosticReport (FMM3)
          • lots of discussion around this
          • not getting feedback from radiology – have a call with II scheduled on 2/18 around this
          • not enough complex examples
          • boundary to documentReference
          • has had production support at Epic – preference to go normative
          • need clear testing across scope testing (broad use in narrow domains)
          • product directors goal is to have this normative
          • align with USCore diagnosticReport
          • request for nested sections => boundary to composition?
            • Can we add this here, or use composition for the use case?
            • Can we find Jira#? - campe from BreastRadiology report IG - that is explorign all the options currently possible - in ballot reconciliation
            • Goal is to structure something that resembles the format radiologists and pathologists are use
            • Use the .Members for sections
            • Needs to support finding a list of all observations in the report
              • Using an observation as a section heading, that this should work, though it has no value itself
            • Add a section element as optional that contains
              • codeableConcept to name the section
              • Result
              • Specimen
            • Alternatively create 2 observation profiles:
              • one that builds the proper panel representation when you have only a grouper function for the first set of observation tree
              • one that builds the proper panel representation when you have a value at the summary level
          • NEXT STEPS:
            • Close discussion around composition profile option
            • Grahame Grieve can create the alternative representations so we can see what either of the above alternatives look like and see how they will work - check with Richard R. Esmond for examples
            • Grahame Grieve to survey existing implementations around what they are currently doing around
        • documentReference (FMM3)
          • so broad, overlaps with everything – used as a catch all
          • goal is to have this normative
          • renaming to contentReference?
            • Since there is a request for imageReferenceresource
            • What is the impact at this time?
            • documentManifest (SD) – should we then also rename that – or make it go away – still open – this maps to the IHE transaction models – Grahame hopes that IHE can use list and update their specs
            • NEXT STEPS:
              • Grahame Grieve to survey the implementers before ballot (feedback before May WGM2020) Epic does not care about namechange
        • serviceRequest (FMM2)
          • should get to FMM3/maybe FMM4
        • task (FMM2)
          • should get to FMM3 (stretch goal)
          • a lot of workflow still needs more work
          • need to have more folks better understand how this can be helpful in converting v2
        • device (FMM2)
          • has been in use for a long time but with the resource split the FMM changed
          • would be nice to have the attributes that are covered by regulation / common use of identification to make those normative, while keeping the other elements TU
          • look at what is in USCore (FDA required)
          • Software algorithms should not be treated as device
          • NEXT STEPS:
            • Identify the attributes that should be normative by May2020
        • specimen (FMM2)
          • working on aligment with DAM
          • working with IHTSDO
          • whatever we can get to, no implementer push at this time

Q3

Chair:  Hans Buitendijk

Scribe: Riki Merrick

With Conformance/

  • V2 Change request review – this is aimed at mostly the editors of V2 – ensure that the existing gForge items are properly characterized in terms of status and potentially
  • V2-FHIR mapping
  • Conformance ballot questions
    • Rob to review
    • Will set up confluence and schedule calls for review after that
  • FMG topics
    • V2+ presentation
      • Status update
      • Interest in using FHIR structures to host the source of truth for publication
    • New datatype anatomicalLocation to support post-coordinated bodyLocation
    • What to do around bodyStructure resource in light of creating the new datatype / use specimen for that instead?
    • How to apply changes to normative resources
    • Dealing with resource history
    • Patterns for product resources
      • Workflow perspective is what is currently defines the pattern – but products may have their own
    • Ownership of substance resource
    • diagnosticReport/documentReference boundaries
    • Creation of more genericDelivery as response to deviceRequest and supplyRequest / sync up with dealing with patient transport
  • Jira review
    • searches
      • Need to be careful to select the right type in order to have search functionality on specific other attributes to work
      • HQ/TSC is aware of the need to create How to documentation for triaging jira comments
      • created OO specific open issue search: 
    • #19249 – documentReference boundaries
      • Do NOT create just a documentReference for a diagnosticReport, only in addition
      • Anything non-FHIR is fine as a documentReference
      • Add comments from this week @Hans to do
    • #19253 – DiagnosticReport procedure
      • code can that be used to figure out the procedure related to the this report:
        • there is no intent to use code in that manner
        • this is linked to LOINC diagnostic report codes
        • there is no clear place for procedure in this – should we add procedure as allowable reference to basedOn?
          • observations have their own method to describe the
          • imagingStudy – only the images
        • there is an interest to link the diagnosticReport to link to the procedure(s) that produced the observations
        • procedure may be able to be obtained from the serviceRequest
      • Hans Buitendijk  to reach out to Eric and Michelle before dropping in a note
    • #19362
      • Related to 19253
    • #19516
      • Is workflow related; was in blockvote
    • #19734 – diagnosticReport.media should allow reference to documentReference
      • In R4 still pointing to media, but in current build it already points to documentReference – ask John Moehrke if this can be closed.
    • #20337 – update the valueset definition for diagnosticReport.category
      • We no longer see this text – the current text is much better than what is
      • it looks like this is resolved
      • motion to find persuasive with mod – we note that other changes have already been addressed in R4 – Riki Merrick, Issac Vetter, no further discussion, against: 0, abstain: 0, in favor: 6
    • #22147 - need to allow a device to be performer
      • observation.Performer:
        • Performer is currently defined as the entity that asserts the observation it is "true".
        • Update definition to read: Who performed the observation (with or without a device) and was responsible for asserting the observed value is accurate and complete.
        • Device is separate attribute in observation, so covered there.
      • DiagnosticReport.Performer:
        • Is responsible for issuing the report
        • This seems to be the person that is collating all the information into the report – should this be renamed to be DiagnosticReport.author?
          • Does author has another implication in FHIR?
          • Checking in composition
            • Allows for device – should this be attester = which is the same as authenticator in CDA
          • Update attribute name to DiagnoticReport.author and allow use of device in this slot
      • Often what we really are interested in is the person responsible for reviewing and releasing the report => we think that will be the
        • DiagnosticReport.resultInterpreter:
          • Practitioner and organization responsible for the report's conclusions and interpretations
          • that should never just be a device, so current references are unchanged
    • #23808 - add biologicallyDerivedProduct to DiagnosticReport.subject
      • Motion to find persuasive and add biologicallyDerivedProduct as reference option in diagnosticReport.subject; compatible, substantive, R5, assigned to Eric - Riki Merrick, Ralf Herzog, no further discussion, against: 0, abstain:0, in favor: 7
  • notes for jira feedback:
    • if already identified as pre-applied in the form, shouldn't status go to applied?
    • Should be easier to get from proposed disposition to go to voting, when resolving an item on a call rather than as part of a block vote

Q4

No Quorum




  • No labels