Concrete Implementation Workgroup > IHE Implementation Development Team > IHE Concrete Implementation Capability Worksheet

Issues with our proposal are addressed here.

1. Overview

The IHE implementation of NHIN Direct is primarily distinguished by the fact that it focuses the majority of its efforts on pairing a defined, standardized, and industry-tested protocol for HISP backbone communication with flexible edge communications. While the IHE implementation could have focused solely on the use of XDR between the source and the destination, we chose instead to leverage the breadth of the IHE model with the power of a well formed Content Package (SubmissionSet) that has different modes for SOAP (XDR), REST (XDM), SMTP (XDM), XMPP (XDM), and potentially others. This approach has the simplicity to address the entire range of NHIN Direct requirements, bridges with other NHIN Direct implementations, and mantains consistency with the more robust NHIN Exchange. The implementation required very little code to be created, since the support for XDR and/or XDM is already widely implemented and tested.

1.1 Provide a high-level end-to-end description of your implementation.

We call our implementation the IHE implementation because our backbone transactions are defined by a healthcare initiative called Integrating the Healthcare Enterprise. Specifically, our backbone uses the XDR standard, a lightweight point-to-point protocol designed specifically to push documents from a source to a destination. Our implementation has focused on two primary goals:

1) Support multiple edge protocols, providing a structure for and examples of swappable black boxes that can take generic inputs and transform them to appropriate XDR metadata.
2) Support a single backbone that can integrate seamlessly into existing interoperability infrastructure currently in place or under development in HIEs and by more than 20 federal agencies supporting the Federal Health Architecture around the country.

Thus, an end-to-end description of the IHE implementation could contain any number of paths for data to flow from a Source system to a Source HISP. The Source HISP provides a translator that processes incoming data and provides step-up transforms to create usable XDR metadata. The metadata and the document payload is then sent via secure channel using a SOAP IHE XDR message to the Destination HISP, which optionally deconstructs the message through a step-down transform to provide it to the Destination in a format the Destination can process.

1.2 Provide a diagram representing the software blocks required for a representative end-to-end system implementation.

1.3 Describe the current overall state of the implementation.

In our test cases of this implementation, we provided for XDR, XDM, REST, and SMTP edge protocols at the Source and Destination systems. We believe that our infrastructure would easily support other edge protocols with the creation of appropriate step-up and step-down add-in transforms. Currently we are at varying stages of creating messages and preparing test systems for end-to-end demonstration of the test cases.

1.4 Describe the working group participants and contributions.

Working group contributors include

MedAllies/GSI Health (HISPs and XDM transformers),
Allscripts (Source EMR),
Epic (Combined HISPs with Source and Destination, both EMR and PHR),
GE (transformers),
IBM (REST Source and XDM transformers),
Vangent (HISP), and
others

2. Benefits/Drawbacks of this approach

2.1 Outline why you believe this is the best approach to achieving the goals of NHIN Direct

Our case for IHE elaborates on the benefits of our approach. In short, we believe that NHIN Direct’s strength lies in both its integration with the work already done through NHIN Exchange and its accessibility to programmers of all stripes. Our approach has tried to marry these two advantages in the most practical way possible by (a) selecting a single protocol for the backbone, consistent with the existing NHIN Exchange, and (b) allowing several protocols along the edge, based on their relative value and ease of construction. We believe that the inclusiveness of this approach is a strength.
 
  We believe that our choice for a single, XDR-based push protocol on the backbone is practical because we recognize that systems along the communications backbone:

1) Likely already can communicate with each other using the protocols defined by IHE and NHIN Exchange
2) Have both the wherewithal and incentive to participate in the necessary IHE, NHIN, and Meaningful Use testing sessions, ensuring reliable and proven interoperability
3) Are already better positioned to broker communications among themselves

And further, that systems along the edges

1) Account for much more variability in capacity
2) Present a more appropriate opportunity for programmers with a lower cost-of-entry ceiling

Our implementation’s greatest strength lies in the substantial amount of work that has already gone into envisioning, designing, documenting, and testing the IHE protocols for communication, especially in regards to gateways on the NHIN. We leverage this work to allow the numerous systems already tested and in production, including NHIN CONNECT, to focus their efforts on supporting communication at the edges in a uniform and flexible way. IHE Connectathon Results reflect the very large number of vendors (more than 60 who can serve as a document source, more than 60 who can serve as a consumer, and more than 40 as document repository) who have created working XDS.b code (Note: XDS.b metadata and XDR have much in common). And Where in the world are CDA and XDS? indicates a partial list of locations where XDS/XDR are being used today.

2.2 Outline any drawbacks to this approach

When fully expanded to include all possible step-up and step-down configurations, our implementation suffers from two potential drawbacks:

1) In order to provide for the flexibility of multiple edge protocols, the HISP must perform the step-up and step-down transforms. That means that a message payload cannot be encrypted by the Source with the Destination’s public key, since the message will likely need to be unencrypted at both the Source HISP and Destination HISP.
2) In order to provide enough necessary metadata to support the IHE XDR transactions, the source must provide sufficient information regarding the document type, author information, and the patient’s identity.

We attempt to address these potential drawbacks in our implementation cases. It is our experience that end-to-end encryption is not a necessary prerequisite of any exchange, and that sources and destinations who receive services from their respective HISPs will already have a business associate relationship with that HISP. If end-to-end payload encryption is required, and the Source and Destination are required to manage the necessary certificate infrastructure for that purpose, then using XDR as the edge protocol is a viable option.

We also can show how the necessary metadata to support XDR can be derived from a document in an appropriate healthcare format (e.g. a simple CDA, creatable from a Microsoft Word template), or, if the document is in a non-parseable binary format, the necessary metadata can be gathered at the time of sending the message.

3. Specific Artifacts

3.1 Describe the status of working code.

Some components created to demonstrate these scenarios, including building and transformation of messages, have been posted on Google Code. Some of the code uses existing open source solutions, e.g the OHT IHE Profiles project. See the wiki pages for each case for additional technical details.
 
 In order to describe the ‘inclusiveness’ of the proposed approach – the working code demonstrates four different scenarios for participating NHIN actors with varied IT capabilities. All the components at sources, destinations and HISPs are developed using JAVA & .NET technologies. The working code goes a step beyond the proof-of-concept level by integrating production systems from the participating organizations. All the individual components required have been developed and the team is interfacing their systems with other organizations. The team expects to complete the implementation of all four cases before the face-to-face meeting on 6/10/2010. Listed below is the status of working code as of 6/1/2010 -

	Organizations involved	Status	Demonstration (Video clip)
