Over the past 5 years, I've worked with many talented standards developers, implementation guide writers, and software vendor engineers. We've crafted use cases, selected standards, harmonized gaps/redundancies and written interoperability specifications.
I'm very happy with our achievements in content and vocabulary standards. We have excellent momentum and accelerating adoption.
Transmission is still an area requiring work. FHA Connect is a good start, but is challenging for small providers who have different use cases - the push of healthcare data from provider to provider, provider to payer, and provider to public health in support of Meaningful Use. Interoperability specifications and profiles for transmission have been written using combinations of existing standards from many SDOs. The resulting documents are not simple for smaller organizations with limited resources to use.
When I ask about creating simpler approaches, I'm told that these guides were the best that could be done to address the use cases with existing standards.
Here's a very controversial point - what if the standards we are starting with as we write interoperability specifications and profiles are not appropriate for creating simple, easy to use, internet-based data exchange that works for small organizations with limited resources?
The answer - we need a new, simpler approach that leverages REST, simple SOAP, and SMTP for data exchange. I believe NHIN Direct is that approach.
Here's a few highlights from the NHIN Direct FAQ page
What is NHIN Direct?
NHIN Direct is the set of standards, policies and services that enable simple, secure transport of health information between authorized care providers. NHIN Direct enables standards-based health information exchange in support of core Stage 1 Meaningful Use measures, including communication of summary care records, referrals, discharge summaries and other clinical documents in support of continuity of care and medication reconciliation, and communication of laboratory results to providers.
Why NHIN Direct?
There is a need to extend the NHIN to support a broader set of participants and providers through a simple, standards-based, widely deployed and well-supported method for providers to securely transport health information using the Internet in support of the core Meaningful Use outcomes and measures.
What is the relationship between NHIN Direct and the currently described NHIN Architecture?
The currently described NHIN Architecture describes a method for universal patient lookup and document discovery and exchange between National Health Information Organizations, including Federal providers such as the Veterans Health Administration, Department of Defense Military Health System, RHIOs, and large IDNs. NHIN Direct supports cases of pushed communication between providers, hospitals, laboratories, and other health settings of care.
The current members of the NHIN Collaborative will be able to support the NHIN Direct model, and providers and enabling organizations for NHIN Direct will scale to support to support the discovery and exchange use cases. Both models are required and will be in use at the same time for the same participants, depending on the information exchange needs.
Does NHIN Direct replace the current NHIN model? Or is NHIN Direct the current NHIN model on “training wheels”?
No. NHIN Direct and the current NHIN model support different use cases and are coequal in a system of robust nationwide health information exchange.
How will the specifications and standards for NHIN Direct be developed?
The specifications and standards will be developed in a rapid, open process intended to draw from a varied set of stakeholders representing both public and private providers and technology enablers.
What NHIN Direct doesn’t solve
In order to create rapid innovation, we are deliberately constraining the scope of NHIN Direct to a spare set of specifications and standards that solve a well-defined pain point. Unless a particular capability is essential to support the core use cases, we will leave it out or defer it to a later day. In doing so, we do not intent to devalue any particular health information exchange area or need, but merely to define a scope that both advances the state of nationwide health information exchange and is achievable in the short term.
How can I or my organization participate?
There are three basic ways to participate
1. A core group of NHIN Direct stakeholders will come together frequently from March through the end of the year to develop iteratively the core enabling specifications and service descriptions, and test those specifications with working code in both demonstration and real-world implementation contexts. To enable close collaboration, the core group is expected to include 5-8 stakeholders who commit to active participation, code development and contribution, and, most importantly, to implement the resulting specifications and services in a real-world setting that demonstrates the core use cases.
2. The NHIN Direct work will be conducted in an open manner, with ample opportunities for participation. We welcome comment and feedback, working code, code contribution to the open source reference implementation, and implementations of the specifications in different technologies.
3. Technology enablers may passively participate in the standards development work, by monitoring the work and resulting specifications, implementation guides and reference technology implementations, and then actively participate in late 2010 and in 2011 by building the core NHIN Direct services into EHRs, HIEs, and other healthcare technology implementations.
The NHIN Direct effort philosophy is expressed in design rules
The golden standards rule of "rough consensus, working code" will be applied to this effort.
Discuss disagreements in terms of goals and outcomes, not in terms of specific technical implementations.
The NHIN Direct project will adhere to the following design principles agreed to by the HIT Standards Committee from the feedback provided to the Implementation Workgroup
Keep it simple; think big, but start small; recommend standards as minimal as possible to support the business goal and then build as you go.
Don’t let “perfect” be the enemy of “good enough”; go for the 80% that everyone can agree on; get everyone to send the basics (medications, problem list, allergies, labs) before focusing on the more obscure.
Keep the implementation cost as low as possible; eliminate any royalties or other expenses associated with the use of standards.
Design for the little guy so that all participants can adopt the standard and not just the best resourced.
Do not try to create a one size fits all standard, it will be too heavy for the simple use cases.
Separate content standards from transmission standards; i.e., if CCD is the html, what is the https?
Create publicly available controlled vocabularies & code sets that are easily accessible / downloadable
Leverage the web for transport whenever possible to decrease complexity & the implementers’ learning curve (“health internet”).
Create Implementation Guides that are human readable, have working examples, and include testing tools.
I look forward to the efforts of NHIN Direct. As always with emerging technologies, I'm eager to be an early adopter, beta tester, and active contributor.
8 comments:
John - thanks for your ongoing dialog.
Briefly as we jump into NHIN direct or exchanges, we are finding a great deal of immaturity with interoperability vendors and EMR's. One poignant example is our current document exchange turns richly formatted documents into jumbled ascii text. The reason for this is that we must build our interfaces to the lowest common denominator in the information chain. We cannot assure that the downstream user can view an XML tagged document. Therefore, for the next year or more we will transfer summary documents using an ASCII. Without an interim achievable format we may undermine the readability of important handoff information and diminish physician enthusiasm for HIE. NHIN direct sounds like a much needed interim model but the documents need to appear better than a fax machine to the end user!
How can we encourage high quality exchange and usability of these documents while we wait for compatibility with the ultimate CDA/XML standard? Do we say the low bar is RTF, ODF, HTML, PDF, something else? Anyone know if there is a common denominator among the leading EMR vendors? I don’t think PDF is usable by most EMR’s. Alternatively, do we need to package more than one document type in the NHIN direct message until we get to XML/CDA standard across the board?
I am thinking NHIN Direct should specify a lowest common denominator for document formatting that is reachable by all EMR vendors in by phase 1. This will go a long way to improving handoffs and increasing physician acceptance of document exchanges. “better than a fax machine.”
J Mike Kramer - CMIO Trinity Health
I am an HIE novice - non-development resource - for an ambulatory EHR company. While we serve over 40 medical specialties, 68% of our clients are primary care, and 75% of those are in practices of 10 or less. We also serve about 10% of the U.S. community health center market.
I follow your blog religiously for educational purposes and particularly appreciate the NHIN Direct philosophy articulated herein. Yesterday, I attended a "all stakeholders" meeting for statewide HIE in the south. The excitement was tremendous. The scope - all things to all people - was overwhelming. They would benefit from a read of this blog.
As an EHR vendor, our simpliest development tasks will likely be the workflow engine (managing the message - when is the info. available and where does it come up for the provider), construct (we already do C32 messaging and are stepping into XDS)and transport (pretty much a non-issue). Our biggest development challenge will be in the bi-directional translation component, namely because of the multitude of vocabularies.
We are engaged in the NHIN University, with development staff. I agree with Dr. Kramer - and you. Let us start simple and evolve from there.
Thank you for your blogs!
Adele Allison - National Director of Government Affairs, EHS, Inc.
John, Here's a perspective from the other side of the ocean! It's 5 years since I have known about NHIN. I agree with you about establishing a simple and common set of standards which can be rolled out at the base of the healthcare pyramid.
Actually NHIN should be divided into 3 levels, Basic, Intermediate and Advanced. With NHIN-Basic the stress should be to cover more than 90% of the base.
If the small healthcare providers find it easier to be part of the Network which is the toughest part of the implementation, it would be half the job done for NHIN to be a success story. Just some thoughts away from the battleground as an observer :-)
So glad to see NHIN Direct getting momentum - I'm hoping our SpeakFlower project (http://www.speakflower.org) can perhaps lend some more momentum to the effort. I'm still not sure exactly which technical lingua-franca is best to handle this, but if NHIN Direct has a clear answer, then it makes sense to endorse their standard. (If they don't have a clear answer, then I agree with the ASCII approach - Heck, uuencode could handle all other document types, and then we deconstruct at the local level.)
Anyway, thanks for the post!
Hi John,
Not much seems to be defined yet, but NHIN Direct looks very similar (almost identical) to prior work done in AHIC, HL7, IHE, and HITSP.
For example, the use case "A hospital wants to send discharge information back to the referring provider on patient discharge" was defined several years ago.
IHE and HITSP have profiled this use case for both content and transport.
The listed content types can be either HITSP C32(CCD structured document), or IHE XDS-MS (discharge summary as CDA with corresponding level 3 encodings), or HITSP C62 (unstructured documents such as PDF or text)
The exchange mechanism described - secure email - is covered by HITSP T31 (IHE XDR).
Will NHIN Direct reuse and build apon and reuse this prior work, or try to create something new? If something is wrong, incompletely described, or needs simplification/clarification, I would prefer an approach to correct those original profiles (i.e., submit change proposals) rather than creating new ones.
I think the market is getting confusing signals with a new group forming every couple years to define new and slightly different solutions to the same problems (reinventing the wheel) . Rather, we should put our efforts into simplifying existing layered implementation guidance into singular documentation directly on top of the standards referenced, as you have wisely proposed yourself. If further simplification of the underlying standards is necessary, while still meeting the increasingly complex interactions across the continuum of care settings, let's address that separately.
John,
Thanks for your call for a new, simpler approach that leverages REST, simple SOAP, and SMTP for data exchange. Regarding NHIN Direct, would it not make sense to adopt W3C Linked Data standards, whereby data properties, as well as individual products, are assigned URI's to promote use of common HL7 taxonomies?
http://sciencecommons.org/projects/data/background-briefing/
-Steve-
http://web.mit.edu/s_miles/www/
Note that virtually every comment on this blog entry would be great input over on NHINdirect.org. I'd like to encourage folks to post their perspectives and thoughts on the NHIN Direct discussion group or wiki.
Personally, my perspective has been broadened based on interactions on NHINdirect.org, but more participation and ideas from a wider set of perspectives would be wonderful.
Brett
Questions
1.Is Direct project –“Over the internet” or “Over the Internet but Nationwide only”
Does that mean it is not geographically confined within US?
2. Can healthcare providers viz physicians and small hospitals in Asia participate in Direct Project.
3. Any URL for better understanding on this concept.?
Post a Comment