Process+for+Impact+Analysis

= = =Process for Impact Analysis=

=README: Process for impact analysis=

0 row selected - rows selected - [|clear] || ONC (the NHIN testing body) is conducting an impact analysis for any issues found in testing that have the potential to be unresolved at the time of evaluation by the NHIN Coordinating Committee. This analysis is meant to assist the NCC in its decisions.
 * ~ 1 - 1 of 1
 * [[image:http://www.wikispaces.com/i/user_none_lg.jpg width="48" height="48" caption="JoeLamy" link="http://www.wikispaces.com/user/view/JoeLamy"]] || [|JoeLamy]

We are performing an initial analysis based on our reading of the specs, and are reaching out to the spec factory and current testing candidates for more definitive analysis.

We are using the following IEEE severity levels, and assigning a tentative level.

Severity Level 1 – Critical [IEEE definition: The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system.] 1. Any defect that compromises patient safety or system security (examples of system security defects include breach of confidentiality requirements of the Privacy Act, Health Insurance Portability and Accountability Act (HIPAA) or Federal Tax Information guidelines); 2. Loss of system functionality critical to user operations with no suitable workaround (i.e., there is no way to achieve the expected results using the application.) 3. System crash or hang that prevents further testing or operation of the complete application or a section of the application. 4. Any defect that causes corruption of data from a result of the system (as opposed to user error). 5. Any defect in which inappropriate transmissions are consistently generated or appropriate transmissions of HL7 messages fail to be generated. 6. Loss of functionality resulting in erroneous eligibility/enrollment determinations or communications not being sent. Severity Level 2 – High [IEEE definition: The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system.] 1. A major defect in the functionality which does not result in corruption of data. 2. A major defect in the functionality resulting in a failure of all or part of the application, where the expected results can temporarily be achieved by alternate means. The customer indicates the work around is acceptable for the short term. Any work around which affects the interface must be jointly agreed upon by the DoD and VA before proceeding. 3. Any defect that does not conform to Section 508 standards 4. Any defect that results in inaccurate or missing requirements 5. Any defect that results in invalid authentication or authentication of an invalid end user Severity Level 3 – Medium [IEEE definition: The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or inconsistent results, or the defect impairs the systems usability.] 1. Minor functionality is not working as intended and a workaround exists but is not suitable for long term use. 2. The inability of a valid user to access the system consistent with granted privileges 3. Typographical or grammatical errors in the application, including installation guides, user guides, training manuals, design documents, etc. 4. Any defect producing cryptic, incorrect or inappropriate error messages 5. Any defect that results from the use of non-standard data terminology in the application or documentation 6. Cosmetic issues that are important to the integrity of the product, but do not result in data entry and or data quality problems Severity Level 4 – Low [IEEE definition: The defect does not cause a failure, does not impair usability, and the desired processing results are easily obtained by working around the defect.] 1. Minor loss of or defect in the functionality 2. Low level cosmetic issues

-- Joe Lamy ONC S&I Operations Team [|[delete]] ||