Case – 1 EMR to EMR	Allscripts (Source MedAllies (Source HISP), Epic (Destination HISP & destination)	COMPLETE	IHE impl – CASE 1 (mp4)
Case – 2 EMR to Provider	Epic (Source / Source HISP) MedAllies (Destination HISP)	COMPLETE	IHE impl – CASE 2 (mp4)
Case – 3 Provider to PHR	GE & MedAllies (Source & Source HISP) Epic (Destination HISP & destination)	COMPLETE	IHE impl – CASE 3 (mp4)
Case – 4 Provider To Provider	IBM (Source), GE (Source HISP) Vangent (Source HISP) MedAllies (Destination HISP)	COMPLETE	IHE impl – CASE 4 (mp4)

3.2 Describe the status of written specifications.

The NHIN Direct Specification for our implementation is located here. Additionally, the IHE XDR protocols, actors, messages, formats, specifications, and schemas are all exhaustively documented in the IHE ITI Technical Framework. These documents have the benefit of a use-case driven consensus process and extensive testing that has already been done in Connectathons. Further, a required trial implementation period must be completed before documents achieve Final Text status: a "hardening" process that benefits from time and experience that are difficult to capture in just a few weeks. The maturity of these specifications was sufficient for them to be included, both in direct references to the ITI Technical framework and indirect references to HITSP Healthcare Document Management Service Collaboration 112, in the HIT Standards Committee standards and certification criteria recommendations to ONC .

3.3 Describe the status of test tools and cases

NIST provides a test server for submitting and validating XDR transactions (including metadata validation). Our test implementation uses transform add-ons for SMTP and REST (with an XDM payload).

3.4 Describe the “production readiness” of the working code – e.g., are errors and edge cases handled, are administrative and monitoring tools available, etc.

The unique advantage of our approach is twofold - there are existing implementations of the backbone protocol for the purpose of exchanging healthcare data both as infrastructure modules (many of them open source) and as part of existing healthcare IT products. Open source infrastructure implementations that support XDR transactions include NHIN CONNECT and the OHT tools. Parts of the Microsoft Connected Health Platform provide the majority of code necessary for an XDR implementation as open source.
 
  The support of the IHE protocols in existing healthcare IT products means that the communication capabilities are integrated as part of the workflow, which is critical for acceptance by the users of these products. The following systems have demonstrated their ability to support XDR and XDM integrated in their product offerings, through IHE Connectathons: AthenaHealth, CapMed, Corepoint Health, e-MDs, ENOVACOM, Epic, Forcare BV, Fujifilm, GE Healthcare, IBM, Karos Health, Medical Connections, Medical Informatics Engineering, Misys, NextGen, NoMoreClipboard, Sage, Siemens, and Tiani Spirit. Examples of production implementations include the following:

MedAllies, one of the demonstration partners for this effort, will go into production with an end-to-end XDR-based EDGE-HISP-EDGE communication architecture this summer with two major ambulatory EHR vendors that serve small practices.
Greenway, one of the participants in the IHE implementation team, will go into production in June withXDR communications with CMS

4. Abstract Model

4.1 Describe how each numbered transaction is supported by the implementation

Source to HISP

Transaction 1.1 (Source authenticates to HISP): The Source uses TLS to authenticate itself to/from the Source HISP.
Transaction 1.2 (Source sends NHIN Direct Message to HISP): The source creates a message using one of the defined NHIN Direct models: REST, SMTP, IHE, XMPP (or, potentially, another protocol if supported). The message is received by a specialized, step-up transform plug-in hosted by the Source HISP. The plugin decrypts the message, parses apart the information contained therein, and outputs the discrete data elements necessary for XDR. These data elements are handed off from the plugin to the Source HISP proper.
Transaction 1.3 (Source receives message status information): ACK messages are provided to the Source by the Source HISP, who receives said ACKs from the Destination HSP.

HISP to HISP

Transaction 2.1 (Source HISP and Destination HISP mutually authenticate each other): The Source HISP uses TLS for mutual authentication to/from the Destination HISP.
Transaction 2.2 (Source HISP sends NHIN Direct Message to Destination HISP): The Source HISP determines to whom the sender wishes to send his message from the incoming SMTP or REST message, or from the intendedRecipient element in provided XDM metadata. The Source HISP then uses the UDDI NHIN directory to discover the SOAP endpoint for the Destination HISP that services the destination endpoint. Using the data elements provided by the plug-in, the Source HISP creates the appropriate metadata for an XDR Provide and Register message (including placing the recipient's NHIN Direct address in the intendedRecipient element). The Source HISP crafts the message, wraps it in a SOAP envelope, and delivers to the Destination HISP endpoint, possibly through other routing HISPs.
Transaction 2.3 (Source HISP receives message status from Destination HISP): If the message is received by the Destination HISP successfully, the Destination HISP responds synchronously with a response message. In addition, when a delivery confirmation is required, the Destination HISP will send an XDR deferred response to the Source HISP.

HISP to Destination

Transaction 3.1 (Destination authenticates to HISP, or HISP and Destination mutually authenticate to each other): The Destination uses TLS to authenticate itself to/from the Destination HISP.
Transaction 3.2 (HISP MAY provide the Destination with a list of available NHIN Direct Messages): This transaction depends on the edge protocol implemented between the Destination and Destination HISP.
Transaction 3.3 (HISP provides an NHIN Direct message to the Destination): The Destination HISP deconstructs the received message into its constituent discrete data fields and feeds these inputs to the appropriate step-down transform plug-in (based on its knowledge of the Destination’s communication preference). The plug-in uses those elements (most notably, the intendedRecipient field, which identifies which entity at the Destination should receive the message) to craft and send an outgoing message to the Destination.
Transaction 3.4 (Destination updates message status with the HISP): Depends on Edge protocol. For XDR, it is the SOAP response. For XDM, the retrieval of the package either via SMTP or REST is considered an indicator that the message was delivered to destination.

4.2 Describe how each defined "term" in the abstract model is instantiated in the implementation.

Source: A source is any system that can provide a document to an appropriate transformer located at the Source HISP. In our implementation group's demonstration, we have
- * Case 1: An Allscripts EMR providing an XDR message.
- * Case 2: An Epic EMR serving as a combined Source and Source HISP
- * Case 3: An e-mail client providing a structured document
- * Case 4: A web-based front end providing an XDM package through REST

Destination: A destination is any system that can receive (or request) a document from an apporpriate transformer located at the Destination HISP. In our implementation, we have
- * Case 1: An Epic EMR serving as a combined Destination and Destination HISP
- * Case 2: An e-mail client that receives an XDM package
- * Case 3: An Epic PHR serving as a combined Destination and Destination HISP
- * Case 4: An e-mail client that receives an XDM package

HISP: In our implementation, a Source HISP hosts transforms for processing imports and extracting their data. The HISP then uses this data to construct an XDR message, which is sent from Source HISP to Destination HISP. The Destination HISP parses the received message to transform it into a format the Destination can accept.

NHIN Direct Message: An NHIN Direct Message originates at the source and is sent to the destination.The message contains a document and enough data (either within or accompanying the document) to identify the recipient of the document and the patient the message concerns. Along its path, the message may undergo some transformation, although the document remains the same.

NHIN Direct Source Edge Protocol: Any protocol that can interact with an appropriate transformer to extract the minimum necessary metadata is allowed in this implementation. Other factors (such as the technical or business feasibility of supporting said protocol) may affect which protocols are actually supported in practice.

NHIN Direct Destination Edge Protocol: Any protocol that can interact with an appropriate transformer to use the provided data to produce a message is allowed in this implementation. Other factors (such as the technical or business feasibility of supporting said protocol) may affect which protocols are actually supported in practice.

NHIN Direct Address: Just as protocols may change from edge to HISP to edge, addresses may be likewise transformed. In concordance with the NHIN Direct Addressing specification, an address will contain a domain and endpoint.

NHIN Direct HISP Address Directory: A UDDI directory provides the Source HISP with information about how to send messages to the domain that the Source indicates.

NHIN Direct Backbone Protocol: The backbone protocol is XDR.

5. User Stories

5.1 Describe how each user story is supported by the implementation. ALL stories regardless of priority should be addressed; working code may be focused on the priority 1 items.

Our approach of flexibility for the edges and consistency on the backbone supports the large set of business needs demonstrated in the User Stories. Prior to considering each User Story, we present the variety of approaches which could be applied to addressing each User Story.
 
 Source Edge Protocols
  In our approach, a Source HISP chooses a set of edge protocols to support and hosts the necessary step-up transformers for those protocols. We have considered the following cases:

EHR acting as Source with external Source HISP: This is likely the most common case existing today. Many EHRs have already implemented the XDR protocol as part of their workflow. By adding support for the Health Internet Address, the EHR is able, with a trivial addition of code, to support NHIN Direct protocols. In our demonstration, Allscipts provides this capability.
EHR acting as Combined Source and Source HISP: Another extremely likely case is an EHR which chooses to be a Combined Source and Source HISP. To serve as a Source HISP, the EHR adds support for the Health Internet Address and provides the routing capability to deliver the message to the correct Destination HISP. In our demonstration, Epic provides this capability.
EHR creating structured document: In the event that the Source system has an electronic record system capable of creating a structured document (e.g., CDA or CCD), this structured document alone can be used to create the XDR message. The structured document is delivered to the Source HISP through an agreed protocol. Possible protocols for delivering the document include SMTP, REST, and XMPP, and other protocols could also be supported if desired. The Source HISP extracts the necessary metadata from the structured document to create an XDR message, which it then delivers to the Destination HISP. In our demostration, the structured document is sent from the Source via SMTP to a GE plugin provided by the Source HISP (MedAllies). The Source HISP then delivers to the Destination HISP. Although we do not demonstrate it, the considerations from the SMTP Implementation Workgroup in terms of the security of delivering SMTP is required for this scenario. We also note that all the variations supported by the SMTP Implementation Workgroup are applicable to this approach.
Non-structured document packaged into XDM zip file: To handle the case where a document does not contain structured content (e.g., PDF, text, etc), a simple webpage can provide an interface to gather the few elements needed for XDM and to generate the XDM zip file. Similar to the previous case, this zip file can then be delivered through many possible protocols, including SMTP, REST and XMPP. In our demonstration, IBM has created a web application built from OHT building blocks, which allows the Source provider to fill in the details needed, specify the document or documents, and generate the XDM zip file. This XDM zip file is then delivered using a REST interface provided by GE to the Source HISP, who then transforms the message to XDR and delivers it to a Destination HISP.

Destination Edge Protocols
In our approach, a Destination HISP chooses a set of edge protocols to support and hosts the necessary step-down transforms for those protocols. The choice of which step-down transform to use is made by the Destination HISP based on the Health Internet Address of the Destination. We have considered the following cases:

Destination HISP delivers via XDR: A Destination HISP may deliver content to the Destination using the same protocol as the backbone protocol.
EMR acting as Combined Destination and Destination HISP: An EHR may choose to be a combined Desitination and Destination HISP, receiving messages via the backbone protocol and delivering directly to its users. In our demonstration, Epic provides this capability.
Destination HISP delivers XDM attachment: A Destination HISP can provide a step-down transform from XDR to XDM. The XDM zip file can then be delivered using any edge protocol (e.g., SMTP, REST, or XMPP). In our demonstration, MedAllies provides this capability by delivering the XDM zip file as an attachment to an SMTP e-mail.
Destination HISP delivers content only: A Destination HISP may also support a simple Destination by dropping the metadata carried in XDR and delivering only the content of the message. This content could be delivered through any appropriate edge protocol.

User Story Specifics

1) Primary care provider refers patient to specialist
2) Primary care provider refers patient to hospital
3) Specialist sends summary care information (back) to the referring provider
4) Hospital sends discharge info to referring provider

