Requirements

The requirements for a MPI system include:

1. Personal privacy - provisions must exist for an individual to limit sensitive information from unwanted exposure. This is discussed further in the next section.
2. Masking of data sources - related to the personal privacy issue, it must be possible for the source location of patient data to be hidden from the MPI user. Knowing where data is located (such as at a mental health clinic) is many times a sufficient giveaway as to the type of medical problem the patient had.
3. Extendibility - The MPI architecture should be useful to point to locations of medical information about a patient as well as locations of "administrative" information about a patient (i.e., patient enrollment, eligibility, coordination of benefits, and other insurance information).
4. Open architecture - the MPI architecture must be non-proprietary and platform independent. CORBA satisfies this requirement.
5. Scaleable architecture - MPI system implementations will range from within a single provider to possibly the international level. In this regard it is helpful to differentiate between "enterprise directories" at the bottom level, with directories of these directories existing at higher levels (both of which are "MPIs"). Search capabilities developed for the WWW are expected to be useful in this area, and serve as an existence proof that large scale searching can be done efficiently.
6. Legacy system compatibility - the MPI architecture must allow compatible implementations with existing vendor MPI systems to exist. The CORBA concept of developing "object wrappers" around legacy systems will be useful here. It may not be possible to have 100% compatibility with every vendor system now in existence. We should strive for "working" compatibility with virtually all systems. Given that the specified interface, or one like it, becomes a standard, organizations implementing internal MPI solutions could require their vendors to incorporate the standard interface in their products.
7. Access control - users of the MPI must be authenticated as having a legitimate need to access the information. A trusted source will be needed to administer MPI systems above the enterprise level. Possibly the healthcare professional organizations could become involved in determining who should have legitimate access to what information.
8. Security - even with access control in place, transactions should take place in a secure manner (such as being encrypted) to protect the confidential nature of medical information.
9. Audit trail - a record must be maintained of all MPI transactions.

   Many policy issues will need to be addressed, as a standard MPI interface gets defined. However, policy decisions should NOT be addressed directly as part of the interface specification itself. The appropriate public policy and government groups need to address these policy issues in parallel with the development and testing of MPI standard interface applications. It should be possible to implement a number of different usage policies on top of the MPI interface definition. Public policy and government regulations will play a crucial role in determining how large-scale MPIs are actually used, and consensus on these matters has not been reached. Policy decisions that these groups should address concurrently with the development of the interface specification include:

   • Whether pointers to just the date of the first (or last) encounter at a given provider is stored, or whether pointers to all encounters are recorded.
   • How access to detailed patient electronic information (the patient records themselves) is to be granted. That is, the job of the MPI stops when the location of the medical data has been identified. How this data is then retrieved will depend upon such things as the characteristics of the remote system, access negotiations required, and the type of data being retrieved (textual, image, audio, or video).
   • What user category (provider, payer, or patient) is allowed to access what MPI data.
   • How MPIs are organized (hierarchical, federated, loosely distributed or some other network structure).

Patient Privacy and Confidentiality

Of prime interest to patients is the legitimate concern that their private medical problems will be exposed against their desires. Any MPI proposal must address these concerns as a primary, not secondary, requirement. Our proposal has the following privacy/confidentiality features:

• Because information about the locations where a patient receives care can reveal potentially sensitive information, the patient retains extensive control over what information from the MPI can be exported. Records from selected providers (or all providers) and/or sensitive individual medical encounters can be "hidden" from inquiry.
• Release permission for the patient's data for use in an anonymous manner for medical studies can be granted or revoked.
• A patient can be identified by a self-defined "handle", without any demographic data (even the patient's name) needing to be present.
• A mechanism whereby a patient can access information about changes made to his/her MPI information, such as the addition of a new encounter, or when an inquiry is made.
• Only the date of the first and/or last encounter (visit) to a provider can be recorded, or pointers to all encounters can be stored. In the first case it merely identifies that medical records exist at this provider without further details. By storing just the first/last encounter information, the MPI user needs to negotiate with the provider to obtain more details. This feature can be used to limit the visibility of and access to the details of treatment at "sensitive" provider sites.
• To provide a masking of data sources, it is noted that "surrogate" MPIs can be set up. A surrogate MPI would function similarly to a normal MPI, but would pass requests on to referenced MPIs (of presumably sensitive providers), and strip sensitive identifying information from the results returned. Also, subsequent access to the medical records would need to go through the surrogate MPI. The MPI user would never know the electronic address from where the records are obtained.

There are some assumptions involved to make the above a reality. These include:

• MPIs above the enterprise level are managed and administered by a trusted authority. (Note: data within an enterprise is controlled by that enterprise, and the above controls do not come into play in this situation. Also, the creator of an encounter should always be able to see that encounter, regardless of the privacy settings of the patient.)
• Some mechanism is provided by the trusted authority to give the patient the privacy controls. This mechanism could range from an online service that is charged for, down to paper forms that are filled out and snail mailed. This service would need to be universal in nature and so must have low or no-cost options.
• The trusted authority must allow a patient to view their MPI data.

The services provided by the trusted authority might be modeled after those found in the credit reporting industry, for example.

Additional Features

In addition to the above patient privacy features, the specified MPI object model has these features:

• The differentiation between a "collector MPI" (to organize MPIs) and a "directory MPI" (to contain actual MPI information).
• A hierarchical or network organization of MPI collectors.
• A MPI stores "provider", "payer", and "patient" information to identify where medical data exists, but does not store actual medical data other than an optional emergency data set and/or an optional "health profile."
• A The patient can place valuable information in the MPI for emergency use, including emergency medical data and contact information. Also, a non-emergency "health profile" can be maintained to provide a self-defined medical history.
• Providers can control which other providers are allowed to access their information.
• An audit trail of the MPI transactions can be maintained.

MPI Architecture

Figure 1 illustrates the relationships between collector and directory MPIs, in conjunction with access to existing proprietary MPI systems.
IMG00001.GIFCare Master Patient Index (MPI) White Paper (CONT.)" TITLE="Health Care Master Patient Index (MPI) White Paper (CONT.)" />

Health care organizations today can be grouped into two types, based on whether they have an existing internal MPI system or not. They will have a different relationship to the "collector" or "directory" MPIs depending on the type of organization.

One or more "collector MPIs" reference sets of "directory MPIs". Some directory MPIs will be run in a quasi-public manner to provide MPI services to small providers who do not have their own MPI systems. To connect existing proprietary enterprise MPIs to a collector MPI, an "object adaptor" layer will need to be introduced if the existing system is not CORBA-ready. If patient privacy controls are to exist for data exported from enterprise MPIs, either the enterprise MPIs need to be updated to add these features, or a directory MPI must to introduced between the enterprise MPI and the collector MPI to provide the service point.

MPI Object Model

A conceptual, or reference object model has been defined for a MPI. This object model is defined in terms of "objects" as CORBA is object-based. An object consists of both data and a set of operations, or "methods". The set of "services" provided by the MPI interface is the collection of these methods on the MPI objects.

The object model helps in understanding the MPI interoperability interface. It can also serve as a guide in the development of new MPI systems that want to support a standard. Of course, the integration of an existing MPI system to the specified interface will require mapping the data and methods of the interface to data and functions available in the existing system. It is anticipated that this will be satisfactorily doable for most systems available today.

MPI Services

The services to be provided by the MPI interface are defined in the object class definitions. It is the implementation of these services that must be met for a MPI to be considered as compliant with the specified interface.

At this time only the more important or interesting services have been defined in detail. A summary of these is outlined here:

• Login/authorization to obtain MPI services.
• Find known MPIs based on some search criteria, such as geographical location serviced.
• Determine whether a MPI is accessible.
• Search for a patient match. Takes "identity" information as input and returns zero or more patients.
• Return specific patient information, such as race or old addresses. Useful to prune the returned matches.
• Select a patient. Returns a fuller set of patient information, such as full demographics and the set of encounters with the current provider.
• Query the encounter data.
• Iterate over the encounter data.
• Create a new patient, provider, or payer.
• Bulk load of data, such as patients or encounters.
• Update patient information, such as demographics.
• Merge or link "patients" which have been determined to be the same person.
• Administration services - all others probably fall into this category of necessary but less interesting capability, such as access to the audit trail…

Note: it is expected that access to some MPIs, and certainly access to some data in directory/enterprise MPIs will require negotiation (similar to when two modems try to connect). Exceptions will be generated when a operation cannot complete because additional negotiation is required.

Business Opportunities

The business opportunities associated with the creation of MPIs beyond the enterprise level include:

• Provide network infrastructure to connect MPIs together.
• Sales of computer platforms to MPI end-users.
• Sales of databases for MPI implementation.
• Provide a service to connect small providers not having their own MPI to a quasi-public directory MPI, with connection through a dial-up line (or maybe ISDN).
• Develop custom integration software for existing proprietary MPI systems to support the MPI interface.
• Develop software toolkits to support the specified MPI interface, for use by custom integration developers.
• Provide a MPI administration service, responsible for managing provider, payer, and patient access data in a regional or national MPI.
• Provide patient access services - private accounts for online update of emergency medical data, health profile, provider access control, and receiving notifications. Could also provide non-electronic service (paper forms) support.
• Provide a service to handle the uploading of encounter and patient registration data into a MPI from small providers.
• Sales of complete MPI solutions.
• Government support for the implementation of collector MPIs.
• Sales of MPI interface solutions (set of web browser applets for MPI search and gathering of electronic patient data) for situations where the MPI access is not integrated into the local patient registration system.

Scenarios

MPI usage scenarios to be supported include:

• Initial registration of a patient (making a new MPI patient entry).
• Adding a provider or payer.
• Searching for the correct patient.
• Patient updating access permissions or other data under their control.
• Provider or payer updating data under their control.
• Bulk uploading of patient registrations (at MPI startup).
• Uploading of encounter data.
• Access to emergency medical data.
• Access to eligibility data and other insurance and administrative information.

IDL Specification

The specification available for the workshop will include a CORBA IDL version of the Object Model.

A prototyping effort associated with the specification was recently initiated.