The December HIT Standards Committee

The December HIT Standards Committee focused on a review of the President's Council of Advisors on Science and Technology (PCAST) report, a review of the Standards and Interoperability Framework Priorities, and a review of NHIN Direct (now called the Direct Project).

We began the meeting with an introduction from Dr. Perlin in which he noted that reports by commissions such as PCAST need to be read, not for their details, but for their directionality.  We should ask about the trajectory the experts think we should be on and how/when should it modify our current course.   Dr. Blumenthal also offered an introduction to the PCAST discussion, noting that the White House fully supports and encourages interoperability, suggesting that we should accelerate the priority of healthcare information exchange in the progression from Meaningful Use stage 1 to 3.

We discussed the origins and history of the PCAST report.  The President asked PCAST how health IT could improve the quality of healthcare and reduce its cost, and whether existing Federal efforts in health IT are optimized for these goals. In response, PCAST formed a working group consisting of PCAST members and advisors in both healthcare and information technology.

The working group held meetings in Washington, D.C., on December 18, 2009, and in Irvine, California, on January 14 15, 2010, as well as additional meetings by teleconference. The viewpoints of researchers, policy analysts, and administrators from government, healthcare organizations, and universities were presented and discussed.

A draft report developed by the working group was submitted to the Health and Life Sciences committee of PCAST. That committee submitted the draft to several outside reviewers, who made valuable suggestions for improvements.  From the working group draft, the additional input, and its own discussions, the Health and Life Sciences committee produced the present report, which was discussed and endorsed (with some modifications) by the full PCAST in public session on July 16, 2010.

A disclaimer at beginning of report notes "Working Group members participated in the preparation of an initial draft of this report. They are not responsible for, nor necessarily endorse, the final version of this report as modified and approved by PCAST."

We identified a number of key themes in the report
1.  The foundation for healthcare information exchange should be built on an XML-based Universal Exchange Language
2.  Data elements should be separable from documents
3.  Metadata should identify characteristics of each data element i.e. how it was recorded, by whom and for what patient
4.  Privacy controls should integrate patient consent preferences with metadata about the data available for exchange
5.  Search engine technology/data element access service indexing at a national level will accelerate data element discovery
6.  Data reuse with patient consent for clinical trials and population health is a priority

The key ideas from the discussion included:
a.  Thinking at a national scale is good to avoid creating regional health information exchange silos
b.  Messaging (such as HL7 2.x)  is still going to be needed to support event-based transactional workflows
c.  The strength of the PCAST report is in supporting exchange models that require aggregation - research, epidemiology, and unanticipated interactions such as Emergency Department visits.
d.  For some uses such as communication among providers, encounter summaries which provide structured and unstructured data in context, are more useful than data elements
e.  Many data elements are not useful on their own and a module/collection of data elements would be better i.e. Allergies should include the substance, onset date, the type of reaction, the severity of the reaction, and the level of certainty of the reaction (your mother reported it based on a distant memory verses a clinician observed it happening).   To understand how best to collect data elements into modules, clinical data models would be very helpful.
f.  Since information is going to exchanged among multiple parties, metadata will need to include the provenance of the data, so that data is not duplicated multiple times i.e.  Hospital A sends data to Hospital B and C.    C requests a copy of B's data (which includes B and A) and it should be possible to avoid storing a duplicate of A's data which C already has.
f.  We should proceed with the health information exchange work already in progress to achieve interoperability in support of Meaningful Use stage 1 and not derail current efforts.
g.  Finely grained privacy (to the data element level) will be challenging to implement and maintain.  Tagging elements with privacy characteristics is very hard because societal attitudes about the sensitivity of data elements may change over time.  HIV testing used to be a rare event, so the presence of an HIV test alone (not its result) could be concerning.   Today  1/3 of Americans have had an HIV test, generally as part of getting life or health insurance, so the presence of a test is no longer a stigma.
h.  The national scope suggested includes using web search engine technology to keep a data element index, identifying what data is available for what patients and where.   The policy and security issues of doing this are greater than the technology challenges.

