PATIENT IDENTIFICATION CROSS-REFERENCING PIX and PDQ: AS THE STRATEGIC FOUNDATION FOR INTEROPERABILITY

1. 1 Presenters Ian Stahl, Initiate Systems PATIENT IDENTIFICATION CROSS-REFERENCING (PIX and PDQ):AS THE STRATEGIC FOUNDATION FOR INTEROPERABILITY - Patient Identifier Cross-referencing (PIX) provides cross-referencing of patient identiers from multiple Patient Identier Domains. These patient identiers can then be used by identity consumer systems to correlate information about a single patient from sources that know the patient by different identifiers - Patient Demographics Query (PDQ) provides ways for multiple distributed applications to query a central patient information server for a list of patients, based on user-dened search criteria, and retrieve a patient's demographic (and, optionally, visit or visit-related) information directly into the application. - Cross-Enterprise Document Sharing (XDS) provides a standards-based specification for managing the sharing of electronic clinical documents with textual and structured content that healthcare enterprises (anywhere from a private physician to a clinic to an acute care in-patient facility) have decided to explicitly share. This contributes to the foundation of a shared Electronic Health Record. - Patient Identifier Cross-referencing (PIX) provides cross-referencing of patient identiers from multiple Patient Identier Domains. These patient identiers can then be used by identity consumer systems to correlate information about a single patient from sources that know the patient by different identifiers - Patient Demographics Query (PDQ) provides ways for multiple distributed applications to query a central patient information server for a list of patients, based on user-dened search criteria, and retrieve a patient's demographic (and, optionally, visit or visit-related) information directly into the application. - Cross-Enterprise Document Sharing (XDS) provides a standards-based specification for managing the sharing of electronic clinical documents with textual and structured content that healthcare enterprises (anywhere from a private physician to a clinic to an acute care in-patient facility) have decided to explicitly share. This contributes to the foundation of a shared Electronic Health Record.

2. 2 Your Presenter Ian Stahl, Director of Product Management,Initiate Systems, Inc. istahl@initiatesystems.com (512) 634-5183

3. 3 The healthcare reality Volume of patient data increasing exponentially Quality of patient data declining Fragmented, duplicate and conflicting patient information within and across databases andtouch points Regulatory and safety issues drivenew requirements

4. 4 Critical Data Details Over 30% of all Master Person Index (MPI)records have an invalid or blank value inname (first/last), date of birth or gender Jumps to over 60% if middle name counted Over 80% of all confirmed duplicate recordshave a data discrepancy in one or more keypatient identifying fields i.e., Name, date of birth, SSN/SIN or gender Nearly 40% of all duplicate records havea discrepancy in the first or last name Seven specific objections generalized: Technology that facilitates patient identification and data linkage US & Canada Similarities of patient identification and data linkage approaches between US and Canada Review actual & proposed deployments for patient identification and data linkage Master Patient Person CDI Community Patient Person (Show of Hands)Seven specific objections generalized: Technology that facilitates patient identification and data linkage US & Canada Similarities of patient identification and data linkage approaches between US and Canada Review actual & proposed deployments for patient identification and data linkage Master Patient Person CDI Community Patient Person (Show of Hands)

5. 5 PETE: MAKE FONTS AND ELEMENTS LARGER IF POSSIBLE WHILE ALLOWING MORE WHITE SPACE AND ABILITY TO READ TITLE WITHOUT ASK ME IF YOU HAVE QUESTIONS. SEE BUILD NOTES BELOW FROM LORRAINE Pete, this slide should build in the following manner Periphery of ecosystem Then identity for entire ecosystem Lastly all the arrows for standards and timing To create a RHIO, organizations across the healthcare ecosystem need to communicate. As we look across the healthcare ecosystem, we can see that not only hospitals participate in RHIOs, [click to add other organizations] but so will pharmacy and PBM groups, long term care organizations, physicians, lab and imaging systems, disease control centers, physician networks, other hospital groups, radiology centers, public health providers and even consumer organizations. (Click to add EMPI overlays) At the center of the exchange is an EMPI or Identity Hub that will store the 5-10 data elements that will facilitate patient identification. This federated approach, with only this very limited amount of data held centrally, will be maintained and can be update by a variety of messaging approaches, including API calls, HL7 ongoing ADT traffic, highlight update with XML, or perhaps real-time update SOAP. Because of the flexibility of the Initiate Identity Hub software, the high variability in frequency and type of message can be accommodated. While interoperability between the clinical systems is a challenge, interoperability in the context of managing patient identification is readily achievable. This federated approach to data exchange allows for the clinical data to reside where it is created, and where it can best be secured and maintained. Patient identification is the only centralized function, and that is done with limited data that does not upset existing business or data practices. Ideally, RHIOs would achieve a real-time data exchange state. In practice, this is not likely to happen in the near-term. With Initiate Identity Hub software you get flexibility to work with any and all messaging structures from batch to real-time. We accommodate a variety of transport mechanisms in addition to a variety of update intervals as shown in the diagram. PETE: MAKE FONTS AND ELEMENTS LARGER IF POSSIBLE WHILE ALLOWING MORE WHITE SPACE AND ABILITY TO READ TITLE WITHOUT ASK ME IF YOU HAVE QUESTIONS. SEE BUILD NOTES BELOW FROM LORRAINE Pete, this slide should build in the following manner Periphery of ecosystem Then identity for entire ecosystem Lastly all the arrows for standards and timing To create a RHIO, organizations across the healthcare ecosystem need to communicate. As we look across the healthcare ecosystem, we can see that not only hospitals participate in RHIOs, [click to add other organizations] but so will pharmacy and PBM groups, long term care organizations, physicians, lab and imaging systems, disease control centers, physician networks, other hospital groups, radiology centers, public health providers and even consumer organizations. (Click to add EMPI overlays) At the center of the exchange is an EMPI or Identity Hub that will store the 5-10 data elements that will facilitate patient identification. This federated approach, with only this very limited amount of data held centrally, will be maintained and can be update by a variety of messaging approaches, including API calls, HL7 ongoing ADT traffic, highlight update with XML, or perhaps real-time update SOAP. Because of the flexibility of the Initiate Identity Hub software, the high variability in frequency and type of message can be accommodated. While interoperability between the clinical systems is a challenge, interoperability in the context of managing patient identification is readily achievable. This federated approach to data exchange allows for the clinical data to reside where it is created, and where it can best be secured and maintained. Patient identification is the only centralized function, and that is done with limited data that does not upset existing business or data practices. Ideally, RHIOs would achieve a real-time data exchange state. In practice, this is not likely to happen in the near-term. With Initiate Identity Hub software you get flexibility to work with any and all messaging structures from batch to real-time. We accommodate a variety of transport mechanisms in addition to a variety of update intervals as shown in the diagram.

6. 6 The Basic Questions How do I begin to integrate all these solutions? Use and insist on IHE Profiles – Templates for needed interoperability functions What do I use to “glue” these solutions together? HL7 Messages – Healthcare messaging standard already used What drives access to all the solutions? The patient – Healthcare is about the patient information How do I deliver an EHR? Find the patient – Use IHE Profiles with HL7 Messages to access the patient records and other supporting data

7. 7 Patient Identity Drives Interoperability Do we know this patient? Is this the correct patient? What information do I have about this patient? Where did this patient information come from? What “view” do I have of this patient? What else do I know about this patient? I guess this is the typical set of questions being asked in a patient query. Assuming that this is in a RHIO or other affiliation - shared information contextI guess this is the typical set of questions being asked in a patient query. Assuming that this is in a RHIO or other affiliation - shared information context

8. 8 How Does PIX/PDQ Drive Interoperability Do we know this patient? PIX/PDQ Query from client to XRef Manager Is this the correct patient? PIX/PDQ Manager must handle, accurately, the matching and linking with tunable probabilistic algorithms What information do I have about this patient? PIX/PDQ Manager Response to query Where did this patient information come from? Domain based HL7 Messages Identify sources What “view” do I have of this patient? Security applied at the application, PIX/PDQ Manager , or both What else do I know about this patient? Extending the PIX/PDQ Manager and using other IHE profiles (i.e. XDS)

9. 9 Interoperability requires accurate patient matching and linking

10. 10 PETE: MAKE FONTS AND ELEMENTS LARGER IF POSSIBLE WHILE ALLOWING MORE WHITE SPACE AND ABILITY TO READ TITLE WITHOUT ASK ME IF YOU HAVE QUESTIONS. SEE BUILD NOTES BELOW FROM LORRAINE Pete, this slide should build in the following manner Periphery of ecosystem Then identity for entire ecosystem Lastly vall the arrows for standards and timing To create a RHIO, organizations across the healthcare ecosystem need to communicate. As we look across the healthcare ecosystem, we can see that not only hospitals participate in RHIOs, [click to add other organizations] but so will pharmacy and PBM groups, long term care organizations, physicians, lab and imaging systems, disease control centers, physician networks, other hospital groups, radiology centers, public health providers and even consumer organizations. (Click to add EMPI overlays) At the center of the exchange is an EMPI or Identity Hub that will store the 5-10 data elements that will facilitate patient identification. This federated approach, with only this very limited amount of data held centrally, will be maintained and can be update by a variety of messaging approaches, including API calls, HL7 ongoing ADT traffic, highlight update with XML, or perhaps real-time update SOAP. Because of the flexibility of the Initiate Identity Hub software, the high variability in frequency and type of message can be accommodated. While interoperability between the clinical systems is a challenge, interoperability in the context of managing patient identification is readily achievable. This federated approach to data exchange allows for the clinical data to reside where it is created, and where it can best be secured and maintained. Patient identification is the only centralized function, and that is done with limited data that does not upset existing business or data practices. Ideally, RHIOs would achieve a real-time data exchange state. In practice, this is not likely to happen in the near-term. With Initiate Identity Hub software you get flexibility to work with any and all messaging structures from batch to real-time. We accommodate a variety of transport mechanisms in addition to a variety of update intervals as shown in the diagram. PETE: MAKE FONTS AND ELEMENTS LARGER IF POSSIBLE WHILE ALLOWING MORE WHITE SPACE AND ABILITY TO READ TITLE WITHOUT ASK ME IF YOU HAVE QUESTIONS. SEE BUILD NOTES BELOW FROM LORRAINE Pete, this slide should build in the following manner Periphery of ecosystem Then identity for entire ecosystem Lastly vall the arrows for standards and timing To create a RHIO, organizations across the healthcare ecosystem need to communicate. As we look across the healthcare ecosystem, we can see that not only hospitals participate in RHIOs, [click to add other organizations] but so will pharmacy and PBM groups, long term care organizations, physicians, lab and imaging systems, disease control centers, physician networks, other hospital groups, radiology centers, public health providers and even consumer organizations. (Click to add EMPI overlays) At the center of the exchange is an EMPI or Identity Hub that will store the 5-10 data elements that will facilitate patient identification. This federated approach, with only this very limited amount of data held centrally, will be maintained and can be update by a variety of messaging approaches, including API calls, HL7 ongoing ADT traffic, highlight update with XML, or perhaps real-time update SOAP. Because of the flexibility of the Initiate Identity Hub software, the high variability in frequency and type of message can be accommodated. While interoperability between the clinical systems is a challenge, interoperability in the context of managing patient identification is readily achievable. This federated approach to data exchange allows for the clinical data to reside where it is created, and where it can best be secured and maintained. Patient identification is the only centralized function, and that is done with limited data that does not upset existing business or data practices. Ideally, RHIOs would achieve a real-time data exchange state. In practice, this is not likely to happen in the near-term. With Initiate Identity Hub software you get flexibility to work with any and all messaging structures from batch to real-time. We accommodate a variety of transport mechanisms in addition to a variety of update intervals as shown in the diagram.

