| 45 min | eCR Update | John Loonsk | 
- Metrics:
- >28,000 HCOs in production
- 2073 hospitals
- 355 critical access hospitals
- 1472 FQHCs
- 11441 ambulatory facilities
- Accelerated onboarding for EHRs
- 66 EHRs engaged in onboarding
- Wanting to drive everyone to FULL eCR where 200 + conditions are supported by eCR as opposed to COVID Only
- Currently only functional requirements in rules, no standard specified
- Wanting to see specific eCR standards include in certification (CDA or FHIR) and the specific release CDA eICR R3.1 and FHIR eICR R2.1
- Need to move in this direction to address needs in data quality
- Data Quality
- Desire for processable data
- Process for improvement include:
- Quality assurance working group
- DQ schematron; PHAs can get technical support to implement schematron during the HCO onboarding process.
- DQ monitoring report. DQ schematron and monitoring report goes through each data element to determine completeness quality. Given to HCO and EHR vendor during onboarding so they have a clear view of how data coming from them don’t meet the requirements for public health. It is also used during the onboarding process by AIMS to help advance quality improvements
- “Requiredness”
- Requiredness is also expressed with the quality of the data, including where data and /or terminologies are required to be
- Despite having some degree of requiredness, but none meet complete needs
- None of the current federal levers results in getting high quality machine processable complete data for PH
- Part of this is a communication issue and attempting to generate and provide feedback with regards to quality through the DQ monitoring report
- FHIR is as irregularly implemented as CDA right now or more so
- Issues in clinical workflow, feeding systems, EHR interfaces, mapping into resources, API...
- Because the needs of data is different for Public health vs HCO, data quality needs to be more of a priority of standard work, regulation, and national conversation.
|
| 45 min | BSeR update and ballot recon | Sarah G. | https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=16617 - US public health profiles library (USPHPL) are a collection of sharable reusable FHIR profiles
- It is intended to complement US Core. The profiles are intended to be referenced and used by US public health implementation guides to foster interoperability not addressed in US Core.
- 0 published in 8/2023
- IG publisher version that includes the USPHPL check is expected later this month
- IG Publisher QA report will have a warning if a developing IG develops a profile that already exits in USPHPL
- IG developer will need to use the USPHPL profile or engage PHWG to request a variance
- The USPHPL exist in both eICRs, Medmorph IGs
- Moving forward will develop closers relationships with USCDI+, VR CPL, and additional PH programs
- Some USPHPL are needed refinements of US core profiles. There are ongoing processes to retire some profiles when a functional US Core version is available .
- Implementing committee processes with the PH WG
- Would like to develop support for ongoing maintenance
- Draft USPHPL Exception Process Document on our confluence page – US PHPL Variance Request Process
- Suggestions: Include narrative that explains the relationship between this and other artifacts like PHIN VADS/VSAC. Include a flow diagram for implementers
BSeR Ballot recon - Group 5 - 42206, 42207, 42217
- Motion- Sarah moves to approve as persuasive
- Second-John Loonsk
- Abstain-0
- Against-0
- For- 20
- 42218
- Remove MustSupport on slices for Task.Identifier
- Need to research
- 42221
- Remove MustSupport on Task.note
- Would like some guidance on when to use note as opposed to other
- Need to research
- 42220
- Relax Cardinality on subject of task
- Could provide general guidance on expecting subject present in needed resources. Could provide guidance that the task preceding the service
- Need to research
- 42225
- Motion- Sarah moves to find 42225 persuasive
- Second- John Loonsk
- Abstian-0
- Against-0
- For-19
|
