Survey of Network Interfaces Form (SNIF) White Paper

From IHE Wiki
Jump to: navigation, search

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

  • Editor: Steve Nichols (
  • Editor: Ruth Berge (
  • Domain: ITI


IHE ITI Public Comment Page


Video Intro

Youtube Intro

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.



  • 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


  • 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



  • 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


  • 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


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


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

  • HL7 v2
  • XD*
  • FHIR

Process Flow

SNIF Transactions

5. Open Issues and Questions

User Questions

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?


  • What level of portability, availability and openness should be proposed to access SNIF?
  • What amount of security information should be included within the data model without compromising security?

Profile Questions

  • Is there a preferred technical approach based on existing standards??
  • Is there any interest from an organization willing to develop an opensource implementation as a project related to the SNIF profiling activity?
  • Should SNIF have focus on implementation and break-fix use cases, or should it take a greater role in routine network transactions (i.e. reference SNIF in lieu of a static host file)?
  • SNIF-like functionality is exercised in the Carequality/eHealth Exchange Provider Directory, what Carequality attributes should be included in SNIF (and vice-versa)?
  • How should multiple SNIF Repositories be managed?
  • Is there a need for an authoritative Repository and defined data management policies?
  • Do Digital Signatures offer a solution?
  • Should the Repository query Content Creators for updates or does this add unnecessary complexity?

SNIF Data Model

  • What is the preferred approach for timestamps?
  • Which fields are suited for encoding as identifiers for machine readability?
  • Are there recommended standards that can satisfy one or more groups of the data model?
  • How should the data model handle synchronous vs. asynchronous services?