Direct Overview Call for Consensus

Documentation and Testing Workgroup Call for Consensus: NHIN Direct Overview

DUE: 9/8/2010

NHIN Direct specifies a simple, secure, scalable, standards-based way for participants to send encrypted health information directly to known, trusted recipients over the Internet. This document provides a general overview of NHIN Direct: its goals, limitations, use cases, and how it fits into broader exchange standards already in place.

[File:http://www.wikispaces.com/i/mime/32/application/msword.png NHIN_Direct_Overview_ForConsensusFINAL.doc]

NHIN_Direct_Overview_ForConsensusFINAL.doc

• Details
• Download
• 177 KB

You can view a history of this document here.

Company or Individual	Endorsement (Yes or No)	If No, what can be changed to make it Yes?
Workgroup Participants
CareSpark/Serendipity Health	Yes
CSC
Epic	Yes
FEI		Change section 5 to indicate that a NHIN Direct Implementation is a HISP. Proposed wording for section 5: A NHIN Direct Implementation is a HISP. A HISP integrates health records between EHR and email systems. These systems exchange health records with dissimilar messages and transport protocols. An EHR gateway exchanges health records in a XD* message through HTTPS and an email gateway exchanges health records in a XDM message through SMTP. The HISP receives health records -contained in the messages from a source gateway- and forwards it in the messages and transport protocol compatible with the destination gateway.
GE	Yes
Harris Corporation	Yes
HLN Consulting, LLC	Yes, with comments	Document has shaped up nicely. Taking a step back, I still wonder about these three points: 1. Much of local HIE is not done within the context of NHIN at all. If I was in a local HIE this document does not speak to me directly. I am not really exposed to NHIN which is about HIE-to-HIE interoperability, not my local implementation. 2. While we sort of say what a HISP is, an outsider will still wonder, "What is this HISP thing and how do I interact with it, contract with it, or use it?" Today, many people do not think about their ISP; they MAY have to think about their HISP, at least in the short run. 3. We waive a wand at today's email clients being "capable of handling encrypted messages," which they are, but it has never been easy to do. Is NHIN Direct going to make that as effortless as is implied?
IBM		Document is well structured and a good overview level. Just a few comments: 1. Section 2.2 first example #1 and Glossary: The definition of HISP concerns me. The agreed to name was Health Information (NOT Internet) Service Provider, see http://nhindirect.org/NHIN+Direct+Abstract+Model. I disagree with the meaning of this acronym being changed, I'm hoping it was accidental. But I noticed that the glossary and Section 2.2 describe it as "serve a similar purpose as a typical Internet Service Provider that handles e-mail messages today". I think this is misleading and will cause more confusion that not. I agree with another comment that a HISP is not well defined and is unlikely to be as seamless as a typical ISP. A better definition for this key component would be helpful. 2. Section 3: Disagree with the term "universal patient discovery". Change the first bullet to be something like this: NHIN Exchange Specifications support health information exchange across health information organizations (HIOs). A primary aspect of this health information exchange is the ability to identify a common patient even without a common patient identifier and search for and exchange records about patients. This capability goes beyond the “simple, direct, among known participants” scope of NHIN Direct. Exchanges between HIOs {the rest is unchanged} are not limited to “direct” messages or “known participants.” For example, the emergency department that treats a patient who was vacationing did not have a prior relationship with the patient’s providers, and none of the previous providers directed a message to the ED. 3. Glossary: Remove the term "patient discovery" from the glossary. In #2 I recommend adjusting the section that references it and in any case this definition is not accurate if it refers to the NHIn Exchange use of Patient Discovery. 4. I concur with comments from VisionShare # 2, 4, 5, 6. I found these problems also in my review.
MedAllies
Medicity
Siemens	YES!
Redwood MedNet	yes, but...	The "User Stories" add an unncessary sub-plot to the document message. It is the TMI tale of an "Inside NHIN Direct" development process that is unlikely to be relevant to the outside reader who is the intended recipient of this document. The outside reader is likely to care about how NHIN Direct will support Meaningful Use, and not the "priority" project sequence of the user stories. I suggest four edits: 1. Delete from the top of page 6 ("A sample set of user stories...) to the bottom of the Priority Three list. 2. Alter the lead sentence "The analysis of user stories..." to say something like "Analysis of transport requirements for simple and direct point to point messages that can satisfy meaningful use measures identifies the following patterns:" 3. Then follow the Vision Share recommendation to harmonize Sender/Source and Receiver/Destination in the bullet points that follow 4. Alter subsection header 2.2 to "How does NHIN Direct enable simple message delivery" (or something generic to delete "User Stories" from the subhead.)
Other Implementation Group Participants
Akira Technologies	Yes
Alere
Allscripts	Yes
American Academy of Family Physicians
Argonne National Laboratory
Atlas Development
Axolotl
Cautious Patient
Cerner
Christus Health
Clinical Groupware Collaborative	Yes
CMS
Covisint
DoD
eClinicalWorks
EHR Doctors
Emdeon
Google
Greenway Medical Technologies
Healthcare Information Xchange of NY
High Pine Associates
ICA
Inpriva
Intel
Kryptiq
Massachusetts eHealth Collaborative
Medical University of SC, South Carolina Research Authority
MedNet
MedPATH Networks
MedPlus/Quest Diagnostics	Yes
Microsoft	YES
Mirth Corporation
Misys Open Source Solutions (MOSS)
MobileMD
NIH NCI
NIST
NoMoreClipboard.com
NYC Dept. of Health and Mental Hygiene’s PCIP
Oregon HIE Planning Team	Yes
RelayHealth
Rhode Island Quality Institute	Yes
Secure Exchange Solutions
Surescripts
Techsant Technologies
TN State HIE
VA
VisionShare	Yes with comments. Clearing up the issue in comment 3 is very important.	Section 1.3, paragraph 2: The three prerequisite components are listed as Transport, Ontology, and Semantics. The three example sentences that follow seem to be ordered as Transport, Semantics, and Ontology. Assuming that's correct, items 2 and 3 should be swapped for clarity. As a corollary, I'll suggest that the term Ontology won't have much meaning to the target audience. Section 2.2: The Abstract Model diagram and supporting text uses the term Sender and Receiver. The approved Abstract Model uses Source and Destination. Also, the Glossary defines all four terms. I would suggest using the original terms from the Abstract Model, or asking NHIN Direct to change the Abstract Model terms to Sender and Receiver. Multiple overlapping terms can become confusing. Section 2.2 (again): The descriptions of the ack transactions (1.3, 2.4, and 3.4) in the examples do not match what was intended in the Abstract Model. Example 1 says that the service provider (the sender's HISP) acknowledges successful receipt of the message. These transactions in the Abstract Model are actually explaining how a Destination to Source ack occurs (in transaction order 3.4 to 2.4 to 1.3). This is a fundamental semantic disconnect that should be clarified. Section 3, first bullet: The first three words are "NHIN Exchange Specifications". To match the terminology used further down in the doc, the first three words should be replaced with "NHIN Specifications". Section 3, third bullet: There is a spurious "(" before the word "to". Glossary: Since DNS is mentioned in the Abstract Model diagram in section 2.2, the term "DNS" should have an entry in the Glossary.
Others
Barry Hieb		Section 1.2: Are there any scenarios where the participants do not know each other in advance? If so how does that impact these assumptions? Section 1.2: How is this done? What NHIN Direct infrastructure supports this assertion? [that the Sender has determined it is clinically and legally appropriate to send information to the receiver] Section 1.2: Re: Patient identifier - But they DO require accurate patient identification. It seems incorrect to focus on the negative of not requiring an identifier while ignoring the positive requirement that they two must come to a correct agreement on what patient this data regards Section 1.2: In light of these restrictions can an NHIN Direct message contain information on a set of patients rather than a single individual? This makes things like obtaining patient permission much more complicated. If not, then this should be noted in section 1.3 as a limitation in scope. Section 1.2: This is the most critical section of the document. Once these assumptions are finalized they must be implemented in a way that gives the recipient medico-legal assurance that these properties are true. If the recipient is going to trust that the sender met these obligations then several things are required that are not mentioned above. a. Non-repudiation. NHIN Direct must include a mechanism(s) to ensure that a sender cannot later disown authorship of a message.b. Immutability. NHIN Direct must include one or more mechanisms such a check sum in its transport architecture to ensure that the message has not been altered in transport.c. Attestation. Every message that is sent using NHIN Direct must include some form of legally binding assertion that the sender abided by the principles above. This might involve including such a statement in each message or including a reference/pointer in each message to a separate statement or there may need to be a legal judgment that this is implied when an NIHN Direct message is sent.The recipient of an NHIN Direct message is medically, legally and ethically responsible when they use that information for patient treatment. NHIN Direct must provide the above three assurances in order to enable the recipient to act on the information in the message. Section 1.2: Is there an ‘onboarding’ process for senders and receivers in NHIN Direct? If yes, where is this described? If no, how can any participant trust any other participant? Section 1.3: It should be noted in this section that NHIN Direct only supports ‘push’ of medical information, not pull. Section 1.3: Also see the limitation in the last bullet of the previous section – only one patient per message (I assume.) Section 2.1: Aren’t these first four examples [Priority 2, first 4 bullets] of information on a set of patients rather than an individual? I need clarification on whether information on multiple patients is permitted in a single NHIN Direct message. Section 2.2: How are functions such as determining the receiver’s communications requirements and doing message protocol translation handled? Section 2.2 Example 1.3: Would having a patient name in the header be a violation? This example assumes that there has been prior out of band communication. Is that necessary? SEction 2.2 Example 2.1: No! this is his PHR address. The patient may have multiple NHIN Direct addresses including his e-mail, his PHR and his physician’s EHR depending on the specific use case Section 2.2 Example 2.3: How? How is the patient identified? Through having a unique URL? Section 7: Abstract Model - there should be a URL or pointer to this document Section 7: How does a user "qualify" to participate in a HISP?
Ross Martin (Deloitte)		One question: Bottom of page 6 mentions the need to uniquely identify senders and receivers. It seems that this is not sufficient as senders and receivers may act in multiple settings. I may be Dr. Smith all the time, but I'm Dr. Smith at Mayo on Tuesdays and Thursdays, Dr. Smith in my private practice on M, W and F, and Dr. Smith working at the free clinic twice a month. ... It seems like that's just what the line should say: "uniquely and contextually identify a sender/receiver (in the same way an email address identifies an individual and a domain)"