Cloud offers a proven way to accelerate end-to-end chip design flows. In a previous blog, we demonstrated the inherent elasticity of the cloud, showcasing how front-end simulation workloads can scale with access to more compute resources. Another benefit of the cloud is access to a powerful, modern and global infrastructure. On-prem environments do a fantastic job of meeting sustained demand but Electronic Design Automation (EDA) tooling upgrades happen much more frequently (every six to nine months) than typical on-prem data center infrastructure upgrades (every three to five years). 

What this means is that your EDA tool can provide much better performance if given access to the right infrastructure. This is especially useful in certain phases of the design process.

Take for example, a physical verification workload. Physical verification is typically the last step in the chip design process. In simplified terms, the process consists of verifying design rule checks (or DRCs) against the process design kit (PDK) provided by the foundry. It ensures that the layout produced from the physical synthesis process is ready for handoff to a foundry (in-house or otherwise) for manufacturing. Physical verification workloads tend to require machines with large memories (1TB+) for advanced nodes. Having access to such compute resources enables more physical verification to run in parallel, increasing your confidence in the design that is being taped out (i.e., sent to manufacturing).

At the other end of the spectrum are functional verification workloads. Unlike the physical verification process described above, functional verification is normally performed in the early stages of design and typically requires machines with much less memory. Furthermore, functional verification (dynamic verification in particular) accounts for the most time (translating directly to the availability of compute) in the design cycle. Verifying faster, an ambition for most design teams, is often tied to availability of right-sized compute resources. 

The intermittent and varied infrastructure requirements for verification (both functional and physical) can be a problem for organizations with on-prem data centers. On-prem data centers are optimized for maximizing utilization—this does not directly address access to right-sized compute to deliver the best tool performance. Even if the IT and Computer Aided Design (CAD) departments choose to provision additional suitable hardware, the process of provisioning, acquiring and setting up new hardware on-prem typically takes months for even the most modern organizations. A “hybrid” flow that enables use of on-prem clusters most of the time, but provides seamless access to cloud resources as needed would be ideal.

Hybrid chip design in action

You can improve a typical verification workflow simply by utilizing a hybrid environment that provides instantaneous access to better compute. To illustrate, we chose a front-end simulation workflow, and designed an environment that replicates on-prem and cloud clusters. We also took a few more liberties to simplify the environment (described below). The simplified setup is provided in a GitHub repository for you to try out.

In any hybrid chip design flow, there are a few key considerations:

1. Connectivity between on-prem infrastructure and the cloud: Establishing connectivity to the cloud is one of the most foundational aspects of the flow. Over the years, this has also become a very well-understood field, and secure, high availability connectivity is a reality in most setups. 
   
   In our tutorial, we represent both on-prem and cloud clusters as two different networks in the cloud where all traffic is allowed to pass between these networks. While this is not a real-world network configuration, it is sufficient to demonstrate the basic connectivity model.
   
2. Connection to license server: Most chip design flows utilize tools from EDA vendors. Such tools are typically licensed, and you need a license server with valid licenses to operate the tool. License servers may remain on-prem in the hybrid flow, so long as latency to the license server is acceptable. You can also install license servers in the cloud on a Compute Engine VM (particularly sole-tenant nodes) for lower latency. Check with your EDA vendors to understand if you can rehost your license services in the cloud.
   
   In our tutorial, we use an open source tool (Icarus Verilog Simulator) and therefore, do not need a license server.
   
3. Identifying data sources and syncing data: There are three important aspects in running EDA jobs: the EDA tools themselves, the infrastructure where the tools run, and the data sources for the tool run. Tools don’t change much, and can be installed on cloud infrastructure. Data sources, on the other hand, are primarily created on-prem and updated regularly. These could be SystemVerilog files that describe the design, the testbenches or the layout files. It is important to sync data between on-prem and cloud to maintain parity. Furthermore, in production environments, it’s also important to maintain a high-performance syncing mechanism.
   
   In our tutorial, we create a file system hierarchy in the cloud that is similar to one you’d find on-prem. We transfer the latest input files before invoking the tool.
   
