Modello di dati di accesso FHIR e sistema di controllo

Panoramica del modello di dati

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

Le regole di accesso vengono espresse tramite le risorse per il consenso FHIR. Il Consenso FHIR è un tipo di Risorsa FHIR che catturi le scelte dei consumatori nel settore sanitario. Consente o nega un insieme di attori compiere azioni che interessano il consumatore per uno scopo specifico da un ambiente specificato in un determinato periodo di tempo. Ad esempio, un consumatore potrebbe essere un paziente sanitario, chiunque agisca per conto di un paziente sanitario o altro individuo che stipula un contratto per il consenso.

Le azioni registrate in un consenso FHIR possono essere ampie e riguardare più di solo i dati della cartella clinica elettronica del consumatore (EHR), tuttavia per il gli scopi del consenso all'interno dell'API Cloud Healthcare, l'attenzione è focalizzata 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 per il consenso ha un stato che indica lo stato attuale del consenso. Sebbene un datastore FHIR possa contengono molti consensi in stati diversi, solo l'API Cloud Healthcare applica in modo forzato i consensi in stato attivo. Consensi in qualsiasi altro stato non hanno alcun effetto sull'applicazione delle norme. Se il consenso viene concesso per conto di una paziente, il consenso 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 che utilizza Consent.patient (STU3, R4) e associa tutti i dati definiti dal compartimento del paziente (STU3, R4).

  • Criterio di amministrazione: non è associato ad alcun paziente e deve avere un l'URL dell'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 di amministrazione definisce il valore predefinito per tutte le risorse di associazione nello store.

  • Criterio a cascata amministrativo: un tipo di criterio di amministrazione che richiede l'URL dell'estensione https://g.co/fhir/medicalrecords/CascadingPolicy e l'URL dell'estensione dei criteri per gli amministratori. Puoi associare questo tipo di criterio a un compartimento di che soddisfano i criteri delle risorse. Ha il valore seguenti:

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.

Le istruzioni per il consenso sono istruzioni codificate all'interno di un consenso FHIR che Consentire o negare l'accesso ai dati a una persona giuridica autorizzata, come un concesso o un accessor. Un singolo consenso FHIR può codificare più istruzioni di consenso. Ciascuna fornisce quanto segue:

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

  • Azione: le autorizzazioni contemplate da questa direttiva. Solo access è supportato per fornire accesso di sola lettura.

  • Criteri per gli accessi. Un insieme di attributi che identificano il richiedente API coperto dalla direttiva.

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

Criteri della funzione 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. Per applicare un'istruzione, deve esistere una corrispondenza esatta sensibile alle maiuscole sulla funzione di accesso nell'ambito della determinazione dell'accesso offerta dal server FHIR.

Queste proprietà vengono codificate come segue:

  • Attore: rappresenta un ruolo individuale, di gruppo o di accesso che identifica la funzione di accesso o una sua caratteristica.

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

  • Ambiente: rappresenta un identificatore astratto che descrive i dell'ambiente o delle condizioni in cui agisce la funzione di accesso.

Ad esempio, una funzione di accesso può essere rappresentata dalle seguenti proprietà:

  • Attore: Practitioner/123

  • Scopo: ETREAT o accesso per finalità di trattamento di emergenza

  • Ambiente: Application/abc

In questo esempio, queste proprietà rappresentano un medico che accede ai dati quando Eseguire 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 come parte del risorsa per il consenso:

  • Tipo di risorsa (STU3, R4): rappresenta il tipo a cui si vincolano le norme relative al consenso, ad esempio Encounter, Observation o Immunization.

  • ID risorsa (STU3, R4): rappresenta l'ID a cui si associano le norme relative al consenso.

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

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

  • Etichetta di sicurezza: rappresenta le etichette di sicurezza che definiscono le risorse interessate come identificato nel campo meta.security (STU3, R4). Sono supportati i seguenti sistemi di codici:

    • Riservatezza: valori gerarchici classificati da senza restrizioni al più limitato: U, L, M, N, R e V. Se un consenso consente un'etichetta di sicurezza di R allora si applica a tutte le risorse con l'etichetta R o inferiore. Se il consenso nega un'etichetta di sicurezza R, quindi si applica a tutte le risorse sono sensibili almeno quanto R.

    • ActCode: corrispondenza esatta delle stringhe nel codice di sicurezza.

