ITI 2018 New Work Items

From IHE Wiki
Jump to: navigation, search

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.

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

The Document Sharing (XDS, XCA, etc) 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, and Cross-Community Access getting wide deployment, there are now some good Best Practice on how to leverage the metadata. ITI will be producing a Handbook that helps an XDS Affinity Domain or an 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. This problem is amplified in a cross-community where the publishing actor, who published a document decades before, is in a different State or Country from those treating the current clinical need addressing a health condition the patient now has. The primary goal is to define principles that will make cross-border exchange more reliable.

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 is a high-level classification. Thus we look to existing communities for examples of their result, and derive Principles that drive a good valueSet, a process that could be followed for ensure the valueSet is complete, and mechanisms to ensure that the valueSet is used and maintained.

Restricted Metadata Update (RMU) Profile

Where documents are maintained in a XDS Affinity Domain or a federation (XCA) of communities, there are times when authoritative and authorized changes need to be made to the metadata. These documents may be published within a local Health Information Exchange using Cross-Enterprise Document Sharing, or the documents might be distributed among many communities accessible using Cross-Community Access. For example, a Patient may have received treatment while on vacation or might simply live/work on a boundary between communities. To receive treatment, the patient allows their records to be shared among these communities. When treatment is completed, the patient instructs authorities to change the confidentiality code of their documents to restrict access to their personal medical records.

In order to focus the effort, the Technical Committee agreed to limit the changes to stored DocumentEntry metadata elements that are descriptive in nature and do not affect how the metadata is stored within a Document Registry. The experience with the more comprehensive supplement, Metadata Update, shows that managing lifecycle and interrelationships between Registry entries is much more complex. The difficult changes includes Transforms, Appendments, Signatures, etc. The current effort has put these out-of-scope, but IHE will continue to work on them in the future.

The approach separates out these more 'lightweight' metadata elements from the more 'heavyweight' metadata elements (structural) and provides additional flexibility for storing the metadata updates. The RMU profile does not require full implementation of the Metadata Update supplement. These limits will be enforced by separate actor being asked to persist the change to the document's metadata. If that actor can persist the change, the transaction succeeds. This actor is enabled to reject any request that does not meet the requirements within their community. A rich set of error codes is provided for various potential rejection reasons.

AS4 Option on XCA, XCDR and XCPD

This supplement introduces a new Asynchronous Web Services (WS) Exchange stack based on the OASIS Applicability Statement 4 (AS4). The current Asynchronous WS Exchange stack is an IHE specialization of the asynchronous capabilities of the WS stack that has not been widely implemented. It is based on WS-Addressing and MTOM/XOP and is left unchanged by this Supplement. It has been renamed WS-Addressing Asynchronous WS Exchange to distinguish from the AS4 Asynchronous WS Exchange.

Providing a more robust Asynchronous WS Exchange Option is attractive for upcoming cross-border ehealth information exchange, such as the European eHealth Digital Service Infrastructure that deploys the XCA, XCPD, and XCDR Profiles and for countries where the adoption of the OASIS AS4 reliable and secure messaging is common when cross-sector (beyond the health sector) applicability is needed.

This new AS4 Asynchronous Web Services Exchange stack:

  • Relies on the OASIS AS4 WS Stack that has been natively designed to support Asynchronous WS Exchange and offers:
    • Message packaging governed by ebMS 3.0 and message security governed by WS-Security
    • Support for both push and pull message exchange choreographies
    • Payload compression
    • Non-Repudiation of Origin and Receipt (NRO/NRR)
    • Reception Awareness – simple and effective reliable messaging with no known interoperability issues
  • Is introduced as:
    • An option to the XCA, XCPD profiles where the current WS-Addressing based Asynchronous WS Exchange is available,
    • A new option to the XDR and XCDR Profiles.

The end result will be that XCA, XCPD, XCDR and XDR Synchronous Web-Services will stay the same as they are today;

This new AS4 Asynchronous WS option is proposed to be introduced alongside the existing WS-Addressing based Synchronous Web-services, that may be retired in the future if this new AS4 Asynchronous WS is widely adopted in environments where asynchronous exchanges are important.

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

The expected US national extension did not happen.

Ongoing improvement of existing Profiles and documentation

This is ongoing significant effort. This work is driven by Change Proposals. More details can be found ITI Change Proposals 2018.