Versions Compared

Key

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

Facilitator

Andrew Statler

Date:


Quarter:

4


Location:

M102


From Agenda:

  • (tentative for ballot reconcile)...
  • USCDI - Brett MarquardMarti Velezis
    • https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24444
    •  Brett:
      • August 15 block vote: US Core out for updates; Implantable Devices profile was added with UDI mandatory support & approved
      • Eric & Brett applied the tracker
      • Sunday - someone said "hey, I didn't know this was mandatory." - several vendors expressed surprise at this change
      • There were a large number of changes grouped together in the tracker
      • We are now in open comment period - A comment has been submitted that UDI should not be mandatory
    • Hans:
      • In prior discussions there was a difference in opinion on whether it should be mandatory
    • Brett: Let's look at Issue 24444 - handled individually and then subsequently pushed into block vote
    • Marti: want to avoid going back and forth on the cardinality as people find new use cases / justifications / rationale
      • One concern was historical implantable devices; there may be others
    • Hans: quite a few use cases were discussed. Earlier today requested the language that was proposed with 0..1 which was not accepted by FDA. Can we look at that now?
    • Keith: in the context of implantable medical devices in emr, it makes sense for FDA to want it to be 1..1; but in the context of a PHR, there is no way a patient can provide the UDI. A payer may not know; this would require new specifications for payers profiles.
    • Marti: patient reported / international / payer - all are considered historical.
    • Danielle: we want to send the UDI if we have it; it's not always possible
    • Marti: if it's recorded today, UDI MUST be recorded
    • Jenni: someone comes in the ER and triage documents an implant (Marti: that's historical)
    • Brett: (to Marti) do you agree there are times when UDI is not available? (Marti: yes) Then would you be okay with 0..1?
    • Marti: yes, but only with the right text that for active procedures, UDI MUST be recorded
    • Hans: It's clear that historical vs point-of-procedure documentation needs to be clarified. EHR's are being certified; they may not contain the surgical capabilities. The surgical system may or may not be certified. Cannot hold EHR accountable for what other systems support.
      Re-request - what was the original 0..1 text.
    • Brett: Let's clarify what are the appropriate categories where UDI would not be mandatory. Cooper supplied a list (in tracker 24444). Let's go through them.
      • Patient reported - OK
      • Internationally (Marti: yes, those are historical)
      • Old data imported - clearly historical
      • Historical data documented in current EHR - also clearly
      • Current and future devices documented without UDI - Cooper clarifies: example something gets done but barcode scanner was broken or was otherwise not recorded
    • Eric: certification is not going to look at all of this guidance (everyone else: yes, they will)
    • Hans: need to clarify the use case of multiple systems connected to an EHR.
    • Brett: "you shall send UDI.... when you have it"
    • Keith: payers - another alternative. Elsewhere in US Core "if you have it, you shall send it" is the requirement. For certification you are given specific use cases.
    • Hans: need to be careful with SHALL's, 1..1 vs 0..1 and "must support".  0..1 must support means this exactly (what Keith said)
    • Marti: would prefer text that provides more background.
    • Eric: there is plenty of guidance on UDI (from link in tracker 24444)
    • Cooper: if the intention is to enforce surgical practice documentation, FHIR profiles are the wrong lever to pull
    • Avinash: this requirement has been since 2015, similar to "if you have it, exchange it"; test scenario is "given a UDI, enter it and exchange it."  We've never gone through the caveats like historical, etc. (Jenni: that's the equivalent of "must support" in FHIR)
    • Marti: can we keep the 1..1 but require a reason?
    • Jenni: like a DAR - you won't be left with any more information besides "data not available"
    • Cooper: yes, there's an option, but it's not well supported / accepted by the community
    • Marti: just trying to increase the probability that people will submit / exchange the data
    • Keith: can we stop debating and call the question?
    • Marti: we'd have to undo everything that has been done (the cardinality, the invariants, the documentation)
    • Brett: it's very common for us (HL7) to say "we'll do X, Y, and Z" and then there is a final vote at publication. So we don't need to solve this today. It's not a massive rewrite that needs multiple iterations.
    • Marti: I need to vet it with others who are not here. I'm fine with agreeing to the cardinality and invariants and looking at the text, making it clear what the expectations are for additional missing questions.
    • Hans: (presenting and editing the tracker; adding motion as a comment) https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24444
      • Motion made / seconded by Marti / Keith of the above.
      • Discussion:
        • Brett: can we resolve tracker items during the comment period
        • Hans: as long as everyone is notified
        • Marti: when can we validate this?
        • Brett: before we publish, we'll ask everyone whether the comments have been faithfully addressed
        • Friendly amendment: change EHR to HIT (since the comment was still being edited, it now says HIT.
      • Abstain: 5
      • Against: 0
      • For: 16
      • MOTION PASSES!
  • Adjourn 4:40pm



Notes/Minutes

 




Include Page
CDA:Copyright Footnote
CDA:Copyright Footnote