NHIN+Spec+Development+Process


 * NHIN Specification Development Process **

The following description of the NHIN Specification Development Process was presented to the NHIN Technical Committee (NTC) during the October 2009 monthly meeting. Note that this description reflects the state of the process at the time that it was presented to the NTC and may not accurately represent the process as it exists today.

**__Introduction__ ** The development of NHIN Specifications requires the collaborative efforts of several distinct groups:

1) NHIN Spec Factory – A collection of HIE implementers, leaders in standards development organizations, privacy and security experts, and other resources with a direct interest in NHIN development. This group is anchored by a group of contract resources able to commit to an NHIN specific focus and timeline.

2) HITSP – A group of industry experts across a wide range of topics who harmonize and integrate the standards for sharing health information that inform NHIN specifications.

3) OPR – Provides policy guidance, in addition to the DURSA, governing the NHIN.

**__Process Overview__** NHIN functionality/capability requests may be intended for use either in a pilot scenario or in full NHIN production. Each scenario presents its own distinct needs in terms of the degree of stakeholder review and conformance with standards required to develop the request into a NHIN functionality/capability. A request intended for use in a pilot will typically involve a small subset of NHIN participants and therefore will not broadly impact the NHIN community. Given this, a request intended for use in a pilot should necessitate a less rigorous NHIN specification development process than a request intended for full NHIN production. Lessons learned from a pilot implementation may be applied toward submitting a revised functionality/capability request intended for production.

The proposed NHIN specification development request process is outlined in the following sections. Where applicable, variances between the pilot-oriented process and the more rigorous production-oriented process are noted.

Request formulation results in an NHIN Functionality or Capability request which describes the requestor’s use case and business needs in terms of the problem to be addressed. It must also describe the business case – a scenario by which the requestor anticipates the function or capability would be widely implemented and adopted by NHIN Participants. In the case of a request intended for use in a pilot, the business case describes how the functionality or capability would be implemented for the purpose of the pilot. NHIN will provide assistance, but documentation of the request is the responsibility of the requestor.
 * Request Formulation**

NHIN will collaborate with Connect to work with NHIN Participants and other NHIN stakeholders to document requests for new or enhanced NHIN capabilities. Capability requests are framed in terms of defining a problem to be addressed and a potential solution. NHIN staff will focus on understanding the requestor’s problem and working with the requestor to determine a strategy by which the requestor can leverage NHIN to address the problem. NHIN also seeks to coordinate among requestors to identify potential synergy among requests in terms of scope or timing.

The request will be evaluated from several points of view in order to provide an order of magnitude estimate of time and resources required to develop the requested function or capability.
 * Request Sizing**

1) Technical Feasibility – NHIN will coordinate the involvement of the Connect and other gateway development teams, NHIN Participant technical resources, and the NHIN Technical Team to gauge complexity and feasibility from a technical point of view.

2) Availability of Standards – NHIN will seek HITSP’s assistance to evaluate the request in terms of the approach taken to address the problem and its compatibility with applicable workflow and standards. Less emphasis is placed on this aspect of request sizing for pilot-oriented requests.

3) Policy Impact – NHIN will request assistance from the Office of Policy and Research (OPR) in order to identify policy concerns or constraints.

These factors will be used to refine the request as needed and included in the information which will accompany the request to the NHIN Technical Committee (NTC) for evaluation and prioritization.

Based on priorities established by the NTC, the Spec Factory will work with requestors to elaborate their requirements and to design a solution. A team of HIE implementers will collaborate with HITSP and OPR to specify the technical requirements and mechanisms compatible with standards and compliant with policy as needed to support the intended function or capability. Development of pilot-oriented requests may be guided by available HITSP standards, but the eventual solution design is not required to comply with HITSP standards. Further, Spec Factory will involve the Connect development team to ensure a smooth handoff for eventual instantiation in the NHIN Reference Implementation. The Spec Factory will continually solicit and incorporate feedback from the request sponsor during the elaboration phase. Sponsor input will be particularly requested during elaboration of pilot-oriented requests to ensure that the eventual solution design satisfies the sponsor’s needs for use in their pilot.
 * Elaboration**

At the completion of elaboration, the NHIN Spec Factory will submit a working draft of the specification for review and comment by the NHIN Coordinating Comittee (NCC) and the NTC. The intent is to ensure that the NHIN Participants who will eventually be expected to implement the resulting specification, are able to provide input before it is constructed. Review by the NTC and NCC will not be required for pilot-oriented requests due to the limited impact of these requests on only a defined subset of NHIN participants.

Once the technical requirements and mechanisms described in the working draft have been accepted by the NTC, the Connect Development team will assume the lead in their development. The Connect team will iteratively develop and test components of the specification continually providing feedback to the Spec Factory and Requestor as needed to accommodate implementation issues.
 * Construction**

Construction results in the integration of the specification in the NHIN Reference Implementation. The final version is delivered to NTC who votes to accept the specification for use in Production across the NHIN. Due to their limited impact on the NHIN community, the NTC does not vote to accept specifications intended for use in a pilot.

The attached visio diagram illustrates the process.