The next step for the PCAST report will be ONC's naming of a multi-stakeholder workgroup to review the report in detail and make recommendations by April.

We next heard about the planned Implementation Workgroup hearing regarding certification, Meaningful Use, and healthcare information exchange.  On January 10-11, the Workgroup will learn about early adopter successes and challenges.

Next, the Clinical Operations Workgroup reported on its plans to consider vocabulary and content issues for devices - critical care, implantable, and home care.   Issues include universal device identification, ensuring data integrity, and interoperability of devices that may require a clinical data model to ensure the meaning of data communicated is understood by EHRs, PHRs, and devices.

We next considered the standards and interoperability framework priorities as outlined by Doug Fridsma.   The S&I Framework contractors are working on clinical summaries,  templates documents, Laboratory results, Medication Reconciliation, Provider  Directories, Syndromic Surveillance, Quality, Population Health, Clinical Decision Support, Patient Engagement, EHR to EHR data exchange, and Value Sets.

Points raised during this discussion included the need to include policy discussions throughout the process of harmonizing and testing standards.    We agreed that the Clinical Operations workgroup should study these priorities and make recommendations based on real world implementation experience that will help ONC and the contractors focus on the gaps to be addressed such as patient identification and vocabularies/codes sets.

We discussed the HIT Policy Committee's request for the Standards Committee to work on Certificate Management standards.  The Privacy and Security Workgroup will make recommendations for organization to organization and server to server certificate standards.

We next considered the Privacy and Security Workgroup's evaluation of NHIN Direct.  The Workgroup concluded that certificate exchange should not be limited to certificates stored in Domain Naming Services (DNS) applications.  It also suggested that XDR (a SOAP transaction) be removed from the NHIN Direct Core specification, reducing the complexity and optionality of the specification.    The only debate that arose during this discussion revolved around the issue of rejecting an NHIN Direct message because it did not meet regulatory requirements.  Specifically, the Privacy and Security Workgroup recommended the following language -

"Destinations MAY reject content that does not meet Destination expectations. For instance, some Destinations MAY require receipt of structured data, MAY support only particular content types, and MAY require receipt of XDM structured attachments."

Here's a use case that illustrates the issue:

Federal Regulations require quality measures to be sent in PQRI XML as of 2012.

A doctor uses NHIN Direct to send an unstructured text message to CMS "I achieved the quality measures you wanted me to!"

What should CMS do?
1.  Reject the message as not compliant with Federal regulations, notifying the sender as to the reason
2.  Accept the message, but contact the sender out of band to specify the requirements
3.  Accept the message, but later send a functional acknowledgement via NHIN Direct that the contents of the message did not qualify for meaningful use reporting requirements
etc.

In an email dialog following the HIT Standards Committee, many members agreed tat that the message should be rejected with an error message that the contents of the message did not meet regulatory requirements.

At the meeting, we agreed that decisions to reject or accept messages are a matter of policy and that the HIT Standards Committee should only recommend technology that enables messages to be sent securely and error messages to be provided to the message sender if policy requirements are not met.

A great meeting with significant progress on the PCAST review, S&I Framework review, and  the NHIN Direct review.

Next month, we'll hear more about certificates, provider directories, and PCAST.  It's clear that the work of the Policy Committee on Certificates and Provider Directories, the work of NHIN Direct, and the work of HIT Standards Committee are converging such that we will soon have a unified approach to transport that will rapidly accelerate transmission of the standardized content and vocabularies already required by Meaningful Use.

Cool Technology of the Week

In my continuing series on living green and low impact, this week's post is not really about a technology, but about a concept - living small in a house on wheels.

Call this the anti-McMansion, the opposite of living large.

These small houses require innovative use of construction materials, architecture, and three dimensional thinking.   Because of their on wheels construction, they bypass many zoning and permitting restrictions.

Their cost is low, their use of resources modest, and their footprint on real estate and the planet is small.

A home built with advanced materials that includes a kitchen, great room, bathroom/shower, and bedroom - all under 100 square feet.    That's cool.

