Connettiti alle applicazioni utilizzando SMART on FHIR

Questa pagina descrive come utilizzare lo standard SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR v1.1.0 per accedere ai dati nei datastore FHIR nell'API Cloud Healthcare.

Panoramica

SMART su FHIR è uno standard di dati che consente alle applicazioni di accedere informazioni nei sistemi di cartelle cliniche elettroniche (EHR). Un'applicazione uno sviluppatore può scrivere una singola applicazione che si connette a qualsiasi sistema EHR che ha adottato questo standard.

Ad esempio, se hai i dati dei pazienti archiviati in un datastore FHIR nell'API Cloud Healthcare, puoi sviluppare un'applicazione svolge le seguenti operazioni:

  1. Esegue l'autenticazione nell'archivio FHIR.
  2. Recupera i dati del paziente.
  3. Visualizza i dati del paziente in un'interfaccia utente.

SMART on FHIR supporta i modelli di autorizzazione OpenID e OAuth 2.0 per l'autorizzazione e l'autenticazione.

Framework di lancio di app SMART, ambiti e contesto di lancio

L'API Cloud Healthcare supporta il framework di lancio delle app SMART, gli ambiti e il contesto di lancio come segue:

Framework per il lancio SMART App

L'API Cloud Healthcare supporta la sequenza di lancio autonoma del framework di lancio delle app SMART.

Un'app può essere avviata da un sistema EHR esistente o da una sessione del portale per i pazienti, entrambi chiamati "avvio EHR", oppure come app autonoma.

Ambiti

Gli ambiti dei dati clinici definiscono le autorizzazioni di lettura e scrittura per le autorizzazioni e accesso a livello di utente. L'API Cloud Healthcare supporta le seguenti gli ambiti dei dati definiti Ambiti per la richiesta di dati clinici:

  • patient
  • user
  • system
Contesto di lancio

Descrive il paziente, l'incontro o altro contesto attuale in cui viene effettuata la richiesta. L'API Cloud Healthcare supporta il contesto di avvio Patient da Ambiti per la richiesta di dati di contesto.

Configura il tuo server di autorizzazione per SMART su FHIR

L'API Cloud Healthcare offre supporto integrato per SMART su FHIR l'applicazione forzata dell'accesso in base agli ambiti di autorizzazione SMART di input e al contesto del paziente. Gli amministratori del datastore FHIR creano esterno all'API Cloud Healthcare che concede Ambiti di autorizzazione SMART e contesto del paziente.

Se un'applicazione client ottiene un token di accesso che rappresenta gli scopi di autorizzazione SMART e il contesto del paziente concessi, l'API Cloud Healthcare non specifica quale flusso di lavoro di lancio l'applicazione client deve utilizzare con il server di autorizzazione esterno.

Impostare e convalidare gli ambiti di autorizzazione SMART

Se utilizzi SMARTProxy, puoi saltare questa sezione. SMARTProxy imposta e convalida automaticamente gli ambiti di autorizzazione SMART.

Gli ambiti di autorizzazione SMART utilizzano il formato seguente:

( 'patient' | 'user' | 'system') '/' ( resourceType | '*' ) '.' ( 'read' | 'write' | '*' )

Gli ambiti delle autorizzazioni SMART e i contesti dei pazienti vengono passati all'API Cloud Healthcare utilizzando le intestazioni HTTP X-Authorization-. L'API Cloud Healthcare utilizza queste intestazioni per applicare il controllo degli accessi ai dati negli archivi FHIR.

Il server di autorizzazione concede gli ambiti di autorizzazione SMART e il contesto del paziente e li codifica in un token di accesso. Il proxy legge quindi le informazioni il token di accesso e lo passa alle intestazioni delle richieste FHIR.

Se non disponi di un server di autorizzazione, puoi utilizzare l'acceleratore di interoperabilità basato su Apigee HealthAPIx su Apigee.

Utilizza il seguente comando SMART sulle intestazioni FHIR HTTP quando effettui richieste dal proxy. L'applicazione client non deve impostare queste intestazioni perché vengono solo comunicate dal proxy all'API Cloud Healthcare.

  • X-Authorization-Scope: uno o più ambiti di autorizzazione che utilizzano i formati standard degli ambiti di autorizzazione SMART. Ad esempio, se imposti l'ambito di autorizzazione su user/Observation.read, che una richiesta può leggere solo una risorsa Observation. L'API Cloud Healthcare applica questo controllo degli accessi.
  • X-Authorization-Patient: contesto del paziente della richiesta. Se imposti questa intestazione, qualsiasi tipo di risorsa della richiesta idonea a essere inserita in un lo scompartimento del paziente deve appartenere al vano del paziente dell'ID paziente fornito. L'API Cloud Healthcare applica questo controllo degli accessi.
  • X-Authorization-Subject: un identificatore per l'utente finale che accede a SMART sull'applicazione client FHIR. L'API Cloud Healthcare registra l'oggetto negli audit log.
  • X-Authorization-Issuer: l'emittente del token di accesso SMART. La L'API Cloud Healthcare registra l'emittente negli audit log.

