Questa pagina è stata tradotta dall'API Cloud Translation.

Modello di dati di accesso FHIR e sistema di controllo

Questa pagina descrive come utilizzare il sistema di controllo dell'accesso FHIR dell'API Cloud Healthcare per gestire e proteggere i tuoi dati sanitari. Puoi utilizzare il controllo dell'accesso FHIR per definire i criteri di consenso, controllare l'accesso ai dati in base ai ruoli e al contesto dell'utente e applicare questi criteri in un archivio FHIR.

Panoramica del modello di dati

Il modello dei dati per controllo dell'accesso è rappresentato dalle risorse di consenso. Definiscono le regole da applicare e a quali dati si applicano.

Le regole di accesso sono espresse tramite risorse FHIR Consent. FHIR Consent è un tipo di risorsa FHIR che acquisisce le scelte di un consumatore di servizi sanitari. Consente o nega a un insieme di attori di eseguire azioni che interessano il consumatore per uno specifico scopo da un ambiente specificato per un periodo di tempo. Ad esempio, un consumatore potrebbe essere un paziente, chiunque agisca per conto di un paziente o un altro privato che stipula un contratto di consenso.

Le azioni registrate in un consenso FHIR possono essere ampie e riguardare più di semplici dati della cartella clinica elettronica (EHR) del consumatore. Tuttavia, ai fini del consenso all'interno dell'API Cloud Healthcare, l'attenzione si concentra sulle azioni relative all'accesso ai dati e l'applicazione di queste azioni è limitata alla lettura dei dati FHIR da un datastore FHIR.

Una risorsa Consent ha un stato che indica lo stato attuale del consenso. Sebbene un datastore FHIR possa contenere molti consensi in stati diversi, l'API Cloud Healthcare applica solo i consensi nello stato attivo. I consensi in qualsiasi altro stato non hanno alcun effetto sull'applicazione. Se il consenso viene concesso per conto di un paziente, viene registrato come concesso da un esecutore.

Tipo di criterio

L'API Cloud Healthcare supporta i seguenti tipi di norme sul consenso:

Consenso del paziente: è associato a un paziente che utilizza Consent.patient (STU3, R4) e vincola tutti i dati definiti dal compartimento del paziente (STU3, R4).
Norme per gli amministratori: non è associato ad alcun paziente e deve avere un URL di estensione https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Questo tipo di criterio può essere associato a un sottoinsieme o a tutte le risorse nel negozio specificato dai criteri delle risorse. I criteri amministratore impostano i criteri predefiniti per tutte le risorse di binding nello store.
Policy a cascata per gli amministratori: un tipo di policy per gli amministratori che richiede l'URL dell'estensione https://g.co/fhir/medicalrecords/CascadingPolicy e l'URL dell'estensione della policy per gli amministratori. Puoi associare questo tipo di criterio a un compartimento di risorse che corrispondono ai criteri delle risorse. Presenta le seguenti limitazioni:
- Supporta solo Patient (STU3, R4) o Encounter (STU3, R4) come base del compartimento.
- Il datastore FHIR in cui viene applicato il criterio deve avere disableReferentialIntegrity impostato su false. Contatta l'assistenza cloud per utilizzare questa funzionalità per l'archivio FHIR non referenziale.

Puoi combinare i tipi di policy allo stesso livello di risorsa per consentire o negare l'accesso a una risorsa. Se manca il consenso di un paziente, il criterio di amministrazione può approvare l'accesso a una risorsa.

Le direttive di consenso sono istruzioni codificate all'interno di un consenso FHIR che consentono o negano l'accesso ai dati a un'entità autorizzata, ad esempio un beneficiario o un accesso. Un singolo consenso FHIR può codificare più direttive di consenso. Ogni direttiva fornisce quanto segue:

