Project Life Cycle for Product Development

1.3 Project Life Cycle Process [Note to the reader: The Project Life Cycle is maintained by the Project Services Work Group (PSWG) of the Technical and Support Services Steering Division of the Technical Steering Committee (TSC). The PSWG contribution to the HDF is produced in collaboration with other editors and contributors.] The objective of the HDF is to document the context, processes, and work products comprising the life cycle of the HL7 Protocol Specifications. The HDF consists of abstract processes that are applicable to the development, management, and enhancement of any of the protocol specifications. Within the context of a project moving through the product life cycle; the HDF identifies the processes, defines the deliverables and the interdependencies. Secondarily, the HDF serves as input to the development of specific developer guides focused on the various types of protocol specifications. Sources of additional information are provided as an aid to anyone interested in further detail or elaboration of the topics presented in the HDF. This approach was taken for the following reasons: Manage the size and complexity of this document: the HDF is expected to be used by a large audience with diverse interests and varying levels of experience with the processes and techniques used. To accommodate the broader audience and reduce the complexity of the HDF, references and linkages are provided to detailed information on various components of the framework. Insulate the HDF from process change: the HDF is a dynamic document that will result in changes to process, tooling, and work products. By adopting a relatively high level of abstraction the HDF is insulated from changes in the underlying detail of process and technique.

Published by Project Services, November, 2008 Page 1 of 9 Project Life Cycle for Product Development

Anticipate publication of the HDF as a collection of interrelated, linked documents: The HDF and its companion documents are published on or linked to the HL7 web site and Ballot Desktop. When rendered as web artifacts this linkage avoids duplication and conflicting content.

1.3.1 Project Life Cycle for Product Development The following graphic portrays the Project Life Cycle for Product Development (PLCPD) and reflects its alignment with the various components of the HDF including project initiation, analysis and requirements documentation, and specification design. The PLCPD, depicted as a cyclical process flow, presents the HL7 strategy for protocol specification development, enhancement, and management, while the HDF details the process steps specific to the development or enhancement of the protocol specifications. [INSERT PROJECT LIFE CYCLE GRAPHIC]

1.3.1.1 HL7 Protocol Specifications HL7 Protocol Specifications are multiple related products end-users can acquire to implement including traditional messaging specifications, Extensible Markup Language (XML) schema, Clinical Document Architecture (CDA), Clinical Context Object Work Group (CCOW), etc. Feedback from user experience, identification of new requirements or opportunities will result in requests to enhance or create protocol specifications. These requests will be managed as projects. Other products, such as tutorials and information forums, may adopt a project management approach, but the PLCPD is intended primarily for the development, enhancement, and management of HL7 Protocol Specifications.

The Work Group must establish project alignment with stated HL7 strategy and register the project with the HL7 Project Management Office (PMO). To register a project access Project Insight. For assistance contact the PMO: [email protected].

1.3.1.2 Request to enhance or create a product To initiate a project to create or enhance a protocol specification the interested stakeholders will approach the appropriate Work Group to prepare a Project Scope Statement that describes the project’s classification, justification, and benefits while identifying intended deliverables, project sponsors, and possible implementers. This may involve iterative negotiations to complete a Project Scope Statement that meets established criteria. For additional information refer to: Project Scope Statement

When the Work Group reaches consensus on a Project Scope Statement, it is presented to the parent Steering Division (SD) for approval and distribution to other Work Groups who may have an interest in the project.

1.3.1.3 Decision Point: Project Scope Statement Approval or Disapproval Following review by interested Work Groups, the parent SD will review and approve or disapprove the Project Scope Statement. The SD may return the Project Scope Statement to the Work Group for additional information prior to making a decision. A project not aligned with HL7 strategy or seeking the allocation of extensive resources may not be approved. Resource issues may be offset by sponsors who commit sufficient additional resources to the project with the proviso that the project is not detrimental to HL7 strategies. Upon approval by the SD, the Project Scope Statement will be considered by the Technical Steering Committee (TSC) which has ultimate approval authority. A Project Scope Statement returned to the Work Group as disapproved or needing more work may be cancelled or withdrawn.

1.3.1.4 Withdraw or Cancel a Project At any point in the PLCPD a project may be withdrawn or cancelled. A Work Group may withdraw a project if it is apparent that it is not going to be approved or if the necessary resources or funding is not available, is insufficient to complete the project, or has been discontinued. A project that has not met assessed criteria, is lacking funding, has not adhered to the projected scheduling, or fails a Quality

Verification Step may be cancelled by the SD or TSC should the responsible Work Group choose not to withdraw the project. Upon cancellation or withdrawal all appropriate individuals will be notified that the project is closed. The reason for the action will be documented in the project plan. All work material will be archived in the project. The Work Group will update Project Insight indicating the project is closed and adjust their plan to reflect that the project is no longer on the schedule.

1.3.1.5 Project Initiation

Note: For additional information refer to HDF section 2, Project Initiation Process (PIP), Initiation, Planning, and Approval

The initiation phase further refines the project by elaborating on the scope, deliverables, and objectives established by the Project Scope Statement and providing quantifiable measures of success. Project success is defined as the achievement of predefined objectives through the production of deliverables within the boundaries established by project scope. The necessary resources and commitment by stakeholders and participants must be in place to assure success. Each project must have a designated responsible party or project facilitator and at least one sponsor. The sponsor has input into project deliverables and may augment available resources, provide the bulk of necessary resources, or underwrite the costs associated with producing deliverables. The responsible party or project facilitator is accountable for the production of deliverables and adherence to the project schedule. The project plan, in a format determined by the HL7 PMO, will detail activities, schedule, inter-project dependencies, and a ballot strategy that meets market demand and implementation time lines. An important component of project planning is to explicitly identify assumptions and constraints. Assumptions and constraints may be associated with the availability of resources, interdependencies, the outcome of anticipated decision processes, or any foreseeable circumstance with an unknown outcome that may affect progress. It is also important to identify potential risks and develop mitigating strategies or contingency plans. The project plan includes, but is not limited to: a) A proposed time line addressing progress through the various components of the PLCPD b) Identification of necessary resources, both volunteer and funded, to meet the time line c) Funding requirements to be sought from HL7 and/or provided by a project sponsor d) An explanation of alignment with market demand and planned implementations e) The high level expectations of the stakeholders and participants f) A ballot strategy, including any cross-domain or -Work Group issues. which outlines a proposal for validation of any Draft Standard for Trial Use (DSTU) intended to support interoperability g) Quality criteria for each component of the PLCPD h) A proposal for industry outreach specific to the objectives of the project i) Identification of any interaction with or dependency on other projects A project plan incorporating a DSTU is expected to include an implementation plan identifying at least two independent parties committed to demonstrating interoperability in a laboratory or connect-a-thon scenario. Projects intended to support interoperability may not proceed beyond initiation without a non- binding commitment by at least two implementers unless exempted by the TSC. If the project plan calls for the creation of a new Work Group, the participants must prepare a Mission and Charter statement and seek appropriate approvals before moving forward. For further information on establishing a work group see §09.02.01 of the GOM. Many of the components of the PLCPD have an associated Quality Verification Step Decision (QVSD) which is intended to assess the work product of a given process against the quality criteria established at initiation in the project plan and against any relevant quality criteria established by HL7 or its constituent committees and Work Groups. It is conceivable that a QVSD could cause a project to return to a prior process point in the PLCPD or require further work before it can move forward. The method for making

Published by Project Services, November, 2008 Page 3 of 9 Project Life Cycle for Product Development this assessment will depend on the criteria and may vary for a given component of the PLCPD. Some possibilities include: a) An explicit self assessment by the project team resulting in approval of a motion that the quality requirements have been met b) Review by an independent panel of interested individuals convened to assess adherence to quality criteria for a specific project c) Review by a standing panel of HL7 members and staff established to assess adherence to quality criteria for all projects

1.3.1.5.1 QVSD Indentify and secure commitment of sponsors, responsible party or project facilitator, implementers if proposing a DSTU intended to support interoperability, and any necessary resources. Finalize the Project Scope Statement and complete the project plan on Project Insight. Establish a new Work Group if necessary. Record the approval to move to the next phase.

1.3.1.6 Decision Point: Move Forward with Project With project initiation completed it is time to seek approval of the project plan from those engaged or expressing an interest in the project. If appropriate the project team should present the project plan to the broad audience of interested stakeholders and other HL7 Work Groups and committees. Upon confirmation of the project plan by the sponsors, responsible party or project facilitator, and the committed resources the project should move forward. Note that those processes leading up to the ballot decision point are defined in a logical sequence; however, those activities may occur more or less concurrently. Given that circumstance it must be understood that even though a process may not require further effort, it can not be considered complete until the preceding process has cleared QVSD.

1.3.1.7 Requirements Analysis Using HDF methodologies determine the business requirements that will drive the project work products. It may be necessary to refine the project plan especially the quantifiable measures of success and definition of the critical path with associated checkpoint dates. It is recommended that a peer review of the requirements documents be performed before closing this process.

1.3.1.7.1 QVSD Log completed activities in Project Insight and maintain the project schedule assessing the impact of altered checkpoint dates. Ensure that the project addresses perceived need, remains in scope, and is aligned with established objectives. Perform assessment of conformance to organizational quality criteria as it relates to use cases, requirements analysis models, and domain analysis models. Record the approval to move to the next phase.

1.3.1.8 Logical Design Using HDF methodologies process the requirements to develop interim work products constituting the specification design. For message specifications this would include any constrained information models based on the Reference Information Model (RIM) that implement the requirement expressed by the Domain Analysis Model (DAM). The design phase contributes materially to the creation of the specification, but it is also the appropriate point to begin product documentation and collateral. Seeking input from the broader Work Group and other interested parties outline the implementation plan, define user acceptance criteria, and build test plans. The implementation plan should describe and time line implementation activities. The user acceptance criteria should ensure that no user expectations are unmet. As the specification begins to come together create test criteria to validate the project; use model test plans where available. It is recommended that a peer review of collateral documentation be performed before closing this process.

1.3.1.8.1 QVSD Log completed activities in Project Insight and maintain the project schedule. Assess the output against quality criteria established at project initiation and against any relevant organizational quality criteria. Ensure the project remains in scope and continues to address perceived need. Record the approval to move to the next phase.

1.3.1.9 Draft the Protocol Specification Prepare the proposed protocol specification taking care to ensure usability and understandability. If necessary refine the implementation plan and user acceptance criteria. Evaluate the test plan and ensure that resources are available to validate the protocol specification. Conduct a peer review of the draft specification requesting comments that improve clarity and usability. Begin the outline of a marketing plan to roll out the final specification including a draft announcement identifying the specification being produced or enhanced and the target audience.

1.3.1.9.1 QVSD Log completed activities in Project Insight and maintain the project schedule. Assess the draft protocol specification against quality criteria established at project initiation and against any relevant organizational quality criteria. Ensure the project remains in scope and continues to address perceived need. Record the approval to move to the next phase.

1.3.1.10 Decision Point: Seek Comments Although the project team has conducted peer review on the proposed specification, they or the project sponsors may wish to seek input from a broader audience via a comment-only ballot before proceeding to the ballot type decision point. Should the project ballot strategy call for going directly to normative ballot, the project team is strongly encouraged to conduct a comment-only ballot. Further information on comment-only ballots can be found in §13.03 of the GOM.

1.3.1.11 Comment Only Ballot If the decision is to conduct a comment-only ballot, prepare and submit the Notice of Intent to Ballot (NIB) following the embedded instructions and comply with all HL7 ballot requirements as defined by the Publishing Committee. Update Project Insight to reflect the decision. Ensure that all ballot comments are captured in the Ballot Desktop.

1.3.1.12 Decision Point: Ballot Type – Normative or Review The project facilitator will review the ballot strategy defined at project initiation and, making adjustments if necessary, seek approval for the appropriate ballot type. There are a variety of ballot ‘paths’ which may be followed. It is the position of HL7 that those projects intended to address interoperability will produce a Draft Standard for Trial Use (DSTU) via a DSTU review ballot and seek to improve the specification through experience gained by implementations undertaken during the trial use period. Using that experience the project team then finalizes the specification and seeks approval for a normative ballot with the objective of producing an ANSI approved American National Standard (ANS). Exceptions to this position include maintenance releases such as V2.x messaging specifications. If the purpose of the project is to produce an implementation guide or other type of informative document, typically the project will call for an informative document review ballot. The resulting document may then be published with or without ANSI registration as a T3 Technical Report. An informative document may, in turn, be released with the intent of gathering experience through industry use with the intent of finalizing the specification and seeking approval for a normative ballot with the objective of producing an ANS. A DSTU may be accompanied by an implementation guide to facilitate industry use. In that case the project team will be responsible for both a DSTU review ballot and an informative document review ballot concurrently.

There may be reason to initiate a project for the purpose of moving directly to normative ballot in order to meet government mandate or critical market demand. Although the project may bring forward a new specification, typically projects going directly to normative ballot are very limited in scope and address changes to existing protocol specifications necessary to conform to the mandate or meet industry requirements. In either case, project teams are strongly encouraged to seek additional input via a comment-only ballot (1.3.1.10) before proceeding to a normative ballot.

1.3.1.13 Decision Point: DSTU Review Ballot Employing a strategy to release a Draft Standard for Trial Use (DSTU), the project team will now proceed to a DSTU review ballot; otherwise they are to conduct an informative document review ballot. As noted, when a project produces a draft standard and an associated implementation guide both review ballots may be conducted concurrently.

1.3.1.14 DSTU Review Ballot A draft standard will be subjected to review via a DSTU ballot. A DSTU review ballot is not subject to the stringent reconciliation requirements of a normative ballot and is intended as a single occurrence not a series of iterative ballot cycles. The purpose of the DSTU ballot is broad exposure of the proposed draft standard to optimize constructive criticism and comment prior to releasing the draft standard for trial use. Further information on the DSTU review ballot can be found in §13.02 of the GOM. The project facilitator, through the parent Steering Division, will seek approval from the TSC to conduct a DSTU review ballot. The project team will prepare and submit the Notice of Intent to Ballot (NIB) following the embedded instructions and comply with all HL7 ballot requirements as defined by the Publishing Committee.

1.3.1.14.1 QVSD Ensure the ballot content adheres to Publishing Committee criteria and other relevant organizational quality criteria. Validate that the content is in scope and meets perceived needs expressed by requirements analysis. Log completed activities in Project Insight and maintain the project schedule. Ensure that all ballot comments are captures in the Ballot Desktop. Record the approval to move to the next phase. Given that the draft standard will be subjected to industry use, it is not necessary to resolve negative comments or account for any substantive change to the specification resulting from review ballot comments. If the project team feels that incorporating changes suggested by the comments resulted in sufficient change to justify further review they may conduct another DSTU review ballot. However, a second DSTU review ballot is neither recommended nor expected.

1.3.1.15 Specification and Training Establish the length of the trial use period and prepare the specification for release as a Draft Standard for Trial Use (DSTU); see §13.02.05.01 of the GOM. HL7 will notify ANSI of the availability of the DSTU. The Work Group is expected to empower a number of the project participants and other involved parties to provide assistance in interpreting the DSTU and its implementation guidance. This group should also catalog and process all necessary modifications to the DSTU that are identified during trial use. The parties that committed to pilot implementations during project initiation should use this time to ensure they understand the content of the draft standard and are prepared for implementation. The Work Group is encouraged to provide training material and/or conduct a walk through of the DSTU on a scheduled conference call.

1.3.1.15.1 QVSD Ensure conformance to DSTU requirements. Log completed activities in Project Insight and maintain the project schedule. Record the approval to move to the next phase.

1.3.1.16 Industry Use The purpose of the trial use period is to ‘exercise’ the draft standard and validate it meets the stated objectives of the project. During the trial use period, which may run for any period up to two years from release of the DSTU, the project team will capture data related to the viability of the draft standard and its implementation guidance. While it is hoped that there will significant efforts to implement the DSTU, at least the parties that committed to implementation at project initiation are expected to provide evidence of interoperability and validate the implementation guidance. The experience gained through trial use will provide the basis for a final specification that represents the content of a normative ballot.

1.3.1.17 Finalize Specification The project team will produce the final protocol specification for normative ballot. Concurrently they will refine the implementation and test plan based on industry use. Collateral material will be updated with success stories related to industry use. The marketing plan will be updated and an announcement of a successful trial use period will be submitted to headquarters.

1.3.1.17.1 QVSD Log completed activities in Project Insight and maintain the project schedule. Ensure specification is in conformance with criteria for normative ballot content established by the Publishing Committee. Record the approval to move to the next phase.

1.3.1.18 Normative Ballot The normative ballot is the precursor to submission of a protocol specification to ANSI for approval as an American National Standard (ANS). It is subject to ANSI rules for due process by accredited standards development organizations (SDO). A normative ballot exposes the protocol specification to the broadest possible audience including nonmembers who may be interested parties. Specific information on the normative ballot process can be found in §14 of the GOM. The project facilitator, through the parent Steering Division (SD), will seek the approval of the TSC to conduct a normative ballot. The project team will prepare and submit the Notice of Intent to Ballot (NIB) following the embedded instructions and comply with all HL7 ballot requirements as defined by the Publishing Committee. The content of the normative ballot will be the final protocol specifications developed by the project team inclusive of enhancements or modifications resulting from the industry experience during the trial use period.

1.3.1.19 Decision Point: Normative Ballot Passed The criteria for approval of a normative ballot is defined in §14.05 of the GOM. An unresolved negative comment does not preclude approval of a normative ballot. Should a normative ballot fail to pass the updated content, reflecting changes from comments deemed persuasive, will be the subject of another normative ballot. Should changes resulting from comments be deemed substantive, the content will be subjected to another ballot even if it meets the approval criteria. Although it is hoped that normative content will pass in not more than two ballot iterations, ballots may continue until the content is approved or withdrawn. Prior to initiating a subsequent iteration the previous ballot occurrence must have completed reconciliation.

1.3.1.20 Publish the Standard, Implementation Guide, and Training Material The final step in the PLCPD calls for the publication of the project work products. The project team should finalize all associated collateral material including an announcement of successful completion of the project. All materials must meet publication criteria and be provided to headquarters in an acceptable format.

1.3.1.20.1 QVSD Log project completion in Project Insight and close the project schedule. Perform a post mortem analysis of the project.

1.3.1.21 Informative Document Review Ballot Documentation that supports a standard or process and which is not, in and of itself, considered normative may be presented as an informative document. An informative document review ballot is not subject to the stringent reconciliation requirements of a normative ballot and is intended as a single occurrence not a series of iterative ballot cycles. The purpose of the informative documents review ballot is broad exposure of the proposed documentation to optimize constructive criticism and comment prior to publishing the document. Further information on the informative document review ballot can be found in §13.01 of the GOM. The project facilitator, through the parent Steering Division, will seek approval from the TSC to conduct an informative document review ballot. The project team will prepare and submit the Notice of Intent to Ballot (NIB) following the embedded instructions and comply with all HL7 ballot requirements as defined by the Publishing Committee.

1.3.1.21.1 QVSD Ensure the ballot content adheres to Publishing Committee criteria and other relevant organizational quality criteria. Validate that the content is in scope and meets perceived needs expressed by requirements analysis. Log completed activities in Project Insight and maintain the project schedule. Ensure that all ballot comments are captured in the Ballot Desktop. Record the approval to move to the next phase. It is not necessary to resolve negative comments or account for any substantive change to the informative document resulting from review ballot comments. If the project team feels that incorporating changes suggested by the comments resulted in sufficient change to justify further review they may conduct another informative document review ballot. However, a second informative document review ballot is neither recommended nor expected.

1.3.1.22 Decision Point: Take Informative Document Normative Typically an informative document is intended to provide guidance on the implementation or use of an HL7 protocol specification. Following an informative document review ballot it is normally published for use. An informative document may be registered with ANSI as a TR3 Technical Report. While this doesn’t instill any special recognition, it does serve to expose the informative document to a broader audience. An informative document may, with the approval of the TSC, be subjected to a normative ballot with the intent that it becomes an ANSI approved American National Standard (ANS). Should this be the case, the informative document will enter the review process at 1.3.1.14 and be subject to some period of industry use and evaluation before moving to a normative ballot.

1.3.1.23 Request to Sunset Product Product management may also call for the sunset of a protocol specification, that it be removed from service. A call for the sunset of a protocol specification is initiated by the responsible Work Group. Protocol specification sunset will be managed as a project with significantly fewer steps than required to create or enhance a protocol specification. Note that ANSI approved American National Standards (ANS) that have not been enhanced or otherwise maintained or updated over a five year period are subject to reaffirmation or withdrawal. See §15.04 of the HL7 Governance and Operations Manual (GOM) for further information.

1.3.1.24 Request Approved The Work Group will prepare a Project Scope Statement stating at least the justification for the sunset request and follow the regular project approval process.

1.3.1.25 Sunset Product With the approval of a project to sunset a protocol specification the responsible Work Group will:

a) Prepare a time line for retirement of the protocol specification b) Prepare an announcement of the action to sunset the protocol specification c) Identify where the artifacts to be retired will be archived d) Implement the retirement plan. In the case of an American National Standard, headquarters will notify ANSI of the withdrawal of the standard.

Published by Project Services, November, 2008 Page 9 of 9