INTRODUCTION 

What is EHR:

An electronic health record is the systematized collection of patient and population electronically-stored health information in a digital format. These records can be shared across different health care settings. (Wikipedia)

Most hospitals and associated Clinics depend on these records to serve patient care and to track their medical history. Massive amounts of data is processed daily by the applications and companies that serve these records. 

SUMMARY OF REFERENCE ARCHITECTURE

As more and more health organizations are moving it’s infrastructure to the Cloud, it has become imperative for EHR company companies/hospitals to work with it’s clients to provide connectivity from different cloud providers to its data centers and in a HA and redundant fashion. Besides this, and in most cases, EHR companies need to talk not only to it’s Clients but to their Affiliates and Partners through the Client’s Cloud infrastructure and with the same level of redundancy. The following reference architecture attempts to capture many of the common challenges that one might encounter and how they can be addressed using Aviatrix Cloud Platform. 

REFERENCE ARCHITECTURE DIAGRAM

Please see diagram attached to the article

CASE STUDY

The case study is based on a real customer use case but for the purposes of this document we will call them Customer “XYZ”. 

XYZ has been using the Cloud (AWS in this case) for some of their infrastructure and have plans to move more and more of their workloads to it. They use a major EHR company’s solution for their EHR software and as a result expressed interest in their AWS infrastructure to EHR data centers. Additionally many of XYZ’s affiliates (clinics) depend on their Cloud infrastructure for running their workloads as well to reach the EHR company. So part of this architecture was to solve for the Affiliate’s connectivity to EHR via XYZ’s Cloud infrastructure. 

Cloud infrastructure Notes: 

• Single account in AWS that consisted of several VPCs (20s). They use a full mesh of VPC peering for inter-VPC communication. 





• Even at this scale, the peerings could get unmanageable and transitive routing was something that was becoming a necessity. But establishing connectivity from its AWS VPCs, or its affiliates VPCs, to EHR meant that Transitive routing was a must. 





• There was also no L4-L7 security in place and needed to be able to insert one before they could go to production with this connectivity to EHR company. 





• Also, these are patient data, so encrypting it was critical. 





• EHR company provides HA/redundancy by providing connectivity from/to multiple regions so they had their workloads replicated in multiple regions  in AWS as well. 





• Since XYZ and its affiliates are separate entities, the former has no control over its latter’s networking infrastructure, so they had high chances of encountering overlapping IP addresses. 

Business requirements: 

The above description of this customer’s Cloud infrastructure lays the foundation for this reference architecture. In a nutshell, here are the new business requirements - 

• AWS connectivity to EHR company over Direct connect, with Encryption





• Multi region connectivity with HA for both EHR as well as XYZ’s affiliates. 





• XYZ affiliate connections to it’s resources in AWS. 





• XYZ affiliate connections to EHR via the AWS Direct connect 





• Segmentation and Security in cloud with L4-L7 inspection 





• Manage overlapping IP addressing from affiliates. 

Technical requirements: 

As a first step in building this Architecture, it was crucial to translate the various business requirements into technical requirements that can be solved individually to achieve the end state. Following are those technical requirements that Aviatrix concluded as must haves - 

• Transitive routing - this is a must, both as a Hub/Spoke within cloud as well as for the Affiliates to XYZ AWS as well XYZ AWS to EHR data centers connectivity.  





• Direct connect to EHR data centers with Private VIFs that land on a VPC’s VGW - this is needed to connect the DX connection into XYZ’s infrastructure. 





• Firewall insertion in a scalable manner and is not limited by native construct’s limitations - this is required to provide L4-L7 inspection for the customer’s workflows. 





• Provide segmentation of XYZ’s infrastructure from its affiliate’s as well as from infrastructure required to support EHR connectivity.





• Site to Site VPNs over the internet that also supports NAT - this is needed for the affiliates connection into XYZ’s AWS infrastructure. 

AVIATRIX SOLUTION COMPONENTS

Finally, to bring it all together, various functionalities in the Aviatrix Platform was used to achieve each one of the technical requirements. Here is a description of each of those components. 

Aviatrix Controller

This is software on a Cloud Instance that provides all the Management, Orchestration and the Control Plane for the entire solution. It uses SDN routing in the Cloud and BGP to on prem. 

Aviatrix Transit gateways

This is software on a Cloud Instance that forms the Data plane in the solution. The Transit gateways are specialized data plane that can also do dynamic routing (BGP) and are hence used in this architecture to provide the on prem connectivity. Given its ability to do IPSEC over BGP, it is a perfect fit to meet the encryption requirements over direct connect and to make the connectivity to EHR company’s data centers. 

The Aviatrix Transit gateways in multiple regions can also be peered to each other with what is known as Transitive Peering and this enables a highly available and redundant connection (Active mesh) between different regions. This multi region connectivity is also encrypted. 

Note on Transitive peering and Multi region failover: Since EHR company will be advertising the same routes over multiple regions (for multi region failover and redundancy) via the Direct Connect to each of the Transit gateways in their respective regions, the same CIDR is also advertised over this transitive peering connection so they are reachable over the other regions should the first region’s on prem connection go down. One would think that this could cause asymmetric or route loop issues but the Controller has intelligence built in that ensures the local region route is always preferred over the transitive peering route, hence avoiding any loops or asymmetric issues. 

Stress and convergence tests proved really good results with multi region failover under a minute and almost hitless failbacks. 

Aviatrix Firenet Gateways 

Aviatrix’s Firenet solution will be used to insert the customer’s firewalls for L4-L7 inspection in a scalable and highly available fashion. The solution enables customers to deploy these instances directly from the Aviatrix controller, and integrate them with Aviatrix Firenet gateways so they can be responsible for HA, failover, Flow symmetricity, route programming etc. In short, these gateways take care all the routing functionalities so the firewall instances can do the firewalling and inspection. This solution has several other benefits such as avoiding SNAT, IPSEC and BGP which improves the economies of scale for the solution. 

Aviatrix Gateways for S2C

These are normal Aviatrix gateways that form the data plane and they function to provide connectivity from XYZ’s Affiliates into their AWS infrastructure. More importantly these gateways come with full NAT functionalities (DNAT/SNAT) that enable us to completely overcome the overlapping addresses that may result in connecting the affiliates and XYZ infrastructure. 

TGW Orchestration 

Finally, to meet the segmentation requirement and provide policy based control between different segments, Aviatrix’s AWS TGW Orchestration feature will be used to create AWS TGW for transitive routing and orchestrate the security domains with connection policies. 

CONCLUSION

Validation: 

Various test cases were used to validate all the different components of this solution but most importantly the following traffic flows were validated. 

1 - Affiliates traffic to XYZ’s EHR infrastructure inside AWS, with inspection at Firenet VPC

2 - Affiliates traffic to EHR company’s data centers, with inspection at Firenet.

3 - EHR company’s connectivity to XYZ’s EHR infrastructure inside AWS. Also including Firenet inspection. 

4 - Multi region failovers to EHR data centers were successfully tested multiple times and validated. 

5 - Multi region connectivity to XYZ’s AWS infrastructure was also validated. 

6 - DNAT/SNAT rules were tested accurately. 

7 - Encryption over direct connect was also successfully setup and verified. 

Additional Notes: 

Please talk to an Aviatrix representative if there are questions on how to implement this architecture or any one of the individual solutions.