5
NwHIN Specification Version and Migration Plan
Nationwide Health Information Network
(NwHIN)
Specification Version and Migration Plan
4/14/2011
Page 1 of 6
5
NwHIN Specification Version and Migration Plan
1 Executive Summary
The current versioning approach for the Nationwide Health Information Network relies upon the ability to
discover specific transaction versions in the Web Services Registry (UDDI). NwHIN participants are
required to upgrade to latest version of an approved specification in a specified timeframe (3-6 months,
depending on a determination of ‘materiality’). Furthermore, the current approach does not address how
the NwHIN should handle changes to specifications (Messaging Platform, Authorization Framework and
Web Services Registry, etc.).
Additionally, when a new version of a specification is developed, it has to go through a materiality review
by the NCC. The results of a materiality review can delay the approval process for updated
specifications (beyond 6 months). The lock-step upgrade to the new specifications can place a burden
on NwHIN on-boarding personnel, as ALL of the NWHIN participants attempt to seek certification under
the new specifications within the allotted period. The lock-step upgrade path does not address the
situation where an NwHIN participants cannot upgrade in the timeframe allotted (3-6 months) due to
business resource constraints (funds, labor, other priorities, etc.). Once an implementation is up and
running it is difficult to make the business case to expend resources to upgrade to a new version of a
specification.
There is currently no process or plan in place to manage an upgrade to a new NwHIN specification
version that causes a breaking change while maintaining backwards compatibility and production
operational continuity for interoperability. Additionally, maintenance of NwHIN specifications are on
individual specification basis and are not managed in a broader context. There is no universal method to
communicate exactly which arrangement of specifications is required for implementers to support.
The purpose of this document is to define the migration plan for implementers to new versions of NwHIN
specifications. The proposed versioning and migration plan are as follows:
o
o
o
Facilitate the versioning of specifications within the organizing principle of particular core
specifications within the NwHIN community, without requiring NwHIN participants to adopt
new specifications in a blanket fashion across the entire NwHIN community.
If changes occur in core specifications, the NwHIN governing body will set the transition and
deprecation period for the core specification(s) as well as any non-core specification(s) that
uses the core specification(s)
If changes occur in non-core specifications, the NwHIN governing body will NOT set a
transition period for the respective specification(s). The plan will not attempt to dictate or
influence implementer’s internal software development lifecycles in terms of adopting these
non-core specifications. Rather, implementer’s decision to adopt new specification versions
will be driven by their use case (or profile) needs.
This approach will address the lack of a migration plan for both minor and breaking changes to
specifications while gaining support from the NWHIN community because of its flexibility to implementers.
Page 2 of 6
5
NwHIN Specification Version and Migration Plan
2 Proposed Approach
2.1 Assumptions

















All Trial Implementations participants supported a common version of NwHIN core services, which
included transport, security, and other services, for demonstration and production pilot purposes
The core specifications are not profile driven, rather the profiles will be driven by the core
specifications (see Table 1 for list of core specifications)
Web Services Registry is considered a foundational specification to be implemented on the NHIN
network in order to exchange interoperable health information over the Internet
Support for an update to a Core Spec will be mandatory for all NwHIN Implementers
All profiles supporting the core specifications will adopt the latest version of the core specifications
The decision to adopt non-core specifications will be internal to the NwHIN Implementation
Community and the use cases they support
A registry will be created that will allow the ability to capture and track what versions of the non-core
specifications (see Table 1 for list of non-core specifications) implementers are supporting
A new Spec Factory initiative would not require NwHIN governing body approval to enter the
development process, rather consensus by Spec Factory/Implementers community members will be
considered as an approval of new specification initiatives
The NWHIN Governance body will review the Spec Factory’s final product from a technology and
policy perspective
Specification releases will occur twice a year, one major release and one minor release as
necessary
A ‘Major’ release may contain a breaking change
A ‘Minor’ release will not contain a breaking change
If migration to new core specification version overlaps with next release cycle, the release will be
pushed off until the end of the migration period
On boarding process WILL ensure compliance to new specification version
There will only be one version of specifications (core and non-core) maintained for adoption by
implementers
A new participant will be required to support current versions of core specifications and relevant non-core
specifications
The spec factory will not support corrections to previous specification versions. All corrections will be
made to current approved versions of the specification
Table 1 - NwHIN Specifications
NwHIN Specification
Category
Access Consent Policy
Non-core specification
Administrative Distribution specification
Non-core specification
Authorization Framework
Core specification
Continuity Assessment Record and
Evaluation (C.A.R.E.)
Profile
Document Submission
Non-core specification
Page 3 of 6
5
NwHIN Specification Version and Migration Plan
NwHIN Specification
Category
Electronic Submission of Medical
Documentation (esMD) X12
Profile
Electronic Submission of Medical
Documentation (esMD) XDR
Profile
Geocoded Interoperable Population
Summary Exchange (GIPSE)
Profile
Health Information Event Messaging (HIEM)
Service Interface
Non-core specification
Medicaid Eligibility Verification
Profile
Messaging Platform
Core specification
Patient Discovery
Non-core specification
Physician Quality Reporting Initiative (PQRI)
Profile
Query for Documents
Non-core specification
Retrieve Documents
Non-core specification
Web Services Registry
Foundational specification
2.2 Approach Overview
The proposed approached outlined below, will address the lack of a migration plan for both minor and
breaking changes to specifications while gaining support from the NwHIN community because of its
flexibility to implementers. The plan proposes a multi-tiered approach for versioning NwHIN Exchange
technical requirements. Proposed changes to NwHIN specifications or request to create new
specifications will be driven by the following factors:
 New/improved technology
 New policy or regulation
 emerging standard (improvement in best practices)
 Error in existing specifications
