The Genius of the AND

Recently in Washington, an important political figure asked me why I had the reputation of resisting change.

Since I've spent my life catalyzing change and embracing the latest technology, I found this a very strange statement.

I have no idea how history will record my life and work, but I think the answer is - it depends who you ask.

Wes Rishel wrote a great blog today that reduces the debate about standards and interoperability into two points of view - “the healthcare informatics crowd" and "the Internet crowd".

I've spent the past 4 years facilitating standards harmonization in HITSP, bringing together 800 organizations to discuss the parsimonious number of standards needed to facilitate the data exchanges which will support meaningful use.

From the point of view of the healthcare informatics crowd, the harmonization of disparate approaches into CDA/CCD with XDS.b, XDR, XCA and XDM represents significant simplification and convergence of the major stakeholders in healthcare IT.

From the point of view of the Internet crowd, it represents a set of complex content and security constructs that puts the SDOs in the HTTP business.

The work I've done for the past 4 years aimed at unifying the industry on a web services approach, embracing web-centric standards such as SOAP, XML, and HTTPS. In 2006-2007, this was considered very forward looking. In 2009, RESTful data exchange of simple payloads with TLS and application level security is considered cutting edge.

Thus, my challenge as a leader is to bring together both the healthcare informatics crowd and the internet crowd, without having to take sides and choose either/or.

The answer to me is that we need to embrace both approaches - the right tool for the right job depending on what you want to achieve.

For provider to provider communication which requires the exchange of documents with non-repudiation as the medico-legal record for direct clinical care, the CDA/CCD has great metadata and the ability to support structured data as well as free text discharge summaries/operative notes/history&physicals.

For a summary record that represents a snapshot in time of problems, medications, and labs for transmission between EHRs and PHRs, the CCR and other formats such as Google's CCRg or PDF can do the job.

On the FACA blog today, Marc Overhage wrote about good enough standards for a particular purpose.

This blog posting is likely to generate debates from both the healthcare informatics crowd and the Internet crowd.

Certainly, I believe that a single standard with templates or subsets for a particular purpose would reduce costs and ease the vendor burden of having to support multiple standards, but the trick to accomplishing this is to ensure that the standard be simple enough to be easily implementable for "the little guy", the iPhone, and the use cases of EHR to PHR exchange where the goal is to provide basic summaries to patients. As I said in my blog last week, I'm convinced that the SDOs will continue to refine their content standards such as CDA and CCD to clean up the XML (get rid of moodCode) and provide templates to support a range of applications, both complex and simple (hide the OIDs so that most implementers do not need to deal with them).

Until then, we need a glide path that embraces the healthcare informatics crowd and the internet crowd, respecting the hard work and best thinking of both.

My proposal, as a private citizen and not in any of my committee roles is that we take the advice of Jim Collins in Built to Last in which he describes the "the tyranny of the OR verses the genius of the AND"

For provider to provider communication which requires the exchange of documents with non-repudiation as the medico-legal record for direct clinical care, we use the CDA/CCD.

For a summary record that represents a snapshot in time of problems, medications, and labs for transmission between EHRs and PHRs such as would be used by Microsoft, Google or Keas, the CCR or PDF is good enough.

We separate content and transport, recognizing that some organizations will use XDS.b and XDR for SOAP-based transport, while others will use RESTful approaches, enforcing privacy policy with security features at the application level.

As standards evolve we can revisit this with the aim of convergence as long as further parsimony does not impede innovation.

It is my hope, that by embracing the right tool for the right purpose, we can balance standardization, ease of implementation, and innovation.

The genius of the AND - I hope that both the healthcare informatics crowd and the Internet crowd can embrace this path forward.

Certification Verses Meaningful Use

Recently, clinicians have asked me "why should I implement my organization's preferred EHR when I've found a less expensive vendor that promises meaningful use?"

This illustrates a basic misunderstanding of the difference between Certification and Meaningful Use.