Tipo di applicazione: un'istruzione permit o deny.
Azione: l'autorizzazione o le autorizzazioni coperte da questa direttiva. Solo access è supportato per fornire l'accesso di sola lettura.
Criteri di accesso: un insieme di attributi che identificano il richiedente dell'API coperto dalla direttiva.
Criteri delle risorse: un insieme di attributi che identificano le risorse coperte dalla direttiva.

Criteri per gli accessori

L'API Cloud Healthcare supporta tre proprietà di un accessor da utilizzare all'interno di una direttiva di consenso e per la corrispondenza con un accessor che effettua una richiesta di accesso ai dati. Per applicare una direttiva all'accessor nell'ambito della determinazione dell'accesso offerta dal server FHIR, è necessario che la corrispondenza sia esatta e sensibile alle maiuscole.

Queste proprietà sono codificate come segue:

Attore: rappresenta un individuo, un gruppo o un ruolo di accesso che identifica l'autore dell'accesso o una sua caratteristica.
Scopo: rappresenta l'intento di utilizzo dei dati.
Ambiente: rappresenta un identificatore astratto che descrive l'ambiente o le condizioni in cui agisce l'accessor.

Ad esempio, un accessorio può essere rappresentato dalle seguenti proprietà:

Attore: Practitioner/123
Scopo: ETREAT o accesso per scopi di trattamento di emergenza
Ambiente: Application/abc

In questo esempio, queste proprietà rappresentano un medico che accede ai dati quando esegue un trattamento di emergenza utilizzando un'applicazione software chiamata abc.

provision.actor e provision.purpose sono definiti come parte dello standard FHIR, mentre Environment è https://g.co/fhir/medicalrecords/Environment. Tieni presente che questo link non è risolvibile.

Tutte le direttive relative al consenso devono specificare un actor da applicare, ma non devono sempre specificare un purpose o un environment. Ad esempio, se non viene specificato alcun environment nell'istruzione relativa al consenso, l'istruzione corrisponde a qualsiasi environment non ancora coperto da altre istruzioni relative al consenso.

Criteri delle risorse

L'API Cloud Healthcare supporta i seguenti elementi come parte della risorsa consenso:

Tipo di risorsa (STU3, R4): rappresenta il tipo a cui è associata la norma sul consenso, ad esempio Encounter, Observation o Immunization.
ID risorsa (STU3, R4): rappresenta l'ID a cui è associata la norma sul consenso.
Origine dati: rappresenta l'origine della risorsa identificata dal meta.source della risorsa (disponibile solo in R4).
Tag dati: rappresenta l'etichetta personalizzata della risorsa come descritto nella risorsa meta.tag (STU3, R4).
Etichetta Sicurezza: rappresenta le etichette di sicurezza che definiscono le risorse interessate come identificate nel campo meta.security (STU3, R4). Sono supportati i seguenti sistemi di codifica:
- Confidenzialità: valori gerarchici classificati da non limitato a più limitato: U, L, M, N, R, V. Se un consenso consente un'etichetta di sicurezza R allora si applica a tutte le risorse etichettate R o inferiore. Se un consenso nega un'etichetta di sicurezza R, si applica a tutte le risorse che sono almeno sensibili quanto R.
- ActCode: corrispondenza esatta della stringa sul codice di sicurezza.

Flusso di lavoro di accesso

authorization_flow

Questa figura illustra il percorso end-to-end di una richiesta a un archivio con controllo dell'accesso FHIR abilitato. Un token esterno con l'ambito di consenso (a sinistra) viene utilizzato dall'applicazione (#3) quando effettua una richiesta all'archivio FHIR con il controllo dell'accesso abilitato (a destra).

Quando effettua una richiesta di accesso ai dati, un accessor opera all'interno di un particolare ambito di consenso che rappresenta le sue proprietà actor, purpose e environment correlate a qualsiasi richiesta HTTP FHIR. I valori di queste proprietà devono corrispondere esattamente a quelli forniti in un consenso per poter influire sulla determinazione dell'accesso all'applicazione.