The proposed approach will have two major scenarios as outlined in Figure 1 below. Similar to the Direct
Project, the Spec Factory Workgroup will accept proposal to change existing NwHIN specifications or
request to create new specifications based on group consensus. If approved, a Spec Factory domain
workgroup will modify or create the respective specification.
An NwHIN governance body will review and approve the newly created or update specification.
Additionally, an NwHIN governance body will also develop an implementation and migration plan for
core as well as non-core specifications that uses the core specification. The NwHIN governance body
will also set the deprecation plan for previous specification versions for core and non-core specifications
that uses the core specification. Upon approval and publication of the core specifications by the NwHIN
governance body, all NwHIN implementers will be required to implement the newly created or updated
Page 4 of 6
5
NwHIN Specification Version and Migration Plan
version of the core and non-core specifications by the timeframe set by the NwHIN governance body.
However, for changes to non-core specification, NwHIN implementers will have the option to adopt and
implement non-core specifications based on their internal organizational use case needs.
Changes to Core
Specifications
Changes to NonCore Specifications
•Changes to core specs triggers
changes to all non-core specs
and profiles that uses the core
spec
•NwHIN governing body will set
the transition and deprecation
period for core and non-core
spec based on severity of
breaking changes and survey of
implementers
•All implementers will be
required to migrate to the new
spec version (core and noncore) as well as update profiles
•Changes to non-core specs will
NOT require changes to profiles
using such specs
•NwHIN governing body will NOT
set the transition or
deprecation period
•Implementers will NOT be
required to adopt changes to
non-core spec, rather they will
determine the need to support
new non-core spec version
Figure 1 - Proposed Plan for Version Migration
2.2.1 Core Transport Specifications
There should be a unified upgrade approach and timeframe for core transport specifications.
All NwHIN Exchange Participants should be required to support the same version for transport / security
to enable interoperability at the most basic level to assure uniformity across all use cases. Version
updates should occur every couple of years (e.g. an approach like that used for HIPAA Transaction and
Code Set standards, where there is a period for dual use and a final cutoff date).
Near-term Exchange Implications:
 Coordinated upgrade necessary to migrate production participants to the latest version of the
following specifications:
- Auth framework
- Messaging platform
 Proposed timeframe: 4 months (9/1/11)
Longer-term Implications: To support this approach, the following specifications would need to be
cleaned up and modularized in order to support various transport methods, such as SOAP over HTTP,
SMTP.
2.2.2 Other Service-Related NwHIN Specifications to Support Exchange Patterns
The DURSA requires NwHIN Exchange Participants to support at least one “Exchange Pattern” (e.g.
patient discovery/query/retrieve, document submission, publish / subscribe).
Page 5 of 6
5
NwHIN Specification Version and Migration Plan
The corresponding service-related specifications should not be anchored to any particular profile, but
should be available for implementation across a myriad of use cases. However, these specifications
should be versioned on an annual basis.
Required migration timeframes should be specified in NwHIN Exchange Profiles, as described below.
Near-Term Implications: How to address versioning / migration for revised specifications in the absence
of having Exchange profiles today?
Options:
i.
Specify a single timeframe for migration across all use case supported (e.g. VLER, SSA,
and CDC – pub/sub).
ii.
Specify different timeframes for migration of existing use cases, if needed.
iii.
Wait until there are profiles developed to support existing Exchange use cases.
Longer-Term Implications: Participants who exchange for multiple use cases may need to support
different versions for the same specification.
2.2.3 NwHIN Specification Profiles
Profiles define how a community wishes to exchange data using NwHIN service and content
specifications to support a particular use case. Communities should have the flexibility to adopt and
implement the specifications in a manner most appropriate to serve their business needs.
 The community should determine how to constrain / implement a specification, including the
business purpose, core specifications required, versions of specifications supported.
 All profiles should be updated to reflect new versions of the core transport specifications (i.e. Auth
Framework, Messaging Platform, Web Services registry).
 The profile could support current or older versions of NwHIN Exchange service and content
specifications.
o The profile could force an upgrade to a particular version of a new service-related NwHIN
specification such as Patient Discovery.
 Profiles are added to registry to enable NwHIN participants to discover other exchange partners
that support those profiles
Near-Term Implications:
 Profiles that may address NwHIN Exchange needs are being developed as part of two S&I
initiatives: CDA consolidation and Transfer of Care S&I Initiatives.
 Approach / process to develop other NwHIN Exchange profiles.
Longer-Term Implications:
Further discussion needed
2.3 Open Questions



What do we do in the case of an emergency scenario such as security breach that may require a
“patch” release?
Need definition for major vs. minor release and what is mandatory
Will on boarding process ensure compliance to migration/transition period?
Page 6 of 6