One other cool item to share this week - a great YouTube Video on healthcare data visualization.

Living the Good Life

Last Friday, my daughter was admitted early decision to Tufts University, so the anxiety of the college application process is passed.  One of her essays asked her to describe the environment in which she was raised and how it influenced the person she is today. It's worth sharing her observations on what constitute living the good life:

"At this moment, from a room of windows, I can see tall pine trees framing a beautiful, soft green yard. A little vegetable garden lies to my right, with lettuce enduring the brisk autumn wind. Above it stands a lone maple gradually turning brilliant shades of fire. A heavenly light illuminates the clouds passing overhead in the vast baby blue sky. The wisteria climbs the windows to my left, waiting for a warm spring to show its beautiful lavender flowers. The wind passes through the wooden chimes hanging from our crabapple tree, initiating a clonking chorus. Bamboo lines the white rock river with a little wooden bridge. A stone bench rests near the fence, where my father sits and plays his Shakuhachi (traditional Japanese flute). Cardinals, sparrows, and grackles fly overhead, seeking food, warmth, and family. As I open a window, a rush of sweet, crisp autumn cold fills my senses, making me shiver. These wonders surrounding me in such a welcoming, beautiful, and inspiring home and community fostered an appreciation for the subtle things in life. I learned to openly embrace the world around me, understanding and loving its everlasting beauty. Nature is a teacher and a gift, one never to be overlooked. I’ve grown as a student, an observer, an appreciator, and a believer in the magic and beauty of the world."

As a parent, I want my daughter to feel good about herself.     In her essay, she highlighted the simple things that bring richness to her life  - a vegetable garden, autumn colors, and a supportive community of family and friends.

I can understand her point of view.

As I write this, I'm sitting in an old Morris chair, sipping Gyokuro green tea, breathing in wisps of smoke from Blue kungyokudo incense. Breakfast will be a bowl of steel cut oatmeal with a few drops of Vermont maple, and soy milk.  

The ability to sit quietly and think, enjoy wholesome foods, and enjoy the warmth and comfort of a small home while the weather outside is cold and blustery gives me an overwhelming sense of well being.

I hope my daughter continues to appreciate that the good life comes from the basics of food/clothing/shelter/family/self-worth.

Tufts University is a great fit for her and I'm confident the next four years will polish and amplify the foundation she's already built.    As she creates her own version of the good life, we'll always be available for advice and support, but as of next Summer, she's a fledgling, exploring the world on her own.

What is Our Cloud Strategy?

In a meeting last week with senior management at Harvard Medical School, one of our leaders asked, "What is our cloud strategy?"

My answer to this is simple.   The public cloud (defined as the rapid provisioning and de-provisioning of CPU cycles, software licenses, and storage) is good for many things, such as web hosting or non-critical applications that do not contain patient or confidential information.   At Harvard Medical School and Beth Israel Deaconess Medical Center, we've embraced public cloud technology, but transformed it into something with a guaranteed service level and compliance with Federal/State security regulations  - the private cloud.

Here's the approach we're using to create private clouds at HMS and BIDMC:

1.  At HMS, we created Orchestra, a 6000 core blade-based supercomputer backed by a petabyte of distributed storage.   Thousands of users run millions of jobs.    It's housed in Harvard controlled space, protected by a multi-layered security strategy, and engineered to be highly available.  We also use grid computing technologies to share CPU among multiple high performance computing facilities nationwide.

2.  At BIDMC and its physician organization (BIDPO), we've created a virtualized environment for 150  clinician offices, hosting 20 instances of logically isolated electronic health record applications per physical CPU.   It's backed with half a petabyte of storage in a fault tolerant networking configuration and is housed at a commercial high availability co-location center.

3.  At BIDMC, our clinical systems are run on geographically separated clusters built with high availability blade-based Linux machines backed by thin-provisioned storage pools.

Each of our private clouds has very high bandwidth internet connections with significant throughput (terabytes per day at HMS).   The bandwidth charges of public clouds would be cost prohibitive.

