Can HumDay connect to Google Cloud Healthcare?

Yes. HumDay reads Google Cloud Healthcare's own published API description and derives the operations from it, so there is no hand-built connector to wait for. 72 operations are documented.

Do I need to write code to automate Google Cloud Healthcare?

No. You describe the outcome you want in plain words. HumDay agrees a contract with you, writes the program, and shows you a test run before anything touches your Google Cloud Healthcare account.

What can HumDay do in Google Cloud Healthcare?

45 of the 72 documented operations change something in Google Cloud Healthcare, and 27 read from it. HumDay only ever uses the specific operations your approved contract needs.

Is my Google Cloud Healthcare account safe?

Your credentials are stored encrypted and are never shown in chat, code, or logs. Every run is limited to the operations you explicitly approved, and anything that writes to Google Cloud Healthcare is held behind that approval.

Automate Google Cloud Healthcare

HumDay reads Google Cloud Healthcare’s own published API description and derives 72 operations from it. Describe the outcome you want in plain words — you get a program that is written, proven on real data, and run for you.

What Google Cloud Healthcare is

Manage, store, and access healthcare data in Google Cloud Platform.

API host: healthcare.googleapis.com

What HumDay can do in Google Cloud Healthcare

45 documented operations change something in Google Cloud Healthcare.

POSTCreates a new Annotation record./v1beta1/{parent}/annotations
POSTCreates a new User data mapping in the parent consent store./v1beta1/{parent}/userDataMappings
PATCHIf a resource is found based on the search criteria specified in the query parameters, updates part of that resource by applying the operations specified in a JSON Patch document./v1beta1/{parent}/fhir/{type}
POSTCreates a new dataset containing de-identified data from the source dataset./v1beta1/{sourceDataset}:deidentify
POSTCreates a new Consent in the parent consent store./v1beta1/{parent}/consents
POSTCreates a new health dataset./v1beta1/{parent}/datasets
POSTParses and stores an HL7v2 message./v1beta1/{parent}/messages
POSTCreates a new FHIR store within the parent dataset./v1beta1/{parent}/fhirStores
POSTCreates a new DICOM store within the parent dataset./v1beta1/{parent}/dicomStores
POSTCreates a new HL7v2 store within the parent dataset./v1beta1/{parent}/hl7V2Stores
POSTCreates a new consent store in the parent dataset./v1beta1/{parent}/consentStores
POSTParses and stores an HL7v2 message./v1beta1/{parent}/messages:ingest
POSTCreates a new Annotation store within the parent dataset./v1beta1/{parent}/annotationStores
POSTCreates a new Consent artifact in the parent consent store./v1beta1/{parent}/consentArtifacts
POSTCreates a new Attribute definition in the parent consent store./v1beta1/{parent}/attributeDefinitions
DELETEDeletes an HL7v2 message./v1beta1/{name}
PATCHUpdate the message. The contents of the message in Message.data and data extracted from the contents such as Message.createtime can't be altered. Only the Message.labels field is…/v1beta1/{name}
POSTExports the messages to a destination./v1beta1/{name}:export
POSTImport messages to the HL7v2 store by loading data from the specified sources./v1beta1/{name}:import
POSTRejects the latest revision of the specified Consent by committing a new revision with state updated to REJECTED./v1beta1/{name}:reject
POSTRevokes the latest revision of the specified Consent by committing a new revision with state updated to REVOKED./v1beta1/{name}:revoke
POSTArchives the specified User data mapping./v1beta1/{name}:archive
POSTActivates the latest revision of the specified Consent by committing a new revision with state updated to ACTIVE./v1beta1/{name}:activate
DELETEDeletes FHIR resources that match a search query./v1beta1/{parent}/fhir/{type}
PUTIf a resource is found based on the search criteria specified in the query parameters, updates the entire contents of that resource./v1beta1/{parent}/fhir/{type}
POSTConfigure the search parameters for the FHIR store and reindex resources in the FHIR store according to the defined search parameters./v1beta1/{name}:configureSearch
POSTAnalyze heathcare entity in a document./v1beta1/{nlpService}:analyzeEntities
POSTChecks if a particular dataid of a User data mapping in the specified consent store is consented for the specified use./v1beta1/{consentStore}:checkDataAccess
POSTEvaluates the user's Consents for all matching User data mappings./v1beta1/{consentStore}:evaluateUserConsents
POSTSearches for resources in the given FHIR store according to criteria specified as query parameters./v1beta1/{parent}/fhir/_search
PUTUpdates the entire contents of a resource./v1beta1/{name}
POSTStarts asynchronous cancellation on a long-running operation./v1beta1/{name}:cancel
POSTEvaluate an Annotation store against a ground truth Annotation store./v1beta1/{name}:evaluate
POSTCreates a FHIR resource./v1beta1/{parent}/fhir/{type}
DELETEDeletes the specified revision of a Consent./v1beta1/{name}:deleteRevision
POSTSets the access control policy on the specified resource./v1beta1/{resource}:setIamPolicy
POSTDe-identifies data from the source store and writes it to the destination store./v1beta1/{sourceStore}:deidentify
POSTReturns permissions that a caller has on the specified resource./v1beta1/{resource}:testIamPermissions
DELETEDeletes all the historical versions of a resource (excluding the current version) from the FHIR store./v1beta1/{name}/$purge
POSTExecutes all the requests in the given Bundle./v1beta1/{parent}/fhir
POSTQueries all dataids that are consented for a specified use in the given consent store and writes them to a specified destination./v1beta1/{consentStore}:queryAccessibleData
POSTSearches for resources in the given FHIR store according to criteria specified as query parameters./v1beta1/{parent}/fhir/{resourceType}/_search
DELETEDeleteInstance deletes an instance associated with the given study, series, and SOP Instance UID./v1beta1/{parent}/dicomWeb/{dicomWebPath}
POSTStoreInstances stores DICOM instances associated with study instance unique identifiers (SUID)./v1beta1/{parent}/dicomWeb/{dicomWebPath}
POSTValidates an input FHIR resource's conformance to its profiles and the profiles configured on the FHIR store./v1beta1/{parent}/fhir/{type}/$validate

