Patient Identity Management the IHE way

 Here are the IHE relevant works on the topic of Patient.

Most important, this is not an interoperability problem

Nationwide Patient Identity Management, especially in a federation like the USA, is a balance between quality, privacy, and safety. Where patient treatment is involved, mistakes in identity can kill. Where health data are involved, mistakes in identity can be a permanent privacy violation. These problems don't exist in environments outside of healthcare, like the financial / banking industry, where in those industries it is easy and effective to revoke an identity, protect an account, and issue a new identity. Further in these other industries a financial remedy is all that is needed to address damages, and thus insurance against damages is easy.

The more accurate one can identify the patient, the more accurate the linkage to that same patient at other locations. Quality of identity can build upon other identifier numbers, like Drivers License, Passport numbers, social security number, etc.

Architectures

IHE includes two distinct architectures at the interoperability level.

1. Centralized - In this model, all the participating organizations feed their updates to a central service. Thus the central service is completely aware of all the information. It can cross-reference various identifiers into a virtual identity. This central authority 

2. Federated - In this model, all the participants agree to respond to queries from other participants. 

The intention is that regional exchanges that are all within a single policy domain could use the Centralized approach. Where as broader access beyond that regional exchange would be knit together using the Federated approach. 

Within an organization, there tends to be a scale of Centralized, but within an organization there could also be forms of Federated. The original PIX/PDQ model explained below was designed first for use within a healthcare treatment organization. 

This was extended to an XDS "Affinity Domain" when XDS needed an identity. In the case of XDS "Affinity Domain" there is a master identifier that is maintained centrally within the Affinity Domain, yet there is no defined centralized set of master identifier attributes. Within an Affinity Domain there is mechanics for fixing mistaken identity, but no mechanics to inform all participants when a patient changes attributes like name, address, phone number, etc. 

The Federated approach is what was designed for XCA, to enable communities to be self-contained, while enabling a patient discovery in a federated way. The XCPD profile is used in XCA to request that a patient match be discovered. This match is based on the policy, accuracy, and authorization at each responding community. 

The new IHE Profile below that manages a comprehensive identity for each patient. In this way the community participants agree to cooperate on a single identity for each patient. This would include cross-references to local medical record numbers where they exist, but more important includes mechanics for cooperating on updates as the patient changes their address, phone number, e-mail address, and name.

Interoperability solutions

FHIR Profiles

• Mobile Health Document Sharing (MHDS) – Published 2020-05-29
• Section 50.7 MHDS Background
• 50.7.4 Patient Identity Management
• 50.7.4.1 Patient Identity Management Registry (PMIR profile)
• 50.7.4.2 Patient Demographics Query for Mobile (PDQm profile)
• Patient Demographics Query for Mobile (PDQm) – Revised 2020-08-28
  
• transaction for looking up a patient by any identity attribute
• Patient Identifier Cross-reference for Mobile (PIXm) – Revised 2019-12-05
• transaction for converting one identity into known alternatives
• Patient Master Identity Registry (PMIR) – Revised 2020-08-28
• comprehensive community based Patient Identity for Golden Patient Identity

Legacy Architecture Profiles

•  [XCPD] Cross-Community Patient Discovery locates communities with electronic health records for a patient and translates patient identifiers across communities.  

•  [PAM] Patient Administration Management establishes the continuity and integrity of patient data in and across acute care settings, as well as among ambulatory caregivers.

•  [PDQ] Patient Demographics Query queries by patient demographics for patient identity from a central patient information server.
•  [PIX] Patient Identifier Cross Referencing queries for patient identity cross-references between hospitals, sites, health information exchange networks, etc.
•  [XPID] XAD-PID Change Management updates the relationship between XDS Affinity Domain patient identifiers and other patient identifiers.  

Whitepapers and Handbooks on HIE, each have sections on Patient Identity Management

