Friday, December 10, 2010

The Spirit of PCAST

On December 8, the President's Council of Advisors on Science and Technology (PCAST) released the report "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward"

In its 91 pages are several "gold star" ideas for empowering patients, providers and payers to improve quality, safety, and efficiency.

The major ideas are

1.   "Universal Exchange Language" -  As I have discussed many times, interoperability requires content, vocabulary and transport standards.   Although the PCAST report does not provide specifics, it does list characteristics of this language
*Should be XML-based
*Should be optimized for representing structured data, not just unstructured text
*Should include controlled vocabularies/code sets where possible for each data element
*Should be infinitely extensible
*Should be architecturally neutral, decoupling content and transport standards

2.   Data elements should be separable and not confined to a specific collection of elements forming a document.   There are thousands of forms and document types in an average hospital.   Rather than trying to create one ideal format for each of these (which would be a never-ending task) providing a modular approach that enables collections of data elements to be repurposed for different needs would enhance flexibility and reduce the burden on implementation guide writers/developers/users.

3.  Each data element should include metadata attributes that enable the datum to be reused outside of any collection of elements or context.    The report does not specify how this would work, but let's presume that each data element would contain attributes such as the data element name, the patient name, and the patient date of birth so that information about a specific patient could be searched and aggregated.

4.  Privacy controls specified by the patient  used in conjunction with the metadata would enable multiple data uses that adhere to patient consent declarations and support multiple types of consent models (opt in, opt out, HIV/genetics/mental health restrictions etc).   Although this is a noble goal, the reality of implementing this is quite difficult.   Deciding if a data element does or does not imply a condition is a major informatics challenge.

5.  Search engine technology should be able to index data elements based on metadata.  Search results would reflect patient consent preferences and the access rights of the authenticated user.

6.  De-identified data should be available for population health, clinical research, syndromic surveillance, and other novel uses to advance healthcare science and operations.

How does this compare to the work to date by ONC, the Federal Advisory Committees, and vendors to implement meaningful use data exchanges?

I believe that the PCAST report is consistent with the work done to date and that the foundation created by Meaningful Use Stage 1 puts us on the right trajectory to embrace the spirit of PCAST.

Let's look at each of the PCAST ideas as compared to our current trajectory

1.  There are 2 kinds of content standards specified in the Standards and Certification Final rule - transactions and summaries.   Transactions include such things as e-prescribing a medicine or ordering a diagnostic test through a CPOE system.    Summaries include sharing a lifetime health history or episode of care between providers or with patients.   Transactions, such as specific actionable orders, work very well today using the HL7 2.x messages specified in the rule.   Transactions are not a problem.   It's the summaries that should be the focus of the PCAST ideas.

The current summary formats specified by the Standards and Certification Final Rule are CCR and CCD.  Both are XML.   CCR is extensible but I do not believe there has been much demand in the industry to expand it.   CCD is based on CDA which is extensible.   In fact, CCD is just the CCR expressed as a CDA template.  It�s a demonstration of the extensibility of CDA.

CCR and CCD incorporate vocabularies for each data element where appropriate - ICD9/SNOMED-CT for problems, LOINC for labs, and RXNORM for medications.

I would hope that the country does not start from scratch to build a new Universal Exchange Language.   Wise people can take the best of CCR, CDA Templates, Green CDA, and other existing XML constructs to create implementation guides which fulfill the PCAST recommendations.

2.  If data elements are going to stand alone, do we need an information model or dictionary so that we know how to name data elements in a consistent way?  If the goal is to represent every possible data element in healthcare in a manner that allows consistent searching, then the metadata will need to include consistent data element names and the relationship of data elements to each other i.e. a problem list consists of a problem name, problem code, problem date, active/inactive flag.

3.  CCR and CCD/CDA both include metadata.    What does it mean to represent metadata at the data element level?   CCR and CCD have specific sections that incorporate patient identity information.   Should that be replicated in every data element so that each data element can stand alone?   While that could be done, it will result in substantially larger payloads to exchange because of the redundant metadata added to each datum.

4.  The ONC Privacy and Security Tiger Team has already been working on a framework for meaningful consent.   Their work is truly a pre-requisite to the privacy protections suggested by PCAST.   The Tiger Team has acknowledged the value of highly granular consent, but has been realistic about the challenges of implementing it.   A phased approach to get us to the goals outlined in the PCAST report would work well.

5.  Search engine technology has not been a part of the work on healthcare information exchange to date.   It will be interesting to think about the security issues of cached indexes in such search engines.   Just knowing that a data element exists (HIV test or visit to a substance abuse facility), regardless of the actual data contents, can be disclosing.  Another issue is that search engines would have to do a probabilistic match of name, date of birth and other patient demographics from metadata to assemble data elements into a complete record for clinical care.    Although such approaches might work for research, quality measurement, or public health reporting, they are problematic for clinical care where false positives (matching the wrong patient) could have significant consequences.

6.  De-identified data for public health has already been part of the ONC effort.   Novel data mining in support of research has been a part of the NIH CTSA projects, such as Shrine/I2B2.   These CTSA applications already adhere to many of the PCAST principles.

What are the next steps?

I presume ONC/CMS will convene teams from the HIT Policy Committee, the HIT Standards Committee and existing Workgroups to discuss the PCAST report and its implication for the work ahead.

In the spirit of my recent blog about The Glass Half Full, I believe the PCAST report is a positive set of recommendations that builds on the Meaningful Use Stage 1 effort to date.   ONC should be congratulated for creating a foundation that is so consistent with the PCAST vision for the future.

Load disqus comments