Product EIS SFM

Product Brief - Identity Cross-Reference Service Functional Model (IXS)

back to Main_Page

back to Product List

Product Name

Identity Cross-Reference Service Functional Model (IXS), or
Entity Identification Service Functional Model (EIS SFM), or
also known as Identification Service (IS)

Topics

• Administration,
• Service Metadata Management,
• Entity Identification Management
• Query

Standard Category

Application Functional Specifications - Services (SOA)

Integration Paradigm

Services

Type

DSTU

Releases

• HL7 V3 EIS R1 (DSTU) Dec 2006
• HL7 V3 IS, R2 - undergoing normative ballot Sep 2009

Summary

The Entity Identification Service Functional Model (EIS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for managing identities, such as would be used in a Master Patient Index (MPI). Not limited to use for Patients, the EIS SFM can be equally applied to manage identities for staff, providers, facilities, or any other “entities” needing identity management. The EIS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and establishes a basis for an unprecedented collaboration with the Object Management Group (OMG) that has adopted a technical specification complementing this SFM.

Description

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.

• How does this relate to the OMG Technical Specification and to the Healthcare Services Specification Project?
  • For EIS, HL7 has partnered with OMG to produce technical specifications supporting Service Functional Models within OMG’s technology adoption process. To the healthcare industry, this provides value via OMG’s rigorous architectural approach, review process, and distributed systems expertise. For OMG, this relationship brings deep healthcare experience via HL7’s extensive international participation and vertical industry expertise. The Healthcare Services Specification Project (HSSP) is a moniker for the collaboration between groups collaborating on service standards, of which HL7 and OMG are participants.
• How does this relate to the HL7 Services-Aware Enterprise Architecture Framework?
  • In 2008, HL7 embarked upon developing its Services-Aware Enterprise Architecture Framework (SAEAF). SAEAF will be aligning the broad range of HL7 specifications—including services, messages, and document standards—to a consistent approach across the whole of HL7’s offerings. SAEAF also specifies usage constraints for deployed HL7 standards. Several HSSP services predate SAEAF. Over time, we expect all HL7 Service Functional Models to come into alignment with SAEAF.

• Don’t industry standard services (such as the Decision Support Service, Entity Identification Service) limit vendor competition?
  • Not necessarily. While industry standards specify how a consumer interacts with the service, these specifications have expressly left how these functions are supported out-of-scope. In other words, there is no predetermined knowledge modeling formalism, system design platform, or approach that is advocated in the standard. Vendors are able to compete based upon quality-of-service and the benefits of their specific implementation. Further, the specification includes mandatory and supplemental requirements (“nice-to-haves”), which can further stratify marketplace offerings.

Business Case (Intended Use, Customers)

• Vendors: Health Care IT,
• Providers: Hospitals and Health Networks,
• Local and State Departments of Health,
• Integrators/consultants

Benefits

• Quite simply, the Entity Identification Service defines the collective set of behaviors that one would expect system components such as an MPI to perform. This functionality is required of most healthcare organizations and supported by many vendors and product. The challenge is that each one does things a bit differently, and making them work together becomes exponentially complex. Without clearly defined expectations of what falls within the responsibility of the Identification Service, variants abound and interoperability suffers.

Working with the EIS specification will reap the following additional benefits for stakeholders:

1. The ability to provide and utilize a common infrastructure for identifying persons can make it easier for a vendor to bring a product to market and provide functionality that might be greater than having to deliver a standalone system which would include this capability.
2. While many healthcare services and application vendors provide some form of Master Patient Index (MPI), the level of functionality and the implementation details vary greatly. Vendors currently provide MPI functionality because the ability to uniquely and consistently identify a patient is necessary for integrating any systems in which patient data is stored. The functionality of an MPI is supportive and not a core function of the clinical, financial, laboratory, or other applications in the healthcare setting. An MPI implementation is generally not considered a product differentiator. A consistent interface to an Entity Identification Service could allow vendors to concentrate on the business issues for the applications and take advantage of best-of-breed technology for entity identification. For those vendors that supply best-of-breed MPI functionality, providing standard interfaces to their MPI by way of the Entity Identification Service specification would allow those vendors to provide their MPI as key piece of middleware for clinical information system vendors.
3. Consumers of healthcare applications would benefit from the ability to select an Entity Identification Service that meets their needs. In addition, as business environment changes dictate, a standard set of interfaces would allow application consumers to change the Entity Identification Service provider without impact to existing applications
4. From the point of view of a hospital system or a department of health there are potential large cost savings that could be achieved by being able to utilize a common framework for person identification that would work across different commercial products, each of which might be specialized to provide health information specific to its scope. The ability to competitively procure such an identification component could potentially reduce the cost of such a system. For the patient, the benefits would be the ability to receive a higher quality continuum of care across multiple provider and care organizations. This might also be able to impact the medical insurance industry by reducing costs in the process of ensuring accurate care of the correct patient.

Resources

Work Groups

• Services Oriented Architecture (SOA)

Education

• See more at http://www.hl7.org/implement/training.cfm

Relationship to/ Dependencies on, other standards

• HL7 Messaging Standard: V 2.5 and V3; HL7 EHR Functional Model
• IHE Integration Profiles: PIX – Patient Identifier Cross-Referencing, PDQ – Patient Demographics Query, PWP – Personnel White Pages
• Network Working Group RFC3377, Sept 2002, Lightweight Directory Access Protocol (v3), RFC 2426, Sept 1998, vCardMIME Directory Profile
• OMG Person Identification Service (PIDS) Specification Version 1.1, April 2001

Links to current projects in development

• Project Insight ID 264, Infrastructure: Entity Identification Service (EIS) Functional Model