The November HIT Standards Committee

by John Halamka, Life as a Healthcare CIO, November 16, 2011

Today, the HIT Standards Committee shifted gears from the Summer Camp work on Meaningful Use Stage 2 and began new interoperability efforts.

We began the meeting with a presentation by Liz Johnson and Judy Murphy about the Implementation Workgroup's recommendations to improve the certification and testing process.   These 15 items incorporate the Stage 1 experience gathered from numerous hospitals and eligible professionals.   If ONC and NIST can implement this plan, many stakeholders will benefit.  The Committee approved these recommendations without revision.

Next, we focused on content, vocabulary and transport standards.

In my October HIT Standards Committee blog post, I noted that HITSC should work on the following projects:

Content
*Continued refinement of the Consolidated CDA implementation guides and tools to enhance semantic interoperability including consistent use of business names in "Green" over-the-wire standards.
*Simplifying the specification for quality measures to enhance consistency of implementation.
*Standardizing DICOM image objects for image sharing and investigating other possible approaches.   We'll review image transfer standards, image viewing standards, and image reporting standards.
*Query Health - distributed queries that send questions to data instead of requiring consolidation of the data

Vocabulary
*Extending the quality measurement vocabularies to clinical summaries
*Finalizing a standardized lab ordering compendium

Transport
*Specifying how the metadata ANPRM be integrated into health exchange architectures
*Supporting additional NwHIN standards development (hearings about Exchange specification complexity, review/oversight of the S&I Framework projects on simplification of Exchange specifications).   Further defining secure RESTful transport standards.
*Accelerating provider directory pilots (Microdata, RESTful query/response that separates the transaction layer from the schema) and rapidly disseminating lessons learned.

The November Committee agenda included a discussion of  Consolidated CDA, Quality Measures, and NwHIN Implementation Guides.

Doug Fridsma began with a discussion of the Consolidated CDAwork and the tools which support it.

The Committee had a remarkable dialog with more passion and unanimity than at any recent discussion.   We concluded:
*Simple XML that is easily implemented will accelerate adoption
*That simple XML should be backed by a robust information model.   However, implementers should not need expert knowledge of that model.  The information model can serve as a reference for SDOs to guide their work
*Detailed Clinical Models, as exemplified by Stan Huff's Clinical Information Modeling Initiative (CIMI) hold great promise.   Stan has assembled an international consensus group including those who work on
 -Archetype Object Model/ADL 1.5 openEHR
 -CEN/ISO 13606 AOM ADL 1.4
 -UML 2.x + OCL + healthcare extensions
 -OWL 2.0 + healthcare profiles and extensions
 -MIF 2 + tools HL7 RIM – static model designer

Their work may be much more intuitive than today's HL7 RIM as the basis for future clinical exchange standards.

*Rather than debate whether Consolidated CDA OR GreenCDA(simplified XML tagging) should be the over the wire format, the Committee noted that "OR" really implies "AND" for vendors and increases implementation burden.   The Committee endorsed moving forward with GreenCDA as the single over the wire format.   
*We should move forward now with this work, realizing that it will take 9-12 months and likely will not be included in Meaningful Use Stage 2, but it is the right thing to do.

Thus, the future Transfer of Care Summary will be assembled  from a simple set of clinically relevant GreenCDA templates, based on CIMI models, as needed to support various use cases.  There will be no optionality  - just a single way to express medical concepts in specific templates.

To support this approach, we'll need great modeling tools.    David Carlson and John Timm presented the applications developed to support the VA's Model Driven Health Tools initiative.  This software turns clinical models into XML and conformance testing tools.   The committee was very impressed.

Next, Avinash Shanbhag presented the ONC work on Quality Measures  that seeks to ensure quality  numerators and denominators are expressed in terms of existing EHR data elements captured as part of standard patient care workflows.

Avinash also presented an update on transport efforts, which include easy to use, well documented implementation guides for SMTP/SMIME and SOAP.   The work is highly modular and does not require that the full suite of NwHIN Exchange specifications be implemented for SOAP exchanges.

As part of the ongoing efforts to improve NwHIN Exchange, the HIT Standards Committee is seeking input from NwHIN implementers per this blog post.

Finally, Wil Yu updated the committee on the SHARP and other innovation programs. 

There will be a great body of challenging work to do in 2012.   What's needed after that?  The next 5 years will include many new regulations as healthcare reform is rolled out.   It's clear that the Standards Committee will have many topics to discuss.

The September HIT Standards Committee Meeting

by John Halamka, Life as  Healthcare CIO

Today was a big day - the end of Standards Summer Camp.   We presented the HIT Standards Committee work of the past 6 months and then attended a celebratory reception at the White House.

Judy Sparrow, the ONC "national coordinator" who orchestrated all our HITSC meetings, announced her retirement last month.   Jon Perlin and I presented her with a silver bowl, engraved with the words "The Standard Bearer".   Thanks for all you've done, Judy.

As we discussed our Summer Camp work during the meeting, we were guided by a few basic principles:

While it might not be perfect, does it represent the best we have at this point in history?
Does it point us in the right direction?
Is it the next step in an incremental approach to refining the standards and implementation guides?
Does it support our policy objectives?
Can we update it as needed going forward through the SDO community?

Doug Fridsma presented an overview of our Summer Camp activities to date:

The Metadata Analysis Power Team lea by Stan Huff completed the standards for patient identification, provenance (which organization generated the data), and security flags.   Simple XML constructs from CDA R2 and standard X.509 certificates were chosen for these requirements.

The Patient Matching Power Team led by Marc Overhage completed its analysis of best practices for patient matching, noting the types of demographics that should be captured in systems to optimize the sensitivity and specificity of patient matching applications.

The Surveillance Implementation Guide Power Team led by Chris Chute chose one implementation guide  for each of the public health transactions - surveillance, reportable lab, and immunizations.   We had a spirited discussion about the optional fields in the implementation guides and made it clear that we want the core elements to be the certification criteria.   We do not want each state public health department to mandate different "optional" fields.   Our transmittal letter will note that EHRs that send the core set should meet the certification criteria.  Public health departments should accept this core set.   Optional fields are just that - optional items for future reporting needs.

Farzad Mostashari, National Coordinator, framed the important discussion of transport standards by noting that we must move forward, boldly specifying what is good enough.   If we specify nothing, the silos of data we have today in hospitals, clinician offices, pharmacies, and labs will persist.   There's a sense of urgency to act.

The NwHIN Power Team led by Dixie Baker presented its thoughtful analysis of the 10 standards guides included in NwHIN Exchange and the 2 standards guides included in NwHIN Direct.   This analysis was not a comparison of the two, but was an objective look at the suitability of each standards guide for its intended purpose to support aspects of transport functionality at a national scale.   The team did not discuss their suitability for use at the local, state, or regional scale.   The team did not declare "push or "pull" as a superior architecture.    Their thoughtful analysis led to a very robust discussion.    I'd summarize it as:

*Direct is low risk for the purpose intended, pushing data from point A to point B using SMTP/SMIME with an optional XDR (SOAP) connector.   Additional work needs to be done on certificate discovery, but that will use DNS and LDAP, two well adopted technologies.

*Exchange needs additional work to ensure it scales at a national level for pull and push transactions.   The S&I Framework teams are working on modular specifications that should enable a subset of Exchange components to be used, simplifying implementation and support.   The Standards Committee will seek additional testimony from Exchange implementers to learn more about their experience.

*It's worthwhile to think about additional transport standards that do not yet have well specified implementation guides, such as a combination of REST, oAuth and TLS - something that Facebook, Amazon, or Google would use to create a highly scalable transport architecture.

The ePrescribing of Discharge Meds Power Team led by Jamie Ferguson presented the use of HL7 2.2-2.51 transactions to support hospital information system workflows in a manner that is compatible with Medicare Part D.   We clarified that newer versions of HL7 2.x which are backward compatible should also be allowed.

The Clinical Quality Workgroup and Vocabulary Task Force led by Jamie Ferguson presented their transition plans for vocabularies, identifying the cross maps between vocabularies that need to be created and supported as we evolve from our current use of vocabularies to a future state in which there is one structured vocabulary per domain of medicine (problems, medications, labs, allergies etc).

Doug Fridsma then presented an overview of the Standards and Interoperability Framework activities and next steps:

Transitions of Care - Doug described a brilliant approach that incorporates simple XML, such as has been used in the CCR, with the expandability of the CCD.  He calls this next evolution of clinical summaries  "Consolidated CDA templates".  It's likely that the clinical summary certification criteria will evolve to a single XML format that is easy to use, fast to implement, expandable, based on a reference model, and human readable.   Well done!

Reportable Labs -  In the past, standards harmonizers struggled to balance simple, easy to implement lab specifications such as ELINCS with the comprehensive and full featured lab specifications from HITSP.   The S&I group created a foundation based on ELINCS that is expandable to include all the features of the HITSP specifications using a single HL7 2.51 implementation guide.   Amazing work.

Provider Directories - The S&I Framework team had the courage to admit that directory standards are still evolving and need more testing/piloting before selection.   DNS/LDAP approaches are likely to work well for certificate discovery.   Other aspects of directories such as provider routing addresses and electronic service capabilities may be stored in web pages (microdata), LDAP (HPD), or X12 274 directory structures.

Doug also described new works in progress - Query Health for distributed data mining, Data Segmentation to manage disclosures of protected health information, and Electronic Submission of Medical Documentation for transmission to Medicare review contractors.

Finally and very importantly, the Implementation Workgroup led by Liz Johnson and Judy Murphy presented the Implementation Workgroup certification criteria analysis.   We had a thoughtful discussion of each open issue and suggested a path forward for each certification item.

Truly an inspiring meeting - the most work we've ever done in a single day.

The delivery of Meaningful Use Stage 2 Standards and Certification criteria was recognized at a White House celebration by Aneesh Chopra, Chief Technology Officer and numerous members of the Obama administration senior staff.   Thanks so much to Aneesh and others for celebrating our work.

As I told the Standards Committee today, I am honored to serve with this team, the hardest working Federal Advisory Committee in government.  A milestone day for the country.

The June HIT Standards Committee meeting

 by John Halamka, Life as a Healthcare CIO

The June HIT Standards Committee meeting followed the "Summer Camp" schedule precisely, and focused on health information exchange metadata (patient identifiers/provenance/privacy flags),  provider directories, patient matching, meaningful use stage 2 standards, quality measures, and feedback how to ease the burden of certification.

Farzad Mostashari, National Coordinator, began the meeting by highlighting the importance of taking first steps on early health information exchange use cases.  The notion of creating a standard envelope around data that identifies the patient and the sender of the data enables many transactions.   Supporting privacy flags enables the recipient of the data to obtain necessary consents before viewing data and to store the data optimally to respect patient privacy preferences (such as special locked areas for mental health, substance abuse or HIV related data).   Privacy flags may not be needed if the patient is the source of the data or the patient gives consent to disclose and consent to view directly to the provider at the point of care. 

Stan Huff led the metadata discussion and reviewed the work that has been done to date on patient ID and provenance standards.   For patient ID, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header.  This XML has nothing healthcare specific such as OIDs in it.   For provenance, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header and X.509 certificates for digital signature.  The signature could be an institution, a department, or an individual, as needed by the use case.   For Privacy we considered many options and recommended a CDA R2 Header with a simple vocabulary to indicate that sensitive data is present.   The list of sensitive data types could include mental illness, substance abuse, sexually transmitted disease data, HIV data, domestic violence data etc. or it could be a simple indicator that sensitive data is present.  Specifying such a vocabulary is future work.

A robust discussion followed about privacy flags.   Here are important clarifications

1. During transmission, the envelope of metadata plus the payload of content is fully encrypted and so the metadata is not readable until it arrives inside the organization or to the person authorized to read it. 

2.  Much of the time, no privacy flags are needed because the patient will be the source of the data and will elect what to disclose to whom.   Privacy flags would likely be needed when data is assembled from multiple sources and is received by a provider who needs to obtain special consent before viewing it or apply special protections before storing it.

3.  A privacy flag would enable data to be automatically routed to specially protected areas of the EHR.

4.  The CDA R2 header standards are used millions of times per day throughout the world but this subset of them and constrained specifications of how/when they are used should be tested before regulations require them for specific transactions.

5.  The recommendation to use CDA R2 headers for metadata is the beginning of a formal ONC process to seek comment, feedback and stakeholder engagement regarding their use.

Based on all these clarifications, the HIT STandards Committee approved the use CDA R2 header for metadata as a formal recommendation to ONC as it begins the NPRM process.

Next, Dixie Baker and Walter Suarez presented Provider Directory recommendations.   At last month's meeting, they suggested the use of LDAP/IHE HPD standards and received  feedback that these standards were not the best fit for cross organizational/federated directory lookup.   They reconsidered the possibilities and examined DNS as a means to find IP addresses and certificates, the concept of a Top-Level-Domain as a means to create a uniform, secure way to retrieve directory information about healthcare organizations (of note, ICAAN announced that such Top Level Domains will soon be very easy to create), and the use ofmicroformats/microdata as a means of creating simple federated lookups for provider directory information that cannot be stored in DNS, such as street address and phone number.  Web pages containing such data can be secured with Extended Validation certificates to provide identity verification of the entity publishing the information i.e. it really is Beth Israel Deaconess publishing the directory information about Beth Israel Deaconess.  Summarizing their recommendations for provider directories:

1.  DNS should be used for certificate retrieval per the Direct Specification plus web pages with microformats/microdata should be used for additional directory information.   These web pages can be federated via standard search engine technology.

2.  A Top level domain can be considered in the future, but there is no need to implement one now.

The HIT Standards Committee approved this recommendation as input to the S&I framework process.

Next, Doug Fridsma let a discussion of progress on "Summer Camp".

Marc Overhage presented the work on patient matching, noting that the work of the group is to specify those data elements that can be used to match patients, achieving a reasonable balance of sensitivity and specificity i.e. it's ok to occasionally not find a patient's record, but it is very bad to find the wrong record.   The team is not specifying the matching algorithm such as exact match, probabilistic match, partial match (first six letters of last name), Soundex or other approaches.   Their work to date suggests using patient name, gender, date of birth and numeric identifiers (such as driver's license number, payer member number, last 4 of SSN etc.).   It does not preclude the possibility that new identifiers such as an opt in patient healthcare ID, a DIRECT address, or other identifier could be included in the future.

Dixe Baker presented an overview of the Nationwide Health Information Network power team effort which will create a set of building blocks encompassing all the requirements of the existing NwHIN Exchange standards and Direct standards.   Their final report will be presented in September.

Steve Posnack presented the Standards and Certification Criteria codeset update that enables the latest version of SNOMED-CT, LOINC and CVX to be included in Certification testing.

George Hripcsak and Josh Seidman presented an overview of Meaningful Use Stage 2.   In the next few weeks, ONC will determine what gaps need to be filled with new standards specifications.

Jim Walker presented the Clinical Quality Workgroup Update as the group continues to simplify the computation of measures and reduce the level of effort to comply with the quality reporting requirements of meaningful use.

Jamie Ferguson and Betsy Humphreys presented the Vocabulary Task Force Update.  Soon, standards subsets will be available that will reduce the burden of implementation and compliance with meaningful use vocabulary standards adoption.

Judy Murphy and Liz Johnson presented the Implementation Workgroup Update.   They are completing data gathering and analysis of feedback on the certification process and ways in which it can be improved for stage 2.

A very productive meeting.   I look forward to the July meeting and the work ahead on Meaningful Use Stage 2 standards.

PCAST Use Cases

by John Halamka, Life as a Healthcare CIO

As I posted yesterday, the PCAST Workgroup has discussed use cases which correspond to three levels of healthcare information exchange supported by a Universal Exchange Language (UEL) and Data Element Access Service (DEAS) - "push by patient of data between two points", "simple search for data", and "complex search for data".  They are intended to support PHR and EHR health information exchanges for a multitude of uses, include clinical care, population health and clinical research.  A 4th Use Case incorporates de-identified data.



Use Case 1 - Push by patient between two points.



The patient logs into a tethered PHR via username/password or other authentication mechanism provided by the clinical organization hosting the data.   The patient chooses to push the data to the non-tethered PHR of their choice.   Many possible architectures and approaches can support this including download from the tethered PHR with upload to the un-tethered PHR, a push directly from the tethered PHR to the un-tethered PHR (as Google Health and Microsoft Health support today), or the use of secure email from the tethered PHR to the un-tethered PHR using the Direct standards via a secure health email address.  In each case, the data sent wrapped in a UEL envelope containing patient identity, provenance, and privacy metadata information.     UEL Metadata might also include non-disclosing information about the categories health data available in the content package i.e. medication list, problem list, allergy list, labs, radiology images etc.



When the UEL arrives at the non-tethered EHR, data is shown to the patient, who can elect to incorporate structured and unstructured data into their existing un-tethered PHR dataset.   Then, the patient can then choose to share PHR data with clinicians, clinical researchers, or public health by pushing selective PHR data wrapped in an UEL envelope via secure transmission (such as Direct) to recipients of their choice.    Organizational certificates are needed for the senders (un-tethered PHR hosting organization) and the recipients (clinician offices, clinical research organizations, public health organizations).    Audit trails are held by senders, recipients and any Health Information Service Providers used as part of Direct transport.   Patient authentication is username/password as required by the PHRs.  Provider authentication is username/password or other modality as required by the EHR.



Summarizing the infrastructure for this approach, we will need
:

*A UEL that includes patient identity, provenance, privacy metadata, and categories of health data available in the content package.   There will need to be semantic standards for this metadata including the content/vocabulary of identity, providence, privacy metadata, and categories of health data

*Applications which are capable of wrapping content packages of clinical data in the UEL

*Applications which are capable of receiving the UEL and unwrapping content packages


*Certificate management to secure the endpoints and support privacy controls


*Policies that support push of data between two points.   

Use Case 2 - Simple Search



A patient presents to an Emergency Department and notes their records are stored at a specific clinician office and a specific hospital.    An Emergency Physician obtains patient consent to retrieve their records.    A query is created that includes patient identity, consent information, and provider authentication data.    A Data Element Access Service which serves as an entity level provider directory is securely queried to determine the Uniform Resource Identifiers (URIs) of the clinician office and hospital.   The query is sent to the URIs, which return a UEL wrapper containing identity information, provenance, patient privacy metadata based on any consents on file at the organizations hosting patient records, and non-disclosing information about the categories health data available in the content package.    The content package inside the UEL includes numerous appropriate vocabularies.   The receiving clinician can choose to incorporate structured and unstructured data into the Emergency Department record.    All exchanges are query/response.  Organizational certificates are needed for the Emergency Department,  the clinician office and the hospital.   Audit trails are held by all these organizations.   Provider authentication is username/password or other modality as required by the ED information system or national policy.



Summarizing the infrastructure for this approach, in addition to the infrastructure of Use Case 1, we will need:


*Policy for issuing queries to organizations hosting patient records


*A DEAS that includes entity level provider directory information to provide the URIs of provider data sources


*The syntax and semantics of a query for clinical data including identity information that is sent to provider organizations hosting patient information


*Applications which are capable of issuing a query to known URIs


*An approach to disambiguate identity conflicts if the query results in multiple patient matches



Use Case 3 - Complex Search

A patient presents to an Emergency Department and is non-responsive.  However, her wallet contains an ID with name and date of birth.   An Emergency Physician, based on policy which grants implied consent for unconscious patients, clicks the external search icon in their EHR.  The EHR creates a query containing patient identity, implied consent information, and provider authentication and role, then sends it to a Data Element Access Service.   The DEAS returns a list of Uniform Resource Identifiers of the organizations which hold the patient's records.   The Emergency Physician’s EHR sends a query containing patient identity, consent information, provider authentication and role to each of the URIs, with a request for problems, medications or allergies.  Each organization returns as many UEL wrapped data packages as match the query and pass the conditions of patient privacy metadata based on any consents they have on file.  Each UEL wrapped package includes identity, provenance and privacy metadata and non-disclosing information about the categories health data available in the content package.   The content package inside the UELs includes numerous appropriate vocabularies.   The receiving EHR filters and organizes the information for the clinician who can choose to incorporate structured and unstructured data into the local Emergency Department record.    All exchanges are query/response.  Organizational certificates are needed for the Emergency Department, the DEAS provider, and the organizations which contain patient records.  Audit trails are held by all these organizations.   Provider authentication is username/password or other modality as required by the ED information system or national policy.



Summarizing the infrastructure for this approach, in addition to the infrastructure of Use Case 2, we will need:


*Policy for issuing a query to the DEAS

*A DEAS which contains patient identity information, provider URIs and potentially more granular information about the types of data available at those URIs


*The syntax and semantics of a query including identity information that is sent to the DEAS.   
*Applications which are capable of querying a DEAS and then querying URIs of provider data sources specified by the DEAS, assembling the data returned into a meaningful display
*Support for privacy metadata that are returned by the DEAS and provider data sources

Interoperation among Use Cases 1-3

The Use Cases and the Levels of Exchange are not mutually exclusive.  If all three are supported, the patient in Use Case 1 can use the simple search of Use Case 2 to query for the URI of a provider they would like to push their information to; and the complex search of Use Case 3 to expose a UEL wrapped subset of their PHR to the DEAS tagged with a privacy tag indicating their desire that it be made available to someone giving them care and a provenance tag indicating that she had edited it.

Use Case 4 - De-identified aggregate data mining



A researcher wants to retrieve de-identified mammograms to investigate a new technology that provides computer assisted interpretation.    The researcher issues a query to the DEAS requesting de-identified mammograms that are reusable for research based on patient consent.    A list of URIs is returned including pointers to mammograms.   The researcher queries the URIs and receives de-identified mammograms.

Summarizing the infrastructure for this approach
*Policy for issuing a research queries to the DEAS
*A DEAS which supports de-identified queries for a specific type of data
*The syntax and semantics of a query including data type information that is sent to the DEAS.   
*Provider data sources that are capable of returning de-identified data
*An application that can query a DEAS and query provider data sources
*Support for privacy metadata that include consent to release data for research and ensure de-identification

The combination of these use cases and the security model described in yesterday's post provides a clear path forward that enables pilots and research to be done in parallel with the meaningful use activities already in progress.

As I think about the exciting years ahead - a PCAST inspired expansion of health information exchange, meaningful use stage 2 & 3, and healthcare reform, I am concerned that doing ICD-10 in the middle of all these other activities will overwhelm healthcare systems and IT organizations.   My thoughts on rebalancing and aligning all of the projects in front of us will be a blog post for next week.

The PCAST Hearing

by John Halamka, Life as  Healthcare CIO


On February 15 and 16, the HIT Policy Committee and the HIT Standards Committee convened to hear testimony about thePresident's Council of Advisors on Science and Technology HIT Report.

The hearings consisted of 5 panels.   Here are the major themes.

Panel 1 focused on Health Information Exchange and Healthcare Stakeholders

Carol Diamond, MD, Markle Foundation
J. Marc Overhage, MD, Indiana HIE Organization
Art Glasgow, Vice President & Chief Technology Officer, Ingenix

* Trust is more complex than consent and cannot be achieved by technology alone
* Data source systems are frequently not able to meet reasonable service levels for response time and data persistence
* Data source organizations need assistance (strategy, policy, when to attached standardized vocabularies to data) in normalization data
* Need to balance mobilizing data verses losing context

Panel 2 focused on Patients / Consumer / Privacy Advocates

Donna Cryer, JD, CryerHealth Patient-Centric Solutions
Deborah Peel, MD, Patient Privacy Rights
Joyce Dubow, AARP
Lee Tien, Senior Staff Attorney, Electronic Frontier Foundation

* Consent is essential but not sufficient.  PCAST's heavy reliance on consent to achieve adequate privacy is a concern
* First goal of data use should be for treatment of patients and not for secondary uses
* Privacy preferences must be dynamic based on segmentation of data
* Must do proof of concept of pilots of DEAS and privacy
* PHRs can play a role in patients' ability to express granular privacy preferences
* Concern about adequacy of de-identification
* Many privacy issues not discussed during panel

Panel 3 focused on Population Health
Richard Platt, MD, Harvard Medical School, Distributed Health DataNetwork
Joyce C. Niland, Ph.D., Associate Director & Chair of Information Sciences, City of Hope

* Population and clinical research require persistent record sets, curated for the anticipated use
- Observational data is best suited for hypothesis generation
- Correct interpretation requires participation of originator in interpretation, semantic standards will crease but not eliminate this dependence
- research data models reflect study design, not data characteristics
- PCAST does not preclude and can support distributed data management
* Population studies require identification of the population (denominator) and the intervention sub-population (numerator)
- Granular consent and opt out by data suppliers could be problematic
- Policies must support continued use of public health
* De-identification is problematic

Panel 4 focused on Providers and Hospitals

Sarah Chouinard, MD, Medical Director, Primary Care Systems, Inc. and Community Health Network of West Virginia
John E. Mattison, MD, Kaiser Permanente
Scott Whyte, Catholic Healthcare West, provider using middleware
Kevin Larsen, MD, CMIO, Hennepin County Hospital
Theresa Cullen, MD, Indian Health Service, HHS

*PCAST Timeline too aggressive to execute
*Privacy tags may hinder normal institutional use of data
*Propagation/redaction of inaccurate data is a concern
*Middleware may bridge legacy systems to PCAST vision but has limitations
*Patient matching is problematic
*Novel PHR use may additional spur HIT adoption

Panel 5 focused on Technology implications of the report
Michael Stearns, MD, CEO, e-MDs, Small EHR Vendor
Hans J. Buitendik, M.Sc., HS Standards & Regulations Manager, Siemens Healthcare
John Melski,  Marshfield Clinic, homegrown EHR
Edmund Billings, Medsphere

*It is important to maintain the context of a clinical encounter and to preserve the meaning when the data is reused for purposes other than as originally intended.
*Capture structured data with appropriate granularity and controlled terminology.   A "data atom" should be the amount of data that makes sense for the particular use intended.
*Separate the syntax (the container used to send data) from semantics (the ontologies and vocabularies).   Admittedly, in healthcare summary standards, syntax has been driven by semantics, so this separation would require careful thought.
-Syntax is the study of the principles and rules for constructing sentences in natural languages.
-Semantics is the study of meaning. It typically focuses on the relation between signifiers, such as words, phrases, signs and symbols, and what they stand for.
-Information models or relationship types provide frameworks to maintain context.  Explicit representation of context must be integrated into an evolving Universal Exchange Language and may require specification of an information model.
*Evaluate the burden and timeframe and priority in the context of existing meaningful use and ICD10/5010 projects. 
*Simply exchanging data does not necessarily lead to useful and accurate data.  We need to know how the data was captured, for what purpose, and by whom.
*Open source solutions should be considered to drive low cost solutions for data exchange
*Use existing profiles/technologies and middleware to meet PCAST data exchange goals. We should not rip and replace existing applications and standards.

We discussed one strawman idea for incorporating PCAST ideas into Stage 2 and Stage 3 of Meaningful Use.

Given that the Direct project  provides a means to push data securely using secure email standards, require that EHRs push immunization data in an electronic envelope containing metadata (we'll call that envelope the universal exchange language) to state and local immunization repositories as part of Meaningful Use Stage 2.   This will implement the Universal Exchange Language portion of the PCAST report.

ONC should begin work on connecting state level immunization registries with a person identified index and privacy controls.     This will implement the  Data Element Access Services (DEAS)  portion of the PCAST report.   

The DEAS will require significant additional policy and technology work that will not be ready by Stage 2.   Thus, by Stage 3 require that EHRs be able to query a DEAS to retrieve immunization data at the point of care so that clinicians can deliver the right immunizations at the right time to the right patients based on a nationwide federated network of immunization exchange.  It's good for patients, good for clinicians, good for public health, and does not raise too many privacy concerns.   Of course we should pilot granular privacy controls enabling individuals to control the flow of immunization information per their privacy preferences.

We'll have several additional meetings before the final workgroup report is issued.    I believe we're close to achieving consensus on the major concerns and next steps as we offer ONC options for incorporating the spirit of PCAST into their work.

Detailed Clinical Models

 by John Halamka, Life as  Healthcare CIO

As the PCAST Workgroup ponders the meaning of a Universal Exchange Language and Data Element Access Services (DEAS), it is exploring what it means to exchange data at the "atomic", "molecular", and document level.   See Wes Rishel's excellent blog defining these terms.   For a sample of my medical record using one definition of an atomic form, see this Microsoft Healthvault screenshot.   It's clear to me that if want to exchange structured data at a level of granularity less than an inpatient/outpatient/ED encounter, we need to think about detailed clinical models to specify the atoms.

As I've discussed previously, it would be great if EHRs and PHRs with different internal data models could use middleware to exchange a reasonably consistent representation of a concept like "allergy" over the wire.    I think of an allergy as a substance, a precise reaction description, an onset date, a level of certainty, and an observer (a clinician saw you have a severe reaction verses your mother thought you were itchy).    PHRs often have two fields - substance and a severe/minor indicator.    Any EHR/PHR data exchange without an agreed upon detailed clinical model will lose information.

HL7's Reference Information Model (RIM) provides one approach to modeling the data captured in healthcare workflows.  However, many clinicians do not find the RIM easily understandable, since it is an abstraction (Act, ActRelationship, Participation, Roles, Entities) rather than a reflection of the way a clinician thinks about clinical documentation.   Alternatively, a detailed clinical model provides an archetype or template to define the aspects of the data we should exchange.

Stan Huff at Intermountain Healthcare has led much of the work on detailed clinical models in the US.   Here's a recent presentationdescribing his work.

To illustrate the way a detailed clinical model can enhance data exchange, here's a description of an allergy template based on collaborative work between Intermountain, Mayo and GE.

The Australian work on OpenEHR is another interesting approach to detailed clinical models.  It creates a clear expression of a clinical concept in a manner that can be understood both by clinical subject matter experts and technologists. For a given concept, OpenEHR specifies a SNOMED code and then builds the appropriate information structure around it.

The screen shot above illustrates the OpenEHR archetype for adverse reactions/allergies.

Other important efforts include:

William Goossen's ISO 13972 work.  He's writing a review of 6 different approaches (see the comment on Keith Boone's blog) including HL7's CDA templates, OpenEHR archetypes, and Stan Huff's detailed clinical models.  Hopefully it will be published soon.

The UK National Health Service Connecting for Health Project'sLogical Record Architecture.

The Tolven Open Source Project's Clinical Data Definitions.

It's clear to me that wide adoption of a Universal Exchange Language would be accelerated by detailed clinical models.     This is a topic to watch closely.

The Proposed Stage 2 and 3 Meaningful Use Recommendations

 by John Halamka, Life as a Healthcare CIO 


On January 12, the Health Information Technology Policy Committee published its proposed Stage 2 and 3 Meaningful Use recommendations for public comment.

Robin Raiford from Allscripts created a Quick Guide to the recommendations, making it easy to compare Stage 1, 2 and 3 in a single PDF. 

Here's my analysis of the proposed Stage 2 and 3 criteria.

1.  CPOE - Stage 1 requires more than 30% of unique patients with at least one medication in their medication list have at least one medication order entered using CPOE  Stage 2 expands this to 60% of patients for at least one medication, lab or radiology order.  Stage 3 expands this further to 80%.   CPOE orders do not need to be transmitted electronically to pharmacies/labs/radiology departments.   This is a very reasonable rate of CPOE adoption.   The hardest part of implementing CPOE is getting started, which happens in Stage 1.   Adding different types of transactions (without requiring electronic transmission to back end service providers) is more about workflow and behavioral change than technology change.

2.  Drug-drug/drug-allergy interaction checks - Stage 1 requires that interaction technology be enabled.   Stage 2 adds that it will be used for high yield alerts, with metrics for use to be defined.  The idea is that many drug databases contain too many false positive interaction rules, so adoption is slowed by alert fatigue.   If only high yield alerts are required (here's what we've done at BIDMC ), clinicians are more likely to trust drug interaction decision support. Stage 3 adds drug/age checking (such as geriatric and pediatric decision support), drug dose checking, chemotherapy dosing, drug/lab checking, and drug/condition checking.  These are all reasonable goals, but automating chemotherapy protocols is quite challenging.   BIDMC built anOncology Management System and added a full time research nurse to ensure all chemotherapy protocols are updated and accurate.    It may be asking too much to require chemotherapy dosing decision support nationwide by 2015. 

3.  e-Prescribing - Stage 1 requires e-prescribing of 40% of non-controlled substances.  Stage 2 expands this to 50%.  Stage 3 expands it further to 80%.  Electronic faxing is permitted if pharmacies cannot accept e-prescriptions.   These are very reasonable goals and easily achievable if e-prescribing systems are in place, which is required for Stage 1.   E-prescribing of controlled substances, which requires more effort  including two-factor authentication, is not specifically mentioned.

4.  Demographics - Stage 1 requires capture race/ethnicity, primary language, and other demographics for 50% of patients.  Stage 2 expands this to 80%.  Stage 3 expands this further to 90%. Most institutions are already near 100% since they capture this information as part of existing registration and billing processes.

5.  Report quality measures electronically - Stage 2 and 3 will be specified by the Quality Measures Workgroup and CMS.  No further detail is offered at this time.   The hardest part of quality measure reporting is computing the numerators and denominators as is required for Stage 1.  Generating the PQRI XML to send the data to CMS is quite easy.

6.  Maintain problem lists -  Stage 1 requires documentation of at least one problem for 80% of patients.  Stage 2 is unchanged. Stage 3 requires that problem lists be up to date.  This is reasonable.   Clinicians will be motivated to update them because the problem list will be included in clinical summaries sent to the patient after every visit.   I hope that EHR vendors improve the usability of problem list management functions by creating natural language translation into the required SNOMED-CT or ICD9/ICD10 vocabularies. 

7.  Maintain active medication lists - Stage 1 requires documentation of at least one medication for 80% of patients.  Stage 2 is unchanged.  Stage 3 requires that medication lists be up to date as part of medication reconciliation, which per requirement 31 below will be a core requirement with 80% compliance in Stage 2 and 90% in stage 3.  In my view, the greatest strength of EHRs should be medication management.

8.  Maintain active medication allergy lists -  Stage 1 requires documentation of at least one allergy for 80% of patients.   Stage 2 is unchanged.  Stage 3 requires that allergy lists be up to date. Clinicians will be motivated to update them because the allergy list will be included in clinical summaries sent to the patient after every visit.   

9.  Vital signs - Stage 1 requires vital sign recording for 50% of patients.   Stage 2 expands this to 80%.  Stage 3 is the same as Stage 2.  This is reasonable. 

10.  Smoking status -  Stage 1 requires smoking status documentation for 50% of patients.  Stage 2 expands this to 80%.   Stage 3 expands it to 90%.  This is reasonable. 

11.  Use Clinical Decision Support to improve performance on high-priority health conditions -    Implemented properly, decision support can save time while enhancing safety.   Maintaining rules can be challenging and I hope companies evolve to provide cloud-based approaches to decision support. 

12.  Formulary checks - In Stage 1, formulary checks are in the menu set with the requirement that clinicians and hospitals have access to at least one internal or external drug formulary for the entire EHR reporting period.  Stage 2 moves this to core.   Stage 3 requires the functionality to be applied to 80% of medication orders.   Formulary checking is generally a part of e-prescribing, so this is reasonable.   The only unknown is how formularies vary in different regions.   Since Massachusetts has only 3 major payers, all regional, formularies have been relatively easy to manage.

13.  Advanced directives - In Stage 1, Advanced Directives are in the menu set with the requirement that 50% of patients 65 and older have advance directive documentation.   Stage 2 moves this to core.  Stage 3 requires 90%.    I believe this is a laudable but a challenging goal to achieve.   My experience is that most hospitals have advanced directives recorded for less than 25% of their patients. 

14.  Incorporate lab results as structured data - The Stage 1 menu set requirement is that lab results are incorporated into EHRs as structured data for more than 40% of all clinical lab tests ordered.   Stage 2 moves this to core.  Stage 3 expands the functionality for 90%  of tests ordered and requires they be reconciled with structured orders.   Lab workflow improvement is one of the best ways to save clinicians time and ensure followup of abnormal results.   My only reservation with this requirement is that the standards for content and vocabulary (lab compendiums)  are still a work in process, so reconciliation with electronic orders may be premature.

15.  Generate patient lists - The Stage 1 menu set requirement is to generate at least one report listing patients with a specific condition. Stage 2 moves this to core.  Stage 3 requires such lists are used to manage patients for high priority health conditions.    EHRs must include business intelligence capabilities as part of Stage 1 certification, so these recommendations should be easily achievable.

16.  Send patient reminders - The Stage 1 menu set requirement is to send reminders to more than 20% of all unique patients 65 years/older or 5 years old/younger.   Stage 2 makes this core.   Stage 3 requires 20% of all active patients who prefer to receive reminders electronically receive them.   I'm supportive of this requirement if I can fulfill it by offering all our patients secure web-based reminders via our PHR.   Offering multiple electronic notification options (phone, fax, secure email, PHR, Facebook, Twitter, SMS texting) would be hard to manage.

17. Electronic outpatient notes - Stage 2 adds a new requirement for eligible professionals that 30% of visits have an electronic note.  Stage 3 requires 90%.  This note can be scanned, free text, structured etc.   Offering the option of scanning, dictating, structured and unstructured makes this requirement very reasonable.

18. Electronic inpatient notes - Stage 2 adds a new requirement that 30% of hospital days have at least one electronic note by a physician, NP or PA.   As with outpatient notes, this can be scanned, free text, structured etc.   Very few hospitals have electronic inpatient documentation.   Offering the option of scanning paper notes makes this requirement very reasonable.

19.  Electronic Medication Administration Records - Stage 2 adds a new requirement that 30% of medication orders are tracked via an EMAR.   Stage 3 makes this 80%.   The definition of EMAR will be key.   I think of an electronic medication administration record as positive patient identification of every patient, every drug and every staff member with mobile devices to record all medication events in real time.   Requiring this for the entire country by 2015 is aggressive.

20.  Provide an electronic copy of health information - Stage 1 requires this for 50% of patients who request it.  Stage 2 is unchanged.   Stage 3 requires 90%.   The challenge is implementing the workflow to support this requirement, which has to be done for Stage 1.   Thus Stage 2 and 3 are reasonable.

21.  Provide a copy of discharge instructions -  Stage 1 requires this for 50% of patients who request it. Stage 2 expands this to 80%.  Stage 3 expands it to 90%.  Since printed discharge instructions meet the criteria, this is reasonable.

22.  Patient specific educational resources - Stage 1 requires this for 10% of patients. Stage 2 is unchanged.   Stage 3 expands this to 20% in common specific languages.   This key question is what is a common language?  BIDMC supports 37 different languages.   Offering educational resources in all these languages would be challenging.

23.  Web-based download of inpatient records -  Stage 2 adds the ability to view and download inpatient summaries for 80% of patients.  Stage 3 is the same.   Since BIDMC already has a PHR offered to all its patients, this requirement is actually an easier workflow than providing inpatient record summaries upon demand via a manual process.  This requirement will be challenging for organizations which have not yet widely implemented personal health records.

24.  Provide clinical summaries for each office visit - Stage 1 requires this for 50% of all patients (not just those who ask).  Stage 2 expands this to "view and download" within 24 hours.   Stage 3 is the same.   The challenge is that records may not be completed and signed within 24 hours, especially if dictation or scanning processes are used to generate the electronic record.

25.  Timely electronic access -  The Stage 1 menu set requirement is that more than 10% of all unique patients seen by the clinician are provided timely electronic access to their health information subject to the clinician's discretion to withhold certain information.  Stage 2 and 3 make this core and include the requirement that patients should be able to filter or organize information by date, encounter, etc.   More detail is need about the requirement to organize the data to determine just how difficult this will be.   This requirement will be challenging for practices which have not widely implemented personal health records.

26.  Measures for clinical summaries and timely electronic access - Stage 2 requires that  20% of patients use a web-based portal and Stage 3 expands this to 30%.    It seems a bit odd to measure clinician performance based on patient behavior.  BIDMC has offered comprehensive secure email, timely access to all inpatient/outpatient data, and even full text notes.   After 10 years, no more than 20% of our patients use these functions.   I think a better approach is to require such functions be offered to all patients criteria is that all patients.  Adoption is something beyond clinician control.

27.  Online Secure messaging - Stage 2 and 3 adds a new requirement that online secure messaging be in use.  Our experience with online secure messaging is that it reduces clinician time returning phone calls and enhances both clinician and patient satisfaction.   This is a reasonable requirement.

28.  Patient preference for communication medium - Stage 2 adds a new requirement that patient preference for communication be recorded for 20% of patients.  Stage 3 expands this to 80%.   Per my comment in Timely Electronic Access,  I would prefer offering all patients web-based communications rather than trying to manage multiple communication approaches.

29.  Patient Engagement - Stage 3 includes multiple new patient engagement requirements - electronic self management tools, EHR interfaces to PHRs, patient reporting of care experiences online, and patient generated data incorporation into EHRs.   These need to be defined in much greater detail before their implications can be assessed.

30.  Perform test of HIE - Stage 1 required one test.   Stage 2 expands this to at least three external providers in primary referral networks (but outside the delivery system that uses the same EHR) or a bidirectional connection to at least one health information exchange.   Stage 3 expands this to 30% of external providers or a connection to a health information exchange.   Stage 2 and 3 require the HIE to connect to an entity-level provider directory.   Although some regions with well developed HIE capabilities will find this easy to achieve, many will await the functionality promised by the Direct Project in order to exchange data.

31.  Perform Medication reconciliation - The Stage 1  menu set requirement is medication reconciliation in 50% of care transitions.  Stage 2  moves this to core and expands it to 80%.   Stage 3 expands this to 90%.   Since the Joint Commission required this over 3 years ago, it is very reasonable.  Hard to operationalize, but the right thing to do.

32.  Provide summary of care record - The Stage 1 menu set requirement is a summary of care record for more than 50% of transitions of care and referrals.   Stage 2 makes this core.   Stage 3 expands this to 80%.   The challenge will be defining how this content is transmitted from provider to provider.

33.  List Care members - Stage 2 adds a requirement to provide a list of care team members (including PCP) for 10% of patients.  Stage 3 moves this to 50% via electronic exchange.  Once more details about the electronic exchange are provided, I can better assess this requirement.

34.  Longitudinal care plan - Stage 2 adds a requirement to record a longitudinal care plan for 20% of patients with high-priority health conditions.   Stage 3 expands this to 50%.   Although I'm familiar with pilots in which clinicians and patients jointly develop care plans, I have not seen it widely implemented.  This may be a bit aggressive.

35.   Submit immunization data - The Stage 1 menu set requirement was a single transaction.   Stage 2 moves this to core and requires ongoing submission.  Stage 3 requires query and review of immunization registry data.   The challenge is that many state and local public health departments do not offer the ability to receive and query immunization data.

36.  Submit reportable lab data - The Stage 1 menu set requirement was a single transaction.  Stage 2 moves this to core.   Stage 3 includes the requirement for hospitals to include complete patient contact information in 30% of reports.  As with immunizations, state and local public health departments may find this challenging to support.

37.  Submit syndromic surveillance data - The Stage 1 menu set requirement was a single transaction.  Stage 2 moves this to core.   Stage 3 includes patient self report and something called the Public Health button, which is not defined.  Public Health Departments may find this challenging to support.

38.  Ensure privacy - Nothing new was specified but additional privacy and security objectives are under consideration by the HIT Policy Committee’s Privacy and Security Tiger Team.

Thus my areas of concern are chemotherapy automation, recording patient communication preferences, judging clinician performance based on patient adoption of PHRs, EMAR implementation, maturity of HIE capabilities,  widespread rollout of longitudinal care planning, and public health readiness.

The comment period ends Feb. 25 and the Health IT Policy Committee will consider all of the comments in making its final recommendations this Summer to the Office of the National Coordinator for Health Information Technology at HHS. Here's the work plan as I understand it

Jan, 12, 2011: release draft Meaningful Use criteria and request for comment
Feb-March, 2011: analyze comment submissions and revise Meaningful Use draft criteria
March, 2011: present revised draft Meaningful Use criteria to the HIT Policy Committee
2Q11: CMS report on initial Stage 1 Meaningful Use submissions
3Q11: Final HIT Policy Committee recommendations on Stage 2 Meaningful Use
4Q11: CMS Meaningful Use NPRM

It's great to have a roadmap so we know where we're going between now and 2015.   At present BIDMC is completing its certification inspection tests and is working hard to achieve meaningful use by the end of March so we can attest in April.   Given the challenges of achieving certification and meaningful use for Stage 1,  we welcome a two year window to prepare for Stage 2.