Support for these User Stories depends on the technical and business capabilities of the healthcare providers. When the sending actor in these stories uses a EMR, his system can use one of the EMR/EHR based Source Edge and Destination Edge Protocols described above. In cases where an electronic system has nointegrated support for NHIN Direct, the provider could use his e-mail client or a web-based form to send or receive the appropriate documents.

5) Lab sends lab results to an ordering provider

As in the prior case, the lab system may be supported by an electronic record system which supports NHIN Direct communication. In that scenario, the lab would use the workflow provided by their system to create and send the message. In some cases, the lab may not have a means to identify that patient to whom the results belong, only an identifier for the results themselves. This poses a challenge for the ordering provider, whose workflow would be much simpler if his EHR could electronically associate the results message with the appopriate patient. Further considerations for this case are needed, but two approaches can be considered. Approach 1: do not require the patient identification in this case, allowing very selectively chosen optional use of this metadata. Approach 2: agree to use a lab order number or similary identifier as a psuedo-patient identifier in this specific case.

6) Transaction sender receives delivery receipt.

An extension to XDR adopted by NHIN Exchange supports a deferred response to the XDR request. This deferred response can be used to indicate delivery receipt as well as read receipt. Although this extension is not part of the base IHE XDR standard, it is in active use by NHIN Exchange and is expected to be adopted by IHE shortly.

7) Provider sends patient health information to the patient
8) Hospital sends patient health information to the patient
9) Provider sends clinical summary of an office visit to the patient
10) Hospital sends clinical summary at discharge to the patient
11) Provider sends reminder for preventative or follow-up care to the patient

It is expected that a patient will receive these documents, sumnmaries, and reminders through the use of a PHR or other similar system. Any of the Destination Edge protocols are appropriate for PHR systems in the same way they apply to EHR systems.

12) Primary provider sends patient immunization data to public health

Several initiatives within CMS have incorporated the use of XDR to carry quality measures to public health. Enhancing these existing approaches to support patient immunization is a simple exercise.

13) Provider or hospital reports quality measures to CMS
14) Provider or hospital reports quality measures to State

Reporting of quality measures is already supported within the NHIN Exchange through the use of XDR as a backbone protocol. The NHIN Exchange Physician Quality Reporting Intiative (PRQI) Health Information Exchange profile, developed in early 2010 in cooperation with CMS, specifies the use of XDR as the backbone protocol for this use case. NHIN Direct can add extensibility to the existing NHIN Exchange solution by supplying a choice of edge protocols for various environments.

6. Security & Trust

6.1 Describe how each consensus requirement is supported by the implementation.

Use of X.509 Certificates --- This solution utilizes Mutually-authenticated-TLS (as profiled by IHE in ATNA). This mechanism has been tested at IHE connectathon and is the primary recommendation of general IT profiling organizations like WS-I Basic Security Profile. The use of TLS is more robust as it does not require a realtime reliance on DNS or LDAP.
Certificate Authority Anchor Configurations: This solution supports but does not require that the source or destination pre-coordinate the certificates as long as the resulting certificates can be chain-validated to an Anchor.
Self-Signed Certificate Configurations -- This solution can also support self-signed certificates that are pre-coordinated and configured into the trust-store.
Certificate Granularity -- The typical configuration is to use certificates to secure the service-endpoints of the communications. For security that is to the human-endpoint, IHE recommends the use of the Cross-Enterprise User Assertion Profile. This profile uses the SAML - federated identity standard from OASIS. SAML is more agile and better suited to individual authentication and security. This ability to support both system security through TLS and user security through SAML is scalable upon the need.
Revocation -- All Certificates must be validated when they are used to assure their signature validates, that their time boundaries are valid, and that they have not been revoked. IHE does not mandate a revocation checking protocol as the use of CRL and PKCS are both mature and widely available. The ultimate choice is a policy choice.
Sender identification -- All communications are mutually-authenticated using TLS, so the sender is always highly authenticated. When intermediaries are required for step-up or step-down the intermediaries are included in the trust fabric once they have been appropriately onboarded through validation of business process, technology, and procedures.
Encryption -- TLS automatically negotiates for the best encryption algorithm and hashing algorithm. IHE profiles require that production systems are at least able to utilize AES and SHA1. If the systems support more advanced algorithms the TLS protocol will utilize the better algorithms.
Ease of use -- as indicted above with TLS there is little that must be pre-configured as the TLS protocol automatically negotiates. The choice of manual configuration vs an Anchor is offered for the very small organizations with few configurations can chose the manual configuration for it's no-cost ability, while larger organizations can choose a Certificate Authority Anchor. Management of Machine Authentication Certificates

Additional Security comments:

The NHIN-Exchange has a Certificate Authority with revocation mechanisms that fits this model.
The IHE protocols allow for modularity adding the SAML assertion for user authentication Cross-Enterprise User Assertion Profile
The IHE protocols for security also require that the systems involved have access controls sufficient to enforce the local policies
The IHE protocols for security also include security surveillance audit logging that can be used to inform an Accounting of Disclosure
The IHE protocols include a mechanism for recording and validating a patient privacy consent. This mechanism is being further enhanced in a compatible way to support advanced patient privacy consents and preferences.
The IHE process includes a security risk assessment that results in a Security Considerations section of each profile.
The IHE XD* metadata allows for documents to have relationships where one related document is a Document Digital Signature. When needed this can be used to provide high-assurance non-repudiation.
The IHE XD* metadata includes a SHA1 hash and byte-size as a second-channel for data integrity controls, supporting low and moderate level of assurance.
The IHE XD* metadata includes attributes for segmentation (confidentialityCode) of the documents to support multi-levels of access control and privacy controls.
The IHE XD* metadata includes attribution of author on both the content package (submission set) and on each document. This allows for authorship attribution of documents that the sender is forwarding for which they are not the author. This supports multi-level referral. This can be leveraged by the Patient through their PHR to convey original documents that when tied with a document digital signature have a high assurance non-repudiation.
The IHE ATNA Profile does support WS-Security Message level security for configurations that have addressed the problem of pre-distribution of end-user certificates and have handled the scalability issues associated with that over multiple organizations. Generally this solution is not exercised as the added value is not worth the added overall costs.

