Latest revision as of 14:56, 23 May 2018

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:

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.
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.

@@ Line 21: / Line 21: @@
 = 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.
+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.
-= Cross-Community Metadata Update (XCMU) Profile =
+= Restricted Metadata Update (RMU) 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.
+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, 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.
+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 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.
+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.
-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 =
-= 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.
-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.
+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 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.
+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.
-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 =
+= Ongoing improvement of existing Profiles and documentation =
-This is ongoing but not insignificant effort. This work is driven by change proposals. More details can be found [[ITI Change Proposals 2018]].
+This is ongoing significant effort. This work is driven by Change Proposals. More details can be found [[ITI Change Proposals 2018]].

Difference between revisions of "ITI 2018 New Work Items"