Difference between revisions of "Survey of Network Interfaces Form (SNIF) White Paper"

From IHE Wiki
Jump to navigation Jump to search
Line 47: Line 47:
  
 
===Standards===
 
===Standards===
Initially, this profile will be limited endpoints of commonly supported protocols:
+
Initially, this profile will be limited endpoints of commonly supported standards:
 
:* HL7 v2
 
:* HL7 v2
 
:* xds repository
 
:* xds repository
 
:* DICOM
 
:* DICOM
 
:* FHIR
 
:* FHIR

Revision as of 11:02, 29 October 2019

1. Proposed Workitem: Survey of Network Interfaces Form (SNIF) Profile

  • Proposal Editor: Steve Nichols / Ruth Berge
  • Editor:
  • Domain: ITI

2. The Problem

Configuration management of peer interfaces enabling IHE profiles is burdensome within to HDOs (Healthcare Delivery Organizations). 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 properties, such as logging and certificates.

There is little public information on the cost of configuring interoperable products, however there is much commentary on the expense associated with system integration. One paper estimates a savings of seven hours when a configuration management tool is used to assist in the set up a new cath lab [1] Barriers include lack of an inventory of systems, and their related connectivity properties, features and requirements. Organizations differ: some can readily provide this information, others do not maintain it, taking weeks to complete a site inventory.

3. Key Use Case

Goal: Standardize a configuration management catalogue of endpoint parameters.

Current workflow:

  • HDO purchases departmental system
  • An interface analyst is assigned to the implementation project
  • The analyst collects initial interface information and provides to the vendor
  • Several interactions occur between the analyst, vendor and departmental stakeholders to curate the interface information
  • The vendor and analyst configure systems in a development environment
  • Issues are identified during testing:
  • Troubleshooting and correction of failed connectivity occurs
  • Additional, previously undiscovered, endpoints are added
  • The vendor charges customer for unforeseen interfaces (e.g. unplanned software options additional implementation time)
  • The new system is cut into production
  • The interface analysis is reassigned to another project


Proposed workflow:

  • Prior to placing a purchase order, the vendor reviews a human readable SNIF file to size the application server and quote interoperability software options
  • After the interface analyst is assigned to the implementation project she reviews a human readable SNIF file to learn the number of existing endpoints within the healthcare enterprise, confirming application requirements
  • During installation, the system software:
  • Registers with the SNIF repository
  • Auto-configures endpoint properties
  • Endpoints on the network also poll the SNIF repository and add configuration properties of the new application
  • Upon registration, endpoints that require a service restart send a notification to the local administrator to schedule a restart during downtime.

4. Standards and Systems

Content Source – the application or human providing the endpoint information

Repository - Repository of the SNIF form(s)

Content Consumer – the application or human reading the endpoint information

Registry - like REM Dose Registries

Standards

Initially, this profile will be limited endpoints of commonly supported standards:

  • HL7 v2
  • xds repository
  • DICOM
  • FHIR