IHE support for PCAST Use Cases

Today John Halamka posted Use Cases for Health Information Exchange discussed by the PCAST Workgroup.  There were four use cases:

1. Push by patient of data between two points
2. Simple Search for Data
3. Complex Search for Data
4. Deidentified Aggregated Data Mining

These are all presently supported by existing IHE Profiles, many of which have already been deployed in Health Information Exchanges in the US and around the world.

Push by patient of data between two points

This is the use case for which XPHR was designed.  As a UEL, XPHR uses CDA, which captures medications, problems, allergies, labs and references to other studies (e.g., imaging).  The metadata includes patient identity, provenance (author, source of submission, and privacy metadata).  The assumption made by IHE PCC was that an XDS registry could act as a non-tethered PHR, be able to receive pushes from their providers EHRs.  It could also support input using IHE's XDR profile, or using XDM via The Direct protocol.

These profiles include requirements to support ATNA, which requires user authentication, certificates on both sides of the communication, audit logging by all entities engaged in communication.

The IHE BPPC profile supports capture of patient consent, and supplies metadata about consent.

With regard to the Infrastructure John suggests is needed for this approach:

• The XDS, XDR and XDM profiles include metadata on patient identity, provenance and privacy.
• Categories of health data are already captured in the metadata as specified in the vocabularies selected in the  HITSP C80 Clinical Document and Message Terminology Component, in section 2.2.3.15 Document Metadata, and in the LOINC codes for document sections using in the HITSP C83 CDA Content Modules.
• Providers of Applications capable of wrapping content packages of clinical data in the CDA format can be found here. 
• Providers of Applications capable of receiving the CDA format and "unwrapping" the content can be found here. 
• Certificate management can be through X.509 certificates supported by a number of different providers.
• And I agree, that policies are needed, but that's outside of the IHE scope.

Simple Search

For this use case, the IHE BPPC Profile can be used to capture the patient consent. Queries can be created using the IHE XDS Stored Query or XCA profiles to locate information for a patient from numerous sources specified in URIs as web service endpoints.  These are the very same query/response exchanges already supported in the NwHIN.  As before, XDS Stored Query and XCA require ATNA which supports authentication, audit and encryption of the exchange.

Again, on Infrastructure suggested:

• Policy is needed, but is outside of IHE's scope.  The profiles are built to support wide variation in policy.
• Syntax and semantics for XDS queries have been well established.
• Applications capable of performing the queries are listed here.  Some of the current deployments can be seen here.  This is already available in NwHIN implementations, and through the CONNECT Open Source. 
• An approach to identity patients using the IHE XCPD profile has already been specified (pdf) by the NwHIN Spec Factory.  That profile supports disambiguation of patient identity.

Complex Search

Complex search is different from the perspective of the PCAST use cases, but technically implemented using the same capabilities.  What differs are policies.

• IHE XUA can be used to communicate provider identity and role in the query transaction.
• The "DEAS" is an XDS Registry and eMPI supporting XCPD, or an XCA and XCPD Gateway
• Syntax and semantics for this are already specified. 

De-identified Aggregated Data Mining
This one is the "weakest" of the use cases given that John doesn't talk about the challenges of deintification.  In fact the use case he gives provides data that is probably as accurate as a fingerprint for identifying a person ... a radiological image.

• Policy is again out of scope, but please note that IHE profiles are always designed to support a wide variation in policy due to their International nature.
• IHE is developing a handbook (doc) on this topic this year.
• The IHE MPQ profile release last year is one of the infrastructure components that can be used to support this capability.  

As John notes in his post, Policy is required for all of these use cases.  I'd love to see a workgroup focused on the policy issues irrespective of any standards or technology.

Comments on Advice to ONC on PCAST

Wes Rishel recently gave some advice to ONC on what they should do with respect to the PCAST report.   In it, he largely agrees with me, or I with him.  There are a few points of departure, which I'd like to address:

• Documents vs. Molecules
• The arcanity of CDA.
• The dreaded OID.
• The unwillingness of HL7 to do more than experiment.
• Getting agreement on important molecules vs. documents.

More than 200 products have been ONC-ATCB certified.  Based on reports from others, I would estimate that at least 80% of those support generating a CCD (and therefore CDA).  Viewing IHE Connectathon results, more than 50 companies around the world have demonstrated the ability to generate a CDA, and as evidenced by IHE Conformance statements, nearly 40 of those companies are shipping product that does so (and many have more than one product). 

Arcane?  Maybe, BUT also doable and shipping.

Should we go back to the drawing board and do it better?  My answer to this question depends on what your time frame is.  If it for stage 2, the answer is pretty clear.  NO.  If you want to get it right, and take in the experiences of others, you need to take the time to figure this out and to build consensus.  If you want this to get started, great.  Just don't tie it to an arbitrarily tight deadline.

Documents vs. Molecules
Actually, I don't disagree with Wes at all on this topic.  I just wanted to point out a few things from my own experiences creating a system envisioned in a former job that is similar to what PCAST envisioned.  The importance of context is one we built into that system.  It extracted problems, medications, allergies and procedures from dictated text, coded the problems, and saved the links back to the documentation with the data stored in the database.  That database was successfully used to identify patients taking Vioxx when that recall was announced.

The IHE Query for Existing Data profile envisions just such an extraction.  In fact, it uses very similar XML as found in CDA, and when data is extracted from documents, requires that references to the source documents be provided with the data.  Does IHE support the PCAST vision?  Yes, it does.

The Arcanity of CDA
Any critique of arcanity should start by addressing the specific issues, not just an essential claim of difficulty.  So, to add to Wes's point, what contributes to the arcanity:

• The lack of readily available educational materials and instruction (which is why I wrote The CDA Book).
• An insistence upon rigor in modeling information correctly, and the complexity reporting information rigorous models in a generalized XML implementation technology. 
• Counterintuitive uses of XML, including he use of attributes (moodCode and classCode) to define semantics in the model, rather than element names [brought about by the parsing limitations of XML].
• The onion peeling problem, which is really a question of publication format rather than a problem directly related to the standard.
• The use of the dreaded OID.

Lack of Educational Materials and Instruction
One of the problems in healthcare IT is that it is a "small" vertical market when compared to the much larger IT market.  While it didn't take me long to find a publisher for The CDA Book, what I heard from traditional publishers in the IT space was that it was "small potatoes" compared to things like HTML, XSL, XSLT, et cetera.  I'm not going to get rich off that title, nor did I expect to, but neither is my publisher (although I expect we will both do better than he projects).

It's also not the kind of thing that used to show up frequently in informatics classes, although I do see that changing (and have taught a few classes on the topic).  I expect by this time next year that there will be a few classes that spend at least a few weeks, and maybe an entire semester on the topic.

Rigor in Modeling
I don't want to see the perpetuation of the abuse of OBX and ORU that we've seen in HL7 Version 2.  This is after all possibly my mother you are caring for.  That being said, a rigorous model that creates difficult XML presents other opportunities for things to get messed up in implementation, and makes it hard to see what is being said.  There should be a way to have both.  That is what the standards experts need to do.  GreenCDA is a way forward that supports both, and other ways might also be developed.

Counterintuitive XML
In the HL7 XML ITS, the XML element names don't carry semantics.  The moodCode and classCode attributes do.  Once you learn to get over that obstacle, much of the "complexity" is readily understood.  There are two different projects in HL7 to make that easier to comprehend.  The first of these is the RIM ITS, which uses semantically meaningful names, but still puts some information into classCode and moodCode.  The other is greenCDA which goes for "molecular" names of things.  I'm not convinced that either has the XML right yet, but both are headed in the right direction, making the XML more readily accessible to engineers. 

Onion Peeling
This is really a problem of how the standard is published.  There is a push from ONC to use model based development tools and to publish not just the standard, but also the data used to create the models.  One of the important challenges here is addressing how to manage the various intellectual property issues across all of the organizations that want to use this data.  That's no longer a problem I can claim to be beyond my ability to address (it is an issue that the HL7 Board is focused on).  The CDA Conslidation Project being worked on by HL7, IHE and ONC is making substantial progress in this direction.

