This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "HL7 DSTU testing toolkit"

From HL7Wiki
Jump to navigation Jump to search
Line 7: Line 7:
  
 
This project does not directly address the testing of locally produced implementation guides, but it may inform such activity.  This may become the subject of a future project.
 
This project does not directly address the testing of locally produced implementation guides, but it may inform such activity.  This may become the subject of a future project.
 +
 +
== Rationale ==
 +
There is more and more pressure that HL7 standards, as well as other standards, are of high quality before they are normative. In fact, several governments are requiring, by law, normative standards be adopted.
 +
 +
To meet this need, the Implementation and Conformance Technical Committee (ICTC), in conjunction with the project lifecycle task force, is determining the best procedures for testing standard. The ICTC have approved a project that focuses on procedures and artifacts for testing. The following document is a straw man for what tests needs to occur before each ballot type and also provide an example of a test plan. At this time, this document only covers testing a standard. This document does not cover the topic on how to ensure an implementation guide meets the standard or how to ensure a system is conformant to the standard.
 +
 +
Please note that no process will ensure that an exchange standard is perfect. No matter how much effort you put in the testing process, it is probable that once the exchange standard is used in the mainstream, deficiencies of said standard will be uncovered.
  
 
== related / existing work ==
 
== related / existing work ==

Revision as of 16:09, 15 September 2008

Introduction

This is a project hosted by the ICTC as part of its Implementation workstream

The HL7 development framework (HDF) provides guidance on how to develop a standard. However, the HDF does not provide guidance on how best to evaluate the standard. Without guidance on how to evaluate a standard it is the burden of each technical committee (TC) to determine there own methods of proving a standard is fit for purpose. In addition, implementers have no clear way to claim that a system confirms to an HL7 V3 standard

The goal of this project is to provide guidance to implementers on when a HL7 V3 standard is stable enough to implement and a mechanism to ensure a system confirms to an HL7 V3 standard. During the course of this project we may need to make a distinction on when an HL7 V3 standard is ready for early adoption compared to mainstream adoption.

This project does not directly address the testing of locally produced implementation guides, but it may inform such activity. This may become the subject of a future project.

Rationale

There is more and more pressure that HL7 standards, as well as other standards, are of high quality before they are normative. In fact, several governments are requiring, by law, normative standards be adopted.

To meet this need, the Implementation and Conformance Technical Committee (ICTC), in conjunction with the project lifecycle task force, is determining the best procedures for testing standard. The ICTC have approved a project that focuses on procedures and artifacts for testing. The following document is a straw man for what tests needs to occur before each ballot type and also provide an example of a test plan. At this time, this document only covers testing a standard. This document does not cover the topic on how to ensure an implementation guide meets the standard or how to ensure a system is conformant to the standard.

Please note that no process will ensure that an exchange standard is perfect. No matter how much effort you put in the testing process, it is probable that once the exchange standard is used in the mainstream, deficiencies of said standard will be uncovered.

related / existing work

Early Adopters of project outputs

Deliverables

  • Changes to co-chairs handbook
  • Guidelines for running DSTU
  • Templates for reporting test results
  • examples of best practice
  • Provide guidance and documentation to prove that a HL7 V3 standard fit for purpose and stable enough for implementers

Document a testing process that can be followed to establish whether a standard meets these requirements Create artefacts and templates to record how an HL7 V3 standard meets the balloted business requirements

  • Provide guidance and documentation to prove that a system, either a consumer or producer, conforms or partially confirms to an HL7 v3 standard

Project Plan

  • Produce project scope statement

Conference calls

This project is discussed on the regular implementation calls http://www.hl7.org/concalls/index.cfm?action=home.calldetail&wg_concall_id=3289&workingcalendardate=06/04/2007&listofwgids=