Survey of Network Interfaces Form (SNIF) White Paper

1. Survey of Network Interfaces Form (SNIF) White Paper

• Editor: Steve Nichols (steven.nichols@ge.com)
• Editor: Ruth Berge (ruth.berge@ge.com)
• Domain: ITI

Link

IHE ITI Public Comment Page

Table of Contents

1 Introduction

1.1 Purpose of the Survey of Network Interfaces Form White Paper

1.2 Scope

1.3 Intended Audience

1.4 Open Issues and Questions

1.5 Closed Issues

2 Summary

2.1 Problem Description

2.2 System Configuration Catalogs in Other Work Items

3 Use Cases

3.1 Use Case #1 New Single System Implementation

3.2 Use Case #2 Service

4 Profile Proposal

4.1 Description

4.2 Process Flow

4.3 Security Controls

4.4 Actors

4.5 Transactions

4.6 Data Model

4.7 Future Profile Extensions

2. The Problem

Configuration management of peer interfaces enabling IHE profiles is burdensome within 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 Cases

Goal: Standardize a configuration management catalogue of endpoint parameters.

Implementation

Current:

• 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

Desired:

• During the planning phase, the institution interface analyst reviews the new system specifications, comparing them to a readable SNIF
• The vendor is provided relevant entries from the institution’s SNIF
• Mismatches are reviewed implementation plans are modified to ensure desired connectivity between the new and existing systems
• During implementation, relevant SNIF entries are imported into the new system (avoiding manual entry and typographical errors)
• The new system is created in the institution’s SNIF repository and it’s SNIF parameters are retrieved by existing systems

Service

Current:

• An institution interface analyst or system administrator responds to the service disruption
• In evaluating the disruption, the interface analyst requires endpoint interface details to perform triage

• They research technical details of each interface in order to assess availability and identify vendors to engage in addressing the problem
• Once engaged, vendor(s) may require additional interface details, depending on the completeness of the initial discovery performed by the institution

• Through iterative testing and gathering of information by those involved, the root cause of the disruption can be determined and addressed

Desired:

• The institution system administrator searches and retrieves interface connectivity details for the effected systems registered in the SNIF repository
• With this information, the administrator focuses activities based on known security profiles, network addresses, ports and departmental contacts documented within the SNIF

4. Standards and Systems

Actors

Content Source – the application or human providing the endpoint information

Repository - catalogue of the SNIF form(s)

Content Consumer – the application or human reading the endpoint information

Standards

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

• HL7 v2
• XD*
• DICOM
• FHIR

Process Flow

5. Discussion open issues

As this profile relies on HDO (vs. vendor) adoption, we are interested in answers to the following questions:

• How are interface endpoints catalogued today?
• Who maintains the catalogue?
• If an endpoint catalogue was standardized, would you adopt it?
• Would you transition your current system to this one?