Formato dei dati delle cartelle cliniche elettroniche

I dati dei record sanitari personali (PHR) vengono memorizzati nel formato HL7 FHIR.

La PHR supporta le seguenti versioni di Fast Healthcare Interoperable Resources (FHIR):

Tipi di risorse mediche

FHIR è costituito da un insieme di componenti modulari chiamati risorse. L'insieme supportato di risorse FHIR e le categorie corrispondenti si basano approssimativamente sulle sezioni del riepilogo del paziente internazionale.

Queste risorse sono mappate alle categorie di dati in Connessione Salute, denominate tipi di risorse mediche nell'API. Le risorse di osservazione vengono mappate in base a contenuti come i codici LOINC (Logical Observation Identifiers Names and Codes) e le categorie FHIR.

Le osservazioni che non appartengono a nessuna di queste categorie non vengono scritte in Connessione Salute.

Tabella 1: tipi di risorse mediche di Connessione Salute
Tipo di risorsa medica di Connessione Salute Risorse FHIR
Allergie AllergyIntolerance
Patologie Condizione
Laboratorio

Osservazione

  • Categoria FHIR laboratory
Farmaci Medication, MedicationRequest, MedicationStatement
Dettagli personali Paziente
Dettagli del medico Practitioner, PractitionerRole
Gravidanza

Osservazione

  • Codici LOINC per la gravidanza
Interventi Procedura
Stile di vita

Osservazione

  • Codici LOINC per la cronologia social
  • Categoria FHIR social-history
Vaccini Immunizzazione
Visite Incontro, Località, Organizzazione
Parametri vitali

Osservazione

  • Codici LOINC per i parametri vitali
  • Categoria FHIR vital-signs

Risorse per i pazienti

Al momento, Connessione Salute è progettata per archiviare i dati dei CRS solo per un singolo individuo. Pertanto, tutte le risorse FHIR scritte devono appartenere alla stessa persona.

Non è raro che in un sistema esistano più risorse paziente FHIR per un singolo individuo. È preferibile che le app riconcilino i dati e scrivano una singola risorsa paziente in Connessione Salute. Tuttavia, questo non viene applicato per adattarsi alle diverse strutture organizzative esistenti.

Convalida dei dati

Le API PHR accettano risorse FHIR valide dalle versioni supportate e Health Connect esegue alcune convalide per verificare che venga rispettata la specifica FHIR per ogni versione supportata.

I controlli di convalida contrassegnati come Disponibile a breve non sono ancora applicati, ma lo saranno in una release futura. Ti consigliamo di sviluppare in base a tutti i controlli di convalida elencati per mantenere la compatibilità con le release future.

Tabella 2: convalida dei dati FHIR da parte di Connessione Salute
Livello Controllo di convalida
JSON valido I dati sono conformi al formato JSON.
FHIR supportato

La versione FHIR dichiarata dall'applicazione di scrittura è supportata. Connessione Salute supporta le seguenti versioni FHIR:

  • 4.0.1
  • 4.3.0
FHIR supportato

Il tipo di risorsa FHIR registrato nell'istanza della risorsa è supportato. Connessione Salute supporta i seguenti tipi di risorse FHIR:

  • AllergyIntolerance
  • Condizione
  • Encounter
  • Immunizzazione
  • Posizione
  • Farmaci
  • MedicationRequest
  • DichiarazioneMedici
  • Osservazione
  • Organizzazione
  • Paziente
  • Professionista
  • PractitionerRole
  • Procedura
