The aim of this document is to provide the technical details of implementing major profiles of the IHE IT infrastructure and Patient Care Coordination domains as well as their integration with other applications. It also describes actor XML configuration and installation.

2 Terminology and Definitions

Term	Definition
IHE	Interoperability for Healthcare Enterprise - is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical needs in support of optimal patient care. Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively. Visit www.ihe.net for more information.
Domain	IHE is organized by clinical and operational domains. Each domain develops and maintains its own set of Technical Framework documents. The active IHE domains include IT infrastructure (ITI), Patient Care Coordination (PCC), Cardiology, Eye Care, Laboratory, Patient Care Device and Radiology. Misys Connect actively participates in the first two domains, namely ITI and PCC.
IT Infrastructure Domain	The IT infrastructure domain specifies the transport mechanism of documents and patients. Visit http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf for details about the technical framework.
Profile	Each integration profile is a representation of a real-world capability that is supported by a set of actors that interact through transactions. Each domain is composed a set of profiles. The ITI domain, for instance, includes PIX, PDQ and XDS profiles etc. All the profiles can be found at http://www.ihe.net/Technical_Framework
Actor	Actors are information systems or components of information systems that produce, manage, or act on categories of information required by operational activities in the enterprise. Examples include Document Source, Document Consumer, Patient Identity Source etc.
Transaction	Transactions are interactions between actors that communicate the required information through standards-based messages. For example, register and submit document set.
Affinity Domain	A clinical affinity domain is a group of healthcare enterprises that have agreed to work together using a common set of policies and share a common infrastructure.
Patient Identifier Domain	A Patient Identifier Domain is defined as a single system or a set of interconnected systems that all share a common identification scheme (an identifier and an assignment process to a patient) and issuing authority for patient identifiers.
Assigning Authority	An assigning authority is an identifier domain identifier. For example, the Misys Assigning Authority used at Connectathon is *MIEH*, which uniquely identifies Misys identifier domain. An assigning authority can be used interchangeably with Patient Identifier Domain.
XDS	XDS stands for Cross-Enterprise Document Sharing. It enables a number of healthcare delivery organizations belonging to a clinical affinity domain to cooperate in the care of a patient by sharing clinical records in the form of documents as they proceed with their patients’ care delivery activities.
PDQ	PDQ stands for Patient Demographics Query. It provides ways for multiple distributed applications to query a central patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s demographic information directly into the application.
PIX	PIX stands for Patient Identifier Cross-referencing. It provides cross-referencing of patient identifiers from multiple Patient Identifier Domains. These patient identifiers can then be used by identity consumer systems to correlate information about a single patient from sources that know the patient by different identifiers.
ATNA	ATNA stands for Audit Trail and Node Authentication. It establishes the characteristics of a basic secure node.
CDA	The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. This standard is promoted by the HL7 group. Visit www.hl7.org for more information.

3 Overview

IT infrastructure domain provides transport mechanisms for sharing patient documents among different IHE vendors. This domain does not specify any details about document content (i.e., document content agnostic). The document content is handled separately by the PCC (Patient Care Coordination) domain. Ideally, any type of document can be transported in this framework as long as there is an agreement among the affinity domain to use a common set of policies.

XDS describes the actors and transactions used to submit and query documents. However, a document does not exist by itself; it must have a context that describes the patient that the document is associated with. Unfortunately, the same patient would have different identifiers in different EHR vendors (or patient identifier domains). So PIX profile comes into play to reconcile different patient identifiers. PDQ provides additional features on top of PIX; it allows a patient to be searched based on the patient’s demographic information rather than the patient identifier. Finally ANTA and CT are the two auxiliary profiles that provide audit trail secure node and consistent time.

4 Design Details

The Braid IHE Connection Library is broken up into two pieces, the base library and the IHE library. The base library contains the data class and configuration that must be used to call the API. The IHE library is the functional entry point to the IHE systems. The data communication is facilitated via brokers.

All calls to external data sources are made through the different brokers:

AuditBroker – Used to send audit messages to one or more audit record repositories.
DocumentBroker – Used to submit documents to a XDS repository, query documents from a XDS registry, or retrieve documents from a XDS repository.
PatientBroker – Used to register a patient to a PIX manager, or query patient demographics from a PDQ supplier.

