Ajouter des en-têtes HTTP personnalisés pour auditer des journaux d’audit dans le Service FHIR
Important
L’API Azure pour FHIR sera mise hors service le 30 septembre 2026. Suivez les stratégies de migration pour passer au service FHIR® de Services de données de santé Azure d’ici à cette date. En raison de la mise hors service de l’API Azure pour FHIR, les nouveaux déploiements ne seront plus autorisés à compter du 1er avril 2025. Le service FHIR des Services de données de santé Azure est la version évoluée de l’API Azure pour FHIR qui permet aux clients de gérer les services FHIR, DICOM et MedTech avec des intégrations dans d’autres services Azure.
Dans l’API Azure Fast Healthcare Interoperability Resources (FHIR®), un utilisateur peut souhaiter inclure des informations supplémentaires dans les journaux, qui proviennent du système d’appel.
Par exemple, quand l’utilisateur de l’API est authentifié par un système externe, ce système transfère l’appel à l’API FHIR. Au niveau de la couche de l’API FHIR, les informations sur l’utilisateur d’origine sont perdues parce que l’appel a été transféré. Il peut s’avérer nécessaire de journaliser et conserver ces informations utilisateur à des fins d’audit ou d’administration. Le système d’appel peut fournir l’identité de l’utilisateur, l’emplacement de l’appelant ou d’autres informations nécessaires dans les en-têtes HTTP, qui sont transmises au moment du transfert de l’appel.
Vous pouvez utiliser des en-têtes personnalisés pour capturer plusieurs types d’informations. Par exemple :
- Informations d’identité ou d’autorisation
- Origine de l’appelant
- Organisation d’origine
- Détails sur le système client (dossier médical électronique, portail des patients)
Important
Sachez que les informations envoyées dans les en-têtes personnalisés sont stockées dans un système de journalisation interne de Microsoft pendant 30 jours après leur mise à disposition dans Azure Log Monitoring. Nous vous recommandons de chiffrer les informations avant de les ajouter à des en-têtes personnalisés. Il est déconseillé de transmettre des informations PHI dans les en-têtes de clients.
Vous devez utiliser la convention d’affectation de noms suivante pour vos en-têtes HTTP : X-MS-AZUREFHIR-AUDIT-<nom>.
Ces en-têtes HTTP sont inclus dans un jeu de propriétés qui est ajouté au journal. Par exemple :
- X-MS-AZUREFHIR-AUDIT-USERID : 1234
- X-MS-AZUREFHIR-AUDIT-USERLOCATION : XXXX
- X-MS-AZUREFHIR-AUDIT-XYZ : 1234
Ces informations sont ensuite sérialisées en JSON quand elles sont ajoutées à la colonne de propriétés du journal. Par exemple :
{ "X-MS-AZUREFHIR-AUDIT-USERID" : "1234",
"X-MS-AZUREFHIR-AUDIT-USERLOCATION" : "XXXX",
"X-MS-AZUREFHIR-AUDIT-XYZ" : "1234" }
Comme pour tout en-tête HTTP, il est possible de répéter le même nom d’en-tête avec des valeurs différentes. Par exemple :
- X-MS-AZUREFHIR-AUDIT-USERLOCATION : HospitalA
- X-MS-AZUREFHIR-AUDIT-USERLOCATION : Emergency
Une fois ajoutées au journal, les valeurs sont combinées à l’aide d’une liste séparée par des virgules. Par exemple :
{ "X-MS-AZUREFHIR-AUDIT-USERLOCATION" : "HospitalA, Emergency" }
Vous pouvez ajouter au maximum 10 en-têtes uniques (les répétitions d’un même en-tête avec des valeurs différentes comptent pour un). Au total, la longueur maximale de la valeur d’un en-tête est de 2 048 caractères.
Si vous utilisez la bibliothèque d’API du client C# Firefly, le code se présente comme suit :
FhirClient client;
client = new FhirClient(serverUrl);
client.OnBeforeRequest += (object sender, BeforeRequestEventArgs e) =>
{
// Add custom headers to be added to the logs
e.RawRequest.Headers.Add("X-MS-AZUREFHIR-AUDIT-UserLocation", "HospitalA");
};
client.Get("Patient");
Étapes suivantes
Dans cet article, vous avez découvert comment ajouter des données à des journaux d’audit en utilisant des en-têtes personnalisés dans l’API Azure pour FHIR. Pour découvrir plus d’informations sur les paramètres de configuration de l’API Azure pour FHIR, consultez
FHIR® est une marque déposée de HL7 utilisé avec l’autorisation de HL7.