Format des données de dossier médical personnel

Les données des dossiers médicaux personnels sont stockées au format HL7 FHIR.

Le PHR est compatible avec les versions suivantes de FHIR (Fast Healthcare Interoperability Resources) :

Types de ressources médicales

FHIR est composé d'un ensemble de composants modulaires appelés ressources. L'ensemble de ressources FHIR et des catégories correspondantes compatibles est basé approximativement sur les sections du résumé international du patient.

Ces ressources sont mappées sur des catégories de données dans Santé Connect, appelées "types de ressources médicales" dans l'API. Les ressources d'observation sont mappées en fonction de contenus tels que les codes LOINC (Logical Observation Identifiers Names and Codes) et les catégories FHIR.

Les observations qui n'appartiennent à aucune de ces catégories ne sont pas écrites dans Santé Connect.

Tableau 1: Types de ressources médicales Santé Connect
Type de ressource médicale Santé Connect Ressource(s) FHIR
Allergies AllergyIntolerance
Problèmes de santé Condition
Laboratoire

Observation

  • Catégorie FHIR laboratory
Traitements Medication, MedicationRequest, MedicationStatement
Informations personnelles Patient
Informations sur le praticien Praticien, PractitionerRole
Grossesse

Observation

  • Codes LOINC pour la grossesse
Opérations Procédure
Antécédents sociaux

Observation

  • Codes LOINC pour les antécédents sociaux
  • Catégorie FHIR social-history
Vaccins Immunisation
Consultations Rencontre, Lieu, Organisation
Signes vitaux

Observation

  • Codes LOINC des signes vitaux
  • Catégorie FHIR vital-signs

Ressources pour les patients

Pour le moment, Santé Connect est conçu pour stocker les données de dossier médical personnel d'une seule personne. Par conséquent, toutes les ressources FHIR écrites doivent appartenir à la même personne.

Il n'est pas rare que plusieurs ressources Patient FHIR existent dans un système pour une seule personne. Il est préférable que les applications concilient les données et écrivent une seule ressource Patient dans Santé Connect. Toutefois, cette règle n'est pas appliquée pour tenir compte des différentes structures organisationnelles qui peuvent exister.

Validation des données

Les API PHR acceptent les ressources FHIR valides des versions compatibles, et Health Connect effectue une validation pour confirmer que la spécification FHIR de chaque version compatible est respectée.

Les vérifications de validation marquées comme Bientôt disponibles ne sont pas encore appliquées, mais le seront dans une prochaine version. Nous vous recommandons de développer en fonction de toutes les vérifications de validation listées afin de maintenir la compatibilité avec les futures versions.

Tableau 2: Validation des données FHIR par Santé Connect
Niveau Vérification de la validation
JSON valide Les données sont conformes au format JSON.
FHIR compatible

La version FHIR déclarée par l'application d'écriture est prise en charge. Santé Connect est compatible avec les versions FHIR suivantes:

  • 4.0.1
  • 4.3.0
FHIR compatible

Le type de ressource FHIR enregistré dans l'instance de ressource est accepté. Santé Connect prend en charge les types de ressources FHIR suivants:

  • AllergyIntolerance
  • Condition
  • Encounter
  • Immunisation
  • Position
  • Médicaments
  • MedicationRequest
  • MedicationStatement
  • Observation
  • Organisation
  • Patient
  • Praticien
  • PractitionerRole
  • Procédure
