Guest blog by Karen Witting, co-chair of the IHE ITI Planning Committee and prime on the XCPD profile
See previous blog article: Patient Identity Matching. IHE has a set of profiles all focused on Patient Identity Matching. Each has their focus. There is also recorded webcasts available for replaying, and presentations available for download.
To Centralize or not:
To start, XCPD assumes that the implementation of a centralized source of patient demographics, identifiers or record locations is unacceptable. This is a fundamental assumption because if a centralized source of these types of information is acceptable there are many more effective means of solving the problems XCPD solves. For instance, if all demographics can be sent as feed transactions to a central patient matching engine, like a PIX Manager, then a PIX or PDQ Query is much more effective at finding patient identifiers and correlating patients than any deployment of XCPD. In fact, XCPD was created only because there were countries which felt that collecting demographics for all the patients in a country or region into one system would be dangerous. So XCPD is only appropriate when it is used to link communities that are not closely tied and have only limited governance, in particular, are not willing to feed all patient demographics to a single, central server, or even a small number of duplicated central servers. To Federate or not:
The challenges are: what is a “reasonable number” and how do we encourage centralized approaches in every place where it makes sense. XCPD does not design the architecture; that is for organizations, nations, and regions to do. XCPD, plus many other IHE profiles and healthcare standards, can work together to allow interoperable participation in whatever the architecture turns out to be.
Once we have agreed that a wholly centralized source of patient matching is not acceptable – due to policy or security/privacy concerns or others – application of XCPD can begin.
Flexible Requirements:
XCPD is written to be flexible in its requirements. During the development of XCPD organizations throughout the world expressed requirements to the IHE team and these requirements were designed in as optional behavior. For instance:
- We want to use a national patient identifier instead of demographics.
- We want to only pull data, never support other peer networks to pull data from us.
- We want to restrict the demographics shared in a query/response due to privacy concerns.
- We want to restrict the number of matching responses due to privacy concerns.
- We want to collect patient record locations for selected patients and make that list available for other communities in order to enable efficient searching for the patients we select.
- We want to return multiple potential matches so that a local decision can be made for patient safety reasons.
- We want to avoid returning multiple potential matches due to privacy concerns but would like to request additional demographics to aid in disambiguation.
- We need to provide a cache value for matched patient matches to allow for refresh of that information.
- We need to revoke prior matched patient due to policy, consent or demographic changes.
- We need asynchronous behavior.
- We want to have enough security and privacy context to make an access control decision that respects the patient consent directives
Because of all this optional behavior, XCPD cannot be effectively implemented out of the box. An organization must first understand the environment in which it will be deployed, the balance of risks organizations are willing to accept (e.g. false negative/false positive criteria), and how the mitigations necessary for unacceptable risks should be applied to the optional behavior of XCPD.
Modes of Operation:
There are a few modes of operation of XCPD to allow for different types of typical interactions:
- Demographic Query and Feed mode: This is the base mode and allows the initiator to both feed knowledge or a local patient as well as query for a match at the responder site. This mode allows both sides of the transaction to learn about matching patients.
- Demographic Query only mode: Here we see a simple demographic query, asking only for the responder to provide a match to a local patient. This mode does not allow responder to know about a match with the initiator’s patient. This satisfies the requirement for nodes that will not support other peer network pull requests.
- Shared/national Patient Identifier Query and Feed: This mode includes in the query only identifiers, no demographic data is shared.
XCPD asynchronous behavior:
The XCPD Patient Discovery transaction, the base transaction discussed here, supports three interaction modes each of which satisfies a different interaction environment. The chapter references given are within the XCPD supplement.
Description
|
Target environment
|
|
Normal (synchronous)
|
the SOAP request and response are carried in one TCP/IP connection
|
Response is expected in very short timeframe, e.g. less than 60
seconds
|
Asynchronous
|
where the WS-Addressing support for “replyTo” is used to return the
response through a separate TCP/IP connection
|
Response is expected in short timeframe, e.g. less than 60 minutes
|
Deferred
|
where the request is decoupled from the reply so each are a separate
SOAP interaction (Section 3.55.6.2)
|
Response is expected to have lengthy delay, e.g. more than 60 minutes
|
XCPD as a Record Locator Service (RLS):
A challenging requirement addressed by XCPD is the ability to use XCPD as a form of Record Locator Service. There are several capabilities built into XCPD which enable this functionality. But, as with everything else in XCPD, the architecture for doing this is not spelled out by XCPD since a variety of architectures may be desired. Instead there are hooks within XCPD which enable the capability to be designed. The particular capabilities for enabling this functionality are:
- Carry senders homeCommunityId and local patient identifier in the request (see 3.55.4.1.2.4)
- Carry responders homeCommunityId in response (see 3.55.4.2.2.4)
- Specify support for Health Data Locator in response (see 3.55.4.2.2.5)
- Specifies the “Patient Location Query” optional transaction
Security Considerations:
See the Patient Identity article for a short explanation of Security Considerations. The shorter is that XCPD uses SOAP, and therefore can be grouped with XUA. Thus there is plenty of security/privacy information available for a Privacy and Security decision to be made. Thus things like Privacy Consent can be enforced right away at Patient Identity discovery.
Conclusion:
XCPD is just a profile from IHE, in order to understand how it works and determine the scalability of the solutions that it enables one must include specific Policies, operational environment factors, application workflow, functionality, and safety/security/privacy. There likely is no perfect solution, the problem of patient identity discovery is a very hard one. If you can centralize or have a unified Identity, then that is a solution that is going to be far more efficient.
A more detailed and specific examination of the way that the NwHIN Exchange uses this profile is at NwHIN-Exchange use of XCPD for Patient Discovery. This shows some of the ways that an operational environment can constrain XCPD, and some of the ways that one can get in trouble.
Obligatory disclaimer by Karen regarding IBM: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions."
Resources:
No comments:
Post a Comment