6.2 Security/Privacy Risks

Note the additional Security comments above deal with may Security/Privacy risks in a modular way to scale with the implementation and policies.

The IHE XDR protocol puts the IntendedRecipient (To) and Author (From) into the SOAP message with the other content metadata. This requires that any system that needs access to this for application-level routing needs access to all of the metadata and documents.
- Given a real-world use-case can be described where an intermediary is required and cannot be allowed access to the metadata, then NHIN Direct can specify that the IntendedRecipient (To) and Author (From) values be copied out of the SOAP body and into the SOAP header. The expectation is that XDR would be used as directly as possible. Only using an intermediary when there is a value-add such as protocol conversion (see above) or document conversion (such as code-set conversion, or whole-document conversion)..
- The expectation is that routing is all done at the IP level, with IPv4 support today and no reason to expect problems with IPv6

Although this document outlines the full flexibility of the IHE model, when only two providers need to communicate the XDR profile can be used to make a point-to-point linkage with no need for any intermediary (HISP) interference. We show the full flexibility to emphasize the power of strongly structured and coded metadata on the package (Submission Set) and document level.

7. Comprehensive HIE

7.1 Describe the mechanisms by which the implementation can interact with NHIN Exchange implementations.

Perhaps its strongest point, our implementation is absolutely congruous with NHIN Exchange implementations, not only technically, but also in terms of the architectural and procedural frameworks that surround the exchange infrastructure.

Technical overlap: Our implementation assumes a backbone protocol of XDR Provide and Register messages. NHIN Exchange also supports Provide and Register messages, meaning that any Source HISP can send to any NHIN Exchange endpoint without technical modifications. Additionally, any existing NHIN gateway could provide NHIN Direct services to its constituents without technical modifications, and could offer NHIN Direct services to other sources by implementing the appropriate transform add-ins provided for in our implementation. Although not all NHIN Exchange nodes currently offer Provide and Register messages, the difference between an XDR transaction and an XDS.b transaction (more widely supported) is relatively minimal, much less than the difference between XDR transactions and the proposed REST or SMTP transactions.

Architectural overlap: Our implementation seeks to reuse architectural components from NHIN Exchange wherever possible, thereby reducing the number of centralized (or duplicated) core components needed. We believe this approach will lead to a more efficient eventual national implementation of NHIN Direct communications. For example, NHIN Exchange uses a UDDI phonebook to reconcile endpoints with their IP addresses and the metadata needed to communicate with them. Our implementation uses the same phonebook with the addition of the NHIN Direct address. Similarly, NHIN Exchange provides for a national certificate authority which might be leveraged as a certificate-issuing body for NHIN Direct participants, if needed. And as state after state receives federal funding to implement exchanges, allowing their nodes to seamlessly integrate into NHIN Direct-based exchanges will produce a larger pool of participants, a necessary component for any communication to take hold. (Even the fax machine - the ubiquitous technology we are aiming to replace - was not widely adopted until a critical mass was attained.) NHIN Direct will only succeed if people use it, and people will only use it when other people use it; it's vital that we do everything possible to encourage early participation.

Procedural overlap: As the backbone of NHIN Direct, whichever implementation our group settles upon must be robust enough to power an exchange infrastructure that will stretch across the nation. IHE has already built an extensive network of stakeholder and member organizations, including medical professional societies, goverment agencies, provider organizations, trade associations, and participating vendors of healthcare IT systems. Further, IHE provides a firm grounding into the implementation of its protocols, with documented process, profiles, frameworks, and implementation guides. IHE hosts Connectathons annually in Asia, Europe and North Americaan devoted to the testing and proving of its protocols, thereby providing an assurance of reliability to the users who will leverage them. By using an implementation defined, sanctioned, and overseen by IHE, we can neatly dovetail into this support structure and avoid the burden of recreating it from scratch.

8. Other Workgroups

8.1 If the implementation deviates from requirements of the Addressing, Content Packaging or Individual Involvement workgroups, describe and explain the reasons here.

The implementation does not deviate from the requirements of the Addressing, Content Packaging, or Individual involvement workgroups. Since our proposed approach is based on established standards and the IHE demonstrations integrated production level systems, the IHE implementation team learned some valuable lessons to be compliant with above-mentioned requirements. Please review the IHE Concrete Implementation - Lessons Learned for further details.

9. Cost and Complexity of Development

9.1 Describe what new code is required to create a complete implementation vs. what can be used off-the-shelf.