Configura i token di accesso al server di autorizzazione

Per emettere un token JWT, devi configurare un server di autorizzazione. Il token JWT contiene gli ambiti di autorizzazione SMART e, facoltativamente, il contesto del paziente. L'API Cloud Healthcare non prevede requisiti specifici su come il server di autorizzazione genera il token SMART JWT. Ad esempio, la tua applicazione potrebbe essere registrata per un sottoinsieme di ambiti oppure potrebbe presentare un widget di selezione del paziente per impostare il contesto del paziente.

Se non hai un server di autorizzazione configura i token SMART JWT, puoi utilizzare l'interoperabilità basata su Apigee acceleratore HealthAPIx attivo Apigee per configurare un server di autenticazione che firma i token JWT.

Token di accesso di esempio

L'esempio seguente mostra un token di accesso codificato in base64:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzM4NCJ9.eyJpc3MiOiJzbWFydC50b2tlbi5vcmciLCJpYXQiOjE2MTI4ODQwODUsImV4cCI6MTY0NDQyMDA4NSwiYXVkIjoid3d3LmV4YW1wbGUuY29tIiwic3ViIjoiZG9jdG9yLmpvZUBleGFtcGxlLmNvbSIsInNjb3BlIjoidXNlci9QcmFjdGl0aW9uZXIucmVhZCBwYXRpZW50LyouKiIsInBhdGllbnQiOiJwYXRpZW50MTIzIn0.lC0ouNuXNcj7FxQ83NU_MInULWo0wvyiNuaMt2RbFzBOnnMP_IXJdCeNnw3SQzUV

Dopo aver decodificato il token di accesso, contiene il seguente payload:

{
  "iss": "smart.token.org",
  "iat": 1612884085,
  "exp": 1644420085,
  "aud": "www.example.com",
  "sub": "doctor.gabriela@example.com",
  "scope": "user/Practitioner.read patient/*.*",
  "patient": "patient123"
}

Configura SMART su FHIR nell'API Cloud Healthcare

Questa sezione descrive i passaggi da seguire per iniziare a utilizzare SMART on FHIR con i dati nell'API Cloud Healthcare.

Configurare SMARTProxy

Se utilizzi un tuo server di autorizzazione invece di SMARTProxy, salta questa sezione e continua con Configurare un account di servizio Google Cloud.

SMARTProxy è un proxy open source di Google che offre le seguenti funzionalità:

  • Consente all'API Cloud Healthcare di accettare e convalidare i token di accesso SMART.
  • Consente all'implementazione FHIR nell'API Cloud Healthcare di includere Token di accesso SMART nell'ambito della gestione delle API e del modello di autorizzazione.

Quando effettui una richiesta per recuperare i dati dall'API Cloud Healthcare tramite SMARTProxy, la richiesta segue questi passaggi:

  1. SMARTProxy accetta una richiesta contenente un token SMART di un client.
  2. SMARTProxy convalida il token SMART tramite il server di autorizzazione JWT.
  3. SMARTProxy legge gli ambiti e il contesto del paziente dal token SMART e li passa all'API Cloud Healthcare utilizzando quattro intestazioni HTTP.
  4. L'API Cloud Healthcare riceve le intestazioni e le convalida per applicare il controllo dell'accesso alla richiesta. L'API Cloud Healthcare restituisce una risposta al client tramite SMARTProxy.

Configurare un account di servizio Google Cloud

Un proxy può avere un solo account di servizio Google Cloud. Se più client usano lo stesso proxy, i client devono usare lo stesso servizio . Presta attenzione quando condividi un account di servizio con più client per i seguenti motivi:

  • Per leggere i dati FHIR nell'API Cloud Healthcare, l'account di servizio deve disporre di autorizzazioni di lettura e scrittura ampie.

  • L'indirizzo email dell'entità di Cloud Audit Logs è associato all'account di servizio.

    Ad esempio, se chiami l'API Cloud Healthcare utilizzando Account Google per l'autenticazione, Cloud Audit Logs registra il tuo indirizzo email come indirizzo email dell'entità. Quando utilizzi un proxy per chiamare l'API Cloud Healthcare, il proxy utilizza il proprio account di servizio e l'indirizzo email dell'account di servizio è l'indirizzo email principale, pertanto l'utente chiamante originale viene oscurato. Per salvare l'utente finale nei metadati dell'audit log, supera nell'indirizzo email dell'utente finale nel campo sub del token JWT.

