Modello dei dati di accesso FHIR e sistema di controllo

Panoramica del modello di dati

Il modello dei dati per controllo dell'accesso è rappresentato dalle risorse per il consenso. Definiscono le regole da applicare e i dati a cui applicarle.

Consenso FHIR

Le regole di accesso vengono espresse tramite le risorse FHIR Consent. Consenso FHIR è 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 determinato periodo di tempo. Ad esempio, un consumatore può essere un paziente, chiunque agisca per conto di un paziente o un'altra persona che stipula un contratto per il consenso.

Le azioni registrate in un consenso FHIR possono essere ampie e riguardare più di quanto solo i dati della cartella clinica elettronica (EHR) del consumatore, tuttavia ai fini del consenso all'interno dell'API Cloud Healthcare, l'attenzione è rivolta alle azioni relative all'accesso ai dati e l'applicazione di queste azioni è limitata alla lettura dei dati FHIR da un archivio FHIR.

Una risorsa Consenso ha un stato che indica lo stato attuale del consenso. Sebbene un archivio 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 fornito per conto di un paziente, viene registrato come concesso da un artista.

Tipo di criterio

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

• Consenso del paziente: è associato a un paziente utilizzando Consent.patient (STU3, R4) e lega tutti i dati definiti dal comparto del paziente (STU3, R4).

• Norme di amministrazione: non è associato a nessun 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 nello spazio dei nomi specificato dai criteri delle risorse. Il criterio amministratore imposta il criterio predefinito per tutte le risorse di associazione nel negozio.

• Norma di applicazione gerarchica: un tipo di norma di amministrazione che richiede l'URL dell'estensione https://g.co/fhir/medicalrecords/CascadingPolicy e l'URL dell'estensione della norma di amministrazione. Puoi associare questo tipo di criterio a un compartimento di risorse che corrispondono ai criteri delle risorse. Ha le seguenti limitazioni:

  • Supporta solo il paziente (STU3, R4) o l'incontro (STU3, R4) come base del comparto.
  • Il datastore FHIR in cui viene applicato il criterio deve avere disableReferentialIntegrity impostato su false.

Puoi combinare i tipi di criteri 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.

Direttiva sul consenso

Le direttive per il 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 concedente o un accessore. Un singolo consenso FHIR può codificare più direttive per il consenso. Ogni direttiva fornisce quanto segue:

• Tipo di applicazione: un'istruzione permit o deny.

• Azione: 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 l'autore della richiesta dell'API coperto dalla direttiva.

• Criteri delle risorse: un insieme di attributi che identificano le risorse coperte dalla direttiva.

Criteri di accesso

L'API Cloud Healthcare supporta tre proprietà di un accessore per l'utilizzo all'interno di una direttiva di consenso e per la corrispondenza con un accessore che effettua una richiesta di accesso ai dati. Deve essere presente una corrispondenza esatta sensibile alle maiuscole per applicare una direttiva all'accessore nell'ambito della determinazione dell'accesso offerta dal server FHIR.

Queste proprietà vengono codificate come segue:

• Attore: rappresenta un individuo, un gruppo o un ruolo di accesso che identifica l'accessore o una caratteristica dell'accessore.

• Finalità: rappresenta l'intenzione di utilizzo dei dati.

• Ambiente: rappresenta un identificatore astratto che descrive l'ambiente o le condizioni in cui opera l'accessore.

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

• Attore: Practitioner/123

• Finalità: ETREAT o accesso a fini di cura di emergenza

• Ambiente: Application/abc

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

provision.actor e provision.purpose sono definiti nell'ambito 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 è necessario specificare sempre un purpose o un environment. Ad esempio, se non viene specificato alcun environment nella direttiva del consenso, la direttiva corrisponde a qualsiasi environment non coperto già da altre direttive del consenso.

Criteri delle risorse

L'API Cloud Healthcare supporta i seguenti elementi all'interno della risorsa consent:

• Tipo di risorsa (STU3, R4): rappresenta il tipo a cui è associato il criterio di consenso, ad esempio Encounter, Observation o Immunization.

• ID risorsa (STU3, R4): rappresenta l'ID a cui è associato il criterio per il consenso.

• Origine dati: rappresenta l'origine della risorsa identificata dalla risorsa meta.source (disponibile solo in R4).

• Tag dati: rappresenta l'etichetta personalizzata della risorsa come descritto nella risorsa meta.tag (STU3, R4).

• Etichetta di 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 codici:

  • Riservatezza: valori gerarchici classificati da nessuna limitazione a massima limitazione: U, L, M, N, R, V. Se un consenso consente un'etichetta di sicurezza R, si applica a tutte le risorse etichettate come R o meno. 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

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

Ambito del consenso

