ITI 2018 New Work Items

From IHE Wiki
Jump to navigation Jump to 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

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.

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.

Retrieved from "http://wiki.ihe.net/index.php?title=ITI_2018_New_Work_Items&oldid=109507"