No longer in conjunction with DiVinici project as they did not wish to pursue in connectathon
Have been watching case reporting, but have been watching other reporting activities needs, like quality reporting and common elements started to emerge that need to addressed. Started seeing this too between infectious vs chronic and with other PH domains.
CDC has started to pull together these ‘topics’ and how we commonly talk about them and address them. If we are doing things differently across domains, we need to understand why and be cognizant of the burden we place on reporters as well as ourselves.
CDC was funded by the Patient Centers Outcome Research (PCOR) group to put together a reference arch and common tools that could be used to support getting data out of EHRs for PH, research, and other needs. Led by Maria Michaels and Wendy Blumenthal. We should be hearing more about these activities and hope that this community engages.
Commonalities and need to support each other was recognized
We will start today, and then continue next week
Reporting, Surveillance, Population Health, etc
3 legs that need to be considered- providers, patients, and population/pubic health
Many of these population activities rely on ‘reporting’ that much of the time relies on secondary use of EHR data
While some reporting is required by law and all EHRs are expected to participate, not all major aspects are a part of the FHIR API
Burden- PH has been named in the ONC burden reduction strategy; providers often see it this way. One way to tackle this is to automate, as well as make EHR implementation the least burdensome as possible. Usually in order to implement reporting, significant development is needed to implement, which can be costly
Going to focus on how we can advance reporting infrastructure and make it not a development activities, rather a configuration activity
Common reporting Framework Concepts
Reporting should be more configuration by EHR, and less development
FHIR Ecosystem offers tremendous tools to automate EHR reporting implementation now and do more
Use FHIR API & standards based elements wherever possible
Promote other needed resources and elements into FHIR API
Harmonization of data ‘payloads’ also need attention
Should be advanced in FHIR data model, USCDI, and FHIR IGs
Policy- support reporting to trusted third parties, gov, and possibly other HC organizations
Support bulk operational EHRs and Bulk FHIR repositories
Support identifiable, pseudonymized/limited data set, de-identified data
Should apply to public health and non-public health programs, all of which should use FHIR API
Minimizes varying technical demands that produced reporting burden
Will share slides and will discuss substantive content on the next call
Karla (NC)- Seems like a really great use for FHIR tech would be to go back and get additional information that reported in the initial report
‘Investigation’ is certainly an important PH function, not the only function
The technology supporting going to the EHR to get data is certainly well established in the FHIR paradigm. The problem would likely be more policy and authorization, not so much a technology perspective.
We start with the aspects of reporting that are not necessarily addressed with the ‘querying’ paradigm, that are not attended to in the FHIR construct
Danny- What is the expected timeline that this would be a reality or goal?
The timelines for different elements are very different.
Some are in a proprietary state, construction of an IG, bundle of what needs to be reported. Could use proprietary aps, CQL engine… we will lay out the timeframes at a high level next week when we go through the specific elements. Can be hard to predict.
DiVinici has a tremendous amount of leverage. Was hoping to harmonize with them so they could be leveraged for PH as well.
Currently on release 3. The idea is to make updates to the DAM to accommodate specifications that have been developed in the VR domain that have not yet been represented in the DAM, like Death FHIR and v2.6 Death.
Would want to go from an informative version to an STU with the expectation that specification developed in the domain will be represented in the DAM
Intending to go ballot in May 2020. Cutoff date for PSS is Oct 4.
5B in PSS form didn’t list just STU; you could only list STU to Normative. Not expecting this to go to Normative until subsequent release. We think this is the right value.
The Continuous Maintenance model doesn’t apply to informative, which is one of the reasons why we are moving towards normative so we could do continuous maintenance without additional projects. Only eligible for ANSI standards.
This will have to go through the normal approval cycles, after the workgroup approval, it will head to US Realm. We have had interest from other countries, but nothing expressed formally.
Netherlands, Saudi Arabia,
Every year the demos get more and more international interest
What would need to happen to expand- can be expanded at any time during the life of the project. Would need to come back to the sponsoring WG and get approved… would also impact project timeline
Motion: Craig moved to approve PSS
4.Vital Records V2.6 extension (Mead/Cindy) - 5 min
Nothing to present
The version 2.6 birth and fetal death IG STU ends in Feb. there are a number of comments that have been reported against it and they would like to update. Is there any way to address without going through a ballot cycle?
NCHS wants to move to FHIR and not invest too many resources into this process
Could do DOT release (notification to list serve with 2 week comment period) if not substantive
DOT release doesn’t affect the life of the doc. It doesn’t extend the life of the doc. Would likely have to submit an extension.