Open-Source Audit Log conversion

 I was made aware of an open-source project that has addressed converting classic DICOM Audit Messages into the new FHIR AuditEvent. This open-source project is managed on this github repository. I helped the authors with some background and understanding, but I take no credit for the work they have done. 

I am sure they welcome comments, suggestions, and assistance. 

My blog articles on Audit logging for Security, Privacy, and others

Patient Master Identity Registry

The Patient Maser Identity Registry is a new profile (Implementation Guide) from IHE. It is designed to address a new environment that has no existing HL7 v2 or v3 patient identity management solution, that needs a multiple organization Patient Identity Management. It defines the following actors. This is the typical IHE model of defining abstract actors, not systems. Thus these actors can be grouped in various ways inside a system that one might more typically understand.

At the center is the Patient Identity Manager, as described in the PMIR profile, this is a very simplistic actor that has no intelligence, it is just a FHIR Server that supports the transactions. Often times a real-world system would have intelligence to detect potential conflicts, or mistakes, or opportunities for linking. A system like that would defined that is is both a Patient Identity Manger, and a Patient Identity Source. This does not mean there are not other Patient Identity Source actors in a network.

There would likely be a Patient Identity Source at each organization. It would likely be in a system that is also a Patient Demographics Consumer. An example would be a Registration Desk.

There would also be typical client apps that would be Patient Demographics Consumers or Patient-Identity Cross-reference Consumers. Note that the Patient Identifier Cross-reference Consumer actor would typically be used in cases where national identifiers are issued to patients, thus a lookup is done using just an identifier. The Patient Demographics Consumer can lookup by identifier, but also can lookup by any of the demographics or identification characteristics.

The Patient Identity Subscriber and Patient Identity Consumer are used together by any system that would like to be notified of changes to a Patient Identity. This would be used by data holders (Data Servers), so that they could correct any data they have. Important is to correct the data when a Patient Identity is merged.

Patient Identity flow

The following shows the flow of these systems

First shown is that a Data Source (a typical FHIR Server) would subscribe to be notified.

Second shown is a flow at a Registration Desk

• If there is only one Patient found, and all the demographics are correct, then there is nothing more needing to be done. That one Patient found can be used within the community. 
• There are three alternatives shown: where one patient needs demographics or identifiers updated, where there is no patient found, and where more than one patient are found.  
• In the first case after clarifying that there is a need to make the demographics or identifier change, the Registration desk informs the Patient Master Registry of the  update to the demographics, which causes the Patient Master Registry to record these changes AND inform all the interested parties such as the Data Services that has subscribed.
• In the second case after confirming that no patient has found (e.g. a newborn, or new emigrant), the Registration desk informs the Patient Master Registry of the new patient with given demographics, which causes the Patient Master Registry to record this new Patient AND inform all the interested parties such as the Data Services that has subscribed.
• In the third case after confirming that the patients found are indeed all the same human, the Registration desk determines which patient entry should be merged into the other. The Registration desk informs the Patient Master Registry of the merged patients with specific instructions on which identity should be used and which identity should not be used anymore, which causes the Patient Master Registry to record this merge Patients AND inform all the interested parties such as the Data Services that has subscribed.

This solution is not expected to work everywhere. It is designed for environments that don't have existing Patient Identity infrastructure, and it is designed for places that want to manage a master identity (golden) at the center of multiple organizations.

I do expect that variations will eventually be worked up as well.

Webinar on Document Sharing HIE on FHIR

Webinar recording is available that covers the Document Sharing Health Information Exchange (HIE) on FHIR. 

Covering topics of:

• Document Sharing (concept, XDS, XCA, MHDS)
• FHIR access to Documents
• MHD as API
• Support profiles: IUA, PDQm, PIXm, mCDS, …
• MHDS as a full FHIR stack solution
• Support profiles also include PMIR, SVCM
• Consuming Elements/Resources (mXDE + QEDm)
• Add Provenance – to get back to source documents

.

This is available on the IHE YouTube channel  The slide deck with embedded recording is in the IT-Infrastructure github repo 

The content for this presentation are baked into the IHE Mobile Health Documents Sharing (MHDS) profile.

Patient Generated Health Data

Some background on what the broader government (HHS) under the office of the national coordinator (ONC) is saying about Patient Generated Health Data (PGHD). This is not a very mature definition yet, mostly because of wildly divergent abilities given to patients among the 6000 healthcare provider organizations in the USA. However the details outline here have held up well. This is what we wanted 5 years ago, it is still what we want. This includes the risks outlined 5 years ago, they are still risks today. The details on this page are mostly from January 2018.

The bad news is that we have not progressed as much as we thought we would have 5 years ago.

https://www.healthit.gov/topic/scientific-initiatives/patient-generated-health-data

​The infographic is the most useful thing on this page. It covers the points quite nicely and clearly.

 https://www.healthit.gov/sites/default/files/onc_pghd_final_white_paper_infographic.pdf

IHE-Connectathon in November to be Online

 Brussels face to face Connectathon transformed to ONLINE, 2-6 November

IHE-Europe Connectathon takes place online

After thorough consideration and evaluation of the current COVID-19 developments, we are urged to announce that the 2020 IHE-Europe Connectathon scheduled to take place on November 2-6 in Brussels, Belgium will be taking place online. IHE’s globally-developed, standards-based, open-source interoperability testing platform together with experienced monitors will support the testing event.

Abstract

When we made the decision to postpone IHE-Europe’s 2020 Connectathon Week from March to November 2020 due to COVID-19 imposed lockdowns, we had hoped that the global health environment would have improved sufficiently to hold a successful in-person event. While there have been successes and challenges managing COVID-19 impact across the world, at the moment travel warnings and restrictions are in place for many areas relevant to Connectathon participants, including Brussels. Since improving the health of people is at the heart of IHE, we do not think it is appropriate to bring together people from across Europe and other parts of the world together in-person for these IHE events at this time.

We will be collaborating with IHE domains from across the globe to hold the online IHE Connectathon utilizing IHE’s interoperability testing platform at the same dates as initially planned: 2-6 November. Current registrants' registration fees will be honored for the online event in case they register for it again, and will be refunded if they choose to not make use of this great opportunity to advance the interoperability of healthcare products and to shape the possibilities to test the interoperability of these products online.

All registrants will receive more detailed information soon on:

• fees and registration dates
• list of available IHE-profiles
• vendor connectivity test session before the Connectathon week
• instruction sessions

And more.

We look forward to receiving your registration for Europe’s first ever online IHE Connectathon, performed from November 2-6 in the European time zone, once the registration has opened. You may indicate your wish to participate in advance via secretariat@ihe-europe.net.

As announced in parallel by IHE USA, the IHE North American Connectathon in March of 2021 has been planned from the beginning as a fully online event, facilitating participants from the North American time zone. The NA Connectathon will build upon lessons learned in the European Connectathon and leverage an enhanced version of IHE’s online interoperability testing platform, Gazelle.

IHE World Summit postponed

We regretfully decided to postpone the IHE World Summit which was supposed to be held from 3 to 4 November during the IHE-Europe Connectathon week and to continue to monitor the COVID-19 global situation in order to determine a new date. We are currently aiming for a date in 2021, but this strongly depends on the development of the crisis. All World Summit participants will be refunded their fees. We thank you for understanding and we will keep you informed on the developments.

Date

Wed, 09/16/2020 - 12:00

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.