Un accessore può avere più identificatori actor pertinenti per determinare l'accesso. Allo stesso modo, possono esserci più purposes o environments pertinenti in un determinato contesto di consenso. Pertanto, tutte le proprietà di accesso pertinenti devono essere fornite nell'ambito di una richiesta HTTP FHIR per rappresentare correttamente l'accesso ai fini del consenso.

Ad esempio, l'ambito del consenso per una determinata richiesta di dati potrebbe essere il seguente:

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

Rappresenta un infermiere o un medico noto come professionista sanitario 444 che è membro del gruppo 999, che rappresenta i professionisti sanitari di un reparto di un ospedale specifico. Il professionista è lì per fornire un trattamento regolare, ma potrebbe anche occuparsi di trattamenti di emergenza nell'ambito di queste azioni. Il professionista utilizza un'applicazione software chiamata abc.

L'ambito del consenso viene fornito come Richiedi ambito del consenso nell'ambito di una richiesta di dati di un accessor.

Richiedi ambito del consenso

Le richieste FHIR utilizzano le intestazioni di richiesta HTTP FHIR per ricevere l'ambito di consenso dell'accessor. Questo ambito del consenso contiene un insieme di valori actor, purpose e environment per riflettere l'identità, le qualifiche, l'intento di utilizzo e i vincoli ambientali attuali dell'accessor. Potrebbe esserci più di una di queste proprietà che rappresentano l'ambito del consenso di un accessore in un determinato momento.

Le voci dell'ambito del consenso sono definite come segue:

actor/{type}/{ID}: una proprietà actor in cui viene fornita la risorsa type insieme a ID. Alcuni esempi di type sono:
- Practitioner
- Group
- Patient
Ad esempio, se un negozio con il formato projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID chiama l'API, un riferimento locale a un attore Practitioner/123 viene risolto in projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.
purp/v3/{value}: una proprietà purpose in cui value è un membro del set di valori FHIR Purpose of Use (v3) o della sua estensione. Alcuni esempi di value includono:
- TREAT
- ETREAT
- HRESCH
env/{type}/{value}: una proprietà environment in cui type e value sono stringhe personalizzate senza tassonomia predefinita. Alcuni esempi di type e value includono:
- App/my_app_1
- Net/VPN

Inoltre, le intestazioni delle richieste HTTP FHIR possono ricevere anche ambiti speciali, ad esempio btg e bypass, che sono definiti come segue:

btg: Break the glass (o BTG) consente a te, in qualità di utente umano, di saltare i controlli del consenso in caso di emergenze. Deve essere utilizzato solo in caso di emergenza ed è soggetto a revisione post-audit. Di conseguenza, btg richiede almeno un actor.
bypass: consente a utenti attendibili (ad esempio un amministratore) o applicazioni attendibili (ad esempio una pipeline di addestramento ML) di operare sullo store FHIR senza autorizzazione del consenso. Pertanto, bypass richiede almeno un actor e un env.

Applicazione dell'accesso e determinazione dell'accesso

In un ambiente sanitario complesso in cui coesistono più norme e consensi, l'applicazione dell'accesso e la determinazione delle autorizzazioni di accesso possono essere un compito arduo. I vari stakeholder potrebbero avere aspettative e requisiti diversi in merito all'utilizzo e alla divulgazione delle informazioni sui pazienti. Per orientarsi in questo scenario complesso è necessario comprendere chiaramente come viene applicato l'accesso e la logica sottostante che ne determina la concessione.

Norme sul consenso aggregato

Un consumatore di servizi sanitari, ad esempio un paziente o un amministratore, può avere più direttive di consenso contenute in una singola risorsa di consenso. Le risorse per il consenso possono contenere un mix di permit e deny provision.type direttive. Per impostazione predefinita, un utente può avere un numero qualsiasi di risorse di consenso, ma vengono applicate fino a 200 risorse di consenso active alla volta. Per ulteriori dettagli, consulta Vincoli e limitazioni.