Flusso di lavoro dell'accesso

authorization_flow

Questa figura illustra il percorso end-to-end di una richiesta a un archivio abilitato per il controllo 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).

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. I valori di queste proprietà deve essere una corrispondenza sensibile alle maiuscole con quelle fornite nell'ambito di un consenso affinché possano influisce sulla determinazione dell'accesso da parte dell'applicazione forzata.

Un accessore può avere più identificatori actor pertinenti per prendere una decisione sull'accesso. Analogamente, possono esserci più elementi purposes o environments che siano pertinenti in un particolare contesto di 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

Questo file rappresenta un infermiere o un medico noto come professionista 444 membro del gruppo 999, che rappresenta i professionisti di un dipartimento all'interno di un in uno specifico ospedale. Il medico è presente per offrire un trattamento regolare, e gestire eventuali cure di emergenza nell'ambito di queste azioni. La utilizza un'applicazione software chiamata abc.

L'ambito del consenso viene fornito come ambito Richiedi consenso parte della richiesta di dati di una funzione di accesso.

Ambito del consenso della richiesta

Le richieste FHIR utilizzano le intestazioni delle richieste HTTP FHIR per ricevere il consenso della funzione di accesso l'ambito di attività. 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. Potrebbe esserci più di una di queste proprietà che rappresenta un l'ambito del consenso della funzione di accesso in qualsiasi momento.

Le voci relative all'ambito del consenso sono definite come segue:

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

    • Practitioner
    • Group
    • Patient

    Ad esempio, se un archivio nel 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 fa parte di Scopo d'uso FHIR (v3) valore predefinito o la sua estensione. Esempi di value includono:

    • 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, che sono definiti come segue:

  • btg: "Infrangere i vetri" (o BTG) ti consente, in qualità di utente umano, di saltare il consenso in caso di emergenza. Deve essere utilizzata solo in caso di emergenza ed è obbligatoria la revisione post-audit. Di conseguenza, btg richiede almeno uno actor.
  • bypass: consente agli utenti attendibili (ad esempio un amministratore) o attendibili (ad esempio una pipeline di addestramento ML) per operare sul datastore FHIR senza l'autorizzazione del consenso. Di conseguenza, bypass richiede almeno un actor e uno env.

Applicazione forzata e determinazione dell'accesso

In un ambiente sanitario complesso in cui più norme e consensi coesistere, l'applicazione dell'accesso e la determinazione delle autorizzazioni di accesso può essere un'impresa scoraggiante. dell'attività. Vari stakeholder possono avere aspettative e requisiti diversi in merito all'utilizzo e alla divulgazione delle informazioni sui pazienti. Navigazione qui un panorama complesso richiede una chiara comprensione di come viene applicato l'accesso e la logica sottostante che regola la determinazione dell'accesso.

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. Risorse per il consenso può contenere una combinazione di permit e deny provision.type istruzioni. Per impostazione predefinita, un utente può avere un numero qualsiasi di risorse per il consenso, ma al massimo 200 active risorse per il consenso vengono applicate contemporaneamente. Consulta Vincoli e limitazioni per ulteriori dettagli.

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.

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