4. Workload scheduler configuration and job submission transparency: Most environments that leverage batch jobs use job schedulers to access a compute farm. An ideal environment finds the balance between cost and performance, and builds parameters in the system to enable predictive (and prescriptive) wrappers to job schedulers (see picture below).
   
   In our tutorial, we use the open-source SLURM job scheduler and an auto-scaling cluster. For simplicity, the tutorial does not include a job submission agent.

Other cloud-native batch processing environments such as Kubernetes can also provide further options for workload management.

Our on-prem network is called ‘onprem’ and the cloud cluster is called ‘burst’. Characteristics of the on-prem and burst clusters are specified below:

Once set up, we ran the OpenPiton regression for single and two-tile configurations. You can see the results below:

Regressions run on “burst” clusters were on average 30% faster than on “onprem”, delivering faster verification sign-off and physical verification turnaround times. You can find details about the commands we used in the repository. 

Hybrid solutions for faster time to market

Of course, on-prem data centers will continue to play a pivotal role in chip design. However, things have changed. Cloud-based, high performance compute has proved itself to be a viable and proven technology for extending on-prem data centers during the chip design process. Companies that successfully leverage hybrid chip design flows will be able to better address the fluctuating needs of their engineering teams. To learn more about silicon design on Google Cloud, read our whitepaper “Using Google Cloud to accelerate your chip design process”.

After a seamless migration to Google Cloud Platform with CloudCover and Google Cloud Professional Services, Hike has reduced its costs by 20% and processed analytics queries 20 times faster than with its previous cloud provider. The business is also using AI and machine learning to enhance the experience provided by a new sticker-based messaging app, Hike Sticker Chat.

India is a market of opportunity for businesses that provide messaging apps to consumers. With more than 1.3 billion people, the country is the second most populous in the world. However, global messaging app providers face a robust market challenge from Hike, a home-grown internet and technology startup. Launched in 2012, Hike provides innovative products such as Hike Messenger and more recently the AI- and machine-learning-enabled Hike Sticker Chat, a service that enables young people in the country to express themselves through digital stickers.

The business says it understands the people of India and communication like no one else, while its mission is to reduce individuals’ dependency on the keyboard. To do this, Hike is building one of the largest repositories of AI and machine-learning-enabled stickers for Hike Sticker Chat. This messaging platform is, according to Hike, the only product of its type that enables conversations through stickers covering more than 40 languages and local dialects.

Google Cloud Results

• Processes analytics queries 20X faster than previously
• Doubles compute throughput
• Uses Google Cloud Machine Learning Engine managed, distributed capabilities to train complex models on TensorFlow that provide delightful local sticker recommendations through Hike Sticker Chat

Founded by Kavin Bharti Mittal, the Delhi-based venture is backed by SoftBank, Tencent, Tiger Global, Foxconn, and Bharti. To date, Hike has raised $261 million in funding. In August 2016, Hike raised its Series D round of funding, led by Tencent and Foxconn, at a valuation of $1.4 billion. The business is one of the fastest Indian startups to achieve Unicorn status, doing so in less than four years.

Hike started operations on a multinational cloud service. However, as user numbers and usage grew, the business began exploring options to improve performance and stability, reduce costs, and cut administration loads. In particular, Hike wanted to reduce latency between cloud data centers.

Focus on product development

“We aimed to move away from a technology stack with single points of failure to a horizontally scaled, highly reliable, distributed systems and managed services environment that enabled us to focus on product development rather than operations,” says Aditya Gupta, Director, Engineering, Hike.

Hike then began exploring the opportunities presented by Google Cloud Platform. The business held a number of executive-level meetings with Google to understand the capabilities, roadmap, and track record of the cloud service. It then decided to proceed with a proof of concept with Google Cloud Premier Partner CloudCover.

The proof of concept revealed that when Cloud Load Balancing was operating, latency between the Google Cloud data center in Taiwan and Delhi, India, was less than the latency between the incumbent cloud provider’s data center and Delhi. Further, compute throughput was up to two times greater on Compute Engine than on the equivalent service, while Hike could complete more then 1 million connections on Compute Engine – up from 500,000 connections on the incumbent service.

Migrate to GCP