We are investigating the use of public cloud providers to host websites with low volume, low security requirements, and no mission criticality.  Public solutions could be better/faster/cheaper than internal provisioning.

Thus, our cloud strategy is to create private clouds that are more reliable, more secure, and cheaper than public clouds for those applications which require higher levels of availability and privacy.   For those use cases where the public cloud is good enough, we're considering external solutions.

Someday, it may make sense to move more into the public cloud, but for now, we have the best balance of service, security, and price with a largely private cloud approach.

The Beacon Communities

Last week, the Office of the National Coordinator (ONC) launched a new web resource for Beacon communities, which includes summary videos of each community and their key projects.

Beacon is a program to watch, since it represents a set of innovative pilots that are likely to help us determine what IT-enabled interventions really improve quality, safety, and efficiency.    Healthcare reform will require numerous IT innovations to support accountable care organizations, medical homes, and new reimbursement strategies that focus on quality rather than quantity.

Although Massachusetts was not selected as a Beacon Community, here's a link to the Greater Boston submission, to give you a sense of the depth of work Beacon Communities must do.   The work is so important, that our regional, state, and local efforts are likely to move forward with many aspects of the Beacon proposal, using private funding and other available State and Federal funds.

The Standards Work Ahead

In past years, the Office of the National Coordinator (ONC) has been called the Office of No Christmas (ONC) because of the pace of the year-round effort, especially December/January deadlines.     At the October HIT Standards Committee meeting, one public commenter was concerned that the pace of work on standards would slow down over the holidays.   Although it is vitally important that we all take time with our families and that we recharge for the new year ahead, I can assure you that standards efforts are not slowing down!

Here are a few of the issues we are addressing in December and January.

1.  Evaluation of the Direct Project (formerly called NHIN Direct) -   During December, we'll evaluate the Direct Project to determine if it has met its goals of being simple, direct, scalable and secure:

Simple means it is responsive to the Implementation Workgroup's guidelines which include ease of implementation, concern for the "little guy," and recognition of the fact that the development community is broad and diverse.

Direct means the transport of content from a sender to a receiver, with no content-aware intermediary services.

Scalable means the ability to support increasing workload and to adapt to new exchange models.

Secure means minimizing confidentiality, integrity, and availability risk to the content being transported.

2.  Review of the PCAST Report  - although ONC and CMS are likely to create tiger teams of expert members to make recommendations, the HIT Standards  Committee will review the history and intent of report.

3.  Review of the priorities suggested for the first application of new Standards and Interoperability framework.   Take a look at the FACA blog  for details of the projects being considered.

4.   Begin work on the Policy Committee's requests on certificates and directories.   Regarding certificates, the request from the Policy Committee is

"ONC, through the Standards Committee, should select or specify standards for digital certificates (including data fields) in order to promote interoperability among health care organizations"

Although we have not yet received a request to review the HIT Policy Committee's Provider Directory work, it's likely we'll be asked about standards for Entity Level Provider Directories (ELPD) which are a yellow pages for provider organizations and Individual Level Provider Directories (ILPD) which are a white pages for lookup of individuals to identify their organizational affiliations such that the yellow pages can be used for routing.

5.   Begin work on device standards - Our Vocabulary workgroup has a special interest in the content and vocabulary standards that will ensure home care devices (from pedometers, blood pressure cuffs, glucometers, pulse oximeters, etc) can transmit data in an interoperable format to EHRs and PHRs.

At the HIT Standards Committee December 17 meeting (which I'll blog about on Friday instead of a Cool Technology of the Week), you'll hear about our plans for January hearings on early experiences with the implementation of certified EHR technology/meaningful use of those technologies.   You'll hear about our plans to begin hearings on medical device standards including the FDA's work on unique device identification and content/vocabulary standards for home care devices.   We'll discuss the Standards and Interoperability framework priorities.  We'll begin the PCAST review.

As you can see from the five December/January goals above and our December 17 agenda, we're sustaining the momentum!

The Spirit of PCAST

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

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

The major ideas are

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What are the next steps?

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

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