Current development

The IHE ITI domain has selected the first work items to be developed for the 2019 cycle.

Maintenance is a crucial ongoing activity for the quality and alignment of the ITI assets with the latest standard updates.

The other work items proposals received are available on the ITI 2019 Backlog.

The item proposals are available on the ftp site

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.

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.

Add Feed transaction to PIXm (insert, update, link/unlink, and merge)

There is not, today, an IHE FHIR profile to support the operation of a client registry (CR) or enterprise master patient index (EMPI) solution. The current PIXm profile is missing the FHIR equivalent of ITI-8. The FHIR standard has the needed capability. Extensions to the IHE PIXm profile are needed to support Connectathon testing of FHIR-based CR/EMPI solutions and the point of service (POS) solutions that make use of them.
The purpose of this work item is to update and extend the PIXm profile to support a FHIR-based Patient Identity Feed transaction. There is demand for such an IHE profile from organizations (e.g. the OpenHIE community) and jurisdictions (e.g. eHealth Ontario, Tanzania, Vietnam, Myanmar, the Philippines) that are leveraging FHIR-based IHE profiles and IHE Connectathons to operationalize large-scale (e.g. province-wide, nation-wide, etc.) interoperable digital health infrastructure. The profile development will be supported by members of the OpenHIE community.

XCA Deferred Response Option

Query and retrieval of documents across communities may in some cases require much more time than synchronous web services allow. We identify two such cases. Further, the existing asynchronous mechanisms available in XCA may not be a good match for some systems.
The XCPD profile has a Deferred Response Option, while the XCA profile does not. When ITI was designing the deferred mechanism for XCPD, it proposed and partially designed a draft mechanism for XCA as well. The only reason it was not originally completed was that there was not yet a pressing need. We now have one, so we are proposing to add a Deferred Response option to XCA. The US Social Security Administration and a partnering Release Of Information vendor have indicated strong interest in solving this problem, and we believe others will have similar interest.
IHE ITI is an appropriate venue to solve this, so that the solution may be standardized and not left to individual implementers.

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.

See Also

• Return to ITI Planning Committee
• Return to IT Infrastructure domain page

--