Quando effettua una richiesta di accesso ai dati, un accessor opera in un determinato ambito del consenso che rappresenta le sue proprietà actor, purpose e environment relative a qualsiasi richiesta HTTP FHIR. Affinché i valori di queste proprietà influiscano sulla determinazione dell'accesso da parte dell'applicazione, devono essere una corrispondenza sensibile alle maiuscole con quelli forniti in un consenso.

Un accessore può avere più identificatori actor pertinenti per prendere una decisione sull'accesso. Allo stesso modo, possono essere presenti più purposes o environments pertinenti in un determinato contesto del consenso. Pertanto, tutte le proprietà di accesso pertinenti devono essere fornite nell'ambito di una richiesta HTTP FHIR per rappresentare correttamente l'accessore 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 444 che fa parte del gruppo 999, che rappresenta i professionisti di un reparto all'interno di un ospedale specifico. Il professionista è lì per fornire cure regolari, ma eventualmente anche per occuparsi di cure di emergenza nell'ambito di queste azioni. Il professionista utilizza un'applicazione software chiamata abc.

L'ambito del consenso viene fornito come Ambito del consenso della richiesta nell'ambito della richiesta di dati di un accessor.

Richiedere l'ambito del consenso

Le richieste FHIR utilizzano le intestazioni di richiesta HTTP FHIR per ricevere l'ambito del consenso dell'accessore. Questo ambito del consenso contiene un insieme di valori actor, purpose e environment per riflettere l'identità, le qualifiche, l'intenzione d'uso e le limitazioni ambientali attuali dell'utente che accede. In un determinato momento, possono essere presenti più di una di queste proprietà che rappresentano l'ambito del consenso di un accessore.

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

• actor/{type}/{ID}: una proprietà actor in cui la risorsa type viene fornita insieme a ID. Ecco alcuni esempi di type:

  • Practitioner
  • Group
  • Patient

  Ad esempio, se un negozio del 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 elemento del set di valori Finalità d'uso FHIR (v3) o della relativa estensione. Ecco alcuni esempi di value:

  • TREAT
  • ETREAT
  • HRESCH

• env/{type}/{value}: una proprietà environment in cui type e value sono stringhe personalizzate senza tassonomia predefinita. Ecco alcuni esempi di type e value:

  • App/my_app_1
  • Net/VPN

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

• btg: la funzionalità "Rompi il vetro" (o RGV) ti consente, in qualità di utente umano, di saltare i controlli di consenso in caso di emergenze. Deve essere utilizzata solo in caso di emergenza ed è obbligatoria la revisione post-audit. Di conseguenza, btg richiede almeno un actor.
• bypass: consente agli utenti attendibili (ad esempio un amministratore) o alle applicazioni attendibili (ad esempio una pipeline di addestramento ML) di operare nello spazio FHIR senza autorizzazione al consenso. Di conseguenza, bypass richiede almeno un actor e un env.

Applicazione e determinazione degli accessi

In un ambiente sanitario complesso in cui convivono più criteri e consensi, l'applicazione dell'accesso e la determinazione delle autorizzazioni di accesso possono essere un compito arduo. Vari stakeholder potrebbero avere aspettative e requisiti diversi in merito all'uso e alla divulgazione delle informazioni sui pazienti. Per orientarsi in questo panorama intricato è necessario comprendere chiaramente come viene applicato l'accesso e la logica di base che regola la determinazione dell'accesso.

Norme relative al consenso aggregato

Un consumatore di servizi sanitari, ad esempio un paziente o un amministratore, può avere più direttive per il consenso all'interno di una singola risorsa per il consenso. Le risorse per il consenso possono contenere una combinazione di direttive permit e deny provision.type. Per impostazione predefinita, un utente può avere un numero qualsiasi di risorse di consenso, ma al massimo 200 active risorse di consenso vengono applicate contemporaneamente. Per maggiori dettagli, consulta Restrizioni e limitazioni.

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

Proprietà delle direttive per il consenso

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

Le seguenti regole descrivono i principi per il controllo dell'accesso dell'accesso congiunto del consenso del paziente, del criterio amministrativo e del criterio di applicazione gerarchica dell'amministratore:

• Per impostazione predefinita, a tutte le risorse viene negato l'accesso se non è presente una direttiva corrispondente.

• Se la risorsa richiesta non esiste, sono identificabili solo il tipo di risorsa e l'ID risorsa. Tutti gli altri criteri della risorsa e il proprietario della risorsa sono sconosciuti. Nell'ordine della scheda si applica la seguente regola:

  • Se il tipo di risorsa appartiene al comparto paziente o al comparto incontro: l'accesso viene negato.

  • In caso contrario:

    • Se esiste un criterio amministrativo che nega i criteri di accesso indipendentemente dagli altri criteri della risorsa, l'accesso viene negato.

    • Se esiste un criterio di amministrazione che consente i criteri di accesso per i criteri di risorsa identificabili (ad es. tipo di risorsa e ID risorsa), viene restituito un errore "Risorsa non trovata".

    • In tutti gli altri casi, l'accesso viene negato.

• I criteri di amministrazione sono i criteri predefiniti utilizzati per la corrispondenza delle risorse nel negozio.

• Le risorse che non appartengono a nessun paziente sono determinate solo dai criteri di amministrazione.

• Le risorse nel compartimento del paziente (STU3, R4) o nel compartimento degli incontri (STU3, R4) richiedono almeno un'istruzione di consenso permessa per le norme di o amministrazione del paziente o delle norme di amministrazione gerarchica e nessuna istruzione di rifiuto del consenso dall'e norme di amministrazione del paziente e delle norme di amministrazione gerarchica. Questa condizione è necessaria per tutti i pazienti indicati nelle risorse a cui deve accedere la persona che effettua la richiesta.

  • Alcune risorse potrebbero supportare più partecipanti tra i 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'accessore utilizzando le direttive per il consenso, altrimenti le risorse non vengono restituite. Se una risorsa dispone di un'autorizzazione proveniente da un criterio di applicazione in cascata degli incontri, in cui questo incontro fa riferimento a un paziente tramite il campo subject (STU3, R4), la risorsa è considerata consentita dal paziente.

Le regole descritte sono riassunte nel seguente pseudocodice:

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 per il consenso a livello di risorsa. Qualsiasi riferimento in una risorsa non viene risolto e applicato in cascata ai fini del controllo dell'accesso al consenso. Ad esempio, prendiamo in considerazione un paziente identificato da Patient/f001 che consente a un fornitore di servizi sanitari di accedere all'intera risorsa MedicationRequest, ma non alla risorsa Patient/f001 stessa per motivi di privacy del paziente. In questo scenario, il professionista può vedere l'intera risorsa MedicationRequest che include un campo subject che fa riferimento alla risorsa Patient/f001, ma non può vedere i contenuti della risorsa Patient/f001, ad esempio quando esegue una ricerca FHIR utilizzando _include.

Risoluzione dei conflitti

Sono possibili conflitti tra varie istruzioni permit e deny. Se due direttive 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 viene effettuata una richiesta che tiene conto del consenso a un archivio FHIR, controllo dell'accesso avviene nel seguente ordine:

1. L'API Cloud Healthcare controlla le autorizzazioni per l'account di servizio Google Cloud (o il principale) configurato nel proxy. Se il service account dispone delle autorizzazioni IAM corrette per eseguire il metodo FHIR richiesto nel datastore FHIR, la richiesta viene eseguita.

2. Se l'applicazione del consenso è abilitata nella configurazione dell'archivio FHIR e sono presenti le intestazioni HTTP che rispettano il consenso, l'API Cloud Healthcare applica i criteri di accesso al consenso per le risorse Patient Compartment. L'applicazione dei criteri di accesso al consenso si basa sui campi di applicazione del consenso forniti nella richiesta, in base alle direttive sul consenso acquisite dall'esecuzione più recente di ApplyConsents e ApplyAdminConsents.

Quando viene effettuata una richiesta che tiene conto del consenso a un archivio FHIR, si applicano le seguenti regole:

• Fornisci almeno un ambito del 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:

  • fhir.executeBundle che legge più risorse riceve il messaggio "Accesso al consenso denied o la risorsa a cui si accede non esiste" per la singola risorsa senza autorizzazioni per il consenso (vedi gli esempi in Ottenere le risorse FHIR con l'ambito del consenso).

  • fhir.search ignora le risorse senza autorizzazioni per il consenso e non restituisce l'errore di accesso al consenso negato, anche per la ricerca per _id (vedi gli esempi in Ricerca di risorse FHIR con ambito del consenso).

  • fhir.Patient-everything e fhir.Encounter-everything si comportano in modo simile a fhir.search, tranne per il fatto che restituiscono "Consenso di accesso negato o la risorsa a cui si accede non esiste" se il chiamante non dispone dell'autorizzazione al consenso per la risorsa Paziente o Incontro richiesta, rispettivamente.

Determinazione dell'accesso ai dati per il consenso

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 ciascuno. Alcune direttive per il consenso non specificano tutte e tre le proprietà di accesso, nel qual caso qualsiasi valore della proprietà ambito del consenso può corrispondere a seconda delle regole di risoluzione dei conflitti. Di conseguenza, un ambito del consenso può corrispondere a più di una direttiva sul 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 sul consenso. Alcune direttive per il consenso non specificano un purpose o un environment. Pertanto, l'ambito del consenso deve essere anche associato alle direttive sul consenso che non specificano questi tipi di ambito.

Ad esempio, l'impostazione dell'ambito del consenso su actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc corrisponde a una delle seguenti direttive sul consenso permit o deny:

• 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 in un archivio FHIR