ID de ressource unique La ressource comporte un champ d'ID dont la valeur répond aux exigences concernant les expressions régulières.
ID de ressource unique La ressource ne partage pas d'ID avec une autre ressource FHIR du même type de ressource provenant de la même MedicalDataSource.
Règles métier N'inclut pas de ressource FHIR incluse. Les ressources contenues sont des ressources FHIR imbriquées dans une ressource "parente". Elles sont utilisées lorsque la ressource parente doit référencer une autre ressource, mais que le système ne dispose pas d'informations suffisantes pour la créer en tant que ressource autonome ayant une existence indépendante.
FHIR de base valide Les champs de niveau supérieur du fichier JSON FHIR existent dans la spécification FHIR pour le type de ressource donné.
FHIR de base valide Les champs de premier niveau ne contiennent pas de valeurs nulles JSON.
FHIR de base valide Tous les champs obligatoires de premier niveau sont présents.
FHIR de base valide Les champs de premier niveau définis comme des éléments répétitifs dans FHIR ont un type de données JSON array.
FHIR de base valide Les champs de premier niveau (y compris les éléments des array JSON) définis comme des types complexes dans FHIR ont un type de données object JSON.
FHIR de base valide Les champs de niveau supérieur (y compris les éléments des array JSON) définis comme des types primitifs dans FHIR ont le type de données JSON approprié.
Type de données FHIR Type de données JSON
entier, unsignedInt, positiveInt, décimal nombre
booléen booléen
instant, time, date, dateTime, string, code, markdown, id uri, url, oid, uuid, canonical, integer64, base64Binary nombre
Bientôt disponible
FHIR de base valide Les champs de niveau supérieur définis comme des types primitifs dans FHIR répondent aux exigences des expressions régulières. Bientôt disponible
FHIR de base valide Des extensions aux types primitifs existent dans la spécification FHIR et ont un type de données JSON object.
FHIR de base valide Un seul champ est enregistré pour les champs de choix (fieldname[x]).Par exemple, effectiveDateTime et effectivePeriod ne peuvent pas être tous deux présents dans la même instance de ressource.
FHIR de base valide Les types de données complexes contiennent des champs et des types de données qui correspondent à la spécification FHIR. Bientôt disponible
FHIR de base valide Les éléments de la colonne vertébrale (et les éléments des types complexes) contiennent des champs et des types de données qui correspondent à la spécification FHIR. Bientôt disponible
FHIR de base valide Les champs value[x] de l'élément Extensions sont un type valide et contiennent du contenu en fonction de ce type de données. Les éléments d'extension peuvent être inclus dans n'importe quelle ressource pour représenter des informations supplémentaires qui ne font pas partie de la spécification de base. Ils contiennent un champ url qui fait référence à la définition de l'extension, et un champ value[x] qui contient la valeur de l'extension. value[x] doit provenir de la liste définie des types de données acceptés. Bientôt disponible

Données FHIR transformées

Certaines applications transforment les données FHIR pour répondre à leurs propres exigences. Exemple :

  • Fusionner des données provenant de différentes sources (généralement des API FHIR)
  • Mappage des codes sur des terminologies globales (par exemple, SNOMED, LOINC, ICD) et normalisation des unités.
  • Consolidation et déduplication des données
  • Résolution des problèmes de mise en forme ou d'autres problèmes de qualité des données
  • Filtrage des enregistrements en fonction de règles métier spécifiques à l'application

Les données FHIR non transformées et transformées peuvent être écrites dans Santé Connect, à condition qu'elles respectent la spécification FHIR R4. Nous vous recommandons d'écrire des données transformées dans la mesure du possible. Gardez toutefois à l'esprit les points suivants:

  • Les applications aux cas d'utilisation restreints peuvent filtrer un nombre important d'enregistrements à partir desquels d'autres applications de l'écosystème pourraient créer de la valeur pour l'utilisateur. Dans de telles situations, il peut être utile d'écrire le FHIR non transformé, qui est plus complet. Toutefois, veillez à informer les utilisateurs que cet ensemble de données plus large est partagé.
  • Si vous fusionnez des données provenant de différentes sources, vous pouvez écrire des données dans un seul MedicalDataSource dans Santé Connect. Vous devez également attribuer un nouvel ID à chaque ressource pour éviter les conflits et mettre à jour les références de ressources pour qu'elles pointent vers les nouveaux ID.
  • Fusionner des données provenant de plusieurs sources dans un seul MedicalDataSource peut masquer l'origine des données. Comme il est souvent utile pour les consommateurs de données de comprendre la provenance des données, nous vous recommandons de renseigner le champ meta.source pour chaque ressource avec la source d'origine de l'enregistrement (généralement une URL de base FHIR).