ID risorsa univoco La risorsa ha un campo ID con un valore che soddisfa i requisiti delle espressioni regolari.
ID risorsa univoco La risorsa non condivide un ID con un'altra risorsa FHIR dello stesso tipo di risorsa dello stesso MedicalDataSource.
Regole aziendali Non include una risorsa FHIR contenuta. Le risorse contenute sono risorse FHIR nidificate all'interno di una risorsa "principale". Vengono utilizzati quando la risorsa principale deve fare riferimento a un'altra risorsa, ma il sistema non dispone di informazioni sufficienti per crearla come risorsa autonoma con esistenza indipendente.
FHIR di base valido I campi di primo livello nel JSON FHIR esistono nella specifica FHIR per il tipo di risorsa specificato.
FHIR di base valido I campi di primo livello non hanno valori null JSON.
FHIR di base valido Tutti i campi obbligatori di primo livello sono presenti.
FHIR di base valido I campi di primo livello definiti come elementi ripetuti in FHIR hanno un tipo di dati JSON array.
FHIR di base valido I campi di primo livello (inclusi gli elementi all'interno di array JSON) definiti come tipi complessi in FHIR hanno un tipo di dati object JSON.
FHIR di base valido I campi di primo livello (inclusi gli elementi all'interno dei array JSON) definiti come tipi primitivi in FHIR hanno il corretto tipo di dati JSON.
Tipo di dati FHIR Tipo di dati JSON
integer, unsignedInt, positiveInt, decimal numero
booleano booleano
istante, ora, data, dataOra, stringa, codice, markdown, uri ID, URL, oid, uuid, canonico, integer64, base64Binary numero
Disponibile a breve
FHIR di base valido I campi di primo livello definiti come tipi primitivi in FHIR devono soddisfare i requisiti delle espressioni regolari. Disponibile a breve
FHIR di base valido Le estensioni ai tipi primitivi esistono nella specifica FHIR e hanno un tipo di dati JSON object.
FHIR di base valido Non viene registrato più di un campo per campi di scelta (fieldname[x]).Ad esempio, effectiveDateTime e effectivePeriod non possono essere entrambi presenti nella stessa istanza della risorsa.
FHIR di base valido I tipi di dati complessi contengono campi e tipi di dati corrispondenti alla specifica FHIR. Disponibile a breve
FHIR di base valido Gli elementi principali (e gli elementi all'interno di tipi complessi) contengono campi e tipi di dati che corrispondono alla specifica FHIR. Disponibile a breve
FHIR di base valido I campi Elemento estensioni value[x] sono di un tipo valido e contengono contenuti in base a quel tipo di dati. Gli elementi di estensione possono essere inclusi in qualsiasi risorsa per rappresentare informazioni aggiuntive non incluse nella specifica di base. Contengono un campo url che rimanda alla definizione dell'estensione e un campo value[x] che contiene il valore dell'estensione. value[x] deve provenire dall'elenco impostato dei tipi di dati accettati. Disponibile a breve

Dati FHIR trasformati

Alcune app trasformano i dati FHIR per soddisfare i propri requisiti. Ad esempio:

  • Unisci i dati provenienti da origini diverse (in genere API FHIR).
  • Mappatura dei codici a terminologie globali (ad es. SNOMED, LOINC, ICD) e standardizzazione delle unità.
  • Consolidamento e deduplica dei dati.
  • Risolvere i problemi di formattazione o di altro tipo relativi alla qualità dei dati.
  • Filtrare i record in base a regole aziendali specifiche per l'app.

I dati FHIR non trasformati e trasformati possono essere scritti in Connessione Salute, a condizione che siano conformi alla specifica FHIR R4. Ti consigliamo di scrivere i dati trasformati, se possibile. Tuttavia, tieni presente le seguenti considerazioni:

  • Le app con casi d'uso limitati potrebbero filtrare un numero significativo di record da cui altre app dell'ecosistema potrebbero creare valore per gli utenti. In queste situazioni, può essere utile scrivere il codice FHIR non trasformato, che è più completo. Tuttavia, assicurati di informare gli utenti che questo set di dati più ampio viene condiviso.
  • Se unisci dati provenienti da origini diverse, puoi scrivere i dati in un unico MedicalDataSource in Connessione Salute. Devi anche assegnare un nuovo ID a ogni risorsa per evitare conflitti e aggiornare i riferimenti alle risorse in modo che indirizzino ai nuovi ID.
  • L'unione di dati provenienti da più origini in un unico MedicalDataSource può nasconderne l'origine. Poiché spesso è utile per i consumatori di dati comprendere la provenienza dei dati, consigliamo di compilare il campo meta.source per ogni risorsa con l'origine originale del record (in genere un URL base FHIR).