The proposed IHE implementation approach categorizes the development tasks in three primary areas: Source (data provider), HISP (Source/Destination), and Destination (data consumer).
 
 Source (Data Provider)
  If the source system already implements production-level IHE compliance, no new code is necessary. Systems without this capacity can utilize off-the-shelf open-source solutions provided in the OHT IHE profiles. New code would need to be written for the source with limited/no IT capabilities, in order to capture the minimum set of metadata for its source HISP to successfully transform to XDR. To demonstrate this, IBM has provided a web form to create a XDM package for provider with Internet connection, in our fourth demonstration scenario.
 
 HISP (Source/Destination)
  New code must be written to transform edge messages up to and down from XDR. Off-the-shelf code is available for facilitating XDR transactions between HISPs using open source solutions provided with OHT IHE profiles or Microsoft Connected Health Platform project.
 
 Destination (Data Consumer)
  For the destination system which already supports IHE-defined protocols, no development is necessary. Other systems without this capacity could make use the off-the-shelf open-source solutions in the OHT IHE profiles. For destinations with limited or no IT capabilities, an e-mail client might be used according to the implementation suggested by the SMTP implementation group.
 
  The new code developed by IHE implementation development team to demonstrate the different cases can be made available off-the-shelf as part of NHIN Direct offering. We offer our simple web-app to create XDM package (demonstrated in scenario four), our SMTP to XDR transformer (demonstrated in scenario three), and our XDR to XDM transformer (demonstrated in scenarios two and four).

9.2 Describe library and required component availability across platforms and frameworks.

Our proposed approach requires SOAP for the HISP backbone communication and can be readily implemented using toolkits for different development platforms such as Java, .NET, ruby and others. In our demonstration, we have successfully integrated production-level .NET- and Java-based systems at source, destination and HISPs.

9.3 How does this approach integrate with existing mainstream healthcare applications? Describe cost/complexity of integration.

The cost/complexity of the integration is purely subject to IT capabilities of the NHIN Direct actors based on their choice of protocols on the edge. The approach allows sources/destinations to lower the cost of integration by picking the edge protocol that they can readily incorporate in their workflow and technology platform. The widespread support for IHE standards in healthcare IT systems increases the knowledge-base and enriches the toolset required to implement our proposed approach. This in turn reducies the cost and complexity. The The HIMSS Electronic Health Record Association (EHR Association) Interoperability Roadmap, after recognizing both the business and technical challenges of achieving interoperability, endorses XDR/XDM integration profiles for point-to-point interchange. EHRA's 44 member EHR companies have also endorsed the NHIN Direct IHE implementation (

[File:http://www.wikispaces.com/i/mime/32/application/pdf.png 06042010 EHR Association Letter_NHIN Direct.pdf]

06042010 EHR Association Letter_NHIN Direct.pdf

Details
Download
128 KB

).

The IHE implementation team has created innovative code packages to demonstrate our four test cases, involving NHIN actors with varied IT capabilities. The ease at which those four scenarios were demonstrated with production-ready healthcare applications attests to the simplicity of our proposed approach.

10. Workflow / User Experience

With its emphasis on multiple edge protocols and substitutable handlers, our IHE implementation is a scalable solution with an extremely low cost of entry for the smallest practices. The robustness is provided through HISP systems, which respond to a standard and open set of inputs to produce standards-compliant communications. A new edge protocol would simply need to write two plug-ins that comply with well defined inputs and outputs.

10.1 Describe how a small (1-5 provider) practice with limited IT capability might deploy the implementation.

A practice with limited IT capability would begin by selecting a service provider (HISP) to provide them with NHIN Direct support. This service provider might be a local, regional, or state-run exchange, a larger healthcare organization in the area with HISP capabilities, or even a CONNECT-based service provider provided by the federal government specifically for smaller organizations without existing organizational relationships. Doctors would receive their NHIN Direct addresses from the HISP and would likely use either their e-mail client or a web form created by the HISP to send and receive information from other NHIN Direct participants. Their HISP would be responsible for translating these messages into the XDR backbone protocol and routing them appropriately.

10.2 Describe how a medium practice with an outpatient EMR might deploy the implementation.

While it is definitely plausible that their EMR might directly support the NHIN Direct backbone protocols (given the number of vendors who both target this market and support XDR transactions), for this case, we will assume that the medium practice prefers to also seek the services of a HISP external to their organization. Given that their practice already uses an EMR, we envision that care providers at this organization would best be served by a solution that integrates directly into their EMR, thereby avoiding the overhead imposed by jolting a provider out of his workflow and into a second system (be it mail client or web browser). Therefore, we believe that in order for any implementation to be successful, it must allow for straightforward integration into an EMR system, through the use of well-defined APIs and low infrastructure overhead. Given that our implementation is flexible at the edges, an EMR vendor could choose to implement an entirely custom edge protocol from his system to the HISP, assuming he could also provide the HISP with a plug-in transformer to receive messages and extract necessary data. Alternatively, the EMR provider could use one of the open source implementations of the edge protocol, provided both through this implementation and others.

10.3 Describe how a large practice / hospital might deploy the implementation.

A large practice or hospital, in our experience, is best positioned to both have an EMR that can already support the backbone protocol natively and an organizational structure with the capacity to perform other necessary HISP duties, such as address provisioning. (Of course, not every large practice or hospital will have this capacity or desire, but those that do not have stories very similar to cases i and ii.) This organization may choose to only support its own members, or they may choose to extend HISP services to practices without HISPs.

10.4 Describe how a patient might participate in the implementation.

Much like a doctor's practice, a patient must first find a HISP that will provide the necessary services necessary to participate in NHIN Direct. We anticipate that many PHR providers will roll HISP services in with workflow tools, allowing the PHR, essentially, to act as combined Destination HISP and Destination for the the patient. Such an implementation would abstract away most of the complexity - the patient would sign up for a PHR, receive an NHIN Direct address, and the PHR would handle all other aspects of the backbone communication and routing. Alternatively, we may see patient-targeted HISPs arising that provide a patient with an NHIN Direct address and instructions for configuring, for example, an e-mail client to connect to the HISP's servers.

10.5 Describe the anticipated departure or switching costs a vendor may incur with this approach (versus previously supported paradigms).

Vendors who currently do not support IHE protocols would find it most efficient to implement a widely accepted edge protocol and rely on a transformer to connect to the NHIN Direct backbone. Vendors who support IHE-defined XDS.b transactions (over 60 as of the 2010 IHE North American Connectathon) would find the transition to XDR relatively minimal, in that the technical specs are similar and the means of message transmission and security are identical. Eleven vendors have had their ability to send XDR messages validated by IHE and/or future certification bodies.

11. Miscellaneous

11.1 Metadata Handling

11.1.1 Describe what metadata is inherently handled by the implementation

The IHE implementation requires enough metadata at the edge protocols to support XDR transactions along the backbone: namely, a patient and author identifier. This information can be extracted from the message itself if the message contains a CDA document, or it can be provided through agreed upon channels between the Source system and its associated step-up transform plug-in. Other required XDR metadata may be generated de nova through the transform plug-in itself.

11.1.2 Explain how more complex metadata could be added to the implementation if it is desired

XDR can support much richer metadata, including checksums and levels of association among multiple documents in one message. In addition, XDR allows for any locally identified metadata to be added. This feature is being used by the recently completed NHIN Exchange Electronic Submission of Medical Documentation Profile to carry Claim ID and Case ID in the metadata. Allowing for this simple way to extend metadata about the content is a valuable part of this proposal.

11.2 Content Handling

11.2.1 Describe how the implementation deals with unstructured text content.

Unstructured text and binary content is wrapped in metadata to allow for automatic processing by the Destination. This metadata is normally created by an EHR system. Alternatively, necessary data elements could be provided through agreed-upon headers in a REST implementation or via a simple interface which collects the small amount of metadata needed to aid in processing. While this may seem restrictive, the presence of these metadata elements allows Destination application systems to perform more sophisticated handling for received messages, ultimately simplifying the end users’ workflows in reconciling received documents with existing patient charts. Without structured content, any proposed implementation would be no better than a fax – the very workflow NHIN Direct is attempting to improve upon.

11.2.2 Describe how the implementation deals with unstructured binary content (e.g., PDF)

Unstructured text and binary content is wrapped in metadata to allow for automatic processing by the Destination. This metadata is normally created by an EHR system. Alternatively, necessary data elements could be provided through agreed-upon headers in a REST implementation or via a simple interface which collects the small amount of metadata needed to aid in processing. While this may seem restrictive, the presence of these metadata elements allows Destination application systems to perform more sophisticated handling for received messages, ultimately simplifying the end users’ workflows in reconciling received documents with existing patient charts. Without structured content, any proposed implementation would be no better than a fax – the very workflow NHIN Direct is attempting to improve upon.

11.2.3 Describe how the implementation deals with structured content such as CC*

The metadata used in XDR can be extracted from most structured content, like CDA. If organizations can provide this structured content, a Source HISP step-up translator to XDR messaging is technically simple.

11.3 Extensibility and Future Proofiing

11.3.1 How would this implementation approach extensibility in general to support new use cases?

The IHE model supports the ability to push any type of patient-specific content from originator to recipient. The metadata it supplies allows for support of richer use cases and is extensible to support unique situations.
  The IHE model is supported by the IHE organization to support advancement following the IHE process

12. Additional Capabilities

12.1 Describe any other relevant capabilities or use cases facilitated by this implementation.

The IHE organization already has standardized much of what we leveraged. The few gaps that we have identified can be brought back to the IHE organization to include in the GLOBAL standard and technical framework or adopted as a US-Realm extension supported by IHE USA. By using IHE-defined protocols, the specification defined by NHIN Direct would thus be maintained by IHE and its ISO (ISO TR 23830 approved process for implementation guides and profiles).

IHE Concrete Implementation Capability Worksheet