Maintenance of ITI Profiles Published in 2018 and earlier

In Fall 2018, the IT Infrastructure Domain counts 25 Final Text Profiles, 19 Trial Implementation Profiles, and 7 additional Trial Implementation Supplements that modify existing FT profiles. More new TI supplements are published every year than are moved to Final Text. This growing list of documents has to be maintained with a yearly significant list of change proposals by a finite number of ITI Technical committee members.

The 2018-19 cycle (on Sept.7) begins with 101 assigned CPs, 7 completed CPs in 2 CP ballots, and 9 completed CPs awaiting a future ballot.33 CPs are currently assigned to someone who is no longer active on the ITI Technical Committee. Key expertise has been lost due to contributors who cannot be involved anymore in ITI development (for example, the work on CPs enabling XDS-MU to go to Final Text).

The staggered publication is also an important element to be considered. In scheduling republication of approx. 4 documents per quarter, rather than doing all republications once a year, the publication workload would be better managed.

This situation is becoming critical and the audience for this proposal knows the value of ITI Technical Framework documentation to the other IHE domains and to the healthcare IT community.

The ITI Planning and Technical Committees should explicitly identify maintenance as a work item to evaluate against other work item proposals for new profiles and set aside Technical Committee resources to improve quality in existing documentation.

Alignment of XDM/XDR with the DirectTrust implementation guide for representing Message Context

This work item proposal has two main aims:

Analyzing the gaps between the current IHE XDR/XDM specifications and the Implementation Guide for Message Context developed by the DirectTrust community. This review effort will enable to identify and issue recommendations of merging, or (at least) converging possibilities between the two set of specifications.
Applying the changes identified to the IHE XDR/XDM specifications while extending the perimeter of the uses cases covered to fully take in consideration the use of Direct Secure Messaging (DSM).

The work item suggests that this effort will optimize interoperability by reducing the number of implementation options.

Facilities and Hierarchies in FHIR

FHIR does not have a good definition for facilities and has recommended using both Organization and Location to define a facility. There is also no defined way to handle multiple hierarchies for facilities. Furthermore there is a need to be clear on what data is provided for a facility instead of solely a Location or Organization.

In order to avoid multiple solutions that would not be compatible, this proposal suggests the following approaches:

A larger CP for mCSD can be issued in order to clearly define how facilities are defined by using Location and Organization together.
A whitepaper profiling how this can be achieved in a standard way.
Any other option.

Add RESTful capabilities to DSUB

This proposal is in line with the work already carried out for Mobile access to Health Documents (MHD) with XDS on FHIR, in searching and retrieving documents through RESTful capabilities. This work item consists of studying how to subscribe or unsubscribe, from a mobile application, in order to receive notifications when a clinical document has been created. This work will be achieved in adding restful capabilities to the Document Metadata Subscription profile (DSUB).

Add restfull feed to ATNA

This proposal is in line with the work already carried out for example, for Mobile access to Health Documents (MHD) with XDS on FHIR, in searching and retrieving documents through RESTful capabilities. This work item consists of auditing the access to clinical documents from mobile applications implementing this kind of new profiles for mobile. This work could be achieved in using FHIR, which offers the ability to POST the AuditEvent resource that is suitable to manage the audit of an event.

Enhance ITI-44 and ITI-46 transactions (PIXv3 Feed and Update Notification) to support also patient delete/deactivation and unmerge

The purpose of this proposal is to respond to real-life scenarios in which patient data must be deleted or merged. This work item consists of enhancing the Patient Identity Feed HL7 V3 [ITI-44] and PIXV3 Update Notification [ITI-46] transactions by developing Delete and Merge options.

Update core set of IHE-on-FHIR profiles to FHIR Release 4

Update to FHIR Release 4 for January/February publication: MHD, PDQm, QEDm, mXDE, mCSD This is to meet a desire for ONC to include IHE on FHIR profiles in updated regulation.

Potential New Work Items - not proposed

The following is a list of things that have been spoken about, but for which we have not received a formal new work item proposal

XDM on FHIR -- usecases from XDM, but where the encoding of the metadata is using FHIR structure
- Could extend to carrying non-Document resources on portable media
- https://chat.fhir.org/#narrow/stream/65-ihe/topic/FHIR.20based.20XDM
MHD asynchronous -- usecases from MHD, but where there is a need for asynchronous. Such as MHD as an API to XCA where the asynchronous MHD would allow for non-blocking
- https://healthcaresecprivacy.blogspot.com/2018/09/improving-document-exchange-response.html
ATNA FHIR Audit Client -- (Rob's proposal from last two years). Simply document how a FHIR Client would use AuditEvent to log the same security events as ATNA does today
- https://chat.fhir.org/#narrow/stream/65-ihe/topic/ATNA.20on.20FHIR
FHIR Client security -- package up the requirements for a FHIR Client to be secure. Subset of ATNA without client side cert + IUA +???
SMART-on-FHIR usecases -- authorization of application space, specification of OAuth scope, specification of OAuth interaction (beyond IUA has today)
- Must deal with SMART-on-FHIR overlap. Is there anything to profile? Can we just reference SMART?
FHIR Maturity for MHD and other profiles -- some of the FHIR resources are not being naturally matured, where as IHE may be the best organization to focus on that (e.g. MHD)
- DocumentReference and DocumentManifest -- need IHE to help them progress through the FMM levels.
- DocumentManifest needs introduction, scope, etc
- Both need testing proof etc.
MHD On-Demand -- document how MHD would support On-Demand -- where backend is XDS, where backend is XCA, where backend is native FHIR
PAM on FHIR -- all of the PAM use-cases in FHIR form
Re-Document ITI-18 -- simplify, clarify, various items Thing ONE
Re-Document MU -- now that we have RMU, what would MU look like if we re-started today? Might it be a standalone profile rather than options on XDS? Might it be updates to RMU?
Work more closely with PCC and QRPH to align their newest work with ITI
Work toward a more continuous release structure vs the yearly schedule we now have
Profiling of CDS-hooks for specific clinical usecases. Or does this become a clinical domain responsibility (PCC, etc)
Provider Directory maturity
- Alignment with Argonaut
- Alignment with Sequoia Directory
- Alignment with DirectTrust.org Directory
Overall alignment of our FHIR profiles with Argonaut and/or Da Vinci

Current development

Contents