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.
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.
11 comments:
John, I'm not a Doctor or even a health information expert, but unlike an ecommerce transaction, it seems to me that a healthcare data point would be part of a particular clinical/business context that may be important to preserve with a patient's record. Is there a danger from creating distance between the patient information and this context, by specifying metatagged/retrievable data elements rather than metatagged clinical documents?
I think you are a voice of reason and reassurance for and from the health informatics community.
While you cannot tell just from the report, informatics and the rest of healthcare IT is a new (50 year) scientific and engineering hybrid discipline. Many people are frustrated at the perceived lack of progress. I seem to remember a group of bankers about 4-5 years ago who showed up and were ready to tell informaticists how to do thing ala ATM. (Using ATMs in an analogy to anything in healthcare should be a red flag) They lasted about 18 months before leavinig after recognizing at how many orders of magnitude more complex biomedicine and healthcare is from other domains seeking automation and analysis.
We are at an inflection point, after a reasonable lag in growth. We saw initial progress from HL7 v2.x, work on clinical decision support, and impact on quality of care from a handful of top academic medical centers with "home grown" EHRS. We entered into a slower phase as limitations in the utility of decision support due to a lack of computable clinical data surfaced. It has taken time to evolve a new paradigm, based on well established model-driven principles. The co-evolution with the semantic web offers further promise, and ontologies are now "bread and butter" tools. We are at the cusp of having well enough defined, reusable, unambiguous data elements to pick up the pace and make the visions of the early 1980's a common place realityWe may also be entering into a new phase where comercialization of the technology is matured to the point that these benefits can scale. Early reports, hindered by vendor non-disclosure requirements, are starting to trickle in and we should know shortly what the cost, risks, benefits and altneratives to a range of vendor products are.
The PCAST The Path Forward overall reads like marketing material, is vauge, filled with assertions that are not based in fact, nor substantiated by the cited works (if you read reference 47, for example) and fails to properly describe the problem, the cause and a reasonable solution.
This report will not see acceptance in the health informatics community or with other healthcare information technology experts.
However, there are some pearls within, and some very important ideas, such as privacy/confidentiality/consent annotation and a learning healthcare information system, which should not be persued just because they were advocated in this report.
Here's a somewhat unusual request: I'd like to gain access to about 1,000 CCDs or CCRs. I'd like to run them through some semantic analysis software and see what comes out of the data. Happy to use de-identified content.
Anyone have a thousand or so I can use? Happy to do the de-identification work if required.
John, with reference to your points:
"1. ... 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.", and
"2. ... 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 ",
the PCAST raise valid concerns that I don't think you are adequately addressing. Their primary thrust is one of overcoming the heterogeneity of clinical information representation. HL7, has never seriously attempted to address the incoherence of clinical information across its portfolio of artefacts. It is not even possible to computably extract blood pressure values from a CCD. How could a search engine be expected to do so without deep clinical knowledge of the construct of a blood pressure measurement? The same applies for most clinical concepts. Staying with CCD, for example, the "Alert Observation" template only provides for capturing a reaction to a drug, and even then, it is inconsistent with other representations of reactions to drugs in other HL7 artefacts. It will not be clinically safe to integrate data based on different and inadequate clinical concepts and their representations. And I would also expect that PCAST would envisage something more amenable to implementation than "implementation guides" as a mechanism for achieving their vision.
In keeping with your "glass half full paradigm", you make an excellent point about using wise people. I recommend you go looking for some, beyond the usual cohort. Cast your net wider than the authors and advocates of "CCR, CDA Templates, Green CDA", for these simply won't cut the mustard.
John, I am a ?still? practicing primary care MD in beautiful downtown La Jolla CA. This report and its
inception missed my radar screen, but it has a very
disturbing hint of a view from the top that is PAINFULLY bereft of connection with the realities of
medical practice in the USofA. The financial viability
of solo and small group practice in this country is clearly over. Whether the delay in the 25% reduction is just going to put off the EXODUS of primary providers
is not clear to me yet. The flood of funding to IT when basic services are so poorly reimbursed that
most of the providers I know are in the process of retiring/quitting or planning to join the megaclinics
is very mysterious. As someone who has followed most of the IT issues in the last 15 years, I think there are interesting concepts in this study. But it
is very disturbing that my departure to Singapore or the UK to attempt to get fairly paid for services is
not being discussed yet.
cbmd
I ponder why the government doesn't focus on how to uniquely identify a patient throughout the healthcare continuum.
This is one of the biggest problems we have. This causes so many interoperability constraints in almost every healthcare organization I've had the opportunity to work with.
This is something that has to be solved at the highest level and then it can trickle down.
If we have a universal ID attached to each data element it would make some of their suggestions possible.
Michael Planchart
Having implemented CCD for our EMR product, I can tell you it's neither readable or allows use of standard tools. There are a a number of articles about the difficulty of comprehending/implementing it - http://www.balisage.net/Proceedings/vol3/html/Beuchelt01/BalisageVol3-Beuchelt01.html.
We actually ended up using easy XML layouts internally and mapping to CCD and vice-versa using Mirth, which works but shows the issues that implementers have.
If the goal is for the data to be easy exchanged .. and new application built on top, I do believe the PCAST report is on the mark. The reason facebook, google .. APIs have been successful, because they are easy to use.
I do understand that CCD was a way to get a lot of the "legacy" systems to get to a place/buy in and may be a first step, but if healthcare data exchange needs to be accelerated, revisiting CCD is definitely worthwhile.
The PCAST report also listed such non-IT issues as little to no economic incentive or markets, problems with the pay-per-service payer model, need for organizational and managerial change, issues with adopting EHRs "into the workflow of a clinician's day" (pg 2). Yet all of the 'fixes' focused on the IT component, primarily the ability to exchange the stored data (which isn't yet stored).
What are the recommendations to accelerate changes to the non-IT aspects of this sea-changing problem?
The US health care “system” has a number of deep seated and highly recalcitrant structural problems. Some of these problems are listed under the rubric of “fragmentation” and “perverse payment system”. Over the past 3 decades these problems have intensified and contribute to the fissures and strains noted monotonously in all commentary.
The halcyon thought that Information technology will serve as a panacea that delivers us from what is, at heart, a political problem is nothing but superficial boosterism for the Health IT industry.
The most recent PCAST report – “The Path Forward” takes a page from the “Wizard of Oz”. Just follow the yellow brick road and don’t pay any attention to the man behind the curtain.
As an HIE project manager I too was concerned with the amount of overhead needed to create metadata for each healthcare datum. I was also concerned with the notion that "the data and key are brought together only in the clinician's computer, and only for purposes of immediate display decrypted data are not replicated or permanently stored locally"(p.52). As a clinician reviews external patient information and validates it with their patient, wouldn't they want to import that information into their local EHR? Are they supposed to just view this information, and re-enter it if they want to use it?
Appending metadata to data elements: It’s no showstopper!
Several articles (including this blog post) seem unnecessarily pessimistic about one aspect of attaching metadata to data elements. For example, in this post, we saw:”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.“
There is a really hard problem in determining what the metadata should be. However, the physical storage and attachment problems seem less severe than suggested above.
There is no requirement that the metadata be stored with the annotated item. We just need that the metadata be derivable.
Normally the metadata is associated with some larger chunk, and applicable to all items associated with the chunk. It then suffices to have a means of finding the chunk and retrieving the desired metadata. Doing this cleanly requires careful design, but is possible. Here are a few examples of tactics that can be applied (incrementally) to attach more and more metadata:
• Metadata may be attached to a database column, and apply to all values from that column. (E.g., to tell what standard describes the values in this column)
• Metadata may be attached to a large object and refer to all subitems. An analogy may help. Google understands that words come in context of a document and a website, something similar is needed for a health search engine.
So the patient identity and date/time may be attached to a patient visit summary, and apply to all notes and orders from that visit.
Now when one reaches a medication order within the visit summary, one needs a way to determine the “creation context” path to the item. One can then harvest metadata along that path. Perhaps by convention, URIs might reference the large objects, and then navigate down within it.
• More complex rules can be enabled – instead of metadata, provide a rule that derives the metadata. In the previous example, suppose information captured through 2008 gets used standard S1 version 1, and afterward version 2. To determine the relevant standard for a medication, one retrieves the data, and applies the rule to derive the version. (One can have multiple rule languages, as long as they’re executable).
Good design will be needed, but it’s no grand challenge.
Post a Comment