Getting Started Guide
OHIE.orgDiscourseWikiAcademy
1.0-Beta
1.0-Beta
  • Getting Started Guide: Paths to Data Exchange
  • Select a Pathway
  • PATHWAY 1: Component and Data Exchange Projects
    • Pathway 1.1 - Governance, Value, and Scope
      • Identify Stakeholders
      • Determine and Document Roles and Responsibilities
      • Establish or Define Governance Structures
      • Determine Project Scope
      • Document the Expected Value of the Project
      • Establish a Project Plan
    • Pathway 1.2 - Requirements and Design
      • Establish Training Programs
      • Determine Resources and Identify Constraints and Environmental Factors
      • Analyze the Environment and Context
      • Identify System Constraints
      • Document Requirements
      • Select Software/Component(s)
      • Testing
    • Pathway 1.3 - Implement, Support, and Scale
      • Establish a Support Plan
      • Implement a Scalability Plan
      • Communication and Roll Out
  • PATHWAY 2: Architecture
    • Pathway 2.1 - Governance, Value, and Scope
      • Identify Stakeholders
      • Determine and Document Roles and Responsibilities
      • Establish or Define Governance Structures
      • Determine Project Scope
      • Define Value of Health System Architecture
      • Establish a Project Plan
    • Pathway 2.2 - Requirements and Design
      • Inventory Existing Tools
      • Document Use Cases
      • Establish Architecture Principles
      • Document the Architecture
      • Establish Architecture Processes
      • Establish Standards
    • Pathway 2.3 - Implement, Support, and Scale
      • Communication and Roll Out
  • How to Provide Feedback / Input
  • Change Log
Powered by GitBook
On this page
  • Software Validation and Testing
  • Workflow Testing (Integration Testing)
  • Performance and Load Testing
  • User Testing
  1. PATHWAY 1: Component and Data Exchange Projects
  2. Pathway 1.2 - Requirements and Design

Testing

Component Level Project and Exchange Level Project

PreviousSelect Software/Component(s)NextPathway 1.3 - Implement, Support, and Scale

Last updated 3 years ago

Software Validation and Testing

There are many components required to validate and test software that is used to manage healthcare records. Some ministries of health like the United States FDA have specific guidance documents that need to be followed to ensure that healthcare software has been appropriately validated and tested and that electronic records requirements are being met. The purpose of this section is not to detail good software validation practices, but to highlight specific testing considerations for health software.

Workflow Testing (Integration Testing)

You will need to test to ensure that any components sharing data with other components appropriately integrate with the Interoperability Layer and each of the point-of-care systems or other systems that will provide or receive data. One approach for this testing could be to test various iterations of each workflow(data exchange) that will be used between each of the various components involved. This testing would then be repeated for each system that is in scope. This approach paired with an approach that goes through the whole health care process is recommended.

Performance and Load Testing

There are at least two aspects of performance testing that will need to be addressed. First is transaction through-put. This can be tested by estimating the number of transactions (data exchanges) that will be expected during peak business times and ensuring that the network and hardware can support this volume of transactions. The second aspect of testing that needs to be considered is ensuring that the registry/OpenHIE component(s) is configured to support the number of records required to be stored in the component at its peak usage for the given scope. For component systems such as the client registry, facility registry and other OHIE components, hardware, databases, matching algorithms and key system functions will need to be tested to ensure that they are appropriately configured and tuned to handle the estimated number of records expected in the next two or three years.

User Testing

A key component of the agile process initiated will be to conduct routine field testing of the system that should be completed to gain feedback from a subset of system users. The goal of this activity is to obtain user feedback on the use of the component. The testing should be a separate activity from augmented or decentralized processes to collect and standardize data that may also be desired as part of the governance and management of a facility registry system. It is also likely that the formality of the testing may vary based on the availability of resources and at the request of the central stakeholders.

Examples and References:

  • Example:

  • Reference:

  • Reference:

User Testing Guide
INVEST in Good Stories, and SMART Tasks
Examples of Rwanda User Stories for RHIE