Tutte le direttive relative al consenso vengono estratte dalle risorse per il consenso di un determinato utente per creare un insieme di regole di consenso aggregate.active

Proprietà della direttiva relativa al consenso

L'applicazione del consenso è limitata a un massimo di uno scopo e a un massimo di un ambiente per voce provision.

Le seguenti regole descrivono i principi per il controllo congiunto dell'accesso al consenso del paziente, alle norme dell'amministratore e alle norme a cascata dell'amministratore:

Per impostazione predefinita, l'accesso a tutte le risorse viene negato se non esiste un'istruzione corrispondente.
Se la risorsa richiesta non esiste, sono identificabili solo il tipo di risorsa e l'ID risorsa. Tutti gli altri criteri delle risorse e il proprietario delle risorse sono sconosciuti, si applica la seguente regola nell'ordine di elenco:
- Se il tipo di risorsa appartiene al compartimento del paziente o dell'incontro, l'accesso viene negato.
- In caso contrario:
  - Se esiste un criterio amministratore che nega i criteri di accesso indipendentemente dagli altri criteri delle risorse, l'accesso viene negato.
  - Se esiste una policy amministrativa che consente i criteri di accesso per i criteri di risorse identificabili (ovvero tipo di risorsa e ID risorsa), viene restituito un errore "Risorsa non trovata".
  - In tutti gli altri casi, l'accesso viene negato.
I criteri amministrativi sono i criteri predefiniti utilizzati per la corrispondenza delle risorse nello store.
Le risorse che non appartengono a nessun paziente sono determinate solo dalle policy di amministrazione.
Le risorse che si trovano nel comparto del paziente (STU3, R4) o nel comparto dell'incontro (STU3, R4) richiedono almeno un'istruzione di consenso con autorizzazione per paziente o norma amministrativa o norma amministrativa a cascata e nessuna istruzione di consenso di negazione da parte del paziente e della norma amministrativa e della norma amministrativa a cascata. Questa condizione è necessaria per tutti i pazienti indicati nelle risorse a cui il richiedente deve accedere.
- Alcune risorse potrebbero supportare più partecipanti pazienti. Ad esempio, Appuntamento fornisce un elenco di partecipanti che potrebbero essere pazienti. Tutti i pazienti indicati in queste risorse devono consentire l'accesso all'accessor utilizzando le direttive di consenso, altrimenti le risorse non vengono restituite. Se una risorsa dispone di un'autorizzazione da un criterio a cascata di incontro, in cui questo incontro fa riferimento a un paziente tramite il campo subject (STU3, R4), la risorsa è considerata autorizzata dal paziente.

Le regole descritte sono riassunte dal seguente pseudocodice:

Controllo dell'accesso congiunto

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

L'archivio FHIR controlla l'autorizzazione al consenso a livello di risorsa. Qualsiasi riferimento in una risorsa non viene risolto e propagato ai fini del controllo dell'accesso con consenso. Ad esempio, considera un paziente identificato da Patient/f001 che consente a un medico di accedere all'intera risorsa MedicationRequest, ma non alla risorsa Patient/f001 stessa a causa della privacy del paziente. In questo scenario, il professionista sanitario può visualizzare l'intera risorsa MedicationRequest, che include un campo subject che fa riferimento alla risorsa Patient/f001, ma non può visualizzare i contenuti della risorsa Patient/f001 anche, ad esempio, quando esegue una ricerca FHIR utilizzando _include.

Risoluzione dei conflitti

Sono possibili conflitti tra varie direttive permit e deny. Se due istruzioni in conflitto corrispondono a una risorsa, il conflitto viene risolto utilizzando il modello deny vince su permit.

Per l'applicazione del consenso vengono inclusi solo i consensi active.

Logica di applicazione dell'accesso alle risorse

Quando effettui una richiesta consapevole del consenso a un archivio FHIR, controllo dell'accesso avviene nel seguente ordine:

L'API Cloud Healthcare controlla le autorizzazioni per l' Google Cloud account di servizio (o il principal) configurato nel proxy. Se il service account dispone delle autorizzazioni IAM corrette per eseguire il metodo FHIR richiesto nell'archivio FHIR, la richiesta procede.
Se l'applicazione del consenso è abilitata nella configurazione dell'archivio FHIR e sono presenti le intestazioni HTTP sensibili al consenso, l'API Cloud Healthcare applica le norme di accesso con consenso per le risorse del compartimento del paziente. L'applicazione dei criteri di accesso al consenso si basa sugli ambiti di consenso forniti nella richiesta, in base alle direttive sul consenso acquisite dall'esecuzione più recente di ApplyConsents e ApplyAdminConsents.

Nota: se la configurazione del datastore FHIR definisce la gestione dell'intestazione del consenso come REQUIRED_ON_READ, il controllo dell'accesso al consenso viene applicato (e rifiutato) anche senza le intestazioni che tengono conto del consenso.

Quando effettui una richiesta consapevole del consenso a un archivio FHIR, si applicano le seguenti regole:

Fornisci almeno un ambito di consenso actor pertinente per le azioni di consenso intraprese.
Fornisci eventuali ambiti purpose e environment aggiuntivi pertinenti per le azioni di consenso intraprese.
Se il numero di voci dell'ambito del consenso supera i limiti supportati, viene restituito un errore.
Se chiami un metodo che accede a più risorse (ad esempio, il metodo fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle o fhir.search), l'applicazione del consenso si applica a ogni singola risorsa. Tuttavia, esiste una sottile differenza tra questi metodi di accesso a più risorse:
- La lettura di più risorse da parte di fhir.executeBundle riceve il messaggio "Accesso al consenso negato o la risorsa a cui si accede non esiste" per la singola risorsa senza autorizzazioni di consenso (vedi gli esempi in Recuperare risorse FHIR con ambito di consenso).
- fhir.search ignora le risorse senza autorizzazioni di consenso e non restituisce l'errore di accesso al consenso negato, anche per la ricerca per _id (vedi gli esempi nella Ricerca di risorse FHIR con ambito di consenso).
- fhir.Patient-everything e fhir.Encounter-everything si comportano in modo simile a fhir.search, tranne per il fatto che restituiscono "Accesso al consenso negato o la risorsa a cui si accede non esiste" se il chiamante non dispone dell'autorizzazione di consenso per la risorsa Paziente o Incontro richiesta, rispettivamente.

Una direttiva per il consenso ha al massimo un actor, al massimo un purpose e al massimo un environment, mentre l'ambito del consenso può avere più di uno di ciascuno. Alcune direttive per il consenso non specificano tutte e tre le proprietà di accesso, nel qual caso qualsiasi valore della proprietà dell'ambito del consenso può corrispondere a seconda delle regole di risoluzione dei conflitti. Di conseguenza, un ambito di consenso potrebbe corrispondere a più di una direttiva per il consenso.

Se l'ambito del consenso di una richiesta include due o più voci dello stesso tipo di ambito del consenso (actor, purpose o environment), l'ambito del consenso potrebbe corrispondere a più direttive per il consenso. Alcune direttive per il consenso non specificano un purpose o un environment. Pertanto, l'ambito del consenso deve essere corrispondere anche alle direttive per il consenso che non specificano questi tipi di ambito.

Ad esempio, se imposti l'ambito del consenso su actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc, la corrispondenza viene stabilita con una delle seguenti direttive permit o deny per il consenso:

actor/Practitioner/123 purp/v3/TREAT env/App/abc
actor/Practitioner/123 purp/v3/TREAT
actor/Practitioner/123 env/App/abc
actor/Practitioner/123
actor/Group/999 purp/v3/TREAT env/App/abc
actor/Group/999 purp/v3/TREAT
actor/Group/999 env/App/abc
actor/Group/999

Passaggi successivi

Scopri come applicare l'accesso a un archivio FHIR.