New Google Professional Cloud Architect PCA case study : EHR Healthcare.
As of 1st may 2021, Google has refreshed their case studies related to the Google Cloud Professional Cloud Architect PCA.
2 new cases studies have been introduced: EHR Healthcare and Helicopter Racing League. Also the two other case studies Mountkirk Games and TerramEarth have been updated. Be careful: Google has kept similar names for Mountkirk Games and TerramEarth case studies but their contents are different.
I wanted to dedicate this post to the EHR Healthcare case study.
Disclaimer: update 17/05/2021 : I have now taken and passed the new #Google #GCP #PCA #Google Cloud Professional Cloud Architect exam. Without revealing much I can say that the reading of this article should allow you to gain a few points during the exam !
The statements in this post only reflect my opinion and are only meant to trigger discussions related to the EHR Healthcare case study.
Let’s get started !
The first thing which comes to mind after reading the EHR Healthcare case study is that the company’s business is related to keeping and maintaining Electronic Health Records (EHR). An Electronic Health record is “systematized collection of patient and population electronically stored health information in a digital format”.
Bizarrely, at no point in the case study is there a mention of “HIPAA” (Health Insurance Portability and Accountability Act) compliance (USA), nor General Data Protection Regulation (EU GDPR) compliance — only “Maintain regulatory compliance” in the Business requirements of the case study.
I suggest though to review the GCP compliance offerings related in particular to HIPAA, here, and to GDPR, here. The GCP site states that : “Customers that are subject to HIPAA and want to utilize any Google Cloud products in connection with PHI must review and accept Google’s Business Associate Agreement (BAA). Google ensures that the Google products covered under the BAA meet the requirements under HIPAA and align with our ISO/IEC 27001, 27017, and 27018 certifications and SOC 2 report.”, and goes to list a number of services in scope for HIPAA for Google Cloud Platform, Cloud Identity and Google Workspace. No doubt that EHR Healthcare would have to review and accept Google’s Business Associate Agreement (BAA) to host Protected health information (PHI) data.
There is also a Google whitepaper on “Protecting healthcare data on Google Cloud” which makes an interesting read in the context of this particular case study.
Existing technical environment
The existing technical environment section of the case study could be depicted as below:
Solution Concept
As per the EHR Healthcare case study the solution concept states that :
- EHR Healthcare’s business has been growing exponentially year over year.
- They need to be able to scale their environment
- Adapt their disaster recovery plan
- Roll out new continuous deployment capabilities to update their software at a fast pace.
- They have selected GCP as their public CSP.
Analysis
This is yet another use case of migration from on-prem or colocation facilities to a public Cloud Service Provider (CSP), in this case GCP.
- EHR Healthcare’s business has been growing exponentially year over year.
The example relates to a successful business who is growing exponentially in the last years. This is another typical reason for adoption of Cloud services and to move to a Cloud Service Provider (CSP) where scalability of systems and storage become the responsibility of the CSP. EHR Healthcare would’t have to guesstimate its capacity until the next hardware refresh anymore. The responsibility for capacity management process (ITIL) is transferred to the CSP.
- They need to be able to scale their environment
GCP has many services able to scale exponentially for storage, compute or networking purposes. The good news is that EHR Healthcare has containerized their compute services and are already using Kubernetes clusters. This is a good position to be in pre-cloud migration with multiple options to accommodates containerized workloads in GCP (GKE, Google Cloud Run, Anthos, GAE Standard engine (based on pre-configured run-time containers)…).
Google Kubernetes Engine (GKE): Google has built the Kubernetes platform upon 15 years of experience running production workloads at Google. As EHR Healthcare already uses Kubernetes it should be relatively easy to migrate containers and workloads to multiple Kubernetes clusters GKE inside GCP.
Kubernetes scales up (and down) and shall be able to accommodate the scaling requirements of EHR healthcare. Please also note the Cluster autoscaler feature of GKE which could be leveraged to resize Standard Google Kubernetes Engine (GKE) cluster’s node pools based on the demands of the workloads. With GKE Autopilot clusters, node pools are automatically provisioned through node auto-provisioning, and are automatically scaled to meet the requirements of the workloads. See GCP GKE cluster autoscaler reference.
The only reference to storage in the EHR Healthcare case study is that all data is stored in a mixture of relational and NoSQL databases (MySQL, MS SQL Server, Redis and MongoDB).
For relational databases MySQL, MS SQL Server, Cloud SQL for MySQL could be used as a replacement for on-prem MySQL DB. For MS SQL Server Microsoft SQL Server on Compute Engine or managed Cloud SQL for SQL Server could be leveraged. There are some quotas and limits which could also get in the way of the desired scalability (30TB of storage max for Cloud SQL for MySQL). Please do refer to the quotas and limits for these services.
For noSQL Redis and MongoDB databases some managed options exist too with GCP in the form of Memorystore for Redis and Memcached. MongoDB can also be deployed with GCP via the marketplace. MongoDB could potentially be replaced by GCP Datastore service providing a highly scalable NoSQL database for web and mobile applications.
There is mention of legacy file and API based system which are scheduled to be replaced over the next several years. There is no plan to upgrade or move these systems at the current time. As such there are out of scope for this case study. Looking at the 6 “Rs” of Cloud Migration this is an example of the Retire or Retain strategy.
- Adapt their disaster recovery plan
There is not much related disaster recovery plan (DRP) information in EHR Healthcare case study. It is certain that migrating to GCP will benefit the organisation by leveraging Google’s global infrastructure between and within regions and to use GCP’s extremely high availability time.
- Roll out new continuous deployment capabilities to update their software at a fast pace.
This is indeed a typical requirement for almost any software based companies nowadays. Being able to deliver new versions, bug fixes, new releases faster to a global audience.
This statement refers to continuous deployment (CD)but is most likely to be also associated with continuous integration (CI). In this case I refer to the official Google architecture for deployment to K8s pipeline, with Application source Code, Cloud Build, Container Registry services:
Other considerations
Also do bear in mind GCP offers their specific Cloud Healthcare API. GCP states that the Cloud Healthcare API “accelerates your healthcare solution development with fully managed, enterprise-scale, HL7® FHIR®, HL7® v2, and DICOM® APIs. Help protect your healthcare data while meeting industry-specific security, privacy, and compliance requirements”.
I also found the “MultiScale Health Networks: Powerful systems to enhance patient care” as well as the “Doctor Anywhere” case studies to have some similarities in relation to this EHR Healthcare.
Written by Philippe Le Gal — PLuG IT Consulting.
#Google #GCP #PCA #Google Cloud Professional Cloud Architect #EHR #Healthcare #Cloud Healthcare #API #EHR Healthcare
