Page History

• We’ve moved from use case discovery into planning phase
• Success metric for planning phase: detailed plan with defined resources, 1-2 committed champions, 2 committed implementers (use case actors)
• BP Readings Data Requirements are still a WIP
  • • What was protocol use?
    • What elements are missing?
    • What’s needed for MINIMUM CORE DATA SET that is foundational to IG?
    • Will requirements be the same in 5 years? Want to ensure durability and sustainability
• Average BP (WIP)—continued discussions around what does it mean? What are we asking for?
• Data requirement considerations
  • • Internal discussions on this and call for ideas on building IG from standpoint of data elements themselves
    • Want to ensure community knows what we’re considering
    • Will we allow manually collected data or just device-generated
    • Who determines data fidelity? Physician?
    • How do we balance meta-data needed to assess accuracy of BP measurement against burden of collecting data
• Vital Signs IG Conformant BP Panel
  • • Just a draft/example shown
    • what is the minimum viable instance needed for a BP panel?
    • Can include more information in the MS version
    • Vital signs IG was developed for larger context than just BP
• Vital Signs IG Conformant Average BP Example
  • • What goes into defining an average BP?
    • What information is associated an average vs. a single measurement?
• Note that USCDI v4 adding BP data element: https://www.healthit.gov/isa/taxonomy/term/1391/level-2
• Considerations around reusing existing artifacts
  • • Must Support (MS) is inherited so it can be a significant restriction
    • Aligning to requirements of multiple IGs
      • Hard to determine where incompatibilities exist
      • Implementers will be burdened if we point to 5 different standards, so do we align to a standard or formally depend on it?
      • Don’t know what level of adoption is on some of the existing IG’s so unclear what the likelihood of traction is

Barriers/Obstacles to scoping work:

• • Impact vs. effort—what data elements would be the most impactful, without being too cumbersome on patients or clinicians?
  • And how much work is required to accomplish something that is high impact?
  • Want to focus scope on patient-facing BP measures that will someday become autonomous

 Opportunities for improvement in interoperability:

• • Harmonize vocabulary for patient and device communication
  • Device data standards in plug-and-play way for any vendor to provide SMBP
  • Our work is best focused on the link between EHRs and Personal Health Intermediary and vice versa, and the Device Gateway to Personal Health Intermediary

• Don Casey (IPO 4 Health): Request for specificity in what the standard we’re referring to is and what the goal is. And was the standard used?
  • Response: we don’t want to protocolize the process but the measurements; question of scope for us and what advances the interoperability framework
• Peter Muir (PJM Consulting LLC): Other useful elements to consider: Body posture, rest time before reading, category for home readings vs office readings, defaults for office entry, caution re: clinician overload
• Matthew Kalscheur (University of Wisconsin-Madison): Has the group assessed how common and how accurate the “irregular heartbeat” notifications are on home cuffs. As an EP, I’m biased, but this could be useful data.
  • Response: trying to limit scope creep right now so not something assessed yet but something to consider for future work
• Dan Rutz (Epic): Difficult decision to make on when and how to align with other IGs and otherwise choose the project's dependencies. It can be summed up like this:https://xkcd.com/927/
• Akash T: When interacting with doctors, when talking BP and BP machines, they also provide heart rate and piece of info is collected at the same time. Within scope of work, are we collecting heart rate and how?
  • Response: Yes, this is a base that we extend to multiple other patient-managed or self-monitored values. We’re trying to prevent scope creep right now. Get something that works now and then expand in the future
• Don Casey: Have you considered using categorical classification of each SBP in accordance with the ACC/AHA taxonomy instead of raw numerical values?
  • Response: data placeholder for class is useful but raw data may have a lot of value. Best practice: use pre-processing as little as possible as that’s best bet for reusability
• Stanley Huff (Graphite Health): MS doesn’t mean you must enter it, just instruction for infrastructure and representing data

• Hypertension Management Use Case Team:
  • Connect with organizations that are interested in more in-depth discussions on CardX, the Hypertension Management use case, and becoming a CodeX member.
  • Complete HTN related IG Gap analysis
  • Flesh out plans and obtain commitments for demonstrations (increasing scope and complexity)
  • Scope additional interoperability opportunities in Hypertension Management
  • Further develop BP scenarios and their impact on workflow: what are the 5-10 different ways BP goes from a patient at home to an EHR?
• Community:
  • Provide input on self-measured BP scenarios and workflows
  • Share input on additional priority areas in Hypertension Management - what should we tackle after SMBP?
  • Support the inclusion of the Average Blood Pressure data element in the final version of USCDIv4 (comments due April 17 2023): https://www.healthit.gov/isa/taxonomy/term/1391/level-2
    • To post a comment, log in to your account or register for a new one on the USCDI ABP webpage (links to log in and register are at the very bottom of the linked webpage) and make it known that you support the adoption of Average Blood Pressure into the final USCDI v4.
    • If you’d like to learn more, below are links to the draft USCDI v4 and the ONC Health IT Standards Bulletin: Draft USCDI v4, ONC Health IT Standards Bulletin

• • Share your thoughts on how you prefer to be notified of CardX community calls (email invite only or calendar placeholder)