Transport Method Options

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

• SFTP

While

Detor can support other transport methods, S3 and

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.

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

Detor as long as the LIMS 1) is capable of importing sufficient order information and 2) contains

fields for the data elements necessary to create a result.

Data Field

Recommendations

The

recommended data fields for the in-scope test(s)

will be defined during Gap Analysis discussions with both the PHL and HCO.

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

does not recommend the

use of an integration engine for transformation of data for Detor 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

vendor to communicate updates needed.

Detor Data Storage

Detor adheres to the following storage requirements:

• Message archive – 2 years

  • Order from HCO -> Detor

  • Orders from Detor -> PHL

  • Results from PHL -> Detor

  • Results from Detor -> HCO

• Message processing data and transformation artifacts – 60 days

  • Dynamo db

  • S3

• Message processing metadata (no PII) -indefinite

  • Opensearch

Storage requirements were defined based on CLIA guidelines.

Transport Method Options

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

2. FHIR

3. MLLP/VPN

While

Detor can support other transport methods, RESTful, FHIR and MLLP / VPN are preferred given functionality, resiliency, and versatility.

Network/Firewall Requirements

• For those using RESTful

• API as a transport method:

  • Able to enable AIMS RESTful API service for

• • 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

HCO transport methods.

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

Detor as long as the EHR 1)

contains fields for the data elements necessary to create

an order and 2) is capable of importing sufficient result information.

Data Field

Recommendations

The

recommended data fields for the in-scope test(s)

will be defined during Gap Analysis discussions with both the PHL and HCO.

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

• .

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

• .

• Has the ability to

• 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.

Detor Data Storage

Detor adheres to the following storage requirements:

• Message archive – 2 years

  • Order from HCO -> Detor

  • Orders from Detor -> PHL

  • Results from PHL -> Detor

  • Results from Detor -> HCO

• Message processing data and transformation artifacts – 60 days

  • Dynamo db

  • S3

• Message processing metadata (no PII) -indefinite

  • Opensearch

Storage requirements were defined based on CLIA guidelines.