Configurare un datastore FHIR

Non è necessario configurare l'archivio FHIR contenente i dati FHIR a cui accedi.

Effettuare richieste SMART su FHIR

Questa sezione fornisce una panoramica dei metodi SMART su FHIR supportati nell'API Cloud Healthcare e su come viene applicato l'accesso alle risorse quando viene effettuata una richiesta SMART su FHIR.

Quando effettui una richiesta, il tuo server di autorizzazione è responsabile generare token di accesso con l'ambito di autorizzazione SMART pertinente e avviare il contesto.

Metodi supportati

L'API Cloud Healthcare supporta SMART su FHIR per tutti i metodi projects.locations.datasets.fhirStores.fhir, ad eccezione dei seguenti:

Applicazione dell'accesso alle risorse

Quando si effettua una richiesta SMART su FHIR a un datastore FHIR, si verifica il controllo dell'accesso nel seguente ordine:

  1. L'API Cloud Healthcare controlla le autorizzazioni in Google Cloud configurato nel proxy. Se l'account di servizio dispone delle autorizzazioni IAM corrette per il datastore FHIR, la richiesta viene eseguita.
  2. L'API Cloud Healthcare verifica se il token SMART ha le autorizzazioni appropriate per accedere a ogni risorsa FHIR richiesta dalla richiesta.

L'alloggiamento del paziente è fondamentale per l'applicazione forzata dell'accesso nell'API Cloud Healthcare. SMART on FHIR contiene un elenco di tipi di risorse FHIR idonei per essere inclusi in un comparto del paziente. I tipi di risorsa hanno anche propri criteri di inclusione. Nel resto di questa sezione, i tipi di risorse idonee sono chiamati "tipi di risorse idonee per il comparto dei pazienti". I tipi di risorse non idonee sono chiamati "tipi di risorse non idonee per il comparto dei pazienti".

Le richieste SMART on FHIR a un archivio FHIR devono soddisfare i seguenti requisiti:

  • Fornisci il ruolo patient, user o system nel Ambiti di autorizzazione SMART. Se fornisci il ruolo patient, devi fornire un contesto del paziente. Il contesto del paziente è un ID logico della risorsa Patient. La risorsa Pazient deve esistere già nel datastore FHIR o esistere dopo che è stata effettuata la richiesta, altrimenti l'API Cloud Healthcare rifiuta la richiesta.

  • Durante la creazione, la lettura, l'aggiornamento o l'eliminazione di una risorsa, il resourceType e il tipo di operazione (read o write) devono corrispondere, altrimenti l'API Cloud Healthcare rifiuta la richiesta.

  • Se fornisci un ambito patient contenente tipi di risorse non idonee per il comparto dei pazienti, ad esempio patient/Practitioner.*, il controllo di convalida dell'ambito non va a buon fine e l'API Cloud Healthcare lo rifiuta.

  • Puoi impostare tutti i tipi di risorse con l'ambito user. Se il paziente contestualizza è presente con un ambito user, tipi di risorse idonei al compartimento paziente sono limitati al contesto del paziente. I tipi di risorse rimanenti ignorano il contesto del paziente.

  • La presenza di un contesto del paziente limita l'idoneità al compartimento paziente di risorse a un determinato paziente. Ad esempio, una risorsa Observation deve avere il subject campo che fa riferimento alla risorsa Patient specificata affinché l'osservazione sia accessibile. Consulta i tipi di accesso all'alloggiamento del paziente in Resource CompartmentDefinition - Content per un elenco dei campi in ogni tipo di risorsa dell'alloggiamento del paziente a cui deve essere fatto riferimento al paziente specificato affinché la risorsa sia considerata all'interno dell'alloggiamento del paziente.

  • Le richieste possono contenere sia gli ambiti patient sia user.

  • Non utilizzare l'ambito system con il contesto del paziente, altrimenti la richiesta non va a buon fine.

  • Non utilizzare l'ambito system con l'ambito patient o user.

  • Se chiami un metodo che accede a più risorse (ad esempio il metodo fhir.Patient-everything, fhir.executeBundle o fhir.search), il controllo dell'accesso si applica a ogni singola risorsa.