Le seguenti regole descrivono i principi per il controllo congiunto dell'accesso consenso dei pazienti, norme amministrative e norme a cascata per gli amministratori:

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

  • Se la risorsa richiesta non esiste, vengono indicati solo il tipo e l'ID risorsa identificabili. Tutti gli altri criteri della risorsa e il proprietario della risorsa sconosciuto, la seguente regola si applica all'ordine di elenco:

    • Se il tipo di risorsa appartiene al compartimento paziente receive-compartment: l'accesso è negato.

    • In caso contrario:

      • Se esiste un criterio di amministrazione che nega i criteri di accesso, indipendentemente degli altri criteri delle risorse, l'accesso viene negato.

      • Se esistono criteri amministrativi che consentono i criteri di accesso per il identificabili (ad es. tipo e ID risorsa), un "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 dall'amministratore criteri.

  • 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 per le norme di amministrazione gerarchica e nessuna istruzione di rifiuto del consenso dall'e norme di amministrazione del paziente e dalle 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 ai pazienti. Ad esempio, Appuntamento fornisce un elenco di partecipanti che potrebbero essere pazienti. Tutti i pazienti nominati come tali devono consentire l'accesso alla funzione di accesso usando le istruzioni di consenso altrimenti le risorse non verranno 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 dal seguente pseudo-codice:

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

Il datastore FHIR controlla l'autorizzazione di 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, considera un paziente identificato da Patient/f001 che consente una il medico può accedere all'intera risorsa MedicationRequest, ma non alla risorsa Patient/f001 risorsa stessa a causa della privacy del paziente. In questo scenario, Il medico può vedere l'intera risorsa MedicationRequest, che include un subject che fa riferimento alla risorsa Patient/f001, ma non è in grado di vedere contenuti della risorsa Patient/f001 anche, ad esempio, durante l'esecuzione a una ricerca FHIR utilizzando _include.

Risoluzione dei conflitti

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

Per l'applicazione del consenso sono inclusi solo active consensi.

Logica di applicazione dell'accesso alle risorse

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

  1. L'API Cloud Healthcare controlla le autorizzazioni in Google Cloud account di servizio (o l'entità) configurato nel proxy. Se il servizio l'account utente dispone delle autorizzazioni IAM corrette per eseguire il metodo FHIR richiesto sul datastore FHIR, la richiesta procede.

  2. Se l'applicazione del consenso è abilitata nel Configurazione del datastore FHIR e Sono presenti intestazioni HTTP con consenso, quindi l'API Cloud Healthcare applica i criteri di accesso al consenso per Patient Risorse del compartimento. L'applicazione dei criteri di accesso al consenso si basa sugli ambiti di consenso forniti nella richiesta, in base alle istruzioni 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 il consenso azioni intraprese.

  • Fornisci eventuali ambiti purpose e environment aggiuntivi pertinenti per le azioni di consenso intraprese.

  • Se il numero di voci relative all'ambito del consenso supera le limiti supportati, viene restituito un errore.

  • Se chiami un metodo che accede a più risorse (ad esempio, fhir.Patient-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 con 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 di consenso e non restituisce l'errore di accesso al consenso negato, anche per la ricerca per _id (vedi esempi nella Cerca nelle risorse FHIR con l'ambito del consenso).

    • fhir.Patient-everything si comporta in modo simile a fhir.search, tranne che restituisce il messaggio "Accesso al consenso negato o la risorsa a cui si accede non esistenti" se il chiamante non dispone dell'autorizzazione per il consenso sull'oggetto Risorsa per i pazienti.

Un'istruzione relativa al consenso ha al massimo un actor, un massimo di un purpose e al massimo un purpose un environment, mentre l'ambito del consenso può averne multipli 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 del consenso può corrispondere a più di un'istruzione 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), il consenso l'ambito potrebbe corrispondere a più istruzioni per il consenso. Alcune istruzioni relative al consenso non specificano un valore purpose o environment. Pertanto, l'ambito del consenso deve essere anche associato alle direttive sul consenso che non specificano questi tipi di ambito.

Ad esempio, se l'ambito del consenso viene impostato su actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc, corrisponde a uno qualsiasi dei seguenti elementi Istruzioni per il 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