NHIN Version and Migration Plan_v3_14April2011 by hedongchenchen


             NwHIN Specification Version and Migration Plan

    Nationwide Health Information Network

    Specification Version and Migration Plan


                                                              Page 1 of 6
                              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

 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   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.
         o   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)
         o   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
                                 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
    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
    A new participant will be required to support current versions of core specifications and relevant non-core
    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                    Profile
Evaluation (C.A.R.E.)

Document Submission                                 Non-core specification

                                                                                                         Page 3 of 6
                                NwHIN Specification Version and Migration Plan

NwHIN Specification                             Category

Electronic Submission of Medical                Profile
Documentation (esMD) X12

Electronic Submission of Medical                Profile
Documentation (esMD) XDR

Geocoded Interoperable Population               Profile
Summary Exchange (GIPSE)

Health Information Event Messaging (HIEM)       Non-core specification
Service Interface

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
                               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                         Changes to Non-
        Specifications                        Core Specifications
    •Changes to core specs triggers          •Changes to non-core specs will
     changes to all non-core specs            NOT require changes to profiles
     and profiles that uses the core          using such specs
     spec                                    •NwHIN governing body will NOT
    •NwHIN governing body will set            set the transition or
     the transition and deprecation           deprecation period
     period for core and non-core            •Implementers will NOT be
     spec based on severity of                required to adopt changes to
     breaking changes and survey of           non-core spec, rather they will
     implementers                             determine the need to support
    •All implementers will be                 new non-core spec version
     required to migrate to the new
     spec version (core and non-
     core) as well as update profiles

              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,

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
                              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?
            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
              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

To top