The certification process will be codified in a December 2009 Notice of Proposed Rulekmaking (NPRM) and will define the process for certifying electronic health records including modular and open source approaches. (The Standards for data exchange will be codified in a December 2009 Interim Final Rule and become law immediately.) We know that ONC will specify certification criteria and that NIST will oversee certification conformance testing which will be performed by multiple organizations. However, we will not have the final certification criteria or the defined process until Spring after a period of comment on the NPRM.

Meaningful Use is about electronic documentation to enhance quality/efficiency and actual data exchange among payers, providers and patients. The definition of meaningful use will be codified in a December 2009 Notice of Proposed Rulemaking. We will not have the final meaningful use criteria until Spring after a period of comment on the NPRM.

Thus, it is too early for any software company to declare their product will meet all Certification criteria. In the interim, a vendor can claim product conformance with the latest CCHIT criteria, which is the best indicator of functionality we have at the moment.

Meaningful Use is not about products but about processes - how the software is used and how data flows in an ecosystem of stakeholders. Vendors should not be making claims about meaningful use.

Take a look at the data exchanges in the August 2009 recommendations for meaningful use:

ePrescribing

Sending reminders to patients

Checking insurance eligibility

Submitting claims

Providing patients with an electronic copy of their record

Providing patients electronic access to their records

Capability to exchange key clinical information (e.g., problem list, medication list, allergies, test results) among care providers and patient authorized entities

Capability to submit data to immunization registries

Capability to provide syndromic surveillance data to public health agencies

To achieve these 9 data exchanges, multiple sending and receiving parties need to participate.

In the case of Beth Israel Deaconess, achieving this level of interoperability by 2011 will require that we focus on a small number of software vendors. Over time, as standards and implementation guides become more specific and widely implemented, it will be easier to add additional vendors. However for now, we are focusing on getting the work done with our home built EHR and one purchased EHR (eClinicalWorks). Given scope, time, and resources, there is no way we can implement all 9 data exchanges among payers, providers and patients with another purchased EHR in time for Stimulus funding.

Thus, as you make decisions about what EHR to use, remember that certification describes the features of a product. Meaningful use describes actual data capture and exchange among multiple stakeholders in an entire healthcare ecosystem.

Products may be certified in a single clinician office, but meaningful use "takes a village". It cannot be promised by a vendor.

Cool Technology of the Week

On November 4, I met with my director of IS at Needham hospital and we discussed the effort involved in creating a lab ordering/resulting dictionary that links together clinician offices, Meditech sites, and commercial labs. Imagine a spreadsheet with 3 columns of lab codes that is 12000 lines long!

Clem McDonald, who oversees the Lister Hill National Center for Biomedical Communications at NLM and is the developer of Logical Observation Identifiers, Names, Codes (LOINC). Using data from several sources, including the Indiana HIE, United Healthcare and a few other sources, Clem and his team were able to identify a set of about 300 LOINC order codes that cover about 98 - 99% of the most common laboratory orders.

On November 2, several members of the HITSP Care Management and Health Records TC met at the National Library of Medicine to discuss the development of a value set for creating an common interoperable set of laboratory order codes. Present at this meeting was an unprecedented collaboration of people representing healthcare providers, laboratory vendors, HIT Vendors, HIE developers and payers.

You'll find the details in Keith Boone's blog.

When I described the notion of a single lab compendium for the country, eliminating the need for custom mappings at every institution and clinician's office, my Director of IS agreed - that's cool!

Let's hope we can get rapid adoption of a universal lab ordering compendium in labs, hospitals, and clinician offices. Time and money will be saved, quality and safety will improve.

The H1N1 and Seasonal Flu Vaccines

On Monday, I received the 2009 Live Attenuated Intranasal (LAIV) H1N1 vaccine and the 2009 injectable seasonal flu vaccine.

As a healthy clinician under 50 who sees pediatric patients (mushroom and plant toxicology cases), I'm in the initial tier who qualify to receive the intranasal H1N1 live attenuated vaccine.

The experience of intranasal administration is interesting - inhaling an aerosolized liquid that slowly drips from your nasopharynx down your throat is not the most pleasant sensation. I suspect that pediatric patients will prefer the intranasal approach to an injection.