The Deaded OID
I am reminded of the opening of "The Prisoner".  Q: Who is number one?  A: You are number six.  The ambiguity of indentification requires some mechanism to uniquely and perpetually provide the context that ensures identifiers and codes are correctly interpreted.  HL7 chose to use OIDs, which are remarkably simple to generate, distribute and manage.  What is hard about them is remembering them, but the same can also be said about codes.  But, we don't talk about the "dreaded code".  There seems to be a disconnect here.  OIDs solve a problem that needs to be solved, just like codes do.

One need only recall that several large national programs have been shut down because identifers were not correctly dealt with.  Criticising without proposing a solution is not constructive.  If you have a better solution to this problem, I'd love to hear it.  I can personally think of a few, but they add complexity through indirection, and I'm not sure that helps either.

The Unwillingness of HL7 to do more than experiment.
Progress starts with experimentation, moving beyond the theoretical with the recognition that more information may be needed.  The concept of a "Draft Standard for Trial Use" embodies this principle.  We say try it out and tell us what you think.  That's not an unwillingness to do more than experiment, it's simply a recognition that attempts to theorize the right way to do something are futile beyond a certain point.  Experience is needed, so go ahead, get some and tell us what you learned.  If you'd like some approval beyond that, you might try describing your experiment, but um, do me a favor.  Make sure that you realize that you are experimenting, and that you do have consenting patients participating in your study.

Getting Agreement on Important Molecules vs. Documents
Getting agreement on the molecules is a required step when one creates a document specification.  Having done this more than two dozen times in three different organization, what I can tell you is that we already have a considerable collection (nearly 500) molecules, that have already been agreed upon by multiple organizations, standards experts, clinicians, et cetera.

In developing the HL7 CCD Specification, the IHE PCC Technical Framework, various other HL7 implementation guides, and the HITSP C83 specfication, we used the principle of creating the library of building blocks (molecules).  Documents are composed of sections, which are composed of various entries.  The entries are the same across documents (In HITSP, a problem entry in a C32 is the same as a problem entry in a C84 or C48, and that same principle applies across other specficiations).  In fact, the proliferation of the IHE PCC Technical Framework across Europe and Asia has not been through the documents, but rather the sections and entries that appear within it.

Getting agreement on what the molecules are is NOT the problem.  What is the problem is making that information readily available.  I get just a bit tired of rebuilding the wheel.  It this century, it is round, filled with air and made of rubber.  I'd like to move on to build the next race car.

Public Responses to the PCAST Report

All comments to the PCAST report will eventually be made public on the web.  But until the government releases them, you still have some opportunity to read comments others have already made publically available if you are interested.

First is my "Netizens 2.0 Response".  This really isn't a response by me alone, but all healthcare bloggers I could find, whether I agreed with them or not. 

Comments to ONC: PCAST HIT Report Becomes a Political Piñata (Vince Kuratis) -- Vince provides a list of comments from others and summary of each.  You should read his summaries.  Many (but not all) of the reports he comments on are listed below.

EHRA - I had some input here.
ACR and RSNA (pdf)
IHE USA (pdf) - I also had some input here.
HL7 (pdf) - While I provided some input here, I don't see it in the final result.
Brian Ahier (Healthcare IT Evangelist)
Healthcare Information and Management Systems Society
American Hospital Association (pdf)
Federation of American Hospitals (pdf)
The Center for Democracy in Technology
Project HealthDesign
The Markle Foundation
The Clinical Groupware Collaborative (Microsoft Word)
The Society for Participatory Medicine (pdf)
Siemens (pdf)
FasterCures
CLOUD
Comments on the PCAST Report (Margalit Gur-Arie)


-- Keith

P.S.  Once again, Vince beats Google and Bing for precision (relevance) and recall within the first five pages

Netizens 2.0 Response to PCAST

Government 2.0 (of the USA) meet Citizens 2.0 (of the World)

There is an amazing capacity among us humans to hear what we think is important, and not hear at all what we don't care about. We respond to what makes us feel strongly and not at all to that which doesn't. The PCAST report was something that many of us who blog responded to in these terms.  Some of us who responded may not be interested in formulating a direct response to ONC.  After all, this is a US issue, right?  Others of us will revise our initial visceral responses into much more finely tuned words and phrases better suited to use with policy makers.

 I've gathered up commentary from the Blogosphere to the PCAST Report to put together what I call the "Netizens 2.0" response.  The only editing is to make it readable as a PDF document (so I have to change background and text colors), and removing unnecessary multimedia (YouTube videos of the PCAST Video, the Presidential Logo, copies of the PCAST report and pictures of the commentary authors).  I'm also including the comments on the comments.  I figure that there's as much or more expertise on the net that has already commented on the report as went into the report itself, and that expertise is already much more focused on healthcare, so it is vital reading.

This response WON'T have the finely edited turn of phrase that is typical of formal public responses to federal RFI's.  It's rough, and even the very slight reformatting I did do wasn't quite as thorough as I would have liked because of the hours in which I have to fit this in.  But it will content the cogent thoughts of very skilled professionals who also write well, and to a much broader audience.

Here are the list of postings that I included.  If I missed your favorite, my apologies.

• Summarizing Early PCAST HIT Critiques: “Brilliant, but they didn’t do all their technical homework.”
• Why Context and Relevance
• My Review of the PCAST Report on HealthIT
• The Language of HealthIT
• Recasting e-health in the USA
• Realizing the Full Potential of Health IT to Improve Healthcare for Americans: Yet Another Path Forward?
• The Health IT report is very good; some opinionated suggestions
• Imaging and the PCAST (President's Council of Advisors on Science and Technology) Report
• The Spirit of PCAST
• Don’t re-invent the (clinical content) wheel…
• Toward a Universal Exchange Language for Healthcare
• PCAST and Clarke’s Third Law
• PCAST Report Comment: Looking Toward Truly Patient-Centered Health Data
• Realizing the Full Potential of Health IT to Improve Healthcare for Americans: The Path Forward
• PCAST Report on Health Information Technology
• Thoughts on the PCAST Report
• Understanding the PCAST Report
• IT Everything

All told it's about 65 pages of feedback.  Happy reading.

-- Keith

P.S.  Contrary to what the PCAST reports, modern search engine technology provides inadequate recall and precision on queries.  I had to use both Google and Bing to find some of these reports, and even then,  @VinceKuraitis did a much better job that either.  Thanks Vince, yours was the first on the list.

PCAST and ...

I'm rereading the PCAST report for about the fifth time.  While I find some of the conclusions of this report challenging and worth commenting on more, the single most interesting thing in this report is how closely chapter 4 and 5 follow the software architecture of the Indivo project, which happens to be one of the SHARP grantees.  This influence appears on both the idea of "metadata tagged data elements" in Chapter 4 and in the privacy and security architecture in Chapter 5. The more I read about Indivo and in these sections, and the more I look for points of comparison, the more I find.  

Hmm...

Then I look at it again through different set of eyes and I see the influence of Amalga ...

Hmm...

And then again, there's my own interpretation of it with respect to HL7.

Hmm....

I don't know what to think now.

ONC Seeking Comment on PCAST Report on HealthIT

I've spent most of yesterday and today digesting the PCAST (pdf) report on HealthIT.  Now ONC has put forth an RFI seeking your comments.  Click the link to get the whole RFI including details on how to respond.  The specific questions are detailed below so you can start thinking about your answers.  The back of the book is here if you get stumped ;-)

  Keith

P.S.  Updated URLs for the RFI as of 12/10/2010

---

ONC seeks comment (pdf) on the questions below. Comments on other aspects of the PCAST report are also welcome.

1. What standards, implementation specifications, certification criteria, and certification processes for electronic health record (EHR) technology and other HIT would be required to implement the following specific recommendations from the PCAST report:

a. That ONC establish minimal standards for the metadata associated with tagged data elements;

b. That ONC facilitate the rapid mapping of existing semantic taxonomies into tagged data elements:

c. That certification of EHR technology and other HIT should focus on interoperability with reference implementations developed by ONC.

2. What processes and approaches would facilitate the rapid development and use of these standards, implementation specifications, certification criteria and certification processes?

3. Given currently implemented information technology (IT) architectures and enterprises, what challenges will the industry face with respect to transitioning to the approach discussed in the PCAST report?

a. Given currently implemented provider workflows, what are some challenges to populating the metadata that may be necessary to implement the approach discussed in the PCAST report?

b. Alternatively, what are proposed solutions, or best practices from other industries, that could be leveraged to expedite these transitions?

4. What technological developments and policy actions would be required to assure the privacy and security of health data in a national infrastructure for HIT that embodies the PCAST vision and recommendations?

5. How might a system of Data Element Access Services (DEAS), as described in the report, be established, and what role should the federal government assume in the oversight and/or governance of such a system?

6. How might ONC best integrate the changes envisioned by the PCAST report into its work in preparation for Stage 2 of Meaningful Use?

7. What are the implications of the PCAST report on HIT programs and activities, specifically, health information exchange and federal agency activities and how could ONC address those implications?

8. Are there lessons learned regarding metadata tagging in other industries that ONC should be aware of?

9. Are there lessons learned from initiatives to establish information-sharing languages (“universal languages”) in other sectors?

The Language of HealthIT

Yesterday I summarized my thoughts on the Health IT report from the Presidential Council of Advisors on Science and Technology (PCAST).  The advisors made several recommendations, one of which was to "develop" a language for healthcare that could be used in web services and which could be used to access disagregated healthcare data.

I propose such a standards based language already exists, and will explain in more detail.  It's clear that the PCAST has looked into Health IT standards to some degree.  But its also clear that they aren't experts on the topic.

I've gone through the report again to pull out their suggested requirements for such a language:

1. A robust platform for creating user interfaces, decision support, storage and archiving. (p38, item #2)
2. Support for cross-organization data exchange (p38, item #3)
3. Support for strong privacy protection (p38, item #4)
4. Health IT systems must have the ability to communicate and aggregate health information in the ways needed to serve patients, doctors, and researchers. (p39, 1st para, 1st sent.).
5. Enable communication of clinical data. (p39, 2nd sent.)
6. Enable innovators to develop new tools to use healthcare information. (p39, 3rd sent.)
7. * Support policy and governance models to drive innovation. (p39, 4th sent.)
8. * Support appropriate access to information (p39, 2nd para, 1st sent.)
9. * Service Oriented Architecture (p39, last para)
10. Use XML (p41, 2nd para).
11. Support attachment of metadata on data (p41, 4th para) elements including:
1. Identifying information about the patient
2. * Privacy protection information
3. The provenance of the data—the date, time, type of equipment used, personnel
12. * Availability of a national infrastructure for finding health data, and for controlling access to it (p41, last para).
13. Services to include: services would include those associated with crawling, indexing, security, identity, authentication, authorization, and privacy (p42, 1st sent.)
14. * Support patient (or agent) ability to restrict access to the data. (p42, 1st para)
15. Support dynamic aggregation from multiple systems (p42, 2nd para)
16. Interoperable and intercommunicating in conformance to a single Federal standard (p43, 2nd para)
17. * Auditable for compliance with privacy and security policies (p43, 2nd para)
18. Extensible langauge for tagged data elements (p43, 5th para).

John Halamka summarizes these requirements thus (and check his blog tomorrow for details) as follows:

1. Content for Health Information Exchange should be expressed in XML using structured data with controlled vocabularies/code sets in a format that is infinitely extensible
2. Data elements should be separable and not confined to a specific collection of elements forming a document.
3. Metadata included as attributes of data elements should include at least person name/date of birth/data element name
4. Privacy controls should restrict query of data elements per patient preference. Data elements should be queryable using search engine technology (with privacy filters)
5. De-identified data should be available for population health, research, surveillance etc.

So, let's see how where HL7, IHE and HITSP have already addressed the issues:

Architecture and Standards
The PCAST report talks about different kinds of things.  It does not separate requirements for trasport, content, security and privacy, et cetera.  It does not address application requirements vs. interface requirements.  Applications provide services.  Services have interfaces.  Not all applications will support the same set of services.  Some of the "complaints" PCAST makes about existing standards aren't really appropriate, because they have an application requirement in mind that isn't met by one of the services they are looking at.

Now, privacy and security information need to be separately maintained and stored from clinical data.  About the only thing that needs to be stored with the clinical data is PERHAPS the privacy/security classification of it.  One reason for separating this is that they can change independently from the clinical information (new laws/regulation, new or altered patient preferences, et cetera).  The same is true for more specific access control and audit information.  So there isn't "one row" or set of XML elements that would necessarily appear together in an exchange that includes all of the privacy/security information with the clinical data.  I won't address the privacy/security or infrastructure requirements (marked with a *) from the above in this part of the post.  I will say that these have been addressed to some degree in the existing IHE and HITSP specifications and that more work has been done in HL7 on access controls.

One set of standards (CDA/CCD) are currently used under HITECH/Meaningful Use to send/recieve collections of discrete data in documents.  Now, a document is an aggregation of information for a single visit.  The CDA standard is designed for sending aggregations of data specific to a visit.  To complain that it doesn't support other forms of aggregation fails to acknowledge what it was designed to do.

CDA supports many of the requirements from above, including: #1, #2, #4-6, #10-11, #13, #15, #16 and #18

#1:  CDA is a robust way to store the clinical data and metadata, and can support UI and decision support through other application behaviors.  Some implementors have developed decision support services already based on exchange of CDA and CCD, and there are other interfaces to access the clinical data contained within the CDA document, e.g., the IHE QED profile (pdf).

#2:  This is already being done with CDA at Partners, South Shore Hospital, MA Share to the SSA, in the Vermont HIE, between the VA and DOD, and in other HIEs across the country.  It appears as a requirement in the current Meaningful use Regulations (45 CFR 170.205(a)(1)).

#4:  CDA/CCD is a way to aggregate this information for the collection of data about a SINGLE VISIT.  Other specifications, such as IHE QED profile mentioned above, can access the same data across visits using nearly the same XML.  Work is under way in HL7 on CDA Release 3, and on a new ITS that could uuse the SAME XML for all uses.

#5:  CDA enables exchange of clinical data for a visit.  Other profiles of HL7 RIM based standards support other ways to aggregate the data across visits.

#6:  I mentioned the Clinical Decision Support example under #1 above.  You can use CDA and QED to create a patient specific report based on content in a clinical data repository.  QED becomes the method to aggregate and CDA the way to report the aggregation in human readable narrative.

#10:  Yep, CDA uses XML.

#11:  All of the requested data appears in the CDA header and can also be attached to sections or entries in the CDA document.

#13:  CDA is a document format that can be crawled and indexed at a fine grained level.  In fact, the IHE QED profile anticipates that use and further tells how the two work together.

#15: The IHE QED profile is designed to support query and aggregation of data from multiple sources using almost the same markup found in CDA.  That profile can be used for research, gathering data to generate quality metrics, population surveillance, et cetera.

#16:  CDA can be part of that.  There really isn't ONE single standard, but a collection of them that work together (e.g., CDA/CCD, LOINC, SNOMED, et cetera).  See #18 below as well.

#18:  CDA, like all HL7 Version 3 based standards supports extensibility by binding the content with vocabulary standards that contain the detailed medical knowledge about problems (e.g. ICD or SNOMED), dianostic results (LOINC), procedures (CPT, ICD or SNOMED), medications (RxNORM)

The architecture that PCAST asks for already exists, and CDA is one part of it.  The other parts include the HL7 RIM, the HL7 Care Record, and HL7 Care Record Query standards.

More work is needed.  One of the work items is to make easier to use implementation guides.  HL7, IHE, Health Story and ONC are on it.  Another issue to to address transport.  NHIN Direct is a simple model, but isn't the robust exchange that is needed for other use cases like access to longitudinal data.

As a platform, the HL7 CDA and Care Record standards, as profiled by IHE, and applying the additional rules and vocabulary selected by ANSI/HITSP build the healthcare langauge that PCAST wants.

The language is just one part of the platform.  We need transport and we need security and privacy controls on that information.

NOTE:  The PCAST report speaks to the state of healthcare IT as deployed in the majority of institutions today, but DOES NOT speak to the capability of current healthcare IT solutions that are being deployed now. Much of what is currently available from Healthcare IT products supports the language that I just described.
Innovators are already using this langauge, based on the HL7 RIM, to do very interesting things. You can aggregate the data in multiple CDA documents into a CDR (via services that Crawl, index and identify using the existing profiles like XDS and QED). Then you can query that CDR to get data for a variety of uses (QED). Then you can apply clinical decision suppport (IHE CM and RCG -- also using HL7 Care Record), definitions about quality metrics (HL7 QDS), produce reports on quality (HL7 QRDA), or generate an immunization report for a patient (using HL7 QED and HL7 IC as demonstrated by IHE two years ago). It's all there. We just have to use it, instead of spending time trying to reinvent it.
There's a huge difference between what is available and what has been deployed. Advances in the development of these standards have taken some time to reach the healthcare marketplace, but they are getting there. The reasons for that are NOT a technology problem, but rather related to how Health IT infrastructure is invested in, updated, and deployed in the US.   The problem is not in developing the architecture and specifications, because believe it or not, we've been there and done that. 
 
The challenge is in getting it deployed.  There are several theories on why it hasn't been deployed.

1. Some fault the standards or the ease in which they can be understood and used. 
   Ease of understanding is perhaps reasonable argument but NOT a complete one because I know that a significant share of vendors in the market DO understand them and have implemented them.  HL7, IHE, Health Story, ONC, and others are working on the ease of use problem. 
2. Others explain that there's no incentive to deploy them. 
   That is also reasonable argument.  One part of that has to do with who benefits from use of them, and that's NOT a technology issue, but a policy one that I won't even attempt to address.  There are incenctives through ARRA/HITECH and Meaningful Use which are pushing forward, starting with exchange of data about visits and aggregated data about quality, but over the longer term (e.g., beyond 2015), more will be needed.  We need to think about how to accomplish that long term investment in healthcare IT, and make it worth the investment of healthcare providers. 

Ripping and replacing existing work won't solve either problem, it will just set us back to where we were 5-10 years ago, without addressing the fundamental issues.  Our healthcare system, and the IT it uses, is large, complex and emergent in its behaviors.  We need to figure out how to take the work that has already been done and use it to guide it towards the behaviors we want to see: use of the healthcare language.  That evolution will enable the revolution that PCAST is looking for.

My Review of the PCAST Report on HealthIT

See also The Language of HealthIT which goes into more details about what we already have, John Halamka's thoughts and those of Joyce Sensmieir from HIMSS.

Keith

---

The PCAST report on Health IT was released today.  The first question you might have is who is PCAST and how are they different from the HIT Standards Committee, Policy Committee and other FACAs related to healthcare (e.g., NCVHS). From the report:

The President’s Council of Advisors on Science and Technology (PCAST) is an advisory group of the nation’s leading scientists and engineers, appointed by the President to augment the science and technology advice available to him from inside the White House and from cabinet departments and other Federal agencies. PCAST is consulted about and often makes policy recommendations concerning the full range of issues where understandings from the domains of science, technology, and innovation bear potentially on the policy choices before the President.

So, basically, these are advisors to the President, rather than advisors to the executive branch of government (FACAs). They provide an interesting cross-check to other advisory commmittees.

One of the interesting points made by this report is the focus on ROBUST information exchange rather than simple exchange.  This is along the lines that John Moehrke has pointed out earlier this year, dealing with deeper issues and requirements for information access.  Simple exchange is just one part of the problem, and too much focus on it can (and has) detract from resolution of the complete problem.  As PCAST says:

Though the [Meaningful Use] rule expresses an intent to require more robust exchange of health information among providers at later stages of meaningful use, its initial requirements that EHR systems communicate with each other are very modest. This creates a danger that EHR adoption during early stages of meaningful use may exacerbate the problem of incompatible legacy systems. What is needed is a simultaneous focus on the capability for universal data exchange, able to unleash the power of the competitive market, to produce increasingly better and less expensive systems, and to create the "network effect" that spurs further adoption.  (Page 3)

I was amused by the attribution of CDA to ONC rather than HL7, but impressed with PCAST's understanding of its capabilities and limitations (page 4).

Creating the required capabilities is technically feasible, as demonstrated by technology frameworks with demonstrated success in other sectors of the economy. The best way to manage and store data for advanced data-analytical techniques is to break data down into the smallest individual pieces that make sense to exchange or aggregate. These individual pieces are called "tagged data elements," because each unit of data is accompanied by a mandatory "metadata tag" that describes the attributes, provenance, and required security protections of the data. Universal exchange languages for metadata-tagged data, called "extensible markup languages" are widely and successfully used. Indeed, ONC’s clinical document architecture standard (CDA) is such a markup language, and is an important step in the right direction...

 Later they point out on Page 6:

 ... ONC’s clinical document architecture standard (CDA) is an important step in the right direction, but needs more focus on data transmission, on innate privacy features, and on the enabling requirements of a more robust marketplace in new and innovative health IT products.

Later on Page 72 (underlining is mine):

However, the thrust of CDA seems largely that it be an extensible wrapper that can hold a variety of structured reports or documents, each with vocabulary-controlled metadata. While this shares many features with the universal exchange language that we envisage, it lacks many others. In particular, it perpetuates the record-centric notion that data elements should "live" inside documents (albeit metadata tagged). We think that a universal exchange language must facilitate the exchange of metadata tagged elements at a more atomic and disaggregated level, so that their varied assembly into documents or reports can itself be a robust, entrepreneurial marketplace of applications. In a similar vein, we view the semantics of metadata tags as an arena in which new players can participate (by "publishing"), not as one limited to a vocabulary controlled by the government.

Which is really an acknowledgement that Phase 1 of meaningful use doesn't really address data transmission at all (and isn't part of the CDA standard either). Also missing is a way to address one of the biggest issues in exchange which is how to address Privacy Policy at a National level.Wow, someone actually read the standard and understood its intent.  NOTE: There is a GOOD reason to have a record centric notion of clinical data, but that's another blog post (probably tomorrow's).  If they'd gone one step further, they'd have understood that the CDA is based on the HL7 RIM, and the RIM deals with the metadata tagged elements at that more atomic and disaggregated level.  One of the things that IHE has done has shown how CDA R2 and the HL7 V3 Patient Care Messages (also based on the RIM) can work together, one to produce complete documents, and the other to get at the detailed data. 

Chapter 4 of the report goes on to reinvent HL7 Version 3 ... if only they knew.  FYI: They estimate the cost to create the necessary standards to be around $20 to $40 million.  My guess is that is about right based on what IHE and HL7 have spent actually doing it already over the last decade.  Moving forward, maybe we need to spend 3-12  ($M) more them easier to use and implement, but please, don't send us all back to the drawing board AGAIN.

Chapter 5 on Privacy and Security I will leave to John Moehrke to provide detailed comment on.  I will point out that they recognize that perfect is the enemy of the good, but then go on to describe a nearly impossible to implement, perfect security architecure.  When a policy advisor starts talking about technical approaches, they've probably overstepped their bounds, and in this case, their expertise in real-world implementations (same applies to DEAS reinvention of V3).

In summary, it's a good report, and worth reading.  The council has some good ideas, but isn't aware of some of what has already been done.  They should stay away from designing architectures and focus on policy requirements.  Tomorrow's post will address some of their recommendations on a universal language and how ONC and CMS could move forward on that taking advantage of existing standards.