• Health Information Exchange: Enabling Document Sharing Using IHE Profiles – Published 2012-01-24
• Section 4 Patient Identity Management
• 4.1 Patient Identity Cross-Reference (PIX)
• 4.2 Patient Demographics Query (PDQ)
• 4.3 Cross-Community Patient Discovery (XCPD)
• Template for XDS Affinity Domain Deployment Planning – Revised 2008-12-02
• Defines policy decisions that a community needs to address. Specific to Patient:
• Section A.8.2.2.7 XDS Patient Identity Source
• Section A.8.2.2.8 PIX Patient Identity Source
• Section A.8.2.2.9 PIX Manager
• Section A.8.2.2.10 PIX Consumer
• Section A.8.2.2.11 PDQ Patient Demographics Supplier
• Section A.8.2.2.12 PDQ Patient Demographics Consumer
• Section A.9.2.1 Example of Rules and Restrictions for Patient Demographics Data

• Volume 2x (ITI TF-2x): Appendices A through X and Glossary (Rev. 15.1)
• Appendix E: Patient Identifiers in HL7-based IHE Profiles
• Appendix M: Using Patient Demographics Query in Multi-Domain Environments

• Volume 1 (ITI TF-1): Integration Profiles
• Appendix E.10 XCA and Patient Identification Management

IHE focuses on Interoperability, not policy. This said, the interoperability needs are driven by a set of reasonable policies that are expected to be used. 

IHE ITI Supplements Updated

Big set of new publications. This is not radical changes, but cleanups and approved Change Proposals

IHE IT Infrastructure Technical Framework Supplements Published for Trial Implementation. Is this email not displaying correctly? View it in your browser. IHE IT Infrastructure Technical Framework Supplements Published for Trial Implementation The IHE IT Infrastructure Technical Committee has published the following updated supplements for trial implementation as of August 28, 2020: Add RESTful ATNA (Query and Feed) - Rev. 3.2 Appendix Z on HL7® FHIR® - Rev. 2.2 Healthcare Provider Directory (HPD) - Rev. 1.8 Mobile Access to Health Documents (MHD) - Rev. 3.2 Mobile Care Services Discovery (mCSD) - Rev. 3.2 Patient Demographics Query for Mobile (PDQm) - Rev. 2.2 Patient Master Identity Registry (PMIR) - Rev. 1.2 Remove Metadata and Documents (RMD) - Rev. 1.3 Restricted Metadata Update (RMU) - Rev. 1.2 The profiles contained within the above documents may be available for testing at subsequent IHE Connectathons. The documents are available for download at https://www.ihe.net/resources/technical_frameworks. Comments on these and all IT Infrastructure documents are welcome at any time and can be submitted at ITI Public Comments.

FHIR Security and Privacy Tutorial

I have given a tutorial on FHIR Security and Privacy at a couple of HL7 events, and some HL7 distance learning. These recordings are available on the HL7 Education on Demand site. It is not clear when I will be asked to give the tutorial again.

My slides are freely available on google sheets at this easy to type address http://bit.ly/FHIR-SecPriv. Each time I give the tutorial I update these master slides. So each time you go there you will see the latest set of slides. Some slides do have notes, and there are additional detail in slides that I don't cover during the tutorial.

I would prefer to give this tutorial in three parts, but typically only have two. If I could give it in three parts this would be the agenda

Part 1 - Basics

• Security Principles
• Privacy Principles
• Basic Security and Privacy Considerations
• Anonymous Read
• Business Sensitive
• Individual Sensitive
• Patient Sensitive
• Not Classified
• HTTP[S] - TLS
• Authentication & Authorization
• SMART on FHIR
• IUA
• Mutual-Authenticated TLS
• Access Denied Responses

Part 2 - FHIR capability

• Provenance
• Basic
• Digital Signature
• Audit Logging
• Audit Reporting
• Audit Purging
• Consent - for Privacy
• HEART
• Attribute Based Access Control
• Security Tags
• Compartments / Clearance
• Obligations
• Break-Glass
• De-Identification

Part 3 - Practical application

• Multiple Organization Provider Directory
• using relational linking
• Multiple Organization Profile Directory
• using security tags as compartments with clearance
• Extra-Sensitive Treatment
• Share with Protections
• De-Identified Research

Note that ALL of these topics have been covered in this blog. See Security Topics, Consent/Privacy, and FHIR for index to these articles.