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.

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.

Panel Moderation: ONC Tech Forum - Advancing Trust of Third-Party Applications

Coming up shortly is an ONC Tech Forum ( August 10-11) virtual event. There are many tracks that I would recommend engaging with. 

I have been asked to moderate the afternoon Track 3 on Monday (1:00-2:30 pm Eastern Time)

Track 3: API Standards and Innovation

Advancing Trust of Third-Party Applications: Issues and software solutions

The 21st Century Cures Act Final Rule requires that Health IT Modules provide a standardized API for patient services, including the ability for patients to use third-party applications of their choice. This session will explore industry implications of direct-to-consumer health IT products, privacy and security policies and considerations for the future.

As a moderator I will be guiding the content and questions to the participants. So anyone that wants me to ask their question can feed their question to me via this blog article or email.

The panelists are made up of people who are very active in the API security space. I am very happy to have them be the focus of the topic.

 

IHE ITI Work Items summer 2020

ITI Tech has 5 projects happening and each have made progress in the past few weeks. I encourage participation, even if you are not a typical IHE participant. All of our projects are using GitHub, so let me know if you want to engage and have not yet gotten assigned to the proper GitHub teams. I need your GitHub username.

IHE use of IG Build tool (not exclusively ITI, but we do dominate active members)

* kanban board for this project https://github.com/orgs/IHE/projects/3

* github where we doing most of our work https://github.com/IHE/supplement-template

* example of PIXm profile converted from word/pdf supplement to IG build   http://build.fhir.org/ig/JohnMoehrke/ITI.PIXm/branches/master/index.html 

* example of MHD profile using FSH/sushi authoring http://build.fhir.org/ig/JohnMoehrke/MHD-fsh/branches/master/index.html

* example of the SANER project using FSH/sushi authoring and Keith magic (NOTE this is an HL7 project, but Keith offers this layout as inspired by the IHE supplement layout) http://build.fhir.org/ig/HL7/fhir-saner/

HIE White paper update

* kanban board for this project https://github.com/IHE/HIE-Whitepaper/projects/1

* github where the work is happening https://github.com/IHE/HIE-Whitepaper

* html rendering of current work for committee review (not proper external publication)  https://ihe.github.io/HIE-Whitepaper

IHE publications in html

* kanban has not been started as too much is in flux

* publications github where we are doing our work https://github.com/IHE/publications

* meeting minutes https://github.com/IHE/publications/wiki

* html rendering of current work for committee review (not proper external publication) https://ihe.github.io/publications/

IUA upgrade 

* kanban https://github.com/IHE/IT-Infrastructure/projects/1

* github https://github.com/IHE/IT-Infrastructure/tree/master/IUA.b

* strong use of github issues

* Team is going forward editing in markdown for supplement publication (not word doc)

SNIF White Paper promotion (more of an ITI Planning task)

* Formally published at Survey of Network Interfaces Form – Published 2020-05-29

* GitHub repo for experiment publish as html and use of GitHub Issue Tracking

* https://github.com/IHE/SNIF

* html rendering of github markdown authored for committee review https://ihe.github.io/SNIF/SNIF-Whitepaper.html

* Note we are experimenting here with using Github page publication

* Main goal at this point is to promote this to get feedback on interest in developing this further

ATNA profile specific patterns using Gazelle

* There has not been much work, but the idea is to leverage the fact that Gazelle has and needs the ATNA Audit Message patterns to enable testing.

* Future (likely the above html publications) publications of supplements and technical framework will not include the ATNA audit message pattern table inline, but rather this pattern will be defined in Gazelle and that instance will be pointed to by the IHE specification.

Web API security as foundation for #FHIR

I am a standards geek, and as such I am a strong advocate for standards developed and maintained by experts in their field. HL7 and IHE are where I focus my personal standards development. In the space of things that are special in Health IT. 

I resist when projects are brought to IHE or HL7 that want a standard developed or a profile developed in a technology space that is foundational to Healthcare, but where the specialization for healthcare is not needed. The following are some pointers to "Standards" that healthcare should use as is. This is not to say that there could be no specialization for healthcare, but rather that the fundamentals of these standards need to be followed first before anything special for healthcare is ever needed.

Web API Security -- OWASP Top 10 Web Application Security Risks

1. Injection. Injection flaws
2. Broken Authentication. 
3. Sensitive Data Exposure. 
4. XML External Entities (XXE). 
5. Broken Access Control. 
6. Security Misconfiguration. 
7. Cross-Site Scripting XSS.
8. Insecure Deserialization. 
9. Using Components with Known Vulnerabilities. 
10. Insufficient Logging & Monitoring. 

OAuth 2.0 Security Best Current Practice

This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.

IETF Best Current Practice in security

• BCP038 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
• BCP046 Recommended Internet Service Provider Security Services and Procedures
• BCP061 Strong Security Requirements for Internet Engineering Task Force Standard Protocols
• BCP072 Guidelines for Writing RFC Text on Security Considerations
• BCP106 Randomness Requirements for Security
• BCP136 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)
• BCP140 Preventing Use of Recursive Nameservers in Reflector Attacks
• BCP188 Pervasive Monitoring Is an Attack
• BCP194 BGP Operations and Security
• BCP195 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
• BCP199 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers

etc...