For 12 hours after receiving the vaccine, I experienced slight nasal congestion and mild fatigue. The complete fact sheet about risks and side effects is given to every patient.

During the same visit I received the 2009 Seasonal flu injection, an inactivated (killed virus) vaccine. Other than mild soreness at the injection site, I had no symptoms.

For me, the vaccines were a positive experience and will ensure that I am not a viral vector (call it personal anti-virus software) in the season ahead.

Since vaccine supplies are limited, it is important to understand the epidemiology of H1N1 (rates of reported cases per 100,000 population)

0 to 4 years — 22.9
5 to 24 years — 26.7
25 to 49 years — 6.97
50 to 64 years — 3.9
≥65 years — 1.3

You'll find a great UptoDate summary online.

Also, Harvard Health Publications has launched an iPhone App to provided the latest information about H1N1.

Standards Lessons from the Web

Following last week's HIT Standards Committee Implementation Workgroup Hearing , Microsoft's Sean Nolan and Gartner's Wes Rishel wrote thoughtful blogs.

They point out that the web has two basic standards - content (HTML) and transport (HTTP). Of course there are several other supporting standards such as DNS, TLS/SSL, URL syntax, CSS, etc. but to get started all you need is basic content and transport. You can learn everything you need to know to create a web page in under an hour.

At the hearings, I got that sense that much of the content we've (HITSP, HIT Standards Committee, the industry in general) proposed for healthcare such as NCPDP Script for eRx, HL7 2.x for lab, and X12 for administrative transactions is fine. There is some debate about the right level of simplification for a clinical summary standard, but I'm convinced that the SDOs will continue to refine clinical summaries in a way that ensures suitable content packages will be available for simple and complex use cases. There is additional vocabulary work to do, but that is already is in progress.

On the transport side, let's explore the options:

1. Do nothing and let the market develop a transport mechanism - after all that is what happened with HIPAA (it specified the content as X12 4010 and left implementation of transport up to the market)

I do not favor this option. In Massachusetts, NEHEN implemented secure appliances to solve the problem of data transport. We spent millions and took years to do this. HIPAA transactions are not as widely implemented as the industry would like, largely because transport standards were missing and implementation guidance for the content was not detailed enough. Of course, you could force everyone to sign up for the clearinghouse/intermediary of their choice but this creates heterogeneity, click fees, and unnecessary middlemen.

2. Specify all the standards and policies necessary for end to end secure transport.

Thus far, we've stayed architecturally neutral and provided a suite of standards for transport that ensure authentication, authorization, role-based access control, and auditing to support all policy variations. This approach has been a fine starting point, but it needs to be refined via policy so the number of standards can be constrained. For example, a policy which states that audit trails must be available showing who looked at what when is probably sufficient instead of requiring every organization to implement a standards-based audit trail. It's unclear what the business case is for a completely standardized, interoperable audit trail. Another example - If policy requires segmentation of the record into standard care, HIV care, mental health care, and substance abuse care, as well as requires that the application enables patients to record their preferences for release of these 4 segments, do we need access control standards or accept that the application adequately protects privacy?

If policies and certification ensure appropriate application behavior then point to point transport might be as simple as TLS with bilateral certificate exchange at the infrastructure level, substantially reducing the burden of implementation.

Of course, some may argue that an approach that uses simple web standards for securing transmission and leaves other privacy controls to the application cannot ensure "chain of trust" end to end security. It is true that each organization and stakeholder would have to decide if they trust the applications used by their trading partners. Our experience with NEHEN is that policy, data use and reciprocal support agreements (DURSA), and simple transport standards can facilitate rapid implementation of healthcare information exchange.

3. Deploy appliances that serve as secure gateways between organizations.

With policies and over the wire security standards, the market can develop appliances that securely transport packages of content. Some may be SOAP-based using CAQH Core or XDS/XDR and some may be REST-based. The folks at FHA Connect have done a great job creating an open source application that can serve as such an appliance.

