IXS Specification Overview

Significant portions of text below has been copied from the OMG EIS RFP section 6.1

The following discusses usage of the service primarily with respect to patient identification, but similar functionality and scenarios are relevant to other entity types. The reason for concentrating on patients is both the familiarity and priority of the problem to a wide audience and also that profiles will be defined that support patient related information.

A typical person undergoes in his/her lifetime a vast array of healthcare encounters. Increasingly the nature of the encounter involves understanding the past experience and treatment of the patient, particularly in the case of chronically ill patients and in dealing with the large number of specialists that a patient may encounter. An accurate lifetime health record is becoming increasingly important in the overall management of the health of a patient. Also, throughout a person's lifetime he or she may have episodes of care provided by dozens or hundreds of healthcare providers, many of whom will assign and maintain patient IDs autonomously. In this arrangement, each organization or even department often assigns its own ID that uniquely identify the patient for its own purposes, with the result that these ID values are meaningless outside that system or organization. These autonomously managed IDs suit the purposes of recording and retrieval of service records for the single department or organization; however, there is no basis for efficient collection or correlation of health records among multiple venues or organizations.
The process of identification of a patient is well understood so that having a standard will improve the quality of care without compromising the role of innovation and discovery in healthcare. In addition to patients, providers and other entities or resources involved in patient care must also be uniquely and accurately identified.
This service is intended to allow for the resolution of demographics and other identifying characteristics (or traits) to a unique identifier. This allows any clinical system that uses the service to maintain a common description (set of traits) for each entity and to manage the entities. Having a standard interface for accessing and maintaining entity identification information allows systems and applications to have a consistent means of indexing data related to an entity.
By providing a standard mechanism for any clinical, financial, laboratory, or other application to uniquely identify and then retrieve an identifier associated with the entity, those applications may associate a variety of data with the entity identifier. By standardizing the interface to the service, clinical application vendors can leverage existing technology providers or open source implementations to more rapidly prototype and develop application and enterprise application integration infrastructures.
To put it simply, the Entity Identification Service provides the common thread by which entity data can be indexed. The unique identifier and standard way to search, retrieve and manage entity data will allow healthcare applications and healthcare enterprises to find, exchange and reference entity data while maintaining the data's context and associations.

HSSP Overview The Healthcare Services Specification Project (HSSP) http://hssp.wikispaces.com is a joint endeavor between Health Level Seven (HL7) http://www.hl7.org and the Object Management Group (OMG) http://www.omg.org. The HSSP was chartered at the January 2005 HL7 meeting under the Electronic Health Records Technical Committee, and the project was subsequently validated by the Board of Directors of both organizations. The HSSP has several objectives. These objectives include the following: To stimulate the adoption and use of standardized "plug-and-play" services by healthcare software product vendors To facilitate the development of a set of implementable interface standards supporting agreed-upon services specifications to form the basis for provider purchasing and procurement decisions. To complement and not conflict with existing HL7 work products and activities, leveraging content and lessons learned from elsewhere within the organization.

The Platform Independent Model

The Platform Independent Model (PIM) for EIS represents a wire and payload implementation independent means to describe the EIS interfaces.

It is important to note that the structure of interfaces is specifically defined for the Service provider and reflects a natural structure of components that may provide the EIS functionality. These are effectively orthogonal to the groupings of capabilities defined in Functional Profiles that form the basis for conformance and for consumption of the service by Clients. In some cases, the functional profiles may approximate the interface structure (see section 2.3 for further discussion of Functional Profiles).

EIS PIM Interfaces

A definitive description of the interfaces that implement the EIS PIM is available here: IXS Platform Independant Model Service Interfaces

Functional Profiles

For the purposes of implementing this specification and for management of conformance, the concept of Functional Profiles is an important one.