What HumDay can read from Google Cloud Healthcare

These are the operations a schedule or a trigger can watch.

GETLists the revisions of the specified Consent in reverse chronological order./v1beta1/{name}:listRevisions
GETRetrieves the N most recent Observation resources for a subject matching search criteria specified as query parameters, grouped by Observation.code, sorted from most recent to old…/v1beta1/{parent}/fhir/Observation/$lastn
GETLists all the messages in the given HL7v2 store with support for filtering./v1beta1/{parent}/messages
GETLists the User data mappings in the specified consent store./v1beta1/{parent}/userDataMappings
GETGets multiple messages in the given HL7v2 store./v1beta1/{parent}/messages:batchGet
GETGets the latest state of a long-running operation./v1beta1/{name}
GETGets the access control policy for a resource./v1beta1/{resource}:getIamPolicy
GETGets metrics associated with the FHIR store./v1beta1/{name}:getFHIRStoreMetrics
GETLists all the versions of a resource (including the current version and deleted versions) from the FHIR store./v1beta1/{name}/_history
GETLists information about the supported locations for this service./v1beta1/{name}/locations
GETTranslates a code from one value set to another using a concept map./v1beta1/{name}/$translate
GETLists operations that match the specified filter in the request./v1beta1/{name}/operations
GETLists the Consent in the given consent store, returning each Consent's latest revision./v1beta1/{parent}/consents
GETLists the health datasets in the current project./v1beta1/{parent}/datasets
GETRetrieves a Patient resource and resources related to that patient./v1beta1/{name}/$everything
GETLists the FHIR stores in the given dataset./v1beta1/{parent}/fhirStores
GETLists the Annotations in the given Annotation store for a source resource./v1beta1/{parent}/annotations
GETLists the DICOM stores in the given dataset./v1beta1/{parent}/dicomStores
GETLists the HL7v2 stores in the given dataset./v1beta1/{parent}/hl7V2Stores
GETLists the consent stores in the specified dataset./v1beta1/{parent}/consentStores
GETLists the Annotation stores in the given dataset for a source store./v1beta1/{parent}/annotationStores
GETLists the Consent artifacts in the specified consent store./v1beta1/{parent}/consentArtifacts
GETLists the Attribute definitions in the specified consent store./v1beta1/{parent}/attributeDefinitions
GETGets the FHIR capability statement (STU3, R4), or the conformance statement in the DSTU2 case for the store, which contains a description of functionality supported by the server./v1beta1/{name}/fhir/metadata
GETGets all incoming references to a given target FHIR resource./v1beta1/{parent}/fhir/$references
GETRetrieveRenderedFrames returns instances associated with the given study, series, SOP Instance UID and frame numbers in an acceptable Rendered Media Type./v1beta1/{parent}/dicomWeb/{dicomWebPath}
GETTranslates a code from one value set to another by searching for appropriate concept maps./v1beta1/{parent}/fhir/ConceptMap/$translate

How automating Google Cloud Healthcare works

Describe the outcome. Say what you want to happen, in your own words. No node graphs, no field mapping.
Approve the contract. HumDay writes down exactly what it will do, what it will touch, and what it will never do. You approve it before anything is built.
See it proven. The program runs and shows you the result before it is allowed near your live Google Cloud Healthcare account.
Grant access, then go live. You approve the specific Google Cloud Healthcare operations it may use — and only those.