Difference between revisions of "Upgrade Interface Enablement and Validation"

From Galen Healthcare Solutions - Allscripts TouchWorks EHR Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user not shown)
Line 33: Line 33:
 
|-
 
|-
 
|}
 
|}
−
 
−
=Basic Interface Smoke-Test Plans:=
 
−
==Outbound interfaces==
 
−
#Trigger the outbound event against test patients whose MRN exists in the “Upgrade – Patients to allow” table:
 
−
##Submit charge(s), iterating through the different charge scenarios for your organization (diagnosis, special billing, modifiers, referring provider, etc.)
 
−
##Place order(s), iterating through the different order scenarios for your organization (routine/stat, link to problem, patient insurance, cancellation – EIE/Discontinued, etc.)
 
−
##Execute dictation(s), iterating through the different scenarios for your organization (routine/stat, handheld/desktop, from structured note dictation maker, etc.)
 
−
##Customize for any other outbound interfaces
 
−
##Verify that the corresponding messages are received and processed by the UPGRADE interface superset source system.
 
−
##Verify that the corresponding messages are processed by the UPGRADE interface target system
 
−
##Verify that the corresponding messages are processed by the PROD interface source system
 
−
##Validate that the proper data is received by the vendor
 
−
##'''''Bidirectional considerations'''''
 
−
###If you are testing a bi-directional interface, have the vendor send back the appropriate corresponding inbound message to the AE-EHR (i.e. a corresponding result message for an order, corresponding transcription for a dictation, etc).
 
  
 
=Validation=
 
=Validation=
Line 68: Line 54:
 
| align="center"|'''Category'''||align="center"|'''Data to be Validated'''||align="center"|'''Pass / Fail Data Sent'''||align="center"|'''Pass / Fail Data Sent'''||align="center"|'''Pass / Fail Data Sent'''
 
| align="center"|'''Category'''||align="center"|'''Data to be Validated'''||align="center"|'''Pass / Fail Data Sent'''||align="center"|'''Pass / Fail Data Sent'''||align="center"|'''Pass / Fail Data Sent'''
 
|-
 
|-
−
| EX: PID||EX: MRN, FirstName, LastName||PASS|| || ||  
+
| EX: PID||EX: MRN, FirstName, LastName||PASS|| ||
 
|-
 
|-
 
| ||||Expected: MRN XXX, FirstName XXX, LastName XXX || ||  
 
| ||||Expected: MRN XXX, FirstName XXX, LastName XXX || ||  
Line 77: Line 63:
 
|-
 
|-
 
|}
 
|}
 +
 +
=Basic Interface Smoke-Test Plans:=
 +
==Outbound interfaces==
 +
#Trigger the outbound event against test patients whose MRN exists in the “Upgrade – Patients to allow” table:
 +
##Submit charge(s), iterating through the different charge scenarios for your organization (diagnosis, special billing, modifiers, referring provider, etc.)
 +
##Place order(s), iterating through the different order scenarios for your organization (routine/stat, link to problem, patient insurance, cancellation – EIE/Discontinued, etc.)
 +
##Execute dictation(s), iterating through the different scenarios for your organization (routine/stat, handheld/desktop, from structured note dictation maker, etc.)
 +
##Customize for any other outbound interfaces
 +
##Verify that the corresponding messages are received and processed by the UPGRADE interface superset source system.
 +
##Verify that the corresponding messages are processed by the UPGRADE interface target system
 +
##Verify that the corresponding messages are processed by the PROD interface source system
 +
##Validate that the proper data is received by the vendor
 +
##'''''Bidirectional considerations'''''
 +
###If you are testing a bi-directional interface, have the vendor send back the appropriate corresponding inbound message to the AE-EHR (i.e. a corresponding result message for an order, corresponding transcription for a dictation, etc).
 +
 +
==Inbound interfaces==
 +
#'''''Bidirectional considerations'''''
 +
##For Bidirectional interfaces, you should have test messages sent back via execution of corresponding outbound interface smoke-test.
 +
#You should have a bountiful dataset against which to validate, as the UPGRADE db is fed by PROD, so any of the messages that file into PROD AE-EHR can be used for verification.
 +
#Verify that the corresponding messages are received and processed by the PROD interface target system.
 +
#Verify that the corresponding messages are processed by the UPGRADE interface source system.
 +
#Verify that the corresponding messages are processed by the UPGRADE interface target system.
 +
#Validate that the inbound interfaced message data functions and renders properly within the AE-EHR application:
 +
