Difference between revisions of "Under assessement by planning"

From IHE Wiki
Jump to navigation Jump to search
Line 8: Line 8:
  
 
=Survey of network interfaces form (SNIF)=
 
=Survey of network interfaces form (SNIF)=
Configuration management of system-to-system interfaces that enable IHE profiles is burdensome within the healthcare enterprise. Interfaces are often manually configured, requiring trained integrators to: gather configuration properties, configure and test interoperability. The human element introduces the opportunity for errors, often typographical, that can be difficult to identify and correct. The increasing adoption of secure connectivity protocols complicates connectivity by adding additional connectivity properties, such as logging, and certificates.
+
Configuration management of system-to-system interfaces that enable IHE profiles is burdensome within the healthcare enterprise.
 +
Interfaces are often manually configured, requiring trained integrators to: gather configuration properties, configure and test interoperability. The human element introduces the opportunity for errors, often typographical, that can be difficult to identify and correct. The increasing adoption of secure connectivity protocols complicates connectivity by adding additional connectivity properties, such as logging, and certificates.
 +
 
 
This profile provides a consistent method to catalogue configuration properties for human and machine consumption during installation, upgrade and repair. This profile is a content profile that specifies properties and actors to create a “plug and play” like connectivity of interoperable systems.
 
This profile provides a consistent method to catalogue configuration properties for human and machine consumption during installation, upgrade and repair. This profile is a content profile that specifies properties and actors to create a “plug and play” like connectivity of interoperable systems.
  

Revision as of 07:56, 24 July 2019

The IHE ITI domain has received work items proposals to be developed, see https://trello.com/b/IH4FPDhN

Some of them have been already selected to be developed, see Current development.

Others have been assessed, see Planning assessed work items.

The other work items proposals received are under assessement by planning. They are listed in the present page.

Survey of network interfaces form (SNIF)

Configuration management of system-to-system interfaces that enable IHE profiles is burdensome within the healthcare enterprise. Interfaces are often manually configured, requiring trained integrators to: gather configuration properties, configure and test interoperability. The human element introduces the opportunity for errors, often typographical, that can be difficult to identify and correct. The increasing adoption of secure connectivity protocols complicates connectivity by adding additional connectivity properties, such as logging, and certificates.

This profile provides a consistent method to catalogue configuration properties for human and machine consumption during installation, upgrade and repair. This profile is a content profile that specifies properties and actors to create a “plug and play” like connectivity of interoperable systems.

Re-Document XDS Metadata Update

Now that we have Restricted Metadata Update TF supplement (RMU) for Trial Implementation, what would XDS Metadata Update TF supplement, also for Trial Implementation, look like if we re-started today? Might it be a standalone profile rather than options on XDS? Might it be updates to RMU?


Alignment of XDM/XDR with the DirectTrust implementation guide for representing Message Context

This work item proposal has two main aims:

  • Analyzing the gaps between the current IHE XDR/XDM specifications and the Implementation Guide for Message Context developed by the DirectTrust community. This review effort will enable to identify and issue recommendations of merging, or (at least) converging possibilities between the two set of specifications.
  • Applying the changes identified to the IHE XDR/XDM specifications while extending the perimeter of the uses cases covered to fully take in consideration the use of Direct Secure Messaging (DSM).

The work item suggests that this effort will optimize interoperability by reducing the number of implementation options.


Potential New Work Items - not proposed

The following is a list of things that have been spoken about, but for which we have not received a formal new work item proposal

  • XDM on FHIR -- usecases from XDM, but where the encoding of the metadata is using FHIR structure
  • MHD asynchronous -- usecases from MHD, but where there is a need for asynchronous. Such as MHD as an API to XCA where the asynchronous MHD would allow for non-blocking
  • FHIR Client security -- package up the requirements for a FHIR Client to be secure. Subset of ATNA without client side cert + IUA +???
  • SMART-on-FHIR usecases -- authorization of application space, specification of OAuth scope, specification of OAuth interaction (beyond IUA has today)
    • SMART-on-FHIR is about to be published as normative STU from HL7
    • Must deal with SMART-on-FHIR overlap. Is there anything to profile? Can we just reference SMART?
  • FHIR Maturity for MHD and other profiles -- some of the FHIR resources are not being naturally matured, where as IHE may be the best organization to focus on that (e.g. MHD)
    • DocumentReference and DocumentManifest -- need IHE to help them progress through the FMM levels.
    • DocumentManifest needs introduction, scope, etc
    • Both need testing proof etc.
  • MHD On-Demand -- document how MHD would support On-Demand -- where backend is XDS, where backend is XCA, where backend is native FHIR
  • PAM on FHIR -- all of the PAM use-cases in FHIR form
  • Re-Document ITI-18 -- simplify, clarify, various items Thing ONE
  • Work more closely with PCC and QRPH to align their newest work with ITI
  • Work toward a more continuous release structure vs the yearly schedule we now have
  • Profiling of CDS-hooks for specific clinical usecases. Or does this become a clinical domain responsibility (PCC, etc)
  • Provider Directory maturity
    • Alignment with Argonaut
    • Alignment with Sequoia Directory
    • Alignment with DirectTrust.org Directory
  • Overall alignment of our FHIR profiles with Argonaut and/or Da Vinci
  • Add in Sequoia - CareQuality -- Point-of-Care Consent mechanism to XCPD and XCA

See Also

--