Versions Compared

Version Old Version 1 New Version Current
Changes made by

Hayleigh McCall McDavid

Emma Sudduth

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The following tables outline the technical preferences and/or recommendations considerations for public health laboratories (PHLPHLs) and healthcare organizations (HCOHCOs) implementing electronic test and result (ETOR) exchange via APHL’s AIMS Intermediary.APHL’s Detor solution.

Table of Contents
minLevel1
maxLevel6
outlinefalse
typelist
printablefalse

...

Public Health Laboratories (PHLs) - Technical Considerations

Technical Component

Preference(s) and/or RecommendationsWhile the AIMS ETOR Intermediary

Considerations

Notes

Transport Method Options

  • S3

- preferred

  • STFP

    • (this is the preferred option in most situations)

    • SFTP

    While Detor can support other transport methods, S3 and

    STFP

    SFTP are

    strongly

    preferred given functionality, resiliency, and versatility.

    Network/Firewall Requirements

    • For those using S3 as a transport method, the firewall needs to

    allows

    • 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

    - most preferred

    • (this is the preferred option in most situations)

    • FHIR

    • XML

    • CSV

    - least preferred

    Any of the outlined file formats are compatible with

    the ETOR intermediary solution

    Detor 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

    FieldsMust have the necessary

    Field Recommendations

    The recommended data fields

    of

    for the

    test

    in-scope

    (or the ability to create those data fields)

    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

    Capabilities

    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

    None

    No integration engine required for message transformations.

    APHL

    recommends

    does not recommend the

    LIMS not use and/or not have relevant data flow through

    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

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

    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)

    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.

    Healthcare Organizations (HCOs) - Technical Considerations

    Technical Component

    Preference(s) and/or Recommendations

    Considerations

    Notes

    Transport Method Options

    1. RESTful

    - preferred

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

    - least preferred

    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

    - most preferred

    • (this is the preferred option in most situations)

    • FHIR

    • XML

    • CSV

    - least preferred

    Any of the outlined file formats are compatible with

    the ETOR intermediary solution

    Detor 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 result

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

    Data

    FieldsMust have the necessary

    Field Recommendations

    The recommended data fields

    of

    for the

    test

    in-scope

    (or the ability to create those data fields)

    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

    Capabilities

    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 orde

    • .

    • Has the ability to

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

    Integration Engine

    None

    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.

    APHL is able to assist in conversations with HCO EHR representatives to make these changes

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