Transport Method Options

• S3 (this is the preferred option in most situations)

• STFPSFTP

While the AIMS ETOR Intermediary can support other transport methods, S3 and STFP SFTP are preferred given functionality, resiliency, and versatility.

Network/Firewall Requirements

• For those using S3 as a transport method, the firewall needs to allow for HTTPS in/out

• For those using SFTP as a transport method, the firewall/network needs to allow for SFTP in/out

Network/firewall components are directly linked to PHL transport methods.

File Format Message Payload Options

• HL7 v2.x (this is the preferred option in most situations)

• FHIR

• XML

• CSV

Any of the outlined file formats are compatible with the ETOR intermediary solution as long as the LIMS 1) is capable of importing sufficient order information and 2) contains a field fields for the data elements necessary to create a result.

Data Field Requirements and Recommendations

The necessary and recommended data fields for the in-scope test(s) are defined here: Insert Link to Test in Scope

This allows for the creation of orders and results in the LIMS.

LIMS Capability Requirements

• Able to import sufficient information to create an order within the system.

• Able to link order and results using a unique ID/token.

• Able to export sufficient information to create a result within the system.

• Has a protocol for handling (e.g., consuming, reviewing) of error messages or an automated or manual alternative process external to LIMS.

Additional LIMS configurations may be necessary. If so, APHL will collaborate with the PHL to assist in communicating needs to the LIMS vendor.

Integration Engine

No integration engine required for message transformations.

APHL recommends does not recommend the LIMS not use and/or not have relevant data flow throughuse of an integration engine for transformation of data for ETOR exchange.

Note: No integration engine should be needed if the LIMS can import/export data. If the LIMS cannot import/export data, APHL will work with the LIMS representative vendor to communicate updates needed.

Out of Scope Related Components

APHL developing the code to allow data to be imported/exported from the LIMS. (can write some script but not everything)

APHL is able to assist in conversations with PHL LIMS representatives to make these changes.

Transport Method Options

1. RESTful API (this is the preferred option in most situations)

2. FHIR

3. MLLP/VPN

While the AIMS ETOR Intermediary can support other transport methods, RESTful, FHIR and MLLP / VPN are preferred given functionality, resiliency, and versatility.

Network/Firewall Requirements

• For those using RESTful or FHIR API as a transport method:

  • Able to enable AIMS RESTful API service for orders order receival.

  • Able to enable HCO RESTful API service for result delivery.

  • Able to authenticate RESTful API connection.

• For those using MLLP/VPN, the network/firewall must be able to establish VPN from AWS to VPN/server to VPN/firewall.

Network/firewall components are directly linked to PHL HCO transport methods.

File Format Message Payload Options

• HL7 v2.x (this is the preferred option in most situations)

• FHIR

• XML

• CSV

Any of the outlined file formats are compatible with the ETOR intermediary solution as long as the EHR 1) is capable of importing sufficient order information and 2) contains a field fields for the data elements necessary to create a resultan order and 2) is capable of importing sufficient result information.

Data Field Requirements and Recommendations

The necessary and recommended data fields for the in-scope test(s) are defined here: Insert Link to Test in Scope

This allows for the creation of orders and consumption of results in the EHR.

EHR Capability Requirements

• Able to export sufficient information to create an order suitable for PHL consumption, with necessary data elements.

• Able to link order and results using a unique ID/token.

• Able to import results.

• Has established processes for test data collection and data entry into the EHR with which staff comply, ensuring data of high quality.

• Able to identify (i.e., include in the order) the appropriate PHL to receive the test order (should be included in the order.

• Has the ability to require specific data fields be populated (for data elements required by the test in scope) - preferred

Integration Engine

No integration engine required.

APHL recommends the LIMS not use and/or not have relevant data flow through.

Note: No integration engine should be needed if the LIMS can import/export data. If the LIMS cannot import/export data, APHL will work with the LIMS representative to communicate updates needed.

Out of Scope Related Components

APHL developing the code to make changes to the EHR.

• enforce the population of certain data elements in the EHR prior to creation of the order - preferred

• Has established processes for test data collection and data entry into the EHR with which staff comply, ensuring data of high quality.