11. 11 Interoperability defined Interoperability has been a challenge to define. It means different things to everyone we talk to. In our definition we break interoperability into three components – People, Data and Process People are the consumers of the data Data are the many variations of patient data distributed across the healthcare ecosystem Process are the many activities that the data are used for Together these three components make Interoperability which we define as: “The invocation of the necessary services to provide the most accurate information to the right place at the right time” [Note: services in this definition is in the context of an electronic service, not a human or manual service] As you see on the left, all of this is governed by privacy, security, standards and regulatory compliance.Interoperability has been a challenge to define. It means different things to everyone we talk to. In our definition we break interoperability into three components – People, Data and Process People are the consumers of the data Data are the many variations of patient data distributed across the healthcare ecosystem Process are the many activities that the data are used for Together these three components make Interoperability which we define as: “The invocation of the necessary services to provide the most accurate information to the right place at the right time” [Note: services in this definition is in the context of an electronic service, not a human or manual service] As you see on the left, all of this is governed by privacy, security, standards and regulatory compliance.

12. 12 Reference architecture Now lets look at the reference architecture. You’ll remember the sticky apps across the top from earlier slides. Each of these sticky apps requires interoperability to provide the most accurate information to the right place at the right time. To get this interoperability often requires multiple components. This slide breaks down these components: Starting at the bottom… Messaging services and source adapters – to physically connect to source systems. This can range from traditional EAI, to Web Services to custom adapters designed to connect systems together. (example: EPIC Ambulatory to Cerner Clinical) Data Services – Manage data, clean data, model data, decide what data to persist, decide what data to federate Security Services – Define who has access to data and audit who touched it Identity Services – The core of what Initiate does Core Business Services – Reusable components that leverage data. Fuzzy search on patient name/address, Get all patient records associated with this patient ID, etc. Application Services – The applications that consume the data and apply logic All of these components can be developed internally or through the various consulting services of your favorite systems integrator. For this example we color coded the components that Initiate, IBM (SI and product supplier) and UPMC (subject matter expert and interface builder) have exceptional expertise in. Now lets look at the reference architecture. You’ll remember the sticky apps across the top from earlier slides. Each of these sticky apps requires interoperability to provide the most accurate information to the right place at the right time. To get this interoperability often requires multiple components. This slide breaks down these components: Starting at the bottom… Messaging services and source adapters – to physically connect to source systems. This can range from traditional EAI, to Web Services to custom adapters designed to connect systems together. (example: EPIC Ambulatory to Cerner Clinical) Data Services – Manage data, clean data, model data, decide what data to persist, decide what data to federate Security Services – Define who has access to data and audit who touched it Identity Services – The core of what Initiate does Core Business Services – Reusable components that leverage data. Fuzzy search on patient name/address, Get all patient records associated with this patient ID, etc. Application Services – The applications that consume the data and apply logic All of these components can be developed internally or through the various consulting services of your favorite systems integrator. For this example we color coded the components that Initiate, IBM (SI and product supplier) and UPMC (subject matter expert and interface builder) have exceptional expertise in.

13. 13 How to get started Start with choosing a solution that supports the IHE PIX/PDQ Manager functionality Choose vendors who have products that support the PIX/PDQ client to call the IHE PIX/PDQ Manager Feed the IHE PIX/PDQ Manager patient identifying information

14. 14 IHE Web site: www.IHE .net

15. 15 Questions? Ian Stahl, Director, Product Management istahl@initiatesystems.com Bill Klaver, Healthcare Solutions Architect bklaver@initiatesystems.com www.initiatesystems.com

16. 16