A Functional Profile is simply a named subset of the Operations defined in the overall Service Specification. Note that although the operations in a Functional Profile will commonly be taken from the same interface, this is NOT a restriction. The purpose of the functional profile is to provide a controlled, yet flexible mechanism that allows vendors and implementers to implement parts of the specification and still be able to claim conformance, i.e. conformance claims are made against the Functional Profiles and not then overall Service or specific Interfaces. Actually, conformance claims will be made specifically against "Conformance Profiles" which are simply a combination of a named Functional Profile and a named Semantic Profile. Semantic Profiles define the exact structure and format of the data content of input and output operation parameters.

Note that it is intended that a Registry for Profiles of HSSP Services will be set up in the near future which will help manage the use of Profiles.

A more complete description of the use of Functional Profiles will be provided by the overall HSSP project at http://www.healthinterop.com.

Although not an absolute necessity, it is desirable that the overall number of Functional Profiles is kept fairly low, and are also reused across multiple Platforms, and are therefore presented within the PIM in this specification. Individual organizations or communities can subsequently define their own functional profiles, which may or may not be based on the ones identified here. The important point to remember is that this only affects the management of
conformance claims, and NOT the nature of the behavior or run time interoperability.

Note also that the Functional Profiles are composable, so rather than define different combinations and increase the likelihood of combinatorial explosion, more complex profiles can be defined by aggregating from a few base ones, as in the set defined below.

With this in mind, an initial set of "reusable" profiles have been identified below, some of which are used in the Platform Specific Models in this document.

• Basic Update and Query (CreateOrUpdateIdentity, UpdateIdentity, GetIdentityTraits, FindIdentitiesByTraitsSimple)
• Link (LinkIdentities, UnlinkIdentities)
• Merge (MergeIdentities, UnmergeIdentities)
• Update(CreateIdentityWithSourceID, CreateIdentity, UpdateIdentity, CreateOrUpdateIdentity)
• Query (GetIdentityTraits, FindIdentitiesByTraitsSimple, FindEntitiesByTraits)
• Update and Query (4 plus 5)
• StatusManager (ActivateIdentity, DeactivateIdentity)

  Spec note from AH Some rationale for this basic list - the BasicUpdateAndQuery provides a kind of minimum bar, which will generally work with existing technology like v2 or even v3 messaging. The separate Update and Query and the combined Update and Query provide the more complete set of functionality. My theory is to stick with these or something like it in the PIM and let all other profiles (which may slice things differently to be defined either within PSMs or by implementations). Instead of 2, 3 and 7 a single profile could be defined for the Administration interface operations, but I don't think this is ideal, since the Merge and Link operations will not be supported explicitly in many implementations and would raise the bar too high (although Link may be implicitly behind the create and update operations. It will also be common to provide support for Link but not Merge.

  Rational For Profiles The intention on Profiles is to provide a method by which these profiles can be defined and aggregated rather than a static definition that gets locked in, this is what will enable vendors and implementors to feel comfortable in claiming conformance to. In terms of V2, in this document there should be 1 V2 PSM which may include one or more conformance profiles. Each conformance profile should include a reference to 1 Functional Profile and 1 Semantic Profile (this is by reference and not by value in order to enable reusability of both functional and semantic profiles).The Semantic Profiles are unique to v2, and looks like there is only a need for one, which is v2 Patient (and it only need contain whatever items you define, in response to your question further down this email - remember that this is a minimum level to define conformance, oe of the key design factors in EIS is flexibility to add new traits on a local basis, the fact that an implementation would allow more traits does not break conformance in my view as long as the defined traits are included). In terms of Functional Profiles, I am very keen on a relatively small number (10 - 15?) which are defined in the PIM and are reusable across PSMs, which will help my end consumer world where I am dealing with a heterogeneous environment. Note that not all of these need to be actually used in the PSMS we present, e.g. only 3 or 4 may actually be used. This would show that we have thought about the real world problems and need for flexibility but only fully defined the PSMs for you simpler cases. Other than agreeing the initial list in the PIM, this does not create extra work in the PSMs.

Key Concepts

EIS embodies a number of key concepts that should be understood up front before attempting to read and understand this specification. A full Glossary is included later in the document, but key terms are described below: