IHE Concrete Implementation - Lessons Learned

This page is a draft under development.

No.	Lesson	Area	Comments
1.	NHIN Direct Address presentation in XDS Metadata	Addressing Specification	The initial mapping of the NHIN Direct Address to the XDS metadata uses the Intended Recipient and the Author as the structures to contain the To: and From: addresses. In order to simplify the mapping, the decision was made to use the email format of the NHIN Address as a "person" identifier. The observation was made that existing implementations already identify the author in some way, and usually the NPI is in use. Since the NHIN Direct Address is a telecommunications address (in HL7 modeling terms), a change proposal will be submitted to IHE to add a telecommunications attribute to the Intended Recipient and Author structures in order to properly represent the NHIN Direct address in the XDS Metadata, and allow for the "identifier" part in these structures to be used as intended.
2.	NHIN Direct Address presentation at the protocol level	Addressing Specification	In addition to having the NHIN Direct Address in the XDS Metadata, an argument can be made to add it the the SOAP level as well, since it is used for routing.This will be a good discussion topic.
3.	NHIN Direct Address as an email address	Addressing Specification	When mapping the NHIN Direct Address to an email implementation, making it the same as the email address may cause issues: If the use of email happens at the Destination HISP - Destination link, and the path from the Source to the Destination address goes through a transformation, there needs to be special handling of the From: address at the destination, otherwise replying to the email may not work properly. Using the Destination NHIN Direct Address as an email address seems to restrict a Destination to the use of a single Destination HISP for that one address.
4.	Handling plain/html/rich message text associated with CDA attachment(s)	MIME Message to XDR Mapping	When an e-mail message is composed to a Destination with one or more clinical document attachments it is possible the Source will supply additional relevant information pertaining to the transmission (such as a cover letter or other explanatory text). When converting from MIME to XDR this body part cannot be ignored and should be 'packaged' as an additional document in the XDR SubmissionSet. As such it will require the minimal metadata of XDS which includes a patientId. Some options considered that would need further analysis include: Use the required & globally unique MIME Message-ID as a patient context 'pseudonym'. This enables the document to be traceable back to the source system / sender. Assume that the body text refers to the patient Id found in one of the structured attachments (exa: CDA or CCR) and assign that identifier to the main message body part. This option relies on user discipline on the Source to avoid creating messages with mixed patient context. Slice and dice to body parts into separate patient identify buckets: If a body part contains content that can be recognized and is known to contain a unique patient id, such as a CDA, CCR or other structured content type, that id can be used in the XDS metadata. If a body part does not contain a recognizable patient identifier, the MIME Content-ID or random generated UUID is used as surrogate for this concept in the XDS metadata. The difficulty here is that we cannot presume that unstructed text contained in an email message pertains to a single patient identity. However, because the surrogate selected will not correlate with any known patient id on the Destination system it will require manual inspect (as it should) for a user to associate with the correct patient (or no patient at all). This tension is caused by the fundamental patient-centric nature of IHE metadata that works against general clinical messaging. Once each body part has an associated identifier (either from content or generated surrogate) each distinct set of identifiers will result in a separate XDR transaction and submission set in the conversion due. This results in a message splitting side-effect where Source has sent one message but 2 separate XDR transactions are te result.
5.	Lossy Viewer Problem in XDM Step Up - Step Down	XDM to XDR to XDM	XDM and XDR both carry documents and metadata using the same underlaying information model defined by IHE and based on the ebXMLRegistry standard. However, XDM also defines additional artifacts to support a capability for a user viewing the archive content to do so, such as (minally) and HTML index.htm page as well as any artifacts the HTML viewer may need to render content such as XSLT stylesheets (for example to render an HL7 CDA) or Cascading Style Sheets and image files to support an more element browsing UI. These artifacts are ancillary to the clinical data being conveyed in the XDM archive, but reflect how a user at an XDM source system might expect a receiver of the XDM to see the content. When XDM is converted to XDR these artifacts are left behind. In our NHIN Direct IHE Concrete Implementation when a Destination receives a message from such a source using XDM using email client, our specification calls for a Step Down on the Destination HISP that would generate a new XDM archive (including viewer artifacts, index,htm page etc) that almost certainly look quite different from the Source's.
6.	Multple XDR transactions per XDM - XDM Splitting Problem	XDM to XDR to XDM	XDM archives may contain multiple submission sets for each for, potentially, a different patient. Because XDR only supports a single submission set per transaction, the XDM to XDR Step Up Converter would have to generate a separate XDR transaction for each submission set found in the XDM archive. This causes a single message REST/XDM based message sent by a NHIN Direct Source with an XDM archive (for example in Case 4) to result in mulitple NHIN Direct Messages placed on the backbone and multiple responses to each from the Destination. This is an edge case that is consistent with XDM since each submission set will contain its own NHIN Direct Address in the SubmissionSet.intendedRecipient and this represents the equivalent of multiple 'To' addresses with email. However the converter will have no way to reassemble a single XDM archive on the Destination HISP Step Down to Email/XDM nor will a an XDR Source have any way to determine or correlate that these came from a single initial interaction at the Source.