ITI 2018 New Work Items

The IHE ITI domain has selected the following work items for the 2018 cycle:

Produce FHIR conformance resources for a subset of current FHIR Profiles

There are a set of profiles ITI has published that use FHIR. These profiles have been written using the normal IHE Governance and Documentation. This however, did not produce a brand new kind of documentation that is made possible by FHIR 'conformance' resources. These conformance resources have two different uses:

1. A server can advertise exactly what the server supports. aka Conformance Claims. This can then be used by applications to determine if the server supports the capabilities that the app needs.
2. A Profile can document exactly what clients and servers need to do in order to be compliant with that Profile. aka Conformance Needs. This enables application and server developers to know more 'automatically' the conformance criteria. This enables organizations to more 'automatically' test an app or server compliance to that defined Profile

There is a relationship between #1 and #2; in that a Server will likely implement many capabilities as the sum total of all the capabilities of the sum total of all the Profiles that it has chosen to implement. It is possible that an app or server exists only to use one Profile, but it is unusual. The app and server must combine the capability needs from those Profiles (#2) into their published conformance claims (#1).

It is this second thing that IHE ITI will be working on producing, reviewing, and incorporating into the future Governance and Documentation. This effort will produce:

• StructureDefinitions, that hold the resource-by-resource constraints found in the Profile.
• CapabilityStatement, that hold the actor-by-actor constraints found in the Profile.
• ValueSet and CodeSystem, that hold constraints around codes.
• ImplementationGuide, that for now will just be a manifest of all the conformance (the above things) and a link to the IHE publication.

There is more advanced work ongoing in IHE, working with HL7, and the HL7 "Implementation Guide" publication mechanism. An HL7 "Implementation Guide" is the same concept as an IHE "Profile". This more advanced work is looking at leveraging more advanced ways of publication.

XDS metadata guidelines for Affinity domain and cross-community information exchange

The XDS metadata are a set of data that describe a document, a submission set, and a folder. These data elements are intended to make the discovery of relevant data possible. With Cross-Enterprise Document Sharing now 14 years old, there is now some good Best Practice on how to leverage the metadata. ITI will be producing a Handbook that helps an XDS Affinity Domain or XCA Community define rules for how the metadata will be used within their community. Most specifically this Handbook will define principles, process, and mechanisms that would help create a Value Set of vocabulary that would assure best use of the metadata.

For example the classCode metadata element is intended to be a high-level classification of document type. It is thus related to typeCode, but would be a smaller set of vocabulary (valueSet) that has high-level classification. Thus we look to existing communities for examples of this result, and derive Principles that drive a good valueSet, a process that could be followed for assuring the valueSet is complete, and mechanisms to assure that the valueSet is used and maintained.

Cross-Community Metadata Update (XCMU) Profile

Where documents are maintained in a federation (XCA) of communities, there are times when authoritative and authorized changes need to be made to the metadata. Specific example is where a Patient has asked authorities to change the Privacy/Security mark on a document so that the document Privacy protections change. That is the confidentialityCode metadata element. there are times where the documents that cover a Patient are thus distributed among many communities. An example of how this happens is where a Patient may have received treatment while on vacation, or may have multiple homes, or might simply live/work on a boundary between communities.

In order to focus the effort, we agreed to limit the metadata elements that can be changed to DocumentEntry metadata elements that are not structural. Those metadata elements that, to the Registry, are simply descriptive. The reason this simplifies the effort is that much of the struggle with Metadata Update is related to the lifecycle and interrelationships between Registry entries. This includes Transforms, Appendments, Signatures, etc.

The approach is to separate out these more 'lightweight' metadata elements from the more 'heavyweight' metadata elements; leverage the Metadata Update transaction; but limit what can be done. This limit is recognized by the lightweight focus, but is more importantly enforced by the actor that is being asked to persist a change to the metadata. If that actor can persist the change, than it does that, and the transaction succeeds. However given the various 'heavyweight' issues, we enable this actor with the power to reject any request and give a long list of specific error codes so that it can be expressive on the reason the transaction failed.

This transaction must also be extended to the Cross-Community environment, and not be limited to an XDS Affinity Domain.

AS4 Option on XCA, XCDR and XCPD

The EC Commission has mandated that network communications between countries must use a Web-Services configuration called "AS4". AS4 is a web-services industry defined profile of how to use the web-services network stack (including SOAP, SAML, etc) for use in cross boarder use-cases. This concept of profiling is just like IHE profiling, except that it is done by a general purpose web-services community. Thus IHE using this AS4 'profile' is a good use of profiles using profiles.

This AS4 effort will produce Transactions that are not compatible with existing IHE Profiles web-services. Therefore this effort will need to carefully manage this. The effort will thus focus on Asynchronous Web-Services specifically for the XCPD and XCA profiles. Where these profiles do include an Asynchronous Web-Services today, the survey of operational XCA networks have resulted in clear evidence that only the Synchronous Web-Services are actively being used today. Thus the AS4 effort will replace the Asynchronous Web-Services specification.

The end result will be that XCPD and XCA synchronous web-services will stay the same as they are today; the existing asynchronous web-services will be retired; and an Asynchronous Web-Services based on AS4 will replace it going forward.

we expect a US national extension for PAM to be presented, following approval by IHE USA.

The expected US national extension did not happen.

we continue to work on Change Proposals

This is ongoing but not insignificant effort. This work is driven by change proposals. More details can be found ITI Change Proposals 2018.