The success of the exercise prompted Hike to migrate its messaging app to Google Cloud Platform. “We chose Google Cloud Platform because of its very broad set of services and features,” explains Gupta. “In addition, Google’s innovation mindset and the richness of the partnership would allow us to be onboarded quickly to machine learning services such as Cloud Machine Learning Engine.”

The business called on Google Cloud Professional Services (Technical Account Management) to help ensure a seamless lift-and-shift migration over two months. Google Cloud Professional Services initially undertook a technical infrastructure kickoff to establish a foundation for architecture requirements such as identity and access management and security.

Google Cloud Professional Services team delivers smooth migration

Google Cloud Professional Services worked closely with Hike to map out and deliver the Google Cloud Platform architecture that would deliver the greatest value to the business. The Professional Services team also worked with Hike to resolve product and support queries quickly; provided project background for product and support teams; and organized project meetings and early adopter program access.

In addition, Professional Services team members worked on site at least once a week, coordinated external support during critical migration periods, and coordinated teams in five countries for a single, 17-hour migration marathon. Over 60 days, the business migrated 7,000 processor cores, running virtual machine instances used for messaging infrastructure and analytics, to Google Cloud Platform.

Throughout the exercise, Google Cloud Professional Services worked with CloudCover to educate the customers’ technology teams to achieve proficiency with Google Cloud Platform. The teams soon built up skills and knowledge of best practices and began applying them to the Google Cloud Platform environment.

The Hike Google Cloud Platform architecture comprises virtual machine instances running in Compute Engine; Cloud Storage for unified object storage; networking; a BigQuery analytics data warehouse; Cloud Dataflow to transform and enrich data; Cloud Load Balancing to distribute workloads to maximize efficiency; and Cloud Dataproc to run Hadoop clusters.

Hike is also stepping up its AI & machine learning capabilities. It uses Google Cloud Machine Learning Engine managed, distributed computing capabilities to train complex models on TensorFlow. This powers key use cases such as delightful local sticker recommendations on Hike Sticker Chat. Hike is also investing heavily on AI and machine learning research.

Hike has achieved a range of benefits from its Google Cloud Platform deployment. As well as reduced latency, improved compute throughput, and increased connection handling, Google Cloud Platform managed services have enabled the business to reduce the time and effort required to administer core infrastructure, with the saved resources allocated to improving its messaging product.

“Managed services are beginning to reduce our operational overheads,” says Gupta. “For example, managed instance groups and Cloud Load Balancing are reducing our instance count and costs, thereby reducing involvement from DevOps and developer teams.”

Google Cloud Platform 20% cheaper

Gupta and his team have calculated that running for three years on Google Cloud Platform will cost, including the cost of migration, 20 percent less than on its previous platform. BigQuery is processing queries 20 times faster than a similar service offered by the previous provider, while storing 125TB of data and streaming 1.5TB of data daily. Furthermore, Hike’s analytics pipeline costs 80 percent less than in its previous environment.

“Google Cloud Platform has played an important role in enabling us to continue to innovate and realize our mission of reducing dependency on the keyboard,” says Gupta.

Throughout the past couple of years, I have helped a good number of companies, big and small, migrate their systems to the Google Cloud Platform (aka GCP). During the course of these migrations, there are always a few of those moments where people look at a specific Google Cloud feature and say, “now, that’s cool!”.

More often than not, it is because, coming from other platforms, they have gotten used to some features requiring multiple steps, or some operations being complicated, etc. And often they find out that in GCP you can do this specific operation in a couple of clicks, or by setting up a simple text-based configuration. Then you see that light bulb turning on in their head, and there you go… happy customer.

A few of these happen so often that I compiled them in a list to share with others who might also benefit from these “aha!” moments. You could say these are the five things I wish they told me when I started using Google Cloud.

Projects: Naturally Group Resources Together

A project is a namespace where resources live. Every resource you instantiate in GCP, from load balancers to Kubernetes clusters to virtual machines, belongs to a single project, and has no access (by default) to resources in other projects. User roles and authorisations can be defined per-project and trickle down to everything in it. This has two immediate benefits: you can group things that belong together in neat logical units, and things that don’t belong together are isolated from each other (and isolation is a Good Thing)