The braid contains another library called bridge. It contains classes used to access IHE components through web services. The client application implemented in .net or other technologies can call IHE components through web services.

Figure 1

The above figure describes two different client application accessing IHE client components.

Client-1 is implemented in java and it can directly access IHE client library API.

Client-2 is implemented in .net and it can access IHE components through web services.

The ITI infrastructure integration profile can be obtained from http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf, and the transactions details can be obtained from http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf.

Besides the above three brokers, IheService provides CDA/CCD document creation interfaces that can create Referral Summary, Discharge Summary, Emergency Department Referral, Scanned Document and BPPC Consent Document. Also, IheService provides a user friendly document submission API, which wraps up the document submission in the DocumentBroker, with rich metadata.

4.1 IHE Profiles

4.1.1 PIX – Patient Identifier Cross-referencing

Actors: There are 3 actors in this profile, namely Patient Identity Source (PIX Source), Patient Identifier Cross-referencing Manager (PIX Manager) and Patient Identifier Cross-referencing Consumer (PIX Consumer). In Braid, we implemented PIX Source and PIX Consumer.

Transactions: We have implemented the following transactions:

- Patient Identity Feed – Send patient identity from the PIX Source to the PIX Manager. There are 3 methods associated with this transaction, namely, createPatient, updatePatient and mergePatients.

- Patient Identity Query (PIX Query) – Find a patient identity in other patient identifier domain (Assigning Authority) from the PIX Manager using the patient identity of the Misys domain.

The PIX Source Actor is represented by the IPatientConsumer interface as follows:

public interface IPatientConsumer {

/**

* Values acceptable as reasons for creating a new patient within

* Braid.

public enum CreationReason {INPATIENT_ADMIT, INPATIENT_PREADMIT, OUTPATIENT_REGISTER}

/**

* Start this patient consumer. Do any initialization and logging that

* might be needed.

public void start();

/**

* Stop this patient consumer. Do any deinitialization and logging that

* might be needed.

public void stop();

/**

* Create a new patient with the supplied demographics. The reason the patient

* was created must be supplied.

* @param patient The demographics of the new patient

* @param reason The reason the patient was created

* @throws PatientException When there is an error creating the patient

public void createPatient(PatientDescriptor patient, CreationReason reason) throws PatientException;

/**

* Update the demographic information associated with a patient.

* @param patient The new demographics for the patient

* @throws PatientException When there is an error updating the patient

public void updatePatient(PatientDescriptor patient) throws PatientException;

/**

* Merge the two patients demographics together as they represent the

* same patient. The patient will now be known by the deomgraphics and IDs

* in the first patient. The second patient IDs will no longer be used.

* @param patientMain The patient demographics and IDs to remain

* @param patientOld The patient demographics and IDs found to be the same as the main patient

* @throws PatientException When there is an error merging the two patients together

public void mergePatients(PatientDescriptor patientMain, PatientDescriptor patientOld) throws PatientException;

}

The PIX Consumer Actor is represented by the IPatientXref interface as follows:

public interface IPatientXref {

/**

* Start this document xref. Do any initialization and logging that

* might be needed.

public void start();

/**

* Stop this document xref. Do any deinitialization and logging that

* might be needed.

public void stop();

/**

* Ask the patient ID cross reference source for all of the IDs that it

* knows for a given patient. If a Misys Unique ID is discovered, it will be

* returned. Other IDs are added directly to the patientId object.

* @param patientId The known IDs for the patient of interest

* @return The Misys Unique ID for the patient according to this cross reference source

* @throws PatientException When there is a problem talking with the cross reference source

public String getPatientIds(PatientID patientId) throws PatientException;

/**

* Get an informative name for this patient ID cross reference source for use in error

* and log messages.

* @return An informative name for this patient ID cross reference source

public String getName();

}

4.1.2 PDQ – Patient Demographics Query

Actors: There are 2 actors in this profile, namely Patient Demographics Supplier (PDQ Supplier) and Patient Demographics Consumer (PDQ Consumer). In Braid, we implemented PDQ Consumer.

Transactions: We have implemented the following transactions:

- Patient Demographics Query (PDQ Query) – Find patients by searching the patient demographic information from the PDQ Supplier. The corresponding implemented method in Braid is findPatients.

The PDQConsumer Actor is represented by the IPatientSource interface as follows:

public interface IPatientSource {

/**

* Start this patient source. Do any initialization and logging that

* might be needed.

public void start();

/**

* Stop this patient source. Do any deinitialization and logging that

* might be needed.

public void stop();

/**

* Find all of the patients from a particular patient source

* that have properties matching those in the given descriptor.

* @param descriptor The patient description to match against

* @return The patients found that match the description

* @throws PatientException When there is a problem making the query

public List<PatientDescriptor> findPatients(PatientQuery query) throws PatientException;

/**

* Get an informative name for this patient source for use in error

* and log messages.

* @return An informative name for this patient source

public String getName();

}

4.1.3 XDS

Actors: There are 4 actors in this profile, namely Document Source, Document Repository (The server to store documents), Document Registry (The server to store document metadata) and Document Consumer. In Braid, we implemented Document Source and Document Consumer.

Transactions: We have implemented the following transactions:

- Provide and Register Document Set (XDS Submit) – Submit a document set to Document Repository. The corresponding implemented method in Braid is submitDocument.

- Query Registry (XDS Query) – Find documents from Document Registry and retrieve documents from Document Repository. The implemented methods are findDocuments and getHistory.

An XDS Source Actor should implement the following IDocumentConsumer interface:

public interface IDocumentConsumer {

/**

* Start this document consumer. Do any initialization and logging that

* might be needed.

public void start();

/**

* Stop this document consumer. Do any deinitialization and logging that

* might be needed.

public void stop();

/**

* Submit a new document to this consumer.

* @param document The complete document to submit, metadata and content

* @param description Description of this document

* @param contentCode The content code for this document

* @throws DocumentException When this consumer has a problem submitting the document

public void submitDocument(Document document, String description, XdsContentCode contentCode) throws DocumentException;

/**

* Submit a set of documents to this consumer.

* @param documents The collection of documents to submit, metadata and content

* @param description Description of this document set

* @param contentCode The content code for this document set

* @throws DocumentException When this consumer has a problem submitting the documents

public void submitDocuments(Collection<Document> documents, String description, XdsContentCode contentCode) throws DocumentException;

}

An XDS Consumer Actor should implement the following IDocumentSource interface:

public interface IDocumentSource {

/**

* Start this document source. Do any initialization and logging that

* might be needed.

public void start();

/**

* Stop this document source. Do any deinitialization and logging that

* might be needed.

public void stop();

/**

* Get all of the documents that match the given document query.

* @param query The document query

* @return The documents in this source that match the query

* @throws DocumentException When there is a problem making the query

public List<Document> findDocuments(DocumentQuery query) throws DocumentException;

/**

* Gets the history, the immediately replaced document, of a given documentId.

* @param documentId the id of the document whose immediately replaced docs are to be found

* @return the immediately replaced docs

* @throws DocumentException where there is a problem getting the history.

public List<Document> getHistory(String documentId) throws DocumentException;

}

4.1.4 ATNA

The ATNA profile contains two parts. The first part AT stands for Audit Trail; and the second part NA for Node Authentication. The Node Authentication is integrated with each Secure Transaction. Here the main focus is Audit Trail.

The following methods are in IheAuditTrail.java

/** Sends actor start log message. Must be called when actor is started. */

public void start()

/** Sends actor stop log message. Must be called when actor is finished. */

public void stop()

/** Call when the node fails to authenticate itself with another node.

* Generally you don't log successes since there can be many of those.

* Described in DICOM Supp95 A 1.3.14 as Security Alert.

* Described in ITI TF-2 p. 172 as Node-authentication-failure.

public void nodeAuthenticationFailure(SuccessCode success, IConnectionDescription otherServer)

/** Call when a user authenticates himself.

* Described in DICOM Supp95 A 1.3.15 as User Authentication.

* Described in ITI TF-2 p. 172 as Node-authentication-failure.

public void userLogin(SuccessCode success, ActiveParticipant user)

/** Call when a user logs out.

* Described in DICOM Supp95 A 1.3.15 as User Authentication.

* Described in ITI TF-2 p. 172 as Node-authentication-failure.

public void userLogout(SuccessCode success, ActiveParticipant user)

/** Call when a query is made.

* Described in DICOM Supp95 A 1.3.13 as Query.

* Described in ITI TF-2 p. 173 as Query Information

* @param destination The description of the connection used to issue the query.

public void queryIssued(IConnectionDescription destination, ParticipantObject patient)

/////************** ILL DEFINED MESSAGES *********************

/** Call to log a document submission and registration event.

public void recordCreated(ParticipantObject patient)

/** Call to log a patient record find and deletion event.

public void recordDeleted(ParticipantObject patient)

/** Call to log a patient record find and modification event.

public void recordModified(ParticipantObject patient)

/** Call to log a request to view a patient record.

public void recordAccessed(ParticipantObject patient)

4.1.5 CT

The Consistent Time is not embedded in Braid. There are plenty of free software products available for downloading that implements NTP.

4.2 Integration with Braid

4.2.1 Patient Broker

The PatientBroker class provides a facade to manage IHE patient create, update, merge and search.

The following steps describe to create, update or merge patient using Braid:

Create a PatientDescriptor object with all patient demographics information.
Create an instance of PatientBroker.
To register a patient call patientBroker.createPatient() method with a PatientDescriptor object and reason.
To update patient call patientBroker.updatePatient() method with a PatientDescriptor object
To merge patient call patientBroker.mergePatient() method with two PatientDescriptor objects.

4.2.2 Document Broker

The PatientBroker class provides a facade to submit and query document.

To submit documents:

Create one or more Document objects with document metadata and attachements.
Create an instance of DocumentBroker.
To submit one or multiple documents call documentBroker.submitDocuments() with a collection of Document objects

To query documents:

1. Create a DocumentQuery object with query parameters

2. To query documents call documentBroker.findDocuments() with a DocumentQuery object.

4.2.3 Ihe Service

IheService class provides a façade to create documents and submit documents to XDS repository. The IheService class can create the following documents.

Referral Summary – call buildReferralSummary(ReferaralSummaryData) method to create Referral Summary document.
Discharge Summary – call buildDischargeSummary(DischargeSummaryData) method to create Discharge Summary document.
ED Referral – call buildEDReferral (EDReferaralData) method to create ED Referral document.
Scanned Document – call buildScannedDocument(ScannedDocumentData) method to create Scanned document.
Consent Document – call buildConsentDocument(CosentDocumentData) method to create BPPC Consent document.

The IheService class can be used to submit the documents to XDS repository.

Call submitDocumentSet(SubmissionSet set) method in IheService class to submit the documents. Here SubmissionSet contains multiple documents.

4.2.4 Document Retrieving

Documents associated with a patient can be retrieved from XDS repository using DocumentBroker class. There are two steps involved in this action: first, generates a XDS Query, and send it to XDS Registry. The XDS Registry returns a list of document metadata associated with the current patient. One of the metadata is the URI where the document exists in the XDS Repository. So the second step is to use http or https protocol to retrieve the document content from the XDS Repository.

5 Configuration

We have a separate document, “IHE Actor Configuration”, with detailed description. Please refer IHE actors configuration document.

6 API Usage and Samples

Note: all the examples below can be found Test folder in Braid source code.

6.1 Load and Install Actor Configuration

ConfigurationLoader loader = ConfigurationLoader.getInstance();

URL url = IBMTest.class.getResource("/ihetest/IheActors.xml");

File file = new File(url.toURI());

loader.loadConfiguration(file, false);

Collection actors = loader.getActorDescriptions();

//reset to add log file

loader.resetConfiguration(actors, "c:\\testlog.xml");

6.2 Create a Patient

PatientDescriptor patient = _createPatient();

PatientBroker patientBroker = PatientBroker.getInstance();

patientBroker.createPatient(patient, IPatientConsumer.CreationReason.OUTPATIENT_REGISTER);

6.3 Update a Patient

PatientDescriptor patient = _createPatient();

patient.setNameSuffix("III");

PatientBroker patientBroker = PatientBroker.getInstance();

patientBroker.updatePatient(patient);

6.4 PIX Query.

The Pix Query is indirectly used by Patient.java (the hasId, getIdList, hasMisysUniqueId, getMisysUniqueId). They all internally invoke the getPatientIds method in the PixConsumer.java.

PatientBroker patientBroker = PatientBroker.getInstance();

PatientDescriptor patient = _createPatient();

PatientID pid = patient.getPatientId();

String misysId = pid.getMisysUniqueId();

if ( pid.hasId("MIEH") ) {

List<String> ids = pid.getIdList("MIEH");

}

6.5 PDQ Query

PatientBroker patientBroker = PatientBroker.getInstance();

PatientQuery query = new PatientQuery();

query.setNameFirst("Jemi%");

query.setNameLast("Lope%");

List<PatientDescriptor> pds = patientBroker.findPatients(query);

6.6 Create a Referral Summary Document

ReferralSummaryData data = new ReferralSummaryData() ;

//provide relevant clinical data and metadata to the data object

CCDDocument doc = IheService.buildReferralSummary (data);

6.7 Create a Discharge Summary Document

DischargeSummaryData data = new DischargeSummaryData() ;

//provide relevant clinical data and metadata to the data object

CCDDocument doc = IheService.buildDischargeSummary (data);

6.8 Create an Emergency Summary Document

EDReferralData data = new EDReferralData() ;

//provide relevant clinical data and metadata to the data object

CCDDocument doc = IheService.buildEDReferral(data);

6.9 Create a Scanned Document

ScannedDocumentData data = new ScannedDocumentData () ;

//provide relevant data and metadata to the data object

CCDDocument doc = IheService. buildScannedDocument(data);

6.10 Create a BPPC Consent Document

ConsentDocumentData data = new ConsentDocumentData() ;

//provide relevant data and metadata to the data object

CCDDocument doc = IheService. buildConsentDocument(data);

6.11 Submit a Document

//Approach 1

SubmissionSet sset = new SubmissionSet();

sset.setDocuments( documents );

sset.setSubmissionSetMetaData( ssetMetadata );

IheService.submitDocuments(sset);

//Approach 2

DocumentBroker docBroker = DocumentBroker.getInstance();

Document doc = _createDocument("testdata/CDASample1.xml", "CDA Sample1" );

docBroker.submitDocument(doc, "Submit a test doc", SharedEnums.XdsContentCode.REFERRAL_SUMMARY);

6.12 Query Document

Build a DocumentQuery object, which can contain patient id and/or start/end dates.

DocumentBroker docBroker = DocumentBroker.getInstance();

PatientDescriptor pd = _createPatient();

DocumentQuery query = new DocumentQuery();

query.setPatientId(pd.getPatientId());

List<Document> docs = docBroker.findDocuments( query );

6.13 Submit Multiple Documents

DocumentBroker docBroker = DocumentBroker.getInstance();

Document doc2 = _createDocument("testdata/CDASample2.xml", "CDA Sample2");

Document doc3 = _createDocument("testdata/CDASample3.xml", "CDA Sample3");

List<Document> docs = new ArrayList<Document>();

docs.add( doc2 );

docs.add( doc3 );

docBroker.submitDocuments(docs, "Test Submiting two docs", SharedEnums.XdsContentCode.REFERRAL_SUMMARY);

6.14 Replace a Document and Find its History

DocumentBroker docBroker = DocumentBroker.getInstance();

Document doc2 = _createDocument("testdata/CDASample2.xml", "CDA Sample2");

docBroker.submitDocument(doc2, "Submit a test doc", SharedEnums.XdsContentCode.REFERRAL_SUMMARY);

//replace doc2 with doc4

Document doc4 = _createDocument("testdata/CDASample4.xml", "CDA Sample4");

String doc2id = doc2.getUniqueId();

doc4.setReplacesId( doc2id );

docBroker.submitDocument(doc4, "Test replacing docs", SharedEnums.XdsContentCode.REFERRAL_SUMMARY);

//get the history of doc4

List<Document> historyDocs = docBroker.getHistory( doc4.getUniqueId() );

6.15 Audit Trail

IheAuditTrail log = new IheAuditTrail("Fake Actor", repositories);

log.start();

log.nodeAuthenticationFailure(SuccessCode.MinorFailure, otherServer);

log.userLogin(SuccessCode.MinorFailure, log.getUser());

log.userLogin(SuccessCode.Success, log.getUser());

log.queryIssued(otherServer, patient);

log.recordCreated(patientdocument);

log.recordDeleted(patientdocument);

log.recordModified(patientdocument);

log.recordAccessed(patient);

log.recordAccessed(patientdocument);

log.userLogout(SuccessCode.Success, log.getUser());

log.stop();