We began the meeting with an introduction from Dr. Perlin in which he noted that reports by commissions such as PCAST need to be read, not for their details, but for their directionality. We should ask about the trajectory the experts think we should be on and how/when should it modify our current course. Dr. Blumenthal also offered an introduction to the PCAST discussion, noting that the White House fully supports and encourages interoperability, suggesting that we should accelerate the priority of healthcare information exchange in the progression from Meaningful Use stage 1 to 3.
We discussed the origins and history of the PCAST report. The President asked PCAST how health IT could improve the quality of healthcare and reduce its cost, and whether existing Federal efforts in health IT are optimized for these goals. In response, PCAST formed a working group consisting of PCAST members and advisors in both healthcare and information technology.
The working group held meetings in Washington, D.C., on December 18, 2009, and in Irvine, California, on January 14 15, 2010, as well as additional meetings by teleconference. The viewpoints of researchers, policy analysts, and administrators from government, healthcare organizations, and universities were presented and discussed.
A draft report developed by the working group was submitted to the Health and Life Sciences committee of PCAST. That committee submitted the draft to several outside reviewers, who made valuable suggestions for improvements. From the working group draft, the additional input, and its own discussions, the Health and Life Sciences committee produced the present report, which was discussed and endorsed (with some modifications) by the full PCAST in public session on July 16, 2010.
A disclaimer at beginning of report notes "Working Group members participated in the preparation of an initial draft of this report. They are not responsible for, nor necessarily endorse, the final version of this report as modified and approved by PCAST."
We identified a number of key themes in the report
1. The foundation for healthcare information exchange should be built on an XML-based Universal Exchange Language
2. Data elements should be separable from documents
3. Metadata should identify characteristics of each data element i.e. how it was recorded, by whom and for what patient
4. Privacy controls should integrate patient consent preferences with metadata about the data available for exchange
5. Search engine technology/data element access service indexing at a national level will accelerate data element discovery
6. Data reuse with patient consent for clinical trials and population health is a priority
The key ideas from the discussion included:
a. Thinking at a national scale is good to avoid creating regional health information exchange silos
b. Messaging (such as HL7 2.x) is still going to be needed to support event-based transactional workflows
c. The strength of the PCAST report is in supporting exchange models that require aggregation - research, epidemiology, and unanticipated interactions such as Emergency Department visits.
d. For some uses such as communication among providers, encounter summaries which provide structured and unstructured data in context, are more useful than data elements
e. Many data elements are not useful on their own and a module/collection of data elements would be better i.e. Allergies should include the substance, onset date, the type of reaction, the severity of the reaction, and the level of certainty of the reaction (your mother reported it based on a distant memory verses a clinician observed it happening). To understand how best to collect data elements into modules, clinical data models would be very helpful.
f. Since information is going to exchanged among multiple parties, metadata will need to include the provenance of the data, so that data is not duplicated multiple times i.e. Hospital A sends data to Hospital B and C. C requests a copy of B's data (which includes B and A) and it should be possible to avoid storing a duplicate of A's data which C already has.
f. We should proceed with the health information exchange work already in progress to achieve interoperability in support of Meaningful Use stage 1 and not derail current efforts.
g. Finely grained privacy (to the data element level) will be challenging to implement and maintain. Tagging elements with privacy characteristics is very hard because societal attitudes about the sensitivity of data elements may change over time. HIV testing used to be a rare event, so the presence of an HIV test alone (not its result) could be concerning. Today 1/3 of Americans have had an HIV test, generally as part of getting life or health insurance, so the presence of a test is no longer a stigma.
h. The national scope suggested includes using web search engine technology to keep a data element index, identifying what data is available for what patients and where. The policy and security issues of doing this are greater than the technology challenges.
The next step for the PCAST report will be ONC's naming of a multi-stakeholder workgroup to review the report in detail and make recommendations by April.
We next heard about the planned Implementation Workgroup hearing regarding certification, Meaningful Use, and healthcare information exchange. On January 10-11, the Workgroup will learn about early adopter successes and challenges.
Next, the Clinical Operations Workgroup reported on its plans to consider vocabulary and content issues for devices - critical care, implantable, and home care. Issues include universal device identification, ensuring data integrity, and interoperability of devices that may require a clinical data model to ensure the meaning of data communicated is understood by EHRs, PHRs, and devices.
We next considered the standards and interoperability framework priorities as outlined by Doug Fridsma. The S&I Framework contractors are working on clinical summaries, templates documents, Laboratory results, Medication Reconciliation, Provider Directories, Syndromic Surveillance, Quality, Population Health, Clinical Decision Support, Patient Engagement, EHR to EHR data exchange, and Value Sets.
Points raised during this discussion included the need to include policy discussions throughout the process of harmonizing and testing standards. We agreed that the Clinical Operations workgroup should study these priorities and make recommendations based on real world implementation experience that will help ONC and the contractors focus on the gaps to be addressed such as patient identification and vocabularies/codes sets.
We discussed the HIT Policy Committee's request for the Standards Committee to work on Certificate Management standards. The Privacy and Security Workgroup will make recommendations for organization to organization and server to server certificate standards.
We next considered the Privacy and Security Workgroup's evaluation of NHIN Direct. The Workgroup concluded that certificate exchange should not be limited to certificates stored in Domain Naming Services (DNS) applications. It also suggested that XDR (a SOAP transaction) be removed from the NHIN Direct Core specification, reducing the complexity and optionality of the specification. The only debate that arose during this discussion revolved around the issue of rejecting an NHIN Direct message because it did not meet regulatory requirements. Specifically, the Privacy and Security Workgroup recommended the following language -
"Destinations MAY reject content that does not meet Destination expectations. For instance, some Destinations MAY require receipt of structured data, MAY support only particular content types, and MAY require receipt of XDM structured attachments."
Here's a use case that illustrates the issue:
Federal Regulations require quality measures to be sent in PQRI XML as of 2012.
A doctor uses NHIN Direct to send an unstructured text message to CMS "I achieved the quality measures you wanted me to!"
What should CMS do?
1. Reject the message as not compliant with Federal regulations, notifying the sender as to the reason
2. Accept the message, but contact the sender out of band to specify the requirements
3. Accept the message, but later send a functional acknowledgement via NHIN Direct that the contents of the message did not qualify for meaningful use reporting requirements
In an email dialog following the HIT Standards Committee, many members agreed tat that the message should be rejected with an error message that the contents of the message did not meet regulatory requirements.
At the meeting, we agreed that decisions to reject or accept messages are a matter of policy and that the HIT Standards Committee should only recommend technology that enables messages to be sent securely and error messages to be provided to the message sender if policy requirements are not met.
A great meeting with significant progress on the PCAST review, S&I Framework review, and the NHIN Direct review.
Next month, we'll hear more about certificates, provider directories, and PCAST. It's clear that the work of the Policy Committee on Certificates and Provider Directories, the work of NHIN Direct, and the work of HIT Standards Committee are converging such that we will soon have a unified approach to transport that will rapidly accelerate transmission of the standardized content and vocabularies already required by Meaningful Use.