This is powerful and quite simple, but it often takes new users off-guard. I’ve had many clients call me and ask me “How can I make sure my developers cannot access the production machines? What’s the best way to create access policies? ”

The answer to this is actually super-simple:

• have a project for development where your developers have rights,
• have a project for production where they don’t.
• That’s it.

Every machine/other resource in the production project won’t be accessible to developers.

Of course there is a lot more to it, and you can refine roles and permissions to a much greater degree using Organizations, Folders, etc. Not to mention all the crazy things you can do with per-project billing. But at least you can say “hey, if it’s a machine in the staging environment then it can be found in the “staging” project”.

Global Virtual Networks Are *Truly* Global

Imagine you are using a Cloud provider and that you have servers in the US, and servers in Singapore, and that they need to communicate.

So you create a VPC (Virtual Private Cloud) network in the US data center, another one in the Singapore data center, and then you will connect them by setting up inter-region VPC peering or a VPN (Virtual Private Network) or a transit VPC or other routing magic.

Lots of work, right? And many moving parts, so lots of opportunities for things to break.

With GCP, however, what makes my clients go “aha!” is when they realize that in GCP a single VPC network covers the entire planet. Only subnets are attached to a geographic location, and virtual machines communicate between subnets on private IPs (good old RFC1918 addresses) — no extra routing needed.

So, to make your server communicate across continents on GCP, here are the steps:

• create a VPC network
• create a subnet in the US, put your US servers in it
• create a subnet in Singapore, put your Singapore servers in it

That’s all there is to it. Your VPC network spanning 2 continents is ready to use. Below is a screenshot of how it looks on my account, for a VPC network called ‘my-global-network’ with 2 subnets. The first column (“us-central1” and “asia-southeast1”) contains the name of the GCP regions (read: data centers). The second column is the subnet name that I picked when I created them.

A machine in the US (on the “us-central” subnet) with IP 10.0.0.5 can communicate directly with a machine in Singapore (on the “singapore”) subnet with IP 10.10.0.8.

Nothing else to set up.

And thanks to the way these networks work, the Google Cloud Load Balancer can present a single IP to the world, and forward traffic to the instances that are the closest to you geographically without having to setup a tedious DNS-based load balancing. But that’s worth an entire blog. I’ll save it for another day.

Firewalls with Tags and (Almost) No IP Addresses

There is no network security without a firewall so unsurprisingly GCP comes with one built-in.

Now, I don’t know about you, but nothing makes my brain hurt like a list of firewall rules displaying IP ranges and addresses and ‘Allow/Deny’ directives. It looks a bit like this:

If you imagine a normal network with a few dozen (hundred?) servers, you can quickly see how this can get out of control. You’d better have a solid printout of your network layout to refer to when you start adding and changing rules. And good luck debugging things!

Wouldn’t it be nice if, instead, you could just tell the firewall: “the HTTP traffic from outside can only reach the HTTP servers and the MySQL database is only reachable by the HTTP server(s) on the same network?”

Turns out it’s pretty simple on GCP by using a little thing called network tags. As the documentation says:

“Network tags are text attributes you can add to Compute Engine virtual machine (VM) instances. Tags allow you to make firewall rules and routes applicable to specific VM instances.”

So let’s see how it works. Firewall rules in GCP are defined in terms of source and target (the traffic flows from the source to the target). You can define filtering rules that apply to the source or the target, and in both cases you can use tags.

This is simpler shown with an example. The rule below states that on the default network, the traffic to the VMs with the tag mysql-server can come from the VMs with the tag http-appserver. Any other traffic is “Deny”-ed by default.

All you have to do is to tag your machines properly, and they will automatically be covered by the rule. You don’t need to enter their IP range.

That’s neat if you ask me. It makes it a lot simpler to grasp what’s happening.

Of course, there’s a TON more to firewalls in GCP. Tags also apply to routes and you can mix and match IP-based rules with tag-based rules. Not to mention that thing called service accounts, but I’ll leave those for another day.

The bottom line is that you can create most rules by just expressing a business need and not having to remember complicated network layouts. I have no hard stats, but I’m pretty sure this has saved me hours of work.

Console Access to VMs from the Browser

Easily access virtual machines (VMs) from the Google Cloud console was one of my first “aha!” moments when I started using GCP.

This is a screen capture of my Google Cloud console, with a virtual machine and its internal IP.

The last column has a header that says “Connect” and when you click on the word “SSH” a separate windows pops up. You wait for a few seconds, and… this is what you get. Your personal shell access — in a browser popup no less.

You are connected through ssh to the virtual machine of your choice. You did not have to download ssh keys and put them in the ~/.ssh directory, do the correct chmod command and run a long-winded ssh -i ~/.ssh/somekey me@<it-took-me-forever-to-copy-paste-the-address-here>

In addition, you have access to a few nifty features such as uploading and downloading files, changing the user etc. Just use the menu behind the cog icon at the top right.

In truth, you should not need to connect directly that often, but when you have to, this is a godsend.

Your Personal Jumphost from the Google Cloud Console

The Google Cloud console has a cool trick: you can actually connect to a virtual environment that is managed by the Google Cloud console itself. It serves a bit as a jump host. You can access most resources from the projects from it, and you can activate it directly from the top menu with, no particular setup on your side. It’s called the Cloud Shell.

This is how it looks at the top right of the console:

When you activate the Cloud Shell, the session opens at the bottom of the console. You get a command line prompt and it’s fully configured with the gcloud command line tool (the jack-of-all-trades of Google Cloud scripting).

You can do a great many things from there, and this even includes uploading and downloading files, editing code or deploying it, a web preview for your AppEngine application, and more.

So you can get access to a fully configured shell environment in your project from any laptop where you can connect with your credentials. On top of this, it persists between connections so you can fine-tune it to your needs and have these changes available the next time you re-connect.

This has saved me many times during my previous life as a traveling consultant!

Live migration

Did I say 5 “Aha!” moments ? Well, you’ve been patient reading all the way to here, so here’s one more for free.

Google Cloud has an amazing way to literally “teleport” a running virtual machine between physical hosts without stopping it. It’s called Live Migration. It allows Google to move your virtual machine away from a defective host, or a host that needs a patch or an upgrade, or for any other infrastructure related reason.

It’s all done in the background, and is totally transparent, so you never really see it happening. Unless you look VERY closely. I once did a demo to a client, where a machine was live migrated while he was simulating a solid network load — and we did not lose a single packet, with no noticeable degradation in latency.

And that’s a wrap!

So there you go. These are 5+1 things that made me go “Aha!” when I became more familiar with the Google Cloud Platform, and that still make my clients do the same.

There is a lot of depth to the platform, and my examples above only scratch the surface of our features. I encourage you to try it yourself. There is a generous free tier, and when you are ready to take the plunge and create that new company, please contact us at Google Cloud for Startups. We’ll get you up and running in no time.

Jerome is a Startup Architect at Google Cloud. Based in Singapore, he helps startups make the most of the Google Cloud Platform.

Google Cloud VMware Engine delivers an enterprise-grade, cloud-native VMware experience that is built on Google Cloud’s highly performant and scalable infrastructure. By enabling a consistent VMware experience, the service allows customers to adopt Google Cloud rapidly, easily, and with minimal modifications to their vSphere workloads, bringing the best of VMware and Google Cloud together on one platform for a variety of use-cases. These include rapid data center exit, application lift and shift, disaster recovery, virtual desktop infrastructure, or modernization at your own pace.

Here are seven ways VMware Engine outshines alternatives for running your VMware workloads in the cloud, simplify your operations, and help you innovate faster:

1. Dedicated 100Gbps east-west networking
   Google Cloud VMware Engine nodes come with redundant switching and dedicated 100Gbps east-west networking with no oversubscription of bandwidth, unlike other options where there is generally oversubscription. This is especially important when it comes to running latency-sensitive workloads.
2. Four 9’s of availability in a single zone
   The service offers 99.99% uptime SLA for a cluster in a single Zone with five to 16 nodes and FTT=2 or more without the need for stretched clusters, which is higher than the alternatives. Further, dedicated connectivity for core service functions such as vSAN and vMotion enables better solution stability and availability. This enables the service to support the needs of enterprise workloads that require high availability.

Note: “Cluster” means a deployment of three or more dedicated bare metal nodes running VMware ESXi and associated networking managed via management interfaces.

3. Global networking without complex routing
   Google Cloud VMware Engine networking is built based on Google Cloud’s powerful networking architecture. With simplified regional and global routing modes—which allow a VPC’s subnets to be deployed in any region where our service is available—you can architect global networks without the need or overhead of creating and connecting regional network designs. You get instant, direct Layer 3 access between them. In alternative cloud environments, you may have to configure special networking between regions, often requiring VPN-based tunnels over the WAN to enable global uniform network communication. This adds to the deployment and operational complexity, in addition to cost.
4. Integrated multi-VPC networking
   Users often have application deployments in different VPC networks, such as separate dev/test and production environments or multiple administrative domains across business units. The service supports “many-to-many” access from VPC networks to Google Cloud VMware Engine networks with multi-VPC networking, allowing you to retain existing deployed architectures and extend them flexibly to your VMware environments. In addition, by providing multi-VPC networking, you can pool their VMware needs—say for QA and dev—to a smaller set of clusters, effectively reducing their costs.

For more information about the end-to-end networking capabilities and services available in Google Cloud VMware Engine, please refer to the Private Cloud Networking for Google Cloud VMware Engine whitepaper. Here, you’ll find details about network flows, configuration options, and the differentiated benefits of running your VMware workloads in Google Cloud.

5. Unified, cloud-integrated model
   Google Cloud VMware Engine is a fully managed Google first-party service, operated and supported by Google and its world-class team. With fully integrated identities, billing, and access control, you have a simpler end-to-end experience that is different from other services. You access Google Cloud VMware Engine service via the Google Cloud console, like any other Google Cloud service. You can also access other native Google Cloud services privately from your VMware private cloud running in Google Cloud VMware Engine over local connections.
6. Flexibility in third-party ecosystem compatibility
   With Google Cloud VMware Engine, you can set up existing VMware on-premises third-party tools or products that require additional privileges by using a solution user account. This uniquely enables operational consistency, ensuring that the tools you have invested in and used over the years work on Google Cloud VMware Engine. Furthermore, in key areas such as vSAN data encryption, you have the choice of not only using Google Cloud Key Management Service (KMS)—which is turned on by default on vSAN datastores—but also external KMS providers such as HyTrust, Thales, and Fortanix.
7. Dense nodes with high storage:core and memory:core ratios and fast provisioning
   Google Cloud VMware Engine nodes are dense. Each node is powered by Intel® Xeon® Scalable Processors and comes with 36 cores, 72 hyperthreaded cores, 768 GB memory, 19.2 TB NVMe data and 3.2 TB NVMe cache storage. This, along with oversubscription, leads to high consolidation ratios and compelling storage:core per dollar and memory:core per dollar. In addition, you can rapidly spin up these nodes in a VMware private cloud often in under an hour, enabling on-demand, VMware-consistent capacity in Google Cloud for your needs.

These are just a few examples of customer-centric innovation that set Google Cloud VMware Engine infrastructure apart. In addition, migrating to Google cloud can save you up to 38% in TCO. Get started by learning about Google Cloud VMware Engine and your options for migration, or talk to our sales team to join the customers who have embarked upon this journey.

The authors would like to thank the Google Cloud VMware Engine product team for their contributions on this blog.

Since the start of the COVID-19 pandemic, there’s been a rapid acceleration of digital transformation across the entire healthcare industry. Telehealth has become a more mainstream and safe way for patients and caregivers to connect. Machine learning modeling has helped speed up innovation and drug discovery. And new levels of integration and data portability have helped enable greater vaccine availability and equitable access to those who need it.

Data has been at the crux of this digital transformation — helping people stay healthy, accelerating life sciences research and delivering more personalized and equitable care. We recently unveiled partial results from our research with The Harris Poll, which revealed that nearly all physicians (95%) believe increased data interoperability will ultimately help improve patient outcomes. Today, we’re unveiling the second part of that research. 

In February 2020, we commissioned The Harris Poll to survey 300 physicians in the U.S. about their biggest pain points — this was just before the COVID-19 pandemic strained the entire healthcare system and made us all hyper-aware of the risks we take in going to the hospital. In June 2021, we followed-up with those same questions and more. What it unveiled was just how much COVID-19 reshaped technology’s role in the healthcare field and how it’s changing day-to-day operations for physicians. 

Here are some of the highlights: 

Healthcare organizations accelerated technological upgrades over the course of the pandemic. After a year shaped primarily by the COVID-19 pandemic, use of telehealth saw substantial YOY growth, jumping nearly threefold from 32% in February 2020 to 90% this year. Forty-five percent of physicians say the COVID-19 pandemic accelerated the pace of their organization’s adoption of technology. In fact, more than 3 in 5 physicians (62%) say the pandemic has forced their healthcare organization to make technology upgrades that normally would have taken years. For example, 48% of physicians would like to have access to telehealth capabilities in the next five years. Before the COVID-19 pandemic, about half of physicians (53%) say their healthcare organization’s approach to the adoption of technology would best be described as “neutral” (i.e., willing to try new technologies only if they have been in the market for awhile or others have tried and recommended them). 

Despite the technological leaps this year, most physicians still believe the industry lags behind in technology adoption but recognize the opportunity for technological support and advancement. The majority of physicians don’t view the healthcare industry as a leader when it comes to digital adoption. More than half of physicians describe the healthcare industry as lagging behind the gaming (64%), telecommunications (56%), and financial services industries (53%). However, the healthcare industry is not seen to be trailing as much as it was last year behind retail (54% in 2020; 44% in 2021); hospitality and travel (53% in 2020; 43% in 2021); and the public sector (39% in 2020; 26% in 2021). 

Better interoperability alleviates physician burnout, improves health outcomes and speeds up diagnoses. The majority of physicians say increased data interoperability will cut the time to diagnosis for patients significantly (86%) and will ultimately help improve patient outcomes (95%.) In addition to better patient experiences and outcomes, more than half of physicians (54%) believe increased access to data via technology has had a positive impact on their healthcare organization overall. A majority believe that technology can alleviate the likelihood of physician “burn-out” (57%) and that efficient tools help decrease friction and stress (84%). And, as a result, 6 in 10 physicians say access to better technology and clinical data systems would allow them to have better work/life balance (60%) and that better access to/more complete patient data would reduce administrative burdens (61%). It is therefore not surprising that nearly 9 in 10 physicians (89%) say they are increasingly looking for ways to bring together all patient data into a single place for a more complete view of health. 

Familiarity with new Department of Health and Human Services (DHHS) interoperability rules grows, and many physicians are in favor. Most physicians (74%) say they have at least heard of the new DHHS rules (launched in 2019) to improve the interoperability of electronic health information. This is a clear rise from 2020 (64%), but deeper knowledge is fairly low. Only 30% of physicians say they are somewhat or very familiar with the new rules (though, again, this is a rise from 2020, when only 18% said they were very/somewhat familiar). Similar to in 2020, among those who have heard of the new rules, nearly half are in favor (48% in 2021; 45% in 2020) but a similar proportion remain unsure (46% in 2021; 50% in 2020). And like in 2020, by far the top potential benefit of the rules is thought to be forcing EHRs to be more interoperable with other systems (70%).

Google was founded on the idea that bringing more information to more people improves lives on a vast scale. In healthcare, that means creating tools and solutions that make data available in real time to help streamline operations and improve quality of care and patient outcomes. For example, our recently announced Healthcare Data Engine makes it easier for healthcare and life sciences leaders to make smart real-time decisions through clinical, operational, & groundbreaking scientific insights. To find out more about the Healthcare Data Engine, click here.

^{Survey methodology: The 2021 survey was conducted online within the United States by The Harris Poll on behalf of Google Cloud from June 9 – 29, 2021 among 303 physicians who specialize in Family Practice, General Practice, or Internal Medicine, who treat patients, and are duly licensed in the state they practice. The 2020 survey was conducted from February 18 – 25, 2020 among 300 physicians who specialize in Family Practice, General Practice, or Internal Medicine, who treat patients, and are duly licensed in the state they practice. Physicians practicing in Vermont were excluded from the research. This online survey is not based on a probability sample and therefore no estimate of theoretical sampling error can be calculated. For complete survey methodology, including weighting variables and subgroup sample sizes, please contact press@google.com.}