Printer Friendly

The role of enterprise person directories.

Enterprise-wide directories of persons are needed to expand the MPI concept to include multiple systems and person entries. This EPD -- Enterprise Person Directory -- addresses accurate identification across the enterprise.

Managed care is impacting the provision of care (continuity and outcomes) and, even more, the business of care (restructuring the industry).

Much has been written about the need for electronic medical records to address the provision of care for continuity across episodes (and a lifetime) as well as for outcomes analysis.

Since care is typically provided in multiple settings, involving multiple information systems, a person must be identified consistently across each system containing information about that person. Therefore, the electronic medical record must depend on accurate identification "up front" which associates patients with their previous visits.

At the same time, even a cursory glance at business publications both inside and outside health care makes it obvious that the health care industry is re-structuring.

Whether it is a "not-for-profit" provider merging or acquiring another provider or whether it is a "for-profit" provider buying or selling a facility, the health care industry is in a state of business flux.

Layered on top of these legal structures are affiliations between providers. Both ownership and affiliation have a record of making and breaking relationships, thus necessitating a modular ability to include and exclude participating information systems as the business needs dictate. For both business functions and customer perceptions, the ability to consistently identify a person across each system containing information about that person is required.

A person directory

In order to address these parallel needs, an enterprise-wide directory of persons is needed.

This directory would span the existing information systems during the initial search/look-up when registering each person into those systems.

All registration systems have some form of internal "MPI" Master Patient Index) if a search for previous registrations is performed. The term MPI has historically been used for the search/look-up file and has been a key tool for medical records departments to validate patient identification.

Since one system cannot practically process each type of care a person may receive in the enterprise (e.g., hospital, physician office, home health, etc.), a "seamless" patient population must be created across all of the participating registration systems.

This enterprise role expands the MPI concept to include multiple systems, as well as person entries which may not have previously been in all (or any) participating registration systems. This broader role is best described at an "EPD" (Enterprise Person Directory), indicating a collection of "persons" known to the enterprise.

The role of the EPD is to address accurate identification across the enterprise, as well as provide a cross-reference of identifiers for the appropriate information systems. As the enterprise-wide source for identification, the EPD provides a consistent, standardized way to identify a person throughout the enterprise.

The EPD, using more reliable probabilistic matching techniques, should also provide for exception monitoring to ensure consistent demographic data capture regardless of where the data may be collected.

The EPD's second role of cross-referencing identifiers results from the fact that a person will commonly have multiple identifiers.

Identifiers such as Social Security number, HMO number, etc., are typically assigned outside the registering system and could be considered "external" IDs. Identifiers assigned within the participating systems, such as medical record number, system ID, etc., could be considered "internal" IDs. The EPD could then cross-reference any external ID (or combination of) with the appropriate internal ID for the requesting system.

This allows existing internal IDs to continue to be used while accommodating new external IDs (e.g., national healthcare ID, managed care group number, etc.). In fact, the external IDs need not even be used or stored in the participating systems, since they may be obtained at any time from the EPD.

Thus the cross-reference role of the EPD can significantly speed the use of new external IDs even before most systems can accommodate them directly.

In summary, the Enterprise Person Directory: * Increases the accuracy and consistency of identification;

* Provides cross-referencing to maintain existing IDs; * Provides rapid assimilation of new populations and

new IDs * Allows phased transitions to new systems and IDs.

Information architecture

The EPD is a key coordination tool in the enterprise's business information flows. Viewing the EPD only as a back-end or standalone process tacked onto the existing applications minimizes its value to the organization.

The business information flow architecture focuses on the increasing value of information as it "flows" through the enterprise. Applications are viewed as services which add value to the information flow.

Figure 1 illustrates the flow of administrative information through a single hospital.

The registration-admission/discharge/transfer (Reg/ADT) service provides the foundation, establishing the person's presence in the facility.

Presence is established by the assignment of a coordinating "tag" which can then be used semi-autonomously by the ancillaries with the summary events sent to the patient accounting system for billing. A similar flow design can be developed for the clinical data flows into an electronic medical record, using the same Reg/ADT foundation and the same ancillaries.

Note that there is no EPD in Figure 1 because only one facility is participating. The EPD becomes necessary when multiple systems are participating, as shown in Figure 2.

Note that each facility's Reg/ADT continues to provide the foundation for its domain with the EPD providing the enterprise-wide coordination. Since the existing systems' domains are "coordinated" rather than "invaded," the structure also illustrates the ease with which additional systems can be added, or current systems removed.

The EPD is not simply "tacked on" to Figure 2, but is an integral component guaranteeing the integrity of information as it flows through the enterprise.

William "Buddy" Gillespie, Vice President and CIO at York Health System (YHS) in Pennsylvania notes, "We operate under well-defined business objectives which require an information infrastructure which allows business functions to be quickly added, changed, or dropped, thus allowing us to obtain an advantage in the market and/or to respond to competitive pressure."

YHS is implementing an electronic medical record system and is using an EPD as a key front-end component in their architecture. The EPD will provide identification and coordination within their facilities with plans to expand across affiliated organizations.

Similarly, Mercy Hospital in Iowa City, Iowa discovered in a recent community survey that their patients had to give all the same insurance and current address information over and over at different points in the health care process.

"Patients referred by Physician A to Physician B didn't understand why Physician B didn't already have all the basic demographic information," explains Gary Wilke, Director of Information Services at Mercy Hospital.

"As the patient walks through the system generating progressively more and more current data within various medical record databases, we need assurance that this is the correct patient, that the various medical record numbers have been resolved, and that the data is most current from anywhere in the system without repetition and redundancy."

IS support and standards

The major obstacle to wider use of EPDs is the ability to use the EPD as a front-end service (during registration).

Most provider systems have been written for a single facility providing care, and do not adjust well to the multi-system enterprises appearing in health care. Existing systems are often viewed as the organization's infrastructure instead of application service nodes on the organization's business information flows.

Providing for service calls (or trigger events) to the EPD during the registration process is minimally invasive, yet provides continued use of that system, extending the enterprise's return on investment. This seems to be a small effort with large value.

Multiple interests are addressing the EPD function. In early 1996, a loose coalition of organizations identified the need for a non-proprietary identification mediator which could point to all locations where a person might have health information.

Los Alamos National Lab hosted an initial workshop on this topic with overwhelming attendance and interest. Following the second workshop, the need for a more structured "home" was recognized.

Believing that the EPD role was complementary to (and possibly a viable alternative for) the unique health identifier called for in the Kassebaum-Kennedy legislation, the coalition sought sponsorship by an ANSI-Accredited standards development organization.

HL7 (Health Level 7) responded with an invitation to form a special interest group (SIG), which was approved in January and began meeting in April of 1997, according to the mission statement for HL7's SIG-MPI.

At the same time, CORBAmed issued a RFP for a patient identification standard.

A coalition of vendors has jointly submitted a comprehensive response. HL7 is also coordinating efforts with the CORBamed submission as well as with American Society for Testing and Materials (ASTM) standards efforts.

These joint efforts should quickly produce more workable solutions to the EPD role. Without a standard for interactions, front-end integration of an EPD into an enterprise is limited to screen "scraping and painting."

Identification versus identifier

The recognition that multiple identifiers already exist and should continue to be used was addressed above.

This is not just a transitional requirement, but an ongoing need. The objective must be to uniquely identify a person based on the available information; however, this sometimes seems to be confused with a unique identifier.

Unique identifiers are certainly desirable both for accuracy and for simplification, but the external and internal identifier roles should be kept separate.

When establishing a person's presence in an information system, that system must be able to assign a unique ID. If an externally assigned ID is also used as an internal ID, conflicts such as two different persons claiming the same external ID are much more difficult to handle quickly; e.g., should care wait while the external discrepancy is resolved? Cross-referencing the internal ID to the appropriate external ID simplifies handling this situation.

Similarly, if a person's external ID is subsequently determined to have been wrong, correction is more complicated when the external ID is also the internal ID. Again, cross-referencing the internal ID to the appropriate external ID simplifies the correction.

System processing is much more workable if each system domain continues to controls its own internal IDs and then cross-references its internal IDs to appropriate external IDs.

This separation allows the external ID to be associated with the person when needed and more easily handled when conflicts arise. As long as the appropriate ID is available when necessary, it does not matter how that ID is carried internally. A parallel might be the process used by credit bureaus when a creditor only needs one ID (SSN, credit card, etc.) to find the associated complete credit history. The EPD role thus relieves each participating system from maintaining all associated IDs.

Making it all work

As the example sites show, the EPD is key to making managed care work. With the involvement of multiple settings and multiple information systems, it is imperative that a person be identified consistently across each system containing information about that person.

As Gary Wilke observed, "If you want a network to work, you've got to first have all parties agree that this is the same patient in all the different computer systems."

James M. Gabler is the enterprise information architect for HUBlink, Inc., Columbus, Ohio. He also is co-chairman of the HL7 SIG-MPI and is a member of the Health Management Technology editorial advisory board. His honorarium will be donated to the Make-A-Wish Foundation.
COPYRIGHT 1997 Nelson Publishing
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1997 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Technology Information; enterprise-wide directories expanding Master Patient Index concept
Author:Gabler, James M.
Publication:Health Management Technology
Date:Oct 1, 1997
Previous Article:Hospital cuts records staff and rent with electronic patient charting.
Next Article:Integrating health information systems, a key to improving patient information, care.

Related Articles
Buzzwords, acquisitions shaping healthcare I/T.
Patient identification: the Achilles heel of computerized health information.
Focus survey: Master patient indexes.
Enterprisewide scheduling systems will become more responsive to users' needs.
How to find who.
Streamline the Registration Process with EMPI.
Enterprise Integration: Is There Life After Consolidation?
Unlocking the Power of Your EMPI.

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters |