• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.

View
 

Integration Testing

FrontPage => Stages of Implementation => The Executing Stage =>

or => Building Blocks

 

Integration Testing

  

Integration Testing is the phase in software testing in which individual software modules are combined and tested as a group.  It occurs after application (unit) testing.  This is where the testing meets real life patient care as integration testing uses patient scenarios.    Bringing these teams together in one room is helpful to discuss progress and issues.  It is also an excellent time to involve more users in the project and to test on a variety of devices that will be used for go live.

 

Testing should be done in as many scenarios as are required to flex the different clinical scenarios.  For a very limited role out of CPOE in pilot only, perhaps this could be covered with less than ten scenarios.  Most CPOE implementations will require many more. 

 

Options to consider when selecting your integration test scripts:

  • Follow true patient stories (de-identified)
  • Assure that the scenarios have a variety of order priorities and order types.
  • Assure that scenarios have a variety of order sets and single ad hoc orders.
  • Assure that all rules and alerts are being tested.
  • Assure there are a variety of administrative changes-admissions, discharges, transfers and patient merges
  • Assure there are variety of patient types at all facilities
  • Pre-load the test patients with some relevant clinical data: allergies, medications, lab results

 

Each test step should have a step to be performed followed by an expected result.  Document the actual outcome of the test against the expected result and document any differences.  Some basic expected results to be tested are:

  • Transmission to another application through an interface
  • Transmission to another module in the same application
  • Printing of paper or labels
  • Generation of a task or message
  • Generation of another order
  • Sending a page
  • Firing an alert
  • Generation of a charge
  • Automated ADT event

 

Issues should be documented as you go.  Fixes or configuration changes in response to testing should be re-tested against the expect result as soon as possible.

 

Additional items to document during testing

  • Any departures from ideal workflows or any new process flows
  • Training considerations especially any functionality to be emphasized
  • Additional benefits that are discovered
  • Workflow tips or tricks

 

For CPOE, the most important goal of integration testing is to assure that the medication safety loop is intact.  There should be many cycles to test:

  • Order entry and transmission to pharmacy
  • Pharmacy receipt and verification
  • Nursing administration and documentation
  • Order modification