AlayaCare External Integrations

Home

AlayaCare Technical Architecture

Technical documentation for AlayaCare’s external integration offerings.

Contents

Overview

Scope

This document describes the technical architecture of AlayaCare external integrations. The goal of such integrations is to satisfy the need to allow data to flow from and into AlayaCare from external systems that clients or partners have in place to satisfy their business requirements.

The goal of this Technical Architecture document is to define the technologies, products, and techniques necessary to develop and support the system, and to ensure that the system components are compatible and comply with the enterprise-wide standards and direction defined by AlayaCare.

Definitions

AlayaCare infrastructure is hosted using Amazon Web Services (AWS) and we extensive use of the following services for this integration:

IAM – Amazon Identity and Access Management

Client credential management. https://aws.amazon.com/iam/

SQS – Amazon Simple Queue Services

Application generated event stream. https://aws.amazon.com/sqs/

S3 – Amazon Simple Storage Service

File exchange https://aws.amazon.com/s3/

The encryption tools used for this integration are:

TLS - Transport Layer Security

https://tools.ietf.org/html/rfc5246

GPG – Gnu Privacy Guard

https://www.gnupg.org/

Technical Architecture

System Architecture Context Diagram

System Architecture Context Diagram

System Architecture Model

The external integration architecture is based in the following components:

Overall Architectural Considerations

Security Strategy

For REST APIs all communications are encrypted at the transport level using TLS v1.2. Authentication and authorization is enforced on every request with http basic auth.

For all AWS services authentication and authorization is enforced using Amazon IAM. For SQS Queues all communications are encrypted at the transport level using TLS v1.2.

For flat files import/exports file exchange is implemented through S3. All communications are encrypted at the transport level using TLS v1.2. Encryption at the payload level is supported using GPG.

Credentials will be provided for each of the different environments at the configuration stage.

Performance requirements and transaction volumes

The required infrastructure will be scaled to satisfy client’s transaction volumes and AlayaCare Service Level Agreement (SLA) as per the client pricing model.

SQS queues standard queues are configured with default message life cycle and visibility timeout. Limitations enforced by the SQS service apply on all cases.

SQS Basic Architecture

SQS Visibility Timeout

SQS Limits

Resilience and recovery

For SQS Queues we implement the AWS standard message retention period of 3 days with a default Maximum Receives of 5 tries. Dead letter queues are configured for all of our queues to catch and retain messages that failed to be delivered:

SQS Dead Letter Queues

System Architecture Component Definition

REST APIs

AlayaCare External API Guide

SQS Queues

Inbound (Intake) Queue

Intake Queue

Intake is the referral processing queue.

Messages posted must validate against the JSON schema provided by AlayaCare and validated by the tenant. Message payload should be encrypted using AlayaCare public key available at the following url:

https://tenant.environment.alayacare.ca/api/v1/config/pub_key

Data posted to this processing queue will be available through AlayaCare interface.

After processing, a ‘result’ message will be put in the intake outbound queue.

Further documentation found here: AlayaCare Intake Guide

Outbound Queues

Outbound Queue

Data in outbound queues does not contain any client related health data.

SQS message schema documentation found here: AlayaCare SQS Messaging Specifications

Intake outbound

Stream of referral processing responses. The referral response includes: