If there’s one thing the healthcare and life sciences field isn’t lacking, it’s data. What it could use more of, though, are easy-to-use and cost-effective ways to analyze and make sense—and use—of it all.
We here on the Google Cloud Healthcare & Life Sciences team recently introduced a set of application programming interfaces (APIs) and data stores that can be used to enable healthcare data analysis and machine learning applications, data-level integration of healthcare systems, and secure storage and retrieval of various types of electronic healthcare and life science data. Today, we’re launching a series of blog posts to familiarize you with the Cloud Healthcare API. In this first article in the series, we’ll provide a brief overview of the Cloud Healthcare API and the innovative use cases it enables; future installments will provide more guidance on how to securely implement the API, and provide details on how to bridge gaps between care systems, cloud applications, and patient/provider channels.
What is the Cloud Healthcare API?
The Cloud Healthcare API provides a managed solution for storing and accessing healthcare data in Google Cloud Platform (GCP), providing a critical bridge between existing care systems and applications hosted on Google Cloud. Using the API, you can unlock significant new capabilities for data analysis, machine learning, and application development, and use these capabilities to build the next generation of healthcare solutions.
The API is comprised of three modality-specific interfaces that implement key industry-wide standards for healthcare data:
FHIR, an emerging standard for health data interchange
HL7v2, the most widely adopted method for health systems integration
DICOM, the dominant standard for radiology and imaging-related disciplines
Each interface is backed by a standards-compliant data store that provides read, write, search and other operations on the data. These data stores also provide an interface into Google Cloud’s high-capacity Publish-Subscribe (Cloud Pub/Sub) product that provides a clean, secure integration point for applications. Cloud Pub/Sub integration can also be used for invoking data transformations in Cloud Dataflow, executing serverless applications using Cloud Functions, streaming data into the popular BigQuery analytics engine, or generating clinical outcome predictions by sending data to the Cloud ML Engine machine learning platform.
The Cloud Healthcare API provides a number of key features that are critical to bridging current technologies to the next generation of healthcare systems and applications:
Standards conformance – Google supports the use of standards-based interoperability through its participation in a number of healthcare standards bodies. In the Cloud Healthcare API each modality-specific data store and its associated API is substantially conformant with its relevant standard. For example, FHIR stores implement STU3, the current version of the FHIR specification, and DICOM stores implement DICOMweb, a web-based standard for exchanging medical images. In future updates, we expect to support additional versions of these specifications as well as the ability to request a resource in a different version than its canonical representation.
Compliance with privacy regulations – GCP provides detailed guidance regarding how it supports compliance with HIPAA in the US, the PIPEDA in Canada, and other global privacy standards at cloud.google.com/security/compliance.
Data location control – The Cloud Healthcare API treats data location as a core component of the API. You have the option to select the storage location for each dataset from a list of currently available locations which correspond to distinct geographic areas aligned with GCP’s regional structure. Future GCP regions will allow for the distribution of storage across wider geographic areas.
Security – The Cloud Healthcare API security model is based on Google’s proven Identity and Access Management (IAM) system. IAM’s fine-grained permissions give you complete control over access to your healthcare data. In addition, we’ve created open-source proxies for our powerful Apigee API Management system, which provides comprehensive threat detection and traffic management capabilities that allow you to securely expose sensitive ePHI with patient and provider applications.
Bulk import and export – The Cloud Healthcare API’s DICOM and FHIR modalities support bulk import and export of data, making it easier to transfer data via the Cloud Storage system.
De-identification – De-identification support for DICOM is available, making it much easier to redact patient information from studies for research and other purposes. The de-identification process operates on a data store basis.
Auditability – Both administrative and data access requests to the Cloud Healthcare API can be audited. Logs are available through Google Cloud’s Stackdriver hybrid monitoring system.
High availability – Availability for mission-critical scenarios is made possible through Google Cloud’s robust and highly redundant infrastructure.
For many applications, the Cloud Healthcare API can provide a modern alternative to legacy stacks implementing DICOM, HL7v2 or FHIR STU3 standards, simplifying data integration with existing systems and enabling the application developers to focus on their differentiating features such as UX and intelligence.
The Cloud Healthcare API enables a wide range of capabilities, spanning administrative, clinical and research use cases. Some common examples for each modality are described below.
Electronic Health Records (EHR) systems integration
The Cloud Healthcare HL7v2 API enables integration with current electronic health records systems or integration engines such as NextGen Connect, Cloverleaf and others. It also includes an open-source adapter for the HL7 Minimal Lower Layer Protocol (MLLP) which can be hosted alongside an EHR system or integration engine for greater security. This adapter communicates with the Cloud Healthcare HL7v2 API over HTTPS, wrapping the HL7v2 message in an API call. Integration architects can also choose to call the API directly if desired.
Data received by the HL7v2 API is stored in GCP, where it becomes accessible only to authorized applications. When new or updated data is received, notifications can be sent to applications via Cloud Pub/Sub, thus providing easy integration into a full HL7v2 message parsing stack customized to your specific message types and content.
HL7v2 to FHIR conversion
HL7v2 data that is received through the Cloud Healthcare API (or imported in batch into Google Cloud Storage) can be immediately made available to customer-specific logic that leverage GCP services such as Cloud Dataflow to transform the messages into a standardized FHIR format. This conversion can include not only the core format conversion to FHIR but also coding system conversions, extraction and classification of important content from clinical notes, and other processes. Newly converted data can then be stored and made available to applications via the Cloud Healthcare FHIR API, forwarded to BigQuery for deep analysis, or processed by TensorFlow models via Cloud ML Engine.
Advanced administrative, clinical and research analysis and reporting
Once data is converted into a standard format such as FHIR or the OMOP Common Data Model, it can be used in BigQuery to produce insights into administrative, clinical and research questions. For example, large-scale analysis and reporting of hospital readmission statistics by facility, disease, practitioner or any of a number of different dimensions is easy using BigQuery’s SQL support. BigQuery also supports a number of popular reporting and visualization tools to help you gain tailored insight into your data.
The ability to apply machine learning to patient data in order to rapidly identify potential diagnoses is an exciting new development. For example, DICOM radiological and natural-light images stored in Cloud Healthcare API datasets can be used to train advanced TensorFlow machine learning models, and those trained models can then run in Google Cloud ML to analyze large volumes of data ingested via production instances of Cloud Healthcare API. Predictions generated by these ML models can then be stored directly in the DICOM images themselves, enabling radiologists to take advantage of this analysis in the context of existing workflows. Such high-volume analysis helps clinicians by performing advanced, consistent scanning for the presence of common diseases. Detected anomalies can then be validated by skilled practitioners, and treatment started quickly if problems are identified.
Similarly, the use of machine learning to leverage large amounts of data to help predict clinical outcomes is helping practitioners identify populations that are at risk of adverse outcomes so that they can intervene early enough to influence the result. This has the potential to significantly reduce hospital readmissions, for example, or to identify patterns of care that require re-evaluation.
Radiological image data extraction
Radiological studies in the DICOM imaging format can be stored in the Cloud Healthcare DICOM API, where they can be retrieved and searched by applications. DICOM study metadata can also be extracted, combined with other clinical data and made available in BigQuery, adding a new dimension to clinical analytics.
De-identification (redacting or transformation) of sensitive data elements is often an important step in pre-processing healthcare data so that it can be made available for analysis, machine learning models, and other use cases. The Cloud Healthcare API provides capabilities to de-identify data stored in the service, facilitating analysis by researchers or machine learning analysis for advanced anomaly scans.
In the next installment of this series, we’ll share much more detail on Cloud Healthcare API concepts and explain how to perform a basic implementation. Watch this space for more information about how you can use the Cloud Healthcare API to better leverage your healthcare data and deliver innovative new healthcare applications.
Feed Source: Google Cloud Platform
Article Source: Getting to know the Google Cloud Healthcare API: Part 1