One thing I've learned from negotiation (my Walks in the Woods) is that being dogmatic about one solution is rarely the right answer. Folks who know me often hear the word "parsimonious" - the smallest number of solutions needed to meet the needs of stakeholders. The answer is not 100 variations but a small number that provides business value - the right tool for the right job. From the work I've seen thus far, I think the transport solutions that will work for stakeholders include:

1. For those who want end to end standards controlled secure transport that guarantees integrity of documents - XDS, XDR, XDM and XCA fulfill the need. These standards are SOAP-based and enable use of WS* security controls, so they are useful for protecting privacy at the standards level.

2. For those who want standards-based security with simple implementation, an appliance such as FHA Connect, NEHEN, Intersystems' Ensemble, or Orion Health's Rhapsody is a very reasonable approach.

3. For those who want a secure channel for transporting data elements such as a problem lists, medication lists, and labs from EHR to PHR, a simple TLS and REST approach is good enough. Ideally, HITSP and the HIT Standards Committee workgroups will provide an implementation guide with standard URIs/querystrings so that we'll not have huge variation in REST APIs. Some have used the term "Healthcare Internet" to describe such an approach.

I look forward to the work of the next several months. I'm confident that HITSP, the HIT Standards Committee Workgroups, and the new HIT Policy Committee NHIN Workgroup will evaluate the options and make recommendations.

The FY10 BIDMC IS Operating Plan

I've previously posted the Draft Clinical Systems Operating Plan for BIDMC Information Systems.

Today, I've posted the entire FY10 BIDMC IS Operating plan for infrastructure, clinical systems, financial systems, HIM, knowledge services, media services, academic computing, and our community sites.

Highlights include:

Numerous infrastructure upgrades to networking, storage, and security

Meaningful Use of EHRs for inpatient and outpatient clinical care

Upgraded supply chain, revenue cycle, and payroll functionality to support enhanced workflow and efficiency

Continued migration from a hybrid paper/electronic record to fully electronic

Enhancement to consent management education, plain language educational resources, and on- line knowledgebases

Expanded telemedicine and collaboration tools

Advanced research administration support tools.

Meditech upgrades including CPOE, eMAR, and interfaces.

The task of building better applications and more reliable infrastructure is never done, but each year we get better and better. Setting priorities that balance available resources, quality and safety is the challenge. I hope our customers and employees agree that we've set a reasonable balance.

Next Steps for our Community Quality Registry

I've previously described the Beth Israel Deaconess Physician Organization's (BIDPO) decision to create a community registry for quality data warehousing in support of meaningful use.

As the project has progressed, we've made several decisions that I'd like to share.

What quality indicators will we store?

We've inventoried all the pay for performance reporting requirements of our local payers and crosswalked it with the 17 quality metrics required for meaningful use, as documented on the new HHS Blog.

In summary, the measures will include treatment process and outcomes data for:

Acute Bronchitis

Adverse drug events

Asthma

Cancer Screening

Cardiovascular Conditions

Depression

Diabetes

HIV

Hypertension

Immunizations

Lead Screening

Medical Home

Pediatrics

Pharyngitis

Reproductive Health

Substance Abuse

Surgery Patients

Tobacco

URI

Vital Signs

You'll find the details in this presentation.

Other decisions we've made include:

1. All our data content transfers from eClinicalWorks and our home built EHR will be done using the HITSP C32 implementation guide of CCD.

2. Transport will be done using the HITSP Service Collaboration 112, specifically using TLS with certificate exchange. We will use the NEHEN network (diagramed above) for routing from our EHR hosting site to the quality data center.

3. To protect confidentiality we will pseudonymise the data, separating identifiers from the data itself. BIDPO will be able to re-identify data for queries such as assembling quality measures from different data sources, but a breach of the registry itself will not release any patient identified information.

This project will enable us to implement and refine many of the standards recommended by HITSP and the HIT Standards Committee. I will continue to report experiences from our implementation efforts which I hope will be used to enhance the standards implementation guides.