##Results: Verify status (final/prelim), numberic/alpha result, result formatting, auto-completion of corresponding order, units and reference range, order level comments, item level comments, abnormal/normal, etc.
 +
##Scheduling: Verify type (arrived/rescheduled/cancelled), provider, patient data, visit data (date,time, etc), patient insurance data, etc.
 +
##Registration: Verify type (new,deceased,merged), organizational access, MRN change, patient data, insurance data, guarantor data, etc.

Latest revision as of 22:21, 31 August 2009

Enablement

For each AE-EHR inbound interface source-target pair:

Environment Step
PROD Enable target pass-thru system
UPGRADE Enable source system, allow for ~10-50 messages to file, then stop source system
PROD/UPGRADE Troubleshoot any connectivity issues between production pass-thru target and upgrade source system
UPGRADE Enable target system, allowing messages to file to the EHR
UPGRADE Process and disposition any resulting errors in the target

For each AE-EHR outbound interface superset source-target pair:

Environment Step
UPGRADE Enable interface superset (One superset per AE-EHR DB instance)
UPGRADE Process and disposition any resulting errors in the superset source
UPGRADE Enable target system (Blocking by MRN should block most messages - only messages with MRNs existing in "Upgrade - Patients to allow" table will process and send outbound)
PROD Enable source pass-thru system
PROD/UPGRADE Troubleshoot any connectivity issues between upgrade target and production pass-thru system

Validation

Best Practice Interface Testing

It is recommended to use the standard AHS interface test plans as a starting point for testing. By no means is this an exhaustive test case set and as such you should modify the test plans in accordance with your organization’s configuration and needs. All testing should be fully documented in a spreadsheet with the following serving as minimal data capture:

Patient 1 Patient 2 Patient X
Patient Name (Include Leading Zeros if applicable) Patient MRN or MPI
Patient Org
Shared or Non Shared Org
Category Data to be Validated Pass / Fail Data Sent Pass / Fail Data Sent Pass / Fail Data Sent
EX: PID EX: MRN, FirstName, LastName PASS
Expected: MRN XXX, FirstName XXX, LastName XXX
Actual: MRN XXX, FirstName XXX, LastName XXX

Basic Interface Smoke-Test Plans:

Outbound interfaces

  1. Trigger the outbound event against test patients whose MRN exists in the “Upgrade – Patients to allow” table:
    1. Submit charge(s), iterating through the different charge scenarios for your organization (diagnosis, special billing, modifiers, referring provider, etc.)
    2. Place order(s), iterating through the different order scenarios for your organization (routine/stat, link to problem, patient insurance, cancellation – EIE/Discontinued, etc.)
    3. Execute dictation(s), iterating through the different scenarios for your organization (routine/stat, handheld/desktop, from structured note dictation maker, etc.)
    4. Customize for any other outbound interfaces
    5. Verify that the corresponding messages are received and processed by the UPGRADE interface superset source system.
    6. Verify that the corresponding messages are processed by the UPGRADE interface target system
    7. Verify that the corresponding messages are processed by the PROD interface source system
    8. Validate that the proper data is received by the vendor
    9. Bidirectional considerations
      1. If you are testing a bi-directional interface, have the vendor send back the appropriate corresponding inbound message to the AE-EHR (i.e. a corresponding result message for an order, corresponding transcription for a dictation, etc).

Inbound interfaces

  1. Bidirectional considerations
    1. For Bidirectional interfaces, you should have test messages sent back via execution of corresponding outbound interface smoke-test.
  2. You should have a bountiful dataset against which to validate, as the UPGRADE db is fed by PROD, so any of the messages that file into PROD AE-EHR can be used for verification.
  3. Verify that the corresponding messages are received and processed by the PROD interface target system.
  4. Verify that the corresponding messages are processed by the UPGRADE interface source system.
  5. Verify that the corresponding messages are processed by the UPGRADE interface target system.
  6. Validate that the inbound interfaced message data functions and renders properly within the AE-EHR application:
    1. Results: Verify status (final/prelim), numberic/alpha result, result formatting, auto-completion of corresponding order, units and reference range, order level comments, item level comments, abnormal/normal, etc.
    2. Scheduling: Verify type (arrived/rescheduled/cancelled), provider, patient data, visit data (date,time, etc), patient insurance data, etc.
    3. Registration: Verify type (new,deceased,merged), organizational access, MRN change, patient data, insurance data, guarantor data, etc.
Retrieved from "https://wiki.galenhealthcare.com/index.php?title=Upgrade_Interface_Enablement_and_Validation&oldid=7399"