Tuesday, November 30, 2010

The November HIT Standards Committee meeting

The November HIT Standards Committee meeting focused on existing implementations of point to point transport standards as a foundation for its evaluation of the Direct project.

We began the meeting with a report from the Implementation Workgroup, which will gather testimony on January 10-11, 2011 about the experience of implementing standards in certified systems and achieving meaningful use goals.

We discussed the work of the other HIT Standards Committee workgroups including the upcoming effort by the Vocabulary Task Force to take testimony on device content and vocabulary standards.   Given the evolving importance of home care devices, implantable devices, and mHealth, ensuring robust standards in this area is important.

We started the day's testimony noting that we will be discussing just point to point "push" use cases this month.   Typical components of such an approach are a routing method, a provider directory, certificate management, auditing, and acknowledgement of delivery.   Use cases covered by the "push" approach include PCP to specialist referrals, routing to registries, e-prescribing data exchanges between providers/pharmacies, and sending summaries to patients.

Here are links to the testimony:

Peter Tippett, Verizon

John Feikema, Visionshare

Joseph Carlson, Covisint

Anand Shroff, Axolotl

Cris Ross, Surescripts 

Eric Dishman & Gary Binder, Intel

After the testimony we summarized the major themes.

Directories -  Proposed directory options ranged from a nationally centralized yellow pages of organizations to a federated white pages of persons/departments/machines to undiscoverable local directories.  Email is an example of a directory which is generally undiscoverable outside an organization.   Once you know the email address of a person, email gateways route from organization to organization.   Once email arrives at the organization, it is routed to the recipient using a local directory.   Whatever directory and addressing scheme is chosen, it is very important that all vendors support it to achieve a network of networks that enables any provider to connect to any other provider.

Identity/Trust - Each of the vendors is using X.509 certificate-based approaches to secure organization to organization transport plus a formal certificate management approach (based on policy) to verifying identity and achieving a trust fabric.   Creating a chain of trust among vendors is very important to supporting network to network transport.

Transport - SMTP/SMIME, REST, and SOAP have all been used successfully in the real world as transport standards for health information exchange.  Achieving common directories and a trust fabric are more important than settling on a single transport protocol.  However, in the interest of keeping the architecture simple, there should be few, not many standards options for transport.  Having at least one common transport approach to enable universal addressing is desirable.

The internet itself is based on a small number of standards specifying directories such as the Domain Naming System (DNS) system, which is implemented in a federated architecture.   The internet has a small set of standards enabling certificate authorities to act as "electronic notaries", establishing identity and trust.   On top of this foundation of directories and trust, there are multiple transport protocols that used to support specific use cases such as HTTPS, FTP, SMTP, etc.    Push-based healthcare information exchange should use an analogous approach - get the directory/addressing and identify/trust right, then use the transport standards that best support workflow and are easy to implement.

Our next steps are to get policy guidance from the HIT Policy Committee Provider Directory Workgroup, review the Implementation guides from the testifying vendors who have successfully implemented a trust fabric, and assemble a multi-stakeholder team of interested participants from the HIT Standards Committee to evaluate NHIN Direct.   We'll use objective criteria, informed by today's testimony to consider NHIN Direct on its own merits, evaluating its implementation specifications against the project goals to be simple, direct, scalable, and secure transport for the little guy.

3 comments:

Keith W. Boone said...

John,

When is the committee going to evaluate use cases that require more than push (e.g., access to a longitudinal record)?

David said...

John,
Thanks as always for your summary. Re the simple "push" case, is a provider directory really a "typical" component of that use case? I saw very little mention of directories in the testimony except for SureScripts' physician and pharmacy directory. As you stated during the meeting, you can't look up another person's e-mail address in a directory either. E-mail clients and FAX machines can store contacts, but that's not really a "directory." A Provider Directory would be helpful, but I think that push to known recipients can be done without it. When the recipients are "unknown" (or not well enough known for you to know their address) then the directory would be more of a requirement than a "nice to have" feature. Keeping the Implementation WG's advice of "not letting the perfect be the enemy of the good" wouldn't that put a Provider Directory into more of an optional feature, rather than up there with the essentials such as encryption and identity assurance?
Thanks,
David

DBBaker said...

Nice summary, John. Principal take-away: "Achieving common directories and a trust fabric are more important than settling on a single transport protocol." Specific to the HIT Standards Committee, the testimony made clear the need for policy and standards around the issuance, management, use, and revocation of X.509 certificates for people, organizations, and software entities. The Privacy and Security Tiger Team has recommended the development of a standard for "organizational" certificates, which are the entitites involved in Stage 1 "meaningful use." But it's clear that certificates for individuals and software also need to be addressed in the relatively near term.