Axial Exchange Technology

Overview

Architecture

Under the hood, Axial looks more like a modern consumer web application than a legacy health IT system. In general, we think of software architecture as the description of how the subsystems of an application interact in order to consume, store, manipulate, and transmit data in a manner that satisfies security and scalability requirements.

Specifically, our architecture works in the following ways:

• Axial's architecture features an n-tier design that separates data, logic, and display. This modularity allows for reusable services and also avoids a single point of failure. The open source subsystems are themselves built with a modular design that is governed by a hierarchy of maintainers in order to accommodate code contributions from a distributed community.
• Data communication and transformation occur via platform-independent interfaces on a bus and queue architecture, which abstracts legacy EHR systems.
• Our Ruby-based engine is capable of showing specific content to specific users (e.g. trauma surgeon, PCP, patient, case manager), based on context (e.g. EMS, ER Visit, Inpatient Admission). Our Rails presentation layer supports customization through these rules that can be defined at the system, group, and/or user level.
• We store data in a document-oriented database, which uses meta data and key value pairs to manage complex data without using an unwieldy database schema that is typically associated with complex relational databases.
• We virtualize hardware resources and are capable of elastic provisioning and failover based on performance and uptime requirements. Axial's cloud environment also supports database sharding, distributed computing, and analytics via MapReduce.
• We maintain secure communications between our clients’ infrastructure and our cloud environment through encrypted VPN communication. End users must authenticate to use the system. Once authenticated, users access the system via HTTPS.

Works with Legacy Apps

This infrastructure means that we can interface with virtually any legacy application. We support the following communication methods:

• HL7 over MLLP via VPN – REALTIME or BATCH
• XML or Delimited Text – SMTP/FTP via VPN – BATCH
• HL7 or CCD/CCR – SMTP/FTP via VPN – BATCH
• HL7 or CCD/CCR – ETL via VPN – BATCH
• HL7 or CCD/CCR – XML/MTOM over HTTPS (SOAP Web Service) – REALTIME
• CCD/CCR – XML/JSON over HTTPS (REST Web Service) – REALTIME

Implementation

Gradual Rollout

To efficiently implement the Alerts platform requires collaboration between the hospital and Axial teams. Once we understand how data flows and users are authenticated, Axial minimizes the impact on hospital IT resources.

A typical implementation must address three core issues:

• Connectivity – getting the hospital and the Axial platform to communicate
• Authorization – controlling which users have access to the application
• Patient Data – getting patient data to the Axial platform

Once these three items are met, the rest of the work is on the Axial side. During implementation, we will present the overall objective, the specific role of players on the hospital team, and a preferred approach.

Privacy & Security

Secure

Data Transmission Security

Axial uses enterprise grade router-to-router VPN security for clinical data transmission and HTTPS/SSL for encryption of presentation layer transmission.

Data storage

Axial’s database requires authentication, and data elements are encrypted.

Cloud environment

Axial is SAS 70 certified and HIPAA audited.