IHE ACCELERATOR GUIDE
Release 9.2
“Initiate,” “Initiate Identity Hub,” “Initiate Master Data Service,” and the Initiate logo are registered trademarks in
the United States and certain foreign jurisdictions. “Initiate Consumer,” “Initiate Organization,” “Initiate Citizen,”
“Initiate Patient,” “Initiate Provider,” and “Initiate Inspector” are trademarks of Initiate Systems. All rights
reserved. All other marks are owned by their respective owners.
The information in this document is protected under the applicable federal law as an unpublished work, and is
confidential and proprietary to Initiate Systems, Inc. Its use, disclosure, reproduction, or publication, in whole or
in part, without the express prior written consent of Initiate Systems, Inc. is prohibited.
© 2010 Initiate Systems, Inc.
Contents
Additional reference documentation ............................................................................................................. 5
How to get help .............................................................................................................................................. 5
ATSC ........................................................................................................................................................... 5
Support Center Knowledge Base ................................................................................................................ 5
Acknowledgments .......................................................................................................................................... 6
Chapter 1 IHE Overview .................................................................................................................................. 7
XDS.b profile .................................................................................................................................................. 7
Actors ......................................................................................................................................................... 7
Transactions ................................................................................................................................................ 8
XDS messages ............................................................................................................................................ 8
Metadata ................................................................................................................................................... 8
IDs in XDS messages ............................................................................................................................... 9
XDS Document Registry workflow
............................................................................................................ 9
Document lifecycle .................................................................................................................................... 10
Availability status ................................................................................................................................... 10
Document relationships .......................................................................................................................... 10
XDS.b use case ......................................................................................................................................... 11
ATNA logging profile .................................................................................................................................... 11
PIX profile ................................................................................................................................................... 12
Actors ....................................................................................................................................................... 12
Transactions .............................................................................................................................................. 12
PDQ profile .................................................................................................................................................. 12
Actors ........................................................................................................................................................ 12
Transactions .............................................................................................................................................. 13
Chapter 2 Getting started .............................................................................................................................. 15
Prerequisites ................................................................................................................................................ 15
Install components ....................................................................................................................................... 15
Chapter 3 IHE Accelerator Project ............................................................................................................... 17
Solution overview ......................................................................................................................................... 17
Project components .................................................................................................................................... 18
MDE environment and Initiate® Workbench project .................................................................................. 18
Proprietary and Confidential
3
www.Initiate.com
Book Title
Initiate Inspector™ .................................................................................................................................... 19
Chapter 4 Web Service .................................................................................................................................. 23
proxy.config.xml ........................................................................................................................................... 24
proxy.config.xsd ........................................................................................................................................... 26
Initiate-IHE.war ............................................................................................................................................. 26
Status page .................................................................................................................................................. 27
Install the Initiate IHE web service
............................................................................................................. 27
Storing the proxy.config.xml and shared libraries ...................................................................................... 29
Installing the Initiate IHE web application .................................................................................................. 29
Updating an existing installation (9.0+) ...................................................................................................... 30
Updating an existing installation (8.7 to 9.0) ..............................................................................................30
Change logging configuration on Tomcat ................................................................................................. 30
Enable SSL for Broker to Hub communication ......................................................................................... 31
Enable ATNA Logging ............................................................................................................................... 31
Chapter 5 Configuration Files ....................................................................................................................... 33
XML and XPath ........................................................................................................................................... 33
XPath ........................................................................................................................................................ 33
XML
......................................................................................................................................................... 35
Inbound broker configuration files ............................................................................................................. 42
CUST_AddPatient.ini ............................................................................................................................... 43
IHE_InboundProcessor.ini ......................................................................................................................... 43
MsgReader<profile>.ini
........................................................................................................................... 43
RegisterDocumentSetB.ini ........................................................................................................................ 43
Query broker configuration files
................................................................................................................. 44
CUST_QueryPatient.ini ............................................................................................................................ 44
IHE_QueryHL7(v2 and v3).ini .................................................................................................................... 44
IHE_QueryCancelRequestHL7v3.ini ......................................................................................................... 44
IHE_QueryCancelResponseHL7v3.ini ...................................................................................................... 44
IHE_QueryPDQ.inii .................................................................................................................................... 44
IHE_QueryPIX.ini ...................................................................................................................................... 44
RegistryStoredQuery.ini ............................................................................................................................. 44
XDSProcessRequest.ini ............................................................................................................................ 44
ATNA logging configuration file .................................................................................................................... 45
Query error responses ................................................................................................................................. 45
XDS stored query configuration ................................................................................................................... 46
Testing the XDS solution .............................................................................................................................. 46
Chapter A Glossary ....................................................................................................................................... 47
Chapter B OID Loader ................................................................................................................................... 51
Initiate Systems, Inc.
4
Proprietary and Confidential
Introduction
This document provides an overview of the profiles set forth by Integrating the Healthcare Enterprise (IHE) for
various Connectathon events and the solutions to meet the profiles as implemented by Initiate Systems using
the Message Broker Suite. The content in this document is intended to provide the Initiate Services team with
information that they might utilize in their various healthcare-related projects. The IHE profile descriptions do
not attempt to provide a complete definition of the specifications, rather they offer a high-level overview.
Additional reference documentation
For additional information about the Message Broker Suite components, refer to the following documents:
Message Broker Suite Reference Guide
HL7 Query Adapter Reference Guide
Initiate Master Data Service® Master Data Engine Installation Guide
Workbench Reference Guide
Workbench Installation Guide
Initiate Inspector™ User Guide
Initiate Inspector™ Installation and Configuration Guide
For information about the IHE and IHE specifications, refer to the IHE website (http://www.ihe.net).
How to get help
ATSC
Each organization designates two (2) or more individuals to act as Authorized Technical Support Contacts
(ATSC) for Initiate software issues. These individuals interact with users in your organization and, when
necessary, work with the technical support staff at Initiate Systems, Inc. to resolve issues.
When you have questions or concerns about the software, and if the information in this guide does not answer
your questions, contact your ATSC. Your ATSC will try to determine if the problem is a hardware system issue
or an operational issue before contacting Initiate Systems for assistance.
Support Center Knowledge Base
We realize that you might have questions that may not be addressed in the documentation, training, or within
your standard workflow procedure. The Initiate Systems Customer Support Web site
(https://support.initiatesystems.com/) provides a knowledge base that offers additional information about
Initiate products and their use. New items are frequently added, so please refer to the Web site when possible.
Proprietary and Confidential
5
www.Initiate.com
IHE Accelerator Guide
Acknowledgments
Third party software code files are shipped along with the Initiate Master Data Service Release 9.2 (the “Third
Party Code”). Third Party Code files are the property of their respective owners and not Initiate Systems and
Initiate Systems claims no rights in or to the Third Party Code. Your use and access to the Third party Code is
governed by the specific restrictions and limitations set forth in the applicable licenses provided by the Third
Party Code owners. The Third Party Code is provided to you by Initiate solely for use with the Initiate Master
Data Service product and Initiate Systems does not authorize or promote any other use of the Third Party
Code by you. The full text of the applicable Third Party Code licenses is provided in the Third Party
License.zip file included along with the Initiate Master Data Service Release 9.2, located on the Initiate
Systems product CD or downloaded CD image.
Initiate Systems, Inc.
6
Proprietary and Confidential
1 IHE Overview
To provide optimal patient care, the creation, management and access to comprehensive electronic health
records (EHR) in a secure and efficient manner is a top priority. IHE is at the forefront of setting the standards
for information exchange among healthcare systems.
Through forums and events, such as the Connectathon, IHE defines the technical framework for implementing
message standards to achieve specific clinical goals. Connectathon events encourage participants to develop
solutions and engage in rigorous testing to meet the technical requirements. The technology benefits gained
from these events are shared with the healthcare community in an effort to encourage their adoption as an
industry standard.
For Initiate Systems, participation in events like the Connectathon offers valuable exposure to healthcare IT
decision makers and enables Initiate to develop product functionality that can assist our implementation teams
to meet customer demands.
Important: This chapter presents a high-level overview of the IHE profiles and the profile transactions that
were met using the Initiate Master Data Service® and Message Broker Suite. Because IHE specifications are
fluid, this document is not meant to describe the complete specifications for the supported profiles. For
detailed requirements, refer to the IHE IT Infrastructure (ITI) Technical Framework (http://www.ihe.net).
For a description of various terms and concepts presented in this document, refer to Appendix A, “Glossary” on
page 47.
XDS.b profile
Cross Enterprise Document Sharing (XDS) registers and shares electronic health record documents between
healthcare enterprises, ranging from physician offices to clinics to acute care in-patient facilities. XDS.b
support enables healthcare organizations that belong to an XDS Affinity Domain to cooperate in sharing clinical
records (documents).
Note: The 9.2 release supports XDS.b.
Actors
While the Initiate Master Data Service® participates in only a portion of the XDS profile, the full profile
requirement includes the following actors:
Document Repository - is responsible for storing documents in a transparent, secure, reliable, and
persistent manner and responding to document retrieval requests. The repository is responsible for
Proprietary and Confidential
7
www.Initiate.com
IHE Accelerator Guide
assigning a Uniform Resource Identifier (URI) to a document and this URI is used by the consumer
during requests.
Document Registry - is responsible for storing information about the documents so that they can be
easily located, selected and retrieved irrespective of the locality of the repository in which they are
stored. The registry maintains metadata about each registered document in a document entry. A
registry can also enforce some healthcare-specific technical policies at the time of document
registration. The Initiate Master Data Service® Hub serves as a Document Registry.
Document Source - the producer and publisher of the document. The document source supplies the
metadata to the registry, which in turn forms the XDS document entry used for query purposes by
consumer systems.
Document Consumer - the source requesting the document contents from the repository.
Patient Identity Source - is the provider of a unique patient identifier and maintains certain patient
identity demographics.
Integrated Document Source/Repository - combines the functionality of a document source and
document repository.
Transactions
The Initiate® IHE Accelerator supports the following required IHE transactions:
Registry stored query. Registry stored queries are predefined queries that return folders and/or
documents. IHE has predefined IDs that identify the type of query that needs to be satisfied.
Register document set.b. Using SOAP, this transaction moves document metadata from the
document repository to document registry. There are no document attachments. A document
repository actor initiates the transaction and allows the repository actor to register one or more
documents in a document registry. The document metadata is used to create the XDS submission set,
documents, and folder entries in the registry. The registry ensures that document metadata is valid
before registration.
Successful processing of the following transactions are optional; however, the IHE Accelerator supports these
transactions.
Multiple document submission - the document source includes multiple documents in a single
submission set request.
Document life cycle management - the source submits an addendum to another document
already existing in the registry and repository, and submits a document transformation of another
document existing in the registry and repository.
Folder management - the source creates a folder, adds one or more documents to the folder.
Consumers can then query the registry for the folder.
XDS messages
To have a basic understanding of XDS messages, it is helpful to understand the metadata objects and the IDs
contained within the messages.
Metadata
An XDS message consists of four predefined metadata objects:
Association
Classification
ExtrinsicObject
RegistryPackage
Initiate Systems, Inc.
8
Proprietary and Confidential
1 IHE Overview
The Association is used to define the parent/child relationships between the metadata objects (ExtrinsicObject
[document] and RegistryPackage [folder or submission set]). It also defines the association type, which
determines the action taken between the objects.
The Classification is used to define metadata object types (ExtrinsicObject and RegistryPackage; again
document and folder/submission set). The Classification attributes, classificationNode and classificationObject,
explain the classification definition. The classificationNode defines the metadata object type, and the
classificationObject references the ID of the metadata object.
The ExtrinsicObject, also called DocumentEntry, contains the document information. The ExtrinsicObject is
marked as a document via the objectType or Classification definition. The ExtrinsicObject must contain a
UUID, a document unique ID, a patient ID and a reference (URI) to a repository. If any of these values are
missing the object is deemed invalid.
The RegistryPackage contains either folder or SubmissionSet information. All submission (inbound) messages
must contain a submissionSet. A submissionSet is a way to keep history of the documents included in a
submission.
IDs in XDS messages
All objects have a Universally Unique Identifier (UUID) assigned via the ID attribute. The UUID is a permanent
global identifier that creates a unique identity for objects. UUIDs are assigned by the Document Repository or
Document Registry. An ID value that has the prefix urn:uuid: is assumed to be a UUID.
Symbolic IDs can be found within the same places as UUIDs, but are used temporarily within a fixed context.
For example, an ExtrinsicObject may have a symbolic ID value for its ID attribute and all references to that
object with the submission will use that symbolic ID. A reference to an object already in the Document Registry
must use a UUID since that is a permanent global ID. Refer to the IHE specifications for more information on
symbolic IDs.
XDS Document Registry workflow
The XDS profile consists of two primary workflows: submission (inbound) and query. The submission workflow
must be able to ensure referential data integrity between folders, submission sets and documents to adhere to
the XDS profile. It must also be able to build parent/child relationships between the XDS data objects.
For a description of the IHE business rules for a submission workflow, refer to the IHE specifications.
The query workflow must be able to retrieve folders, submission sets and/or documents via the message
based query parameters.The query allows clients to retrieve documents in a registry. Query examples include:
Query by patient ID for a time interval, by document types(s), by practice settings(s), or by author
person
Query by document source
Query for folders updated during a time interval
Query for all documents in folder or submission set
Query by time of submission
Refer to IHE specifications for a description of all required query elements in the reference document.
Queries have two response types, LeafClass and ObjectRef. The LeafClass response returns the full metadata
associated to the object. The LeafClass response is used when the client expects only a handful of documents
in the response. The ObjectRef response is used when a large number of documents will be returned. The
returned document references, from the ObjectRef response, are used to retrieve more detailed information on
the documents (LeafClass response) in subsequent searches.
Proprietary and Confidential
9
www.Initiate.com
IHE Accelerator Guide
Document lifecycle
The availability status of a document and the document relationships influence the lifecycle of an XDS
document.
Availability status
Each document contained in an XDS document registry is assigned one of the following availability status
codes:
Approved: Available for patient care (assumes that it is authenticated, if applicable)
Deprecated: Obsolete, will not be returned in the result of a stored query
The XDS document availability status is set to “approved” after the XDS document repository and the XDS
document registry have successfully processed a submission request.
An “approved” XDS document may be changed to “deprecated” under certain circumstances, which are
detailed in the IHE specifications.
Document relationships
XDS documents may be related to predecessor documents by one of the following methods:
Replacement (RPLC)
Addendum (APND)
Transformation (XFRM)
Transformation-Replacement (XFRM_RPLC)
These relationships between XDS documents are tracked in the XDS document registry. The parent
relationship attribute contained in the metadata of such documents is a coded value that describes the type of
relationship. An original document has no parent and, consequently, its parent ID and parent relationship are
absent. The XDS document registry rejects submissions that contain relationships to documents that are not
registered or have been “deprecated”.
A replacement document is a new version of an existing document. The replacement document has a new
document ID. The parent ID attribute contains the document ID of the document entry associated with the
previous version of the XDS document, and the parent relationship contains the code “RPLC”. The document
entry for the previous version will have its availability status changed to “deprecated”.
An addendum is a separate XDS document that references a prior document, and may extend or alter the
observations in the prior document. It modifies the parent document, but the parent document remains a valid
component of the patient record and remains in the “approved” state or available for care. The addendum XDS
document metadata contains the identifier of the previous XDS document version in parent ID, and the parent
relationship contains the “APND” code.
A transformed document is derived by a machine translation from some other format. Examples of transformed
documents could be CDA documents converted from DICOM Structured Reporting (SR) reports, or a rendering
of a report into a presentation format such as PDF. The transformed XDS document contains the document ID
of the previous version in the parent ID, and the parent relationship contains the code “XFRM”. XDS Affinity
Domains may define rules that determine whether a transformed XDS document replaces the source. While
the transformed document typically does not replace the source; in the case where it does, an additional parent
relationship of type “RPLC” is used.
Again, the document relationships can potentially change as new specifications are developed. Refer to http://
www.ihe.net to ensure you understand the latest specifications.
Initiate Systems, Inc.
10
Proprietary and Confidential
1 IHE Overview
XDS.b use case
A doctor (general practitioner) wants to pull up records for a patient who recently visited the emergency room
(ER) for a broken leg. An x-ray of the leg was taken when the patient was admitted to the ER. The ER stored
the x-ray in their x-ray document repository. The doctor pulls up the patient’s record via his own office system.
Linked to the patient's profile are his x-rays. The doctor clicks on the link in the patient record. The doctor's
system (the registry) determines where the x -rays are stored across the enterprise based on document
location information stored as part of the patient's profile. The doctor views the x-rays, pulled from the correct
enterprise repository. The doctor then evaluates the patient, makes notes about the visit and dispenses
additional medications and treatment recommendations. The patients’ visit records are later scanned. The new
record is submitted to the local repository and registered with the patient profile in the document registry for
future user viewing.
ATNA logging profile
To assist in the implementation of confidentiality policies, the Audit Trail and Node Authentication (ATNA)
profile describes authenticating systems using certificates and transmitting PHI-related audit events to a
repository. The need for authentication and audit trails is due to the assumption that documents (patient
records) are being exchanged between machines and, in some cases, being stored on a recipient machine. All
local or enterprise-wide healthcare systems that manage or process PHI are affected by ATNA.
The ATNA profile dictates access control by limiting network access between nodes and limiting access to
each node to authorized users. Network communications between secure nodes in a secure domain are
restricted to only other secure nodes in that domain. Secure nodes limit access to authorized users as
specified by their local authentication and access control policy.
User Accountability is provided through Audit Trail. The Audit Trail allows security officers to audit activities,
assess compliance with a secure domain’s policies, detect instances of non-compliant behavior, and facilitate
detection of improper creation, access, modification and deletion of Protected Health Information (PHI).
The Initiate® IHE solution uses SSL to authenticate users. Audit logging can be enabled to produce ATNA logs
for the actions listed below. Configuration is set in proxy.config.xml file. ATNA messages are written to the
Initiate-IHE-ATNA.log file.
RegisterDocument-b
RegistryStoredQuery
PRPA_IN201301UV02 - Patient Registry Record Added
PRPA_IN201302UV02 - Patient Registry Record Revised
PRPA_IN201304UV02 - Patient Registry Record Merged
PRPA_IN201305UV02 - Patient Registry Find Candidates Query
PRPA_IN201309UV02 - Patient Registry Get Identifiers Query
Note: The specifications for HL7v3 ATNA logging were not available at the time this document was published,
however ATNA logging for RegisterDocument-b and RegistryStoredQuery are fully implemented in the IHE
Accelerator.
Proprietary and Confidential
11
www.Initiate.com
IHE Accelerator Guide
PIX profile
PIX (Patient Identifier Cross-reference) profile supports the cross-referencing of patient identifiers from multiple
Patient Identifier Domains (hospitals, clinics, physician offices, laboratories, etc.). These cross-referenced
patient identifiers are then used by “identity consumer” systems to correlate information about a single patient
from sources that know the patient by different identifiers.
Actors
While the Initiate Master Data Service® participates in only a portion of the PIX profile, the full profile
requirement includes the following actors:
Patient Identity Source - This is a single source system responsible for assigning the unique Patient
Identifier. Patient Identity Source actors are responsible for providing high quality data to the consumer
and manager. Also called Patient Identity Domain.
Patient Identifier Cross-reference Consumer - This is a consuming system that requests, and
sometimes stores, information about a patient. The Consumer actor queries for sets of cross-reference
identifiers or may use both a notification about cross-reference changes and a query transaction to
request information.
Patient Identifier Cross-reference Manager - This system is responsible for creating, maintaining
and providing lists of identifiers that are aliases of one another across different Patient Identifier
Domains.
Transactions
Successful completion of the following transactions are required for IHE-compliance.
Patient Identity Feed - Allows a Patient Identity Source actor to notify a Patient Identity CrossReferencing actor of all events related to patient identification (creation, update, merge, etc.). A Patient
Identity Feed triggers on Admit/Register or Update messages.
PIX Query - Enables a Patient Identity Consumer to find out the identification of a patient in different
Patient Identification Domains by using the services of a Patient Identity Cross-reference Manager
actor.
PIX Update Notification - Allows a Patient Identity Consumer to be notified by the Patient Identity
Cross-reference Manager of changes to the identification of a patient known in the Patient
Identification Domain. When a change is made to a set of cross-referenced patient identifiers, the
Cross-Reference Manager sends a message to the appropriate Patient Identity Consumers. The
Document Registry does not participate in PIX Update Notifications.
PDQ profile
PDQ (Patient Demographics Query) profile supports the ability for multiple distributed applications to query a
patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s
demographic (and, optionally, visit or visit-related) information directly into the application.
Actors
There are two actors directly involved with PDQ:
Patient Demographics Supplier - supplies the patient information to the requesting consumer. The
Initiate Master Data Service® acts as the supplier in this profile.
Patient Demographics Consumer - is the requesting party.
Initiate Systems, Inc.
12
Proprietary and Confidential
1 IHE Overview
Transactions
The Patient Demographics Query transaction is required for both the Patient Demographics Supplier and
Consumer. Patient Demographics and Visit Query is an optional transaction for both actors.
The Patient Demographics Supplier receives patient registration and update messages from enterprise
sources and responds with the appropriate information. For IHE purposes, the Supplier must contain current
demographic information.
The Supplier receives either a Patient Demographics or Patient Demographics and Visit query from the
Consumer and returns the demographics from the single domain that is associated with the application to
which the query was sent. Identifier information may be returned from multiple or single domains.
Proprietary and Confidential
13
www.Initiate.com
IHE Accelerator Guide
Initiate Systems, Inc.
14
Proprietary and Confidential
2 Getting started
Prerequisites
You will need to install the following components:
Master Data Engine 9.2.0
Message Broker Suite 9.2.0 - which includes the following:
IHE Accelerator project - XDS Reference
Web Service
Inbound broker
Query broker
Initiate® Workbench 9.2.0
Initiate Inspector™ 9.2.0 (optional)
Install components
Please refer to the following documentation for information on installing and configuring the various
components:
Initiate Master Data Service® Master Data Engine Installation Guide
Message Broker Suite Reference Guide (for information on installing the Brokers and standard
configuration file details)
HL7 Query Adapter Reference Guide (for information on query instance creation and configuration
files)
Initiate® Workbench Reference Guide (includes Initiate Inspector™ configuration information)
Initiate® Workbench Installation Guide
Initiate Inspector™ Installation and Configuration Guide
Once you have installed the components, continue to Chapter 3 for an overview of the IHE Accelerator Project.
Proprietary and Confidential
15
www.Initiate.com
IHE Accelerator Guide
Initiate Systems, Inc.
16
Proprietary and Confidential
3 IHE Accelerator Project
Solution overview
For ease of implementation, we have created an IHE Accelerator project. The IHE Accelerator project provides
a basic framework from which you can build an XDS.b registry deployment. A Workbench project is included to
assist in defining the basic objects in the registry, and the relationships between these objects. Initialization files
for the Initiate IHE Web Service Broker are also provided, and match the framework configuration. Additionally,
IHE-configured Inbound Message Broker and Query Broker configuration files are provided.
The Initiate solution supports:
The subset of the XDS.b specification known as the document registry
HL7v3
XML formatted messages
SOAP 1.1 and 1.2 (synchronous communication)
The solution further supports two key features: 1) improved Broker search capabilities and 2) parent/child
relationships.
To support the search requirements for XDS, three search filters have been implemented for the brokers.
Date range filter for documents, folders and/or submission sets based on a specified range of dates.
This works exactly like normal date range searches found in components such as Initiate Inspector™.
For example, request/return documents created (submitted) between June 12, 2009 and July 12,
2009.
Deterministic filter that utilizes “AND” logic that returns documents, submission sets, and/or folders
based on an exact specified search criteria. For example, request/return a specific document or folder.
Wildcard filter enabling the use of wildcard characters to search for documents, submission sets, and/
or folders. For example, request/return all documents matching E* Jones.
The search parameters used for documents, folders or submission sets is controlled by the IHE specification.
Taking advantage of the relationship logic in the Master Data Engine and the visual representation of these
relationships via Initiate Inspector™ is one unique feature of the IHE Accelerator solution. Patient records can
be associated to documents and submission sets, documents associated to folders, and folders associated to
submission sets. Relationships are built upon the Patient ID attribute of the document, folder, or submission
set. The relationship rules are created when the Patient ID attribute matches an existing Patient’s MemIdnum.
This chapter discusses the Workbench project and use of Initiate Inspector™. Chapter 4 covers the installation
of the web service and Chapter 5 discusses the Broker configuration files.
Proprietary and Confidential
17
www.Initiate.com
IHE Accelerator Guide
Project components
Components of the IHE Accelerator Project can be found in:
Workbench project, xdsReference.zip, is located in your Broker install directory, e.g. C:\Program
Files\InitiateSystems\Brokers9.2.0\config\xdsReference
Web services files are located in the \proxy directory within your Broker install directory, e.g.
C:\Program Files\InitiateSystems\Brokers9.2.0\proxy. See “Web Service” on
page 23.
Broker configuration files are located in the \config\IHE directory within your Broker install
directory, e.g. C:\Program Files\InitiateSystems\Brokers9.2.0\config\IHE. See
“Configuration Files” on page 33.
MDE environment and Initiate® Workbench project
Since every implementation is different, you can customize the framework provided by the Workbench project
to contain additional attributes, member types or relationships as needed. The four objects included in the IHE
Accelerator are; Person, Submission Set, Folder, and Document. Each of these objects has been defined with
the minimum attributes needed to support an XDS.b registry.
The XDS-only member types have been configured with a minimal algorithm, which allows the system to do
keyed searches against these objects in support of XDS.b required functionality. The Person object has a more
traditional comparison algorithm which can be used to not only search the registry for XDS queries, but can
also provide EMPI capabilities above and beyond standard XDS functionality. The patient ID is the key into the
XDS.b objects. All metadata objects (folders, documents and subsets) have patient IDs associated to them.
The IHE Accelerator includes a set of relationship rules and Initiate Inspector™ configuration (inspector.arm)
for all of the registry objects. This information can be used to query and view the registry contents via Initiate
Inspector™ if desired.
To access the project in Workbench:
1
Unzip the xds_reference.zip to your xdsReference folder.
2
From the Navigator view in Workbench, right click and select Import. Browse to the xdsReference
folder and select the xds.imm. Refer to the Initiate® Workbench Reference Guide for additional details.
A quick look at what you will see in the project:
Member type/Entity types
Assoc/Assoc (Associations)
Person/id
Document/doc
Folder/Folder
Subset/Subset (submission set)
Relationship types:
FOLDERTODOC (folder-to-document)
PATTODOC (patient-to-document)
PATTOSUB (patient-to-submission set)
SUBTODOC (submission set-to-document)
SUBTOFOLDER (submission set-to-folder)
Initiate Systems, Inc.
18
Proprietary and Confidential
3 IHE Accelerator Project
In Initiate Inspector™, these relationships are seen as:
Has Documents (folder-to-document and patient-to-document)
Has Submissions (patient-to-submission set)
Has Folders (submission set-to-folder)
Attribute types: In addition to some of the standard attribute types, you will see the following. These
attribute types have associated implementation-defined segments).
ASSOCIATION (defines document associations)
EXTERNALID (defines external object IDs)
MEMAUTHOR (originating author of document, folder or submission set contents)
NODECLASS (defines the document classification object [metadata])
OBJECTCLASS (defines the object - document, folder, etc)
XDSFILTER (used to define the search filters)
Initiate Inspector™
The relationships between a patient and associated documents, folders, and submission sets can be viewed in
Initiate Inspector™. To view XDS relationships:
1
Search for a member, typically by patient ID or name.
2
Select the desired record from the returned results.
3
Click the Relationship tab.
The following illustrations show two different relationship views.
Proprietary and Confidential
19
www.Initiate.com
IHE Accelerator Guide
Figure 3.1 Patient-to-Submission Set/Documents Relationship
Initiate Systems, Inc.
20
Proprietary and Confidential
3 IHE Accelerator Project
Figure 3.2 Folder-to-Document Relationship
Refer to the Initiate Inspector™ User Guide for detailed instructions.
Proprietary and Confidential
21
www.Initiate.com
IHE Accelerator Guide
Initiate Systems, Inc.
22
Proprietary and Confidential
4 Web Service
Previously, the web-enabled broker used socket connections to connect the web server to the Broker, at which
turn the Broker opened mpinet connections with the Hub. This method meant that each Broker was installed as
a separate service and each service required multiple connections with the Hub.
Through the implementation of Java Native Interface (JNI), the need for Brokers as separately installed
services/daemons is eliminated (the exception to this is the ATNA logger, which is still installed as a service).
Running the Brokers with the Initiate IHE web service means that when you install the Brokers with the intent of
creating an XDS registry, you do not have to create broker instances. With this configuration the Brokers,
libraries, and associated Engine libraries are packaged such that a single, direct line of communication is
created between the Hub and Initiate IHE web service.
The Initiate IHE web service uses three main files to manage processing: proxy.config.xml, proxy.config.xsd
and Initiate-IHE.war. These files are located in your broker install path \proxy directory.
Another added feature of the Initiate IHE web service is the status page, which enables monitoring of message
processing.
Currently, the web service is only supported on Tomcat. Refer to the Initiate Master Data Service® Technology
Requirements for details on supported Tomcat versions.
Proprietary and Confidential
23
www.Initiate.com
IHE Accelerator Guide
proxy.config.xml
The proxy.config.xml file controls the web service and environment configuration, and provides processing
directives for utilizing broker functionality to complete IHE transactions. Those familiar with the services.ini file
will recognize the variables contained in the first part of the file.
When you first open the proxy.config.xml file, you will see a number of REPLACE_ME_WITH... entries. Each of
these entries must be updated with the specifics of your installation. The examples below show an edited file.
The easiest way to handle this is to do a search for “REPLACE_ME_WITH”. Environment variable use, such
as ${MAD_ROOTDIR} is not allowed inside of configuration files running under web services. You must enter
the full path.
Note: Also note that regardless of the operating system on which you are installing, the proxy.config.xml only
accepts forward slashes (/). For example, if you are installing on a Windows® platform your home directory
path may be D:\initiate\software\brokers\. However, it must appear as D:/initiate/software/ in the
proxy.config.xml file.
<proxy.config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="proxy.config.xsd">
<global.config
mad.log_dir=""
mad.log_name="D:/initiate/software/brokers/log/Proxy_log.mlg"
mad.root_dir="D:/initiate/software/brokers/win32-debug"
mad.home_dir="D:/initiate/software/brokers/win32-debug"
mad.broker_dir="D:/initiate/software/brokers/win32-debug"
mad.so_timeout="30"
mad.conn.str="localhost|16000"
mad.login="system"
mad.password="system"
mad.password.scheme="plain"
mad.dtd.dir="D:/initiate/software/brokers/dtd"
ihe.home.community.id="ihe:HomeCommunityId"
>
In the above example, the ihe.home.community.id="ihe:HomeCommunityId" attribute is used in ATNA
logging.
The second part of the file, the body, is where the actual transactions (services) are defined. There are two
types of services: IHE services and generic services.
The IHE portion of the body— handler.config (shown below)—contains the name of the service (e.g.,
"XDS_b_DocumentRegistry" or "PIX Manager") and the service action (e.g.,
RegisterDocumentSet-b", “RegistryStored Query” or “PRPA_IN201301UV02”). The service
name identifies an associated IHE web service (which contains a grouping of IHE actions or profiles). The
action name or element is the action (profile) to be performed, followed by the type of broker (e.g.,
broker.inbound or broker.query) that will process the profile. The associated configuration file (e.g.,
RegisterDocumentSetB.ini) used for the action is also identified. The broker.inbound processes
requests to register or record information in the document registry. The broker.query processes service
requests for information from the registry.
All supported IHE profiles are automatically listed in the proxy.config.xml file. Currently the profiles defined are
XDS.b Document Registry, PIX Manager and PDQ Supplier. Unless you have a reason to deviate from the
IHE standards, you should never have to edit this section.
Initiate Systems, Inc.
24
Proprietary and Confidential
4 Web Service
The example below shows an optional attribute that can be added to the handler.config sections to enable
ATNA logging: atnaLogger="129.6.24.109:8087".
<handler.config serviceName="XDS_b_DocumentRegistry"
atnaLogger="129.6.24.109:8087">
<action actionName="RegisterDocumentSet-b">
<broker.inbound>
<config.file.request>D:/initiate/software/brokers/config/IHE/
msgBroker/RegisterDocumentSetB.ini</config.file.request>
<config.file.reject.response>D:/initiate/software/brokers/config/
IHE/msgBroker/MsgReaderFailureXDS.ini</
config.file.reject.response>
<config.file.success.response>D:/initiate/software/brokers/config/
IHE/msgBroker/MsgReaderSuccessXDS.ini</
config.file.success.response>
<config.file.path>D:/initiate/software/brokers/config/IHE/
msgBroker</config.file.path>
<queue.dir>D:/initiate/software/brokers/inbound</queue.dir>
<queue.success.name>success</queue.success.name>
<queue.reject.name>reject</queue.reject.name>
<attribute.update.queue.dir></attribute.update.queue.dir>
<attribute.update.queue.name></attribute.update.queue.name>
<attribute.update.filter></attribute.update.filter>
<attribute.update></attribute.update>
<manage.duplicates></manage.duplicates>
<application.name></application.name>
<parser.handler.lib>parser_xds.dll</parser.handler.lib>
</broker.inbound>
<message.type.xml>
<xml.doc.handler.lib>document_handler_xds.dll</
xml.doc.handler.lib>
<xml.doc.name></xml.doc.name>
<xml.doc.public.id></xml.doc.public.id>
<xml.doc.system.id></xml.doc.system.id>
<message.type.xml>
</action>
<action actionName="RegistryStoredQuery">
<broker.query>
<config.file>D:/initiate/software/brokers/config/IHE/
queryBroker/RegistryStoredQuery.ini</config.file>
<config.file.path>D:/initiate/software/brokers/config/IHE/
queryBroker</config.file.path>
<queue.dir>D:/initiate/software/brokers/query</queue.dir>
<queue.request.name>req</queue.request.name>
<queue.response.name>resp</queue.response.name>
</broker.query>
</action>
Note that in the example above, the parser.handler.lib is operating-system-specific. This example
shows a Windows library extension of .dll (parser_xds.dll). Other OS libraries will have the OS-specific
extension and follow the convention set by all of our native libraries. The libraries are named in the lib folder
of the proxy install directory.
Proprietary and Confidential
25
www.Initiate.com
IHE Accelerator Guide
Following the IHE-specific actions, there is a section for generic broker services that allows for custom services
and actions. Services can be define to enable adding patient records to the Hub using XML, delimited, fixedlength, or HL7v2 messages. The message type is defined by the <message.type.*> tag (e.g,
<message.type.xml>). The example below shows the XML message configuration portion.
<!--handler.config.generic serviceName="GenericBrokerService">
<action rootElement="xmlWrapped">
<broker.inbound>
<config.file.request>D:/initiate/software/brokers/config/IHE/
msgBroker/CUST_AddPatient.ini</config.file.request>
<config.file.reject.response>D:/initiate/software/brokers/
config/msgBroker/MsgReaderFailureXML.ini</
config.file.reject.response>
<config.file.success.response>D:/initiate/software/brokers/
config/msgBroker/MsgReaderSuccessXML.ini</
config.file.success.response>
<config.file.path>D:/initiate/software/brokers/config/IHE/
msgBroker</config.file.path>
<queue.dir>D:/initiate/software/brokers/inbound</queue.dir>
<queue.success.name>success</queue.success.name>
<queue.reject.name>reject</queue.reject.name>
<attribute.update.filter></attribute.update.filter>
<manage.duplicates></manage.duplicates>
<application.name></application.name>
<manage.attribute.update></manage.attribute.update>
<attribute.update.queue.dir></attribute.update.queue.dir>
<attribute.update.queue.name></attribute.update.queue.name>
</broker.inbound>
<message.type.xml>
<xml.doc.handler.lib></xml.doc.handler.lib>
<xml.doc.name></xml.doc.name>
<xml.doc.public.id></xml.doc.public.id>
<xml.doc.system.id></xml.doc.system.id>
</message.type.xml>
</action>
proxy.config.xsd
The proxy.config.xsd is an XML schema that is used to help validate the XML element values before starting
the web service. The .xsd file defines (governs) the proxy.config.xml file and should never be augmented. If
you need to change the proxy.config.xml file (e.g., deviate from the IHE standards), it is recommended that you
contact the Customer Service Group.
Initiate-IHE.war
The Initiate-IHE.war file is a jar used to distribute the collection of files and libraries that make up the web
application.
Initiate Systems, Inc.
26
Proprietary and Confidential
4 Web Service
Status page
The status page provides a static view of the services, such as RegisterDocumentSet-b, being run. The page
shows the minimum and maximum amount of time (in milliseconds) it takes to process each message and the
number of errors. The example below shows the XDS_b_DocumentRegistry and GenericBrokerService
services.
Note that the first message to run, per action, will have a maximum time of 0. This is due to the “spin-up” of
services that takes place for the initial request. The minimum time for the first message is the actual time it took
to process. The true reflections of min/max time per service begins with the second message.
Failure to process a message constitutes an error. For example, if a request comes in and the broker does not
respond, that is considered an error. If a requested document or patient is not in the Hub, that is not an
considered an error because the broker actually processed the request. An error count other than 0 indicates
that there is a problem in either the broker .ini files or the web service portion of the product. Consult the logs
for information on the errors.
Install the Initiate IHE web service
Prior to installing and configuring the web service, verify the following:
You have already installed the Message Broker Suite (see the Message Broker Suite Reference
Guide) and deployed the XDS Reference.zip (see “Project components” on page 18).
You have the JAVA_HOME path set in your system environment variables, for example:
Variable = JAVA_HOME Value = C:\Program Files\Java\jre1.6.0_02
You have installed Tomcat 6.0. Verify that the path to the Tomcat libraries is set in your system
variables. (Note that you can also add the variables directly in the Tomcat startup script
Proprietary and Confidential
27
www.Initiate.com
IHE Accelerator Guide
(<<TOMCAT_HOME>>/bin/startup.*). For example:
Verify the Java library entry under the Java options in the Tomcat properties.
You will need to reboot your system after adding the variables.
In these instructions, the following values should be replaced with values specific to your configuration. These
settings can be added to the <<TOMCAT_HOME>>/bin/startup.*:
Initiate Systems, Inc.
28
Proprietary and Confidential
4 Web Service
<<TOMCAT_HOST>> is the machine name on which Tomcat is running
<<TOMCAT_PORT>> is the port number used by TOMCAT
<<TOMCAT_HOME>> is the directory in which TOMCAT is installed, also referred to as
CATALINA_HOME.
Storing the proxy.config.xml and shared libraries
1
Shut down the Tomcat server.
2
Install Tomcat. For Tomcat 6.x or later, modify the <<TOMCAT_HOME>>/conf/catalina.properties file
so that the shared classloader mechanism works the same as Tomcat 5.x. To do this, verify that the
entry beginning with shared.loader= reads: shared.loader=${catalina.base}/shared/
classes,${catalina.base}/shared/lib/*.jar.
3
If it does not already exists, create a shared\classes directory under the TOMCAT_HOME directory.
4
Copy your proxy.config.xml and proxyconfig.xsd files file into
<<TOMCAT_HOME>>\shared\classes directory.
5
Copy the schemas folder from .../proxy to <<TOMCAT_HOME>>/shared/classes.
6
All of the libraries in the proxy/lib folder must be copied to <<TOMCAT_HOME>>/shared/lib.
In order for Tomcat’s native library loader to see the shared libraries during runtime, the
<<TOMCAT_HOME>>/shared/lib must be added to the java.library.path. One way to accomplish this
is to set an environment variable JAVA_OPT as such:
JAVA_OPT=-Djava.library.path=<<TOMCAT_HOME>>/shared/lib
7
Depending upon your OS, make sure to add the following:
Microsoft Windows®: The <<TOMCAT_HOME>>/shared/lib also need to be added to the system’s
PATH.
Linux or Solaris: Add the <<TOMCAT_HOME>>/shared/lib to the environment's
LD_LIBRARY_PATH.
AIX: Add the <<TOMCAT_HOME>>/shared/lib to the environment’s LIBPATH.
HP-UX: Add the <<TOMCAT_HOME>>/shared/lib to the environments SHLIB_PATH.
8
Due to the large memory footprint of the IHE schemas, the default memory limits in Tomcat are not
sufficient. It is recommend that you allow 1G for the Tomcat instance running this service. This can be
done via the CATALINA_OPTS environment variable. For example: CATALINA_OPTS=-Xms128m Xmx1024m instructs Tomcat to start the heap size at 128 megabytes and grow it to the maximum of 1
gigabyte.
Installing the Initiate IHE web application
1
Restart Tomcat.
2
In a web browser, enter http://<<TOMCAT_HOST>>:<<TOMCAT_PORT>>. You should see “The
Apache Jakarta Project" page with links for Tomcat Administration and Tomcat Manager.
3
Click the link for the Tomcat Manager and login with the name/password of a Tomcat administrator
account.
4
In the Install section, click the browse button in the WAR file to deploy area and navigate to the
Initiate-IHE.war file. Click Deploy.
5
When the page refreshes, you should see an Initiate-IHE row in the Applications section with a Display
Name of Initiate-IHE.
Proprietary and Confidential
29
www.Initiate.com
IHE Accelerator Guide
As an alternative, Tomcat can be configured by default to auto-deploy any war file dropped into the
<<TOMCAT_HOME>>/webapps.
Updating an existing installation (9.0+)
1
Remove/Undeploy the Initiate-IHE Web Application from the Tomcat Manager page. In some cases a
shutdown of the Tomcat server and removal of the <<TOMCAT_HOME>>/webapps/Initiate-IHE and
<TOMCAT_HOME>>/webapps/Initiate-IHE.war is required. This is due to the fact that Tomcat places
a lock on one of the jars in the Initiate-IHE.war and prevents the service from being undeployed while
Tomcat is running.
2
Follow the installation steps above (see“Storing the proxy.config.xml and shared libraries” on page 29):
3
a
Replace the shared libraries in the <<TOMCAT_HOME>>/shared/lib.
b
If the layout of the proxy.config.xml has changed (check the latest 9.0 release notes), port your
settings from the existing proxy.config.xml to the new format and replace the
<<TOMCAT_HOME>>/shared/classes/proxy.config.(xml/xsd) with the new version.
c
In the proxy.config.xml file, do a search for REPLACE_ME_WITH and in each instance, replace
the text with the specifics for your installation. Environment variable use, such as
${MAD_ROOTDIR} is not allowed inside of configuration files running under web services. You
must enter the full path
Follow the instructions for deployment of the Initiate-IHE.war (see “Installing the Initiate IHE web
application” on page 29).
Updating an existing installation (9.0 to 9.2)
1
Remove/Undeploy the Initiate-IHE Web Application from the Tomcat Manager page. In some cases a
shutdown of the Tomcat server and removal of the <<TOMCAT_HOME>>/webapps/brokerproxy and
<<TOMCAT_HOME>>/webapps/brokerproxy.war is required. This is due to the fact that Tomcat
places a lock on one of the jars in the brokerproxy.war and prevents the service from being undeployed
while Tomcat is running.
2
Follow the installation steps above (see“Storing the proxy.config.xml and shared libraries” on page 29):
3
a
Replace the shared libraries.
b
If the layout of the proxy.config.xml has changed (check the latest 9.0 release notes), port your
settings from the existing proxy.config.xml to the new format and replace the
<<TOMCAT_HOME>>/shared/classes/proxy.config.xml with the new version.
Follow the instructions for deployment of the Initiate-IHE.war (see “Installing the Initiate IHE web
application” on page 29).
Change logging configuration on Tomcat
1
The logging configuration is controlled by the log4j.properties file located in the exploded web
application's classes directory, see <<TOMCAT_HOME>>\webapps\brokerproxy\WEB-INF\classes.
2
Find the section "# Initiate Systems Logging." Augment the line:
log4j.logger.com.initiatesystems=<<val>>, IS where <<val>> is one of the following: TRACE,
DEBUG, INFO, WARN, FATAL. You will get less logging as you move further to the right in the list
above. The default out-of-the-box setting is WARN.
Note that TRACE will log every single message to and from JNI layer, so use it with caution (the logs
could contain PHI information in some cases).
TRACE and DEBUG settings are meant to be used during the development and testing phases. In this
section you can also change the location of the Initiate-IHE.log and other log4j properties.
Initiate Systems, Inc.
30
Proprietary and Confidential
4 Web Service
3
Restart Tomcat.
Enable SSL for Broker to Hub communication
To enable SSL encryption between the Initiate-IHE web service and your Master Data Engine, the following
environment variables need to be added. You can do this by adding the settings to your
<<TOMCAT_HOME>>/bin/startup.*
MAD_IPVERSION=4
MAD_SECLIB=SSL
MAD_SSLLIB=ssleay32.dll
MAD_SSLCRYPTOLIB=libeay32.dll
MAD_SSLCACERTFILE=<<BROKER_INSTALL_DIR>>\conf\initiatecert.pem
MAD_SSLCERTFILE=<<BROKER_INSTALL_DIR>>\conf\initiatecert.pem
MAD_SSLPKEYFILE=<<BROKER_INSTALL_DIR>>\initiatekey.pem
MAD_SSLTIMEOUT=0
MAD_SSLVERSION=SSLv3
MAD_SSLVERIFYDEPTH=9
MAD_SSLFIPSMODE=0
For specifics on these variables, refer to the Message Broker Suite Reference Guide.
Enable ATNA Logging
To enable ATNA logging, add the following to your proxy.config.xml file. When ATNA logging is enabled, the
ATNA messages are written to the Initiate-IHE-ATNA.log file.
1
In the global.config section add the following attribute:
ihe.home.community.id="ihe:HomeCommunityId".
2
Add the atnaLogger attribute to the handler.config sections. The format is IP number:port number. For
example: <handler.config serviceName="XDS_b_DocumentRegistry"
atnaLogger="129.6.24.109:8087">.
Proprietary and Confidential
31
www.Initiate.com
IHE Accelerator Guide
Initiate Systems, Inc.
32
Proprietary and Confidential
5 Configuration Files
XML and XPath
XDS.b messages are IHE-specific XML messages. IHE has defined schemas that define how the messages
are constructed. Initiate uses XPath to read/write data from the XML document.
XPath is a language used for addressing parts of an XML document and operates on the abstract, logical
structure of an XML document. Used in the XDS configuration files, XPath acts as an indirect pointer to the
objects (documents, folder, or submission sets) described in the XML file.
XPath
XPath models an XML document as a tree of nodes. Initiate Systems uses a proprietary XPath to manage XML
node data to and from an XML document.
We will use the following XML document in the examples below
<?xml version="1.0" encoding="ISO-8859-1"?>
<bookstore>
<book>
<title lang="eng">Joe Public</title>
<price>29.99</price>
</book>
<book>
<title lang="eng">Learning XML</title>
<price>39.95</price>
</book>
</bookstore>
XPath uses path expressions to select a node in an XML document to read or write to. The node is selected by
following a path or steps. The most useful path expressions are listed below:
Proprietary and Confidential
33
www.Initiate.com
IHE Accelerator Guide
Table 5.1 Expressions
Expression
Description
/
Selects from the root node.
//
Selects nodes in the XML document from the current node that
match the selection no matter where they are. This expression
cannot be used to define a write XPATH expression.
@
Selects attributes
In the table below are some path expressions and the result of the expressions:
Table 5.2 Path expressions
Path Expression
Result
/bookstore
Selects the root element bookstore. Note that if the path starts
with a slash ( / ), it always represents an absolute path to an
element.
/bookstore/book
Selects all book elements that are children of bookstore.
//book
Selects all book elements no matter where they are in the
document.
/bookstore//book
Selects all book elements that are the descendant of the
bookstore element, no matter where they are under the
bookstore element.
/bookstore/book/title/@lang
Selects all attributes that are named “lang.”
Initiate Systems XPath path expressions are designed to read and write a single XML node. If an XPath
expression returns multiple XML nodes, an XPath exception is returned. Predicates can be used to guarantee
a single XML node.
Predicates are used to find a specific node or a node that contains a specific value. Predicates are always
embedded in square brackets. The table below lists some path expressions with predicates and the result of
the expressions:
Table 5.3 Predicates
Path Expression
Result
/bookstore/book[1]
Selects the first book element that is the child of the bookstore
element.
/bookstore/book[title=”Joe
Public”][price]
Selects the price of the Joe Public book.
//title[@lang][1]
Selects the first language of the book titles.
/[fn:name()]
Selects the element name of the root element.
/bookstore/
book[fn:data(@lang)][title=”Jo
e Public”]
Selects the language of the Joe Public book.
It is important to note that we support only the XPath “data” and “name” functions: fn:data() and fn:name().
Initiate Systems, Inc.
34
Proprietary and Confidential
5 Configuration Files
XPath wildcards can be used to select unknown XML elements.
Table 5.4 XPath wildcards
Wildcard
Description
*
Matches any element node.
@*
Matches any attribute node.
boo*tore
Matches any node that begins with “boo” and ends with “tore”
The following table lists some path expressions and the result of the expressions:
Table 5.5 Wildcard path expressions
Path Expression
Result
/bookstore/*
Selects all the child nodes of the bookstore element.
/bookstore/
book[title=”Joe*”][price]
Selects the price of all books starting with Joe.
//title[@*]
Selects all title elements which have any attribute.
XML
As discussed earlier, the XDS.b message consists of four general meta objects: ExtrinsicObject,
RegistryPackage, Classification and Association. Multiple meta object instances may exist if multiple
documents and folders are described in the message.
An important concept to understand is the IHE predefined codes used to define the meta object. Since these
meta objects are designed to be general, IHE created codes to describe them. For example,
urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d defines the meta object
XDSSubmissionSet.author. For a complete list of the UUIDs defined by XDS, refer to IHE XDS specification.
The Submission Set and Folder are described with a RegistryPackage/Classification combination. The
RegistryPackage defines the attributes associated to a Submission Set or Folder. The Classification defines
the type of RegistryPackage we are concerned about. The objects are defined via IHE codes similar to the
ExtrinsicObject or document. In the XML example below, the Submission Set (RegistryPackage) with an ID of
SubmisisonSet01 is associated to the Classification with a classifiedOject of SubmissionSet01. The
Classification contains the classificaitonNode equal to urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd,
which in turn tells us the RegistryPackage is a Submission Set.
Documents, Submission Sets and Folders must all contain a patient ID and unique ID attributes. These
attributes are considered external IDs. These IDs come from sources such as hospital registration systems.
An Association object builds the associations between Submission Sets, Folders, Documents and other
Associations. The targetObject is the child.
Proprietary and Confidential
35
www.Initiate.com
IHE Accelerator Guide
XML example:
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxmlregrep:xsd:lcm:3.0">
<rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxmlregrep:xsd:rim:3.0">
<rim:ExtrinsicObject id="Document01" mimeType="text/plain"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">
<rim:Slot name="creationTime">
<rim:ValueList>
<rim:Value>20051224</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="repositoryUniqueId">
<rim:ValueList>
<rim:Value>1.19.6.24.109.42.1</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="languageCode">
<rim:ValueList>
<rim:Value>en-us</rim:Value>
<rim:ValueList>
</rim:Slot>
<rim:Slot name="size">
<rim:ValueList>
<rim:Value>4</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="hash">
<rim:ValueList>
<rim:Value>e543712c0e10501972de13a5bfcbe826c49feb75</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="URI">
<rim:ValueList>
<rim:Value>http://</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="serviceStartTime">
<rim:ValueList>
<rim:Value>200412230800</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="serviceStopTime">
<rim:ValueList>
<rim:Value>200412230801</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="sourcePatientId">
<rim:ValueList>
<rim:Value>89765a87b^^^fj34r</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="sourcePatientInfo">
Initiate Systems, Inc.
36
Proprietary and Confidential
5 Configuration Files
<rim:ValueList>
<rim:Value>PID-3|pid1^^^domain</rim:Value>
<rim:Value>PID-5|Doe^John^^^</rim:Value>
<rim:Value>PID-7|19560527</rim:Value>
<rim:Value>PID-8|M</rim:Value>
<rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</
rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Physical" />
</rim:Name>
</rim:Description>
<rim:Classification classificationScheme="urn:uuid:93606bcf-949443ec-9b4e-a7748d1a838d" classifiedObject="Document01"
nodeRepresentation="" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_1">
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>^Smitty^Gerald^^^</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Cleveland Clinic</rim:Value>
<rim:Value>Parma Community</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorRole">
<rim:ValueList>
<rim:Value>Attending</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorSpecialty">
<rim:ValueList>
<rim:Value>Orthopedic</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:93606bcf-949443ec-9b4e-a7748d1a838d" classifiedObject="Document01"
nodeRepresentation="" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_2">
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>^Dopplemeyer^Sherry^^^</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Cleveland Clinic</rim:Value>
<rim:Value>Berea Community</rim:Value>
</rim:ValueList>
</rim:Slot>
Proprietary and Confidential
37
www.Initiate.com
IHE Accelerator Guide
<rim:Slot name="authorRole">
<rim:ValueList>
<rim:Value>Primary Surgon</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorSpecialty">
<rim:ValueList>
<rim:Value>Orthopedic</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:41a5887f-88654c09-adf7-e362475b143a" classifiedObject="Document01"
nodeRepresentation="History and Physical"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_3">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon classCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="History and Physical" />
</rim:Name>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a4051-b291-b1ae6a575ef4" classifiedObject="Document01"
nodeRepresentation="Colonoscopy"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_4">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon eventCodeList</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Colonoscopy" />
</rim:Name>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a4051-b291-b1ae6a575ef4" classifiedObject="Document01"
nodeRepresentation="T-D4000" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_5">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>SNM3</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Abdomen" />
</rim:Name>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:f4f85eac-e6cb4883-b524-f2705394840f" classifiedObject="Document01"
Initiate Systems, Inc.
38
Proprietary and Confidential
5 Configuration Files
nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_6">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon confidentialityCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Clinical-Staff" />
</rim:Name>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:a09d5840-386c46f2-b5ad-9c3699a4309d" classifiedObject="Document01"
nodeRepresentation="CDAR2/IHE 1.0"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_7">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon formatCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="CDAR2/IHE 1.0" />
</rim:Name>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:f33fb8ac-18af42cc-ae0e-ed0b0bdb91e1" classifiedObject="Document01"
nodeRepresentation="Outpatient" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_8">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon healthcareFacilityTypeCodes</
rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Outpatient" />
</rim:Name>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:cccf5598-8b074b77-a05e-ae952c785ead" classifiedObject="Document01"
nodeRepresentation="General Medicine"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_9">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon practiceSettingCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="General Medicine" />
</rim:Name>
</rim:Classification>
Proprietary and Confidential
39
www.Initiate.com
IHE Accelerator Guide
<rim:Classification classificationScheme="urn:uuid:f0306f51-975f434e-a61c-c59651d33983" classifiedObject="Document01"
nodeRepresentation="34108-1" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_10">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>LOINC</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Outpatient Evaluation And
Management" />
</rim:Name>
</rim:Classification>
<rim:ExternalIdentifier identificationScheme="urn:uuid:58a6f841-87b34a3e-92fd-a8ffeff98427"
value="d39f0ea99c854f4^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_11"
registryObject="Document01">
<rim:Name>
<rim:LocalizedString value="XDSDocumentEntry.patientId" />
</rim:Name>
</rim:ExternalIdentifier>
<rim:ExternalIdentifier identificationScheme="urn:uuid:2e82c1f6-a0854c72-9da3-8640a32e42ab" value="229.6.58.29.5926"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_12"
registryObject="Document01">
<rim:Name>
<rim:LocalizedString value="XDSDocumentEntry.uniqueId" />
</rim:Name>
</rim:ExternalIdentifier>
</rim:ExtrinsicObject>
<rim:RegistryPackage id="SubmissionSet01"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:RegistryPackage">
<rim:Slot name="submissionTime">
<rim:ValueList>
<rim:Value>20041225235050</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Physical" />
</rim:Name>
<rim:Description>
<rim:LocalizedString value="Annual physical" />
</rim:Description
<rim:Classification classificationScheme="urn:uuid:a7058bb9-b4e44307-ba5b-e3f0ab85e12d" classifiedObject="SubmissionSet01"
nodeRepresentation="" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_13">
<rim:Slot name="authorPerson">
Initiate Systems, Inc.
40
Proprietary and Confidential
5 Configuration Files
<rim:ValueList>
<rim:Value>^Dopplemeyer^Sherry^^^</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Cleveland Clinic</rim:Value>
<rim:Value>Berea Community</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorRole">
<rim:ValueList>
<rim:Value>Primary Surgon</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorSpecialty">
<rim:ValueList>
<rim:Value>Orthopedic</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
<rim:Classification classificationScheme="urn:uuid:aa543740-bdda424e-8c96-df4873be8500" classifiedObject="SubmissionSet01"
nodeRepresentation="History and Physical"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="id_14">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon contentTypeCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="History and Physical" />
</rim:Name>
</rim:Classification>
<rim:ExternalIdentifier identificationScheme="urn:uuid:96fdda7c-d0674183-912e-bf5ee74998a8" value="229.6.58.29.5927"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_15"
registryObject="SubmissionSet01">
<rim:Name>
<rim:LocalizedString value="XDSSubmissionSet.uniqueId" />
</rim:Name>
</rim:ExternalIdentifier>
<rim:ExternalIdentifier identificationScheme="urn:uuid:554ac39e-e3fe47fe-b233-965d2a147832" value="1.3.6.1.4.1.21367.2009.1.2.182"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_16"
registryObject="SubmissionSet01">
<rim:Name>
<rim:LocalizedString value="XDSSubmissionSet.sourceId" />
</rim:Name>
</rim:ExternalIdentifier>
Proprietary and Confidential
41
www.Initiate.com
IHE Accelerator Guide
<rim:ExternalIdentifier identificationScheme="urn:uuid:6b5aea1a-874d4603-a4bc-96a0a7b38446"
value="d39f0ea99c854f4^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_17"
registryObject="SubmissionSet01">
<rim:Name>
<rim:LocalizedString value="XDSSubmissionSet.patientId" />
</rim:Name>
</rim:ExternalIdentifier>
</rim:RegistryPackage>
<rim:Classification classifiedObject="SubmissionSet01"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="ID_20632381_1" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" />
<rim:Association associationType="urn:oasis:names:tc:ebxmlregrep:AssociationType:HasMember" sourceObject="SubmissionSet01"
targetObject="Document01" id="ID_20632381_2"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Association">
<rim:Slot name="SubmissionSetStatus">
<rim:ValueList>
<rim:Value>Original</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Association>
</rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>
Inbound broker configuration files
When you install the Message Broker Suite, an IHE-specific folder is created under the \config\IHE
directory. The \msgBroker folder contains the .ini files needed to configure the Inbound Message Broker:
CUST_AddPatient.ini
IHE_InboundProcessor.ini
RegisterDocumentSetB.ini
There are individual files used to configure the Message Reader for XDS and PIX_PDQ:
Initiate Systems, Inc.
42
Proprietary and Confidential
5 Configuration Files
MsgReader<profile>.ini
MsgReaderFailure<profile>.ini
MsgReaderRequest<profile>.ini
MsgReaderSuccess<profile>.ini
Most implementors are familiar with the contents of Broker configuration files, however the IHE file contains
some values that you may be seeing for the first time. For a description of the InboundProcessor.ini Data,
Event, and Evaluator Broker sections and options, refer to Chapter 3, Standard Inbound Configuration Files, in
the Message Broker Suite Reference Guide. For a description of the MsgReader .ini files, refer to Appendix G,
Message Reader Configuration, also in the Message Broker Suite Reference Guide.
As with standard Broker configurations, you can apply iterators within the data and event sections when you
need to copy a previous data definition within a section of the same configuration file. Refer to “Applying
iterators to a configuration file” in Chapter 3 of the Message Broker Suite Reference Guide.
CUST_AddPatient.ini
This configuration file directs the addition of Patients to the Hub. The inbound message should contain the
source code, patient first and last name, and patient OID number. The contents of this file shows an example of
a generic inbound XML message.
IHE_InboundProcessor.ini
This file is the inbound HL7v3 configuration file used to process PIX/PDQ messages from the IHE profile.
XDS.b uses the PIX/PDQ inbound message to load patient data into the XDS.b Registry. If a patient does not
exist in the Registry, the message is rejected.
Within the configuration file you will see MemHead and MergedMemHead. MemHead is the survivor member
and MergedMemHead is the obsolete member.
MsgReader<profile>.ini
The Message Reader can now manage custom acknowledgements. The MsgReader configuration files
(MsgReaderXDS, MsgReaderFailureXDS, MsgReaderRequestXDS MsgReaderSuccessXDS,
MsgReaderPIX_PDQ, MsgReaderFailurePIX_PDQ, MsgReaderRequestPIX_PDQ, and
MsgReaderSucessPIX_PDQ) are similar to the query broker configuration files. The MsgReaderXDS.ini is the
main, or driver configuration, file that determines which handle will process the message. The Request, Failure
and Success configuration files determine how the message is processed and what the response will look like.
In the Interaction Handle section of the MsgReaderXDS.ini and MsgReaderPIX_PDQ.ini files you will find a
number of REPLACE_ME_WITH_PATH_TO_BROKER_ROOTDIR entries. Replace this text with the
appropriate path to your request, success and failure .ini files.
RegisterDocumentSetB.ini
This file manages the inbound XDS.b messages.
In order to simplify the implementation of XDS, the data section logic is handled in the custom library
document_handler_xds.dll. You will see the following entry in the .ini file. This entry identifies to the Broker that
this is an XDS event, which results in different MemPut settings being used.
0||MSGHEADER|||
evtType||ADDXDS|
The event section has a Manage Generic Events section. Generic events are data management events that
“clean” the data before any other processing occurs.
Proprietary and Confidential
43
www.Initiate.com
IHE Accelerator Guide
Note: The Message Broker Suite Reference Guide lists other data elements that are not used in XDS.b.
Refer back to “Metadata” on page 8 for a description of items like ExtrinsicObject and UUIDs.
Query broker configuration files
When you install the Message Broker Suite, an IHE-specific folder is created under the
\config\IHE\queryBroker directory. This folder contains all of the .ini files needed to configure the Query
Broker for the IHE XDS, PIX_PDQ, and ATNA logging profiles.
Again, most implementors will be familiar with the contents of config files. For details on the Data, Event,
Evaluator, and Handler sections and options, refer to the HL7 Query Adapter Reference Guide.
CUST_QueryPatient.ini
This file contains an example of a non-IHE, or generic, HL7v2 query configuration file. The Handle section has
entries for MSH, MSA, ERR, QAK, etc. These are HL7 segment order definitions. This tells the HL7 response
to reoder the segments in the listed order.
IHE_QueryHL7(v2 and v3).ini
These are IHE PIX/PDQ specific configuration files used for the queries.
IHE_QueryCancelRequestHL7v3.ini
This is used to manage HL7v3 cancel messages. Initiate does not support cancel and the message returns a
failure response.
IHE_QueryCancelResponseHL7v3.ini
This file is used define the failure response for the above cancel requests.
IHE_QueryPDQ.ini
The query PDQ files support both HL7v2 and v3. The files include ErrorResponse, NotFoundResponse,
SuccessResponse, and Request. Request builds the API call, while the response files manage the result of the
request call.
IHE_QueryPIX.ini
The query PIX files support both HL7v2 and v3. The files include ErrorResponse, NotFoundResponse,
SuccessResponse, and Request. Request builds the API call, while the response files manage the result of the
request call.
RegistryStoredQuery.ini
This is the main configuration file that directs which query handles will be called to manage the requests. (Note
that file replaces the IXNDocumentGet_.ini file, which has been removed from the package.)
XDSProcessRequest.ini
The XDS process configuration files support query requests from a document consumer. The Request file
builds the API call to process the query against the registry. The response messages from the registry are
configured in the following files:
XDSProcessResponseFailure.ini
XDSProcessResponseLeafClassSuccess.ini
Initiate Systems, Inc.
44
Proprietary and Confidential
5 Configuration Files
XDSProcessResponseNotFound.ini
XDSProcessResponseObjectRefSuccess.ini.
ATNA logging configuration file
The IHE_AtnaLog.ini file is used to configure ATNA logging for HL7v2. XDS.b and HL7v3 ATNA logging is
configured in proxy.config.xml. ATNA messages are written to the Initiate-IHE-ATNA.log file. See “Enable
ATNA Logging” on page 31 for instructions on enabling ATNA logging.
The following actions will produce ATNA logs:
RegisterDocument-b
RegistryStoredQuery
PRPA_IN201301UV02 - Patient Registry Record Added
PRPA_IN201302UV02 - Patient Registry Record Revised
PRPA_IN201304UV02 - Patient Registry Record Merged
PRPA_IN201305UV02 - Patient Registry Find Candidates Query
PRPA_IN201309UV02 - Patient Registry Get Identifiers Query
Query error responses
When a query is submitted to the registry and the registry is unable to fulfill the request, a detailed error
message is returned. The error messages are found in both the Initiate-IHE and the Broker log files. The web
service writes errors to the Initiate-IHE.log and the native Broker writes errors to the proxy.log file. Note that
both logfile names can be changed if the user wished.
Per the IHE specifications, the registry error must return two attributes: errorCode and codeContext. The
Broker response will always contain two re:RegistryError elements, which are bolded in the Broker response
example below.
<query:AdhocQueryResponse status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure" xmlns:query="urn:oasis:names:tc:ebxmlregrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxmlregrep:xsd:rim:3.0" xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">
<rs:RegistryErrorList>
<rs:RegistryError codeContext="GetFolders requires either
XDSFolderUniqueId or XDSFolderUUID"
errorCode="XDSStoredQueryMissingParam"
severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error">
</rs:RegistryError>
<rs:RegistryError codeContext="No error returned from the engine"
errorCode="OK" severity="urn:oasis:names:tc:ebxmlregrep:ErrorSeverityType:Error">
</rs:RegistryError>
</rs:RegistryErrorList>
<rim:RegistryObjectList></rim:RegistryObjectList>
</query:AdhocQueryResponse>
The first RegistryError element reports exceptions caught in the XDS proxy.
Proprietary and Confidential
45
www.Initiate.com
IHE Accelerator Guide
Field
Description
Default
errorCode
Most relevant exception
caught by the XDS proxy.
“XDSRegistryError”
codeContext
A brief description of the
exception. The codeContext
is set in the code and the
output is dependent upon the
exception caught.
“A general error was returned
from the Document Registry,
see log files for more
information”.
Default verbiage is set in the
XDSProcessResponseFailur
e.ini event section.
The second RegistryError element reports any errors thrown by the Initiate Master Data Service® API calls.
Field
Description
Default
errorCode
Error code (errorCode)
returned from the API call.
“OK”
codeContext
Error text (errText) returned
from the API call.
“No error returned from the
Master Data Service.”
XDS stored query configuration
An XDS Stored Query supports LeafClass and ObjectRef responses. The RegistryStoredQuery.ini determines
the response type requested and uses the set of configuration files defined in the Interaction Handle section of
the configuration file.
Testing the XDS solution
Once the web service is started, it is recommended that you go to the IHE main page to see if the services
have been installed properly. If they are all functioning you will see the splash page listing all of the services. If
a service fails to start it will not be listed on the splash page.
Initiate Systems, Inc.
46
Proprietary and Confidential
A Glossary
The following terms and concepts are used throughout this document.
Actor
In IHE terminology, actors are the functional components within the healthcare enterprise. The IHE technical
framework specifies the interactions of actors in terms of standards-based transactions. For example, the XDS
profile employs document repositories and document registries, both of which are actors.
Affinity Domain (XDS Affinity Domain)
An XDS Affinity Domain is a group of healthcare enterprises that agree to use a common set of policies and
share a common infrastructure, for example a RHIO. Within the domain, policies and business rules control
how patients are identified, consent is obtained and access to information is controlled. Because an XDS
document can contain text (formatted or free-form), images (e.g., x-ray or MRI), or structured/coded clinical
information, the affinity domain further defines the format, content, structure, organization, and representation
of clinical information.
Assigning Authority (AA)
The Assigning Authority identifies the "domain" over which the ID Number represents a unique entity.
Author
The “author” or originating source creating the document content. Contained in the OID, which is made up of
the assigning authority and source. You can use either the assigning authority or source to determine the
source of a member.
APND
Append. The current document is an addendum to the parent document.
Class code (classCode)
The code specifying the particular kind of document (e.g., Prescription, Discharge Summary, Report).
Code List (codeList)
A list of codes specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS
Folder. When a new submission request associates XDS Documents (new submission or previously submitted)
to an XDS Folder, the Code included in the codeList is appended to the existing list of codes for this Folder,
unless this code is already present in the list managed by the Registry for the same XDS-Folder. Only one
code may be assigned to the Folder when an XDS Document is placed in a Folder.
Proprietary and Confidential
47
www.Initiate.com
IHE Accelerator Guide
Confidentiality Code (confidentialityCode)
Code indicating the level of privacy control for the XDS document. All documents submitted shall have
confidentiality codes. The confidentiality codes for different documents in the same submission may be
different .
Content Type Code (contentTypeCode)
The code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS
Submission Set.
Document
An XDS document can contain text (formatted or free-form), images (e.g., x-ray or MRI), or structured/coded
clinical information.
Folder
A folder contains multiple XDS documents.
Submission Set
A submission set associates folders and documents to a submission. The submission set is a way to
historically show what folders and documents were included in a single submission.
EHR
Electronic health records.
Event code list (eventCodeList)
List of codes representing the main clinical acts, such as a colonoscopy or an appendectomy, being
documented.
Format Code (formatCode)
A code that globally uniquely specified the format of the XDS document. Along with the typeCode, it should
provide sufficient information to allow any Document Consumer to know if it will be able to process the
document.
Healthcare Facility Type Code (healthcareFacilityTypeCode)
Represents the type of organizational setting of the clinical encounter during which the documented act
occurred (e.g., Diabetes Clinic). In some cases, the setting of the encounter is inherent in the typeCode, such
as "Diabetes Clinic Progress Note"..
OID
Object identifier (globally unique identifier) or Patient Privacy Consent Identifier. HL7 “documents” or
messages contain an ISO object identifier to encode information. An OID for HL7v2 consists of three parts
separated by a subcomponent token (&). The breakdown is: AssigningAuthority&OID&Standar. For example:
Initiate&1.23.4.55.4555&ISO
The OID itself is a guaranteed world-wide unique number. The assigning authority can change the number for
customer needs.
An OID for HL7v3 consists of broken-out attributes where AssigningAuthorityName represents the assigning
authority ID and root represents the OID. For example:
<id assigningAuthorityName=”initiate” root=”1.23.4.555”/>
Initiate Systems, Inc.
48
Proprietary and Confidential
A Glossary
Registry systems assign the OIDs.
Patient ID (patientId)
The patientId represents the medical record identifier of the person associated with the document.
Patient Identifier Domain
A single system or set of interconnected systems that share a common identification scheme and issuing
authority for patient identifiers.
PHI
PHI or protected health information is any information about an individual’s health status, provision of care, or
payment of care. This is interpreted broadly under the U.S. Health Insurance Portability and Accountability Act
(HIPPA) and includes any part of a patient’s medical record or payment history.
PID
Patient identification message..
Practice Setting Code (practiceSettingCode)
The code specifying the clinical specialty where the act that resulted in the document was performed (e.g.
Family Practice, Laboratory, Radiology).
RHIO
Regional health information organization.
RPLC
Replace. The current document is an replacement to the parent document
Source ID (sourceId)
OID identifying the instance of the Document Source that contributed the Submission Set. When a "broker" is
involved in sending submission sets from a collection of client systems, it should use a different source ID for
submissions from each separate system to allow for tracking
Type Code (typeCode)
A code specifying the precise kind of document (e.g. Pulmonary History and Physical, Discharge Summary,
Ultrasound Report).
UUID
Universally Unique Identifier (UUID) is a permanent global identifier that creates identity for objects. An ID
value that has the prefix urn:uuid: is assumed to be a UUID. Objects are assigned UUIDs for their ID
attributes before being stored in the Document Registry. UUIDs are assigned by the Document Repository.
Unique ID
The globally unique identifier assigned by the document creator to this document. This unique identifier may be
used in the body of other XDS Documents to reference this document. The length of Unique Identifier can not
exceed 128 bytes. This uniqueId can be used to reference an XDS document from within the content of
another document and to ensure that when an XDS Document is retrieved from the Repository using the URI
component, the selected XDS Document is the correct one.
XFRM
Transform. The current document is an transformation of the parent document
Proprietary and Confidential
49
www.Initiate.com
IHE Accelerator Guide
XFRM_RPLC
Transform with replace. The current document is both a transformation and replacement of the parent
document
Initiate Systems, Inc.
50
Proprietary and Confidential
B OID Loader
Note that this madconfig target is intended for internal use only. This information should not be released
outside of the Company.
The madconfig utility is used to run the OID Loader. To run the OID Loader:
1
Begin by opening a shell prompt and navigate to the scripts directory where you installed the Message
Broker Suite (MAD_ROOTDIR). Type madconfig run_oid_loader on Microsoft Windows®, or
madconfig.sh run_oid_loader on UNIX.
2
Enter the data source name. This utility expects that a data source has been previously defined.
3
Enter the database user.
4
Enter the database password scheme.
5
Enter the database password.
6
Enter the path to the OID input file. For each OID in the input file, a definitional source is created
along with the associated inbound and outbound mappings. This utility expects that the input file be in
a standard format. There should be three fields separated by a delimiter. The fields should be in the
following order; Participant, Assigning Authority and OID.
IHE Local|IHELOCAL|1.3.6.1.4.1.21367.2010.1.2.310
Where “IHE Local” is the Participant, “IHELOCAL” is the Assigning Authority and
“1.3.6.1.4.1.21367.2010.1.2.310” is the OID.
7
Enter the delimiter used by the OID input file. The default is |.
8
Enter the path to the OID SQL script to be created by this utility:
9
Enter the entity type associated with the additional sources.
10 Enter the clerical review (CR) threshold associated with the additional sources.
11 Enter the auto-link (AL) threshold associated with the additional sources.
The OID SQL script is then created. This script contains all of the SQL statements required to add the
OIDs to the database.
12 Review the OID SQL script and indicate whether or not to execute it at this time. If fields were
truncated or there were any other errors during processing it is recommended that the input file be
corrected and the utility run again. If ‘n’ then the OID Loader utility has finished it’s processing. If ‘y’
then the OID SQL script will be executed against the database.
13 If there were errors during processing, you are prompted to confirm execution of the OID SQL script.
Proprietary and Confidential
51
www.Initiate.com
IHE Accelerator Guide
If you encounter the error “Build failed...Use a resource collection to touch directories”, you will need to specify
the path to the generated script file. After step 6 above, “Enter the path to the OID input file”, the utility is
deleting and then touching the targeted script file to ensure that the path can be written to. For example, if you
answer, ‘C:\oidload.sql’, the utility will delete that file and then touch it. If the targeted script was still on the file
system from a previous run then it is no longer valid to run it again because there is no guarantee that the
SrcRecnos are still unique. The name of the script is not important and the file does not have to exist prior to
execution. It is important that the path is to a file and that this path is a valid location that is writable.
If you need to add additional OIDs, running the utility again will append the existing sources in the data source.
The OID Loader utility ensures unique SrcRecnos by performing a query to get the current max SrcRecno.
Associations are not created between OIDs that were added during separate utility executions. To create
associates between two environments, you must load both environments in the same input file.
Initiate Systems, Inc.
52
Proprietary and Confidential
Index
Index
A
relationships 10
repository 8
source 8
Accelerator
attribute types 19
components 18
member types and entity types 18
overview 17
relationship types 18
Workbench project 18
Actors 7, 47
APND 47
Assigning Authority 47
Association 9, 35
ATSC (Authorized Technical Support Contacts) 5
attribute types 19
Author 47
E
EHR 48
entity types 18
eventCodeList 48
ExtrinsicObject 9, 35
F
Folder 35, 48
formatCode 48
H
C
healthcareFacilityTypeCode 48
classCode 47
Classification 9, 35
codeList 47
confidentialityCode 48
Configuration
CUST_AddPatient 43
CUST_QueryPatient 44
IHE_InboundProcessor 43
IHE_QueryCancelRequest 44
IHE_QueryCancelResponse 44
IHE_QUeryHL7 44
inbound broker files 42
MsgReaderXDS 43
query broker files 44
RegisterDocumentSetB 43
RegistryStoredQuery 44
XDS stored Query 46
contentTypeCode 48
CUST_AddPatient 43
CUST_QueryPatient 44
I
IHE
accelerator overview 17
accelerator project 18
accelerator project components 18
IHE.war file 26
IHE_InboundProcessor 43
IHE_QueryCancelRequest 44
IHE_QueryCancelResponse 44
IHE_QueryHL7 44
Inbound
configuration files 42
CUST_AddPatient 43
IHE_InboundProcessor 43
MsgReaderXDS 43
M
member types 18
Message
metadata 8
metadata 8
association 9
RegistryPackage 9
metatdata
classification 9
ExtrinsicObject 9
MsgReaderXDS 43
D
Date range filter 17
Deterministic filter 17
Document
availability status 10
consumer 8
ExtrinsicObject 9
lifecycle 10
register document set.b transaction 8
Registry 8
Proprietary and Confidential
53
www.InitiateSystems.com
IHE Accelerator Guide
O
U
OID 48
Unique ID 49
UUID 9, 49
P
W
Patient
Identity Source 8
Patient ID 49
PHI 49
PID 49
practiceSettingCode 49
proxy.config.xml 24
proxy.config.xsd 26
Web Service
overview 23
Web service
IHE.war 26
install 27
overview 23
proxy.config.xml 24
proxy.config.xsd 26
status page 27
Wildcard filter 17
Workflow
query 9
submission 9
Q
Query
configuration files. 44
CUST_QueryPatient 44
IHE_QueryCancelRequest 44
IHE_QueryCancelResponse 44
IHE_QueryHL7 44
registry stored transaction 8
RegistryStoredQuery 44
X
XDS messages
metadata 8
XDS stored query
configuration 46
XDS workflow 9
XDS.b
actors 7
Document Consumer 8
Document Registry 8
document repository 8
Document Source 8
Patient Identity Source 8
profile 7
XFRM 49
XFRM_RPLC 50
XML 33, 35
example 36
XPath 33
expressions 34
path expressions 34
predicates 34
wildcard path expressions 35
wildcards 35
R
RegisterDocumentSetB 43
Manage Generic Events 43
Registry 8
RegistryPackage 9, 35
RegistryStoredQuery 44
relationship types 18
Relationships
viewing 19
Repository 8
RHIO 49
RPLC 49
S
Search filter
date range 17
deterministic 17
wildcard 17
sourceID 49
Status page 27
Submission Set 35, 48
Support Center Knowledge Base 5
T
third party software 6
Transaction
register document set.b 8
registry stored query 8
typeCode 49
Initiate Systems, Inc.
54
Proprietary and Confidential