Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Fonctionnalités de transformation des données
Chaque fonctionnalité ci-dessous est documentée avec ce qu'elle est, comment elle fonctionne, les différences entre les sources C-CDA et les sources CSV, et quand l'utiliser.
Profils de transformation et gestion des versions
Un profil de transformation est la définition réutilisable de la façon dont un format source est converti en FHIR R4. Il contient la logique de conversion (modèles Velocity pour C-CDA, configuration de mappage YAML pour CSV) et est créé une seule fois et réutilisé dans toutes les banques de données et les tâches de transformation de votre compte. Séparer la définition (profil) de l'exécution (tâche) signifie que vous créez et testez une conversion une fois, puis que vous appliquez la même version publiée à un nombre quelconque de tâches.
Création d'un profil
Vous pouvez créer un profil de trois manières :
-
À partir d'un profil de départ ou de base : partez d'un profil fonctionnel plutôt que d'un profil vierge. En C-CDA effet, le profil de AWS démarrage est un AWS-defined profil prédéfini qui gère les formats de C-CDA documents courants dès le départ. Pour le format CSV, vous fournissez des exemples de fichiers dans Amazon S3 lors de la création du profil, puis vous appelez l'agent AI pour les analyser et générer une configuration de mappage YAML.
-
Par clonage : clonez n'importe quel profil existant comme point de départ pour en créer un nouveau.
-
À partir d'un mappage brut : fournissez directement des modèles Velocity (C-CDA) ou un mappage YAML (CSV). Il s'agit de la voie à suivre pour déployer des profils contrôlés par version via un CI/CD pipeline (voirCommencer à utiliser le SDK et AWS CLI).
Important
La création d'un profil CSV qui SampleData enregistre l'emplacement de l'échantillon mais n'exécute pas l'agent AI. Pour générer le mappage YAML, vous devez appeler UpdateProfileWithAgent après la création. L'agent analyse vos fichiers d'échantillons à ce stade et produit le profil de base.
Le cycle de vie des versions
Un profil peut comporter au plus un brouillon et jusqu'à 99 versions publiées :
-
Un nouveau profil commence comme un brouillon (version 0) : une copie de travail modifiable que vous pouvez modifier librement.
-
La publication du brouillon crée une version numérotée immuable (v1, v2, etc., jusqu'à la v99). Les versions publiées ne changent jamais.
-
Les tâches de transformation sont toujours exécutées sur la base de la dernière version publiée. Comme le brouillon est distinct, vous pouvez continuer à le modifier pendant que les tâches de production continuent de s'exécuter par rapport à la dernière version publiée : les modifications en cours n'affectent jamais les conversions en cours.
-
Un profil avec une version publiée et de nouvelles modifications inédites est dans un état de modification non publiée ; la version publiée reste active jusqu'à ce que vous publiiez à nouveau.
Comparaison et retour en arrière
Comme chaque version publiée est conservée, vous pouvez voir exactement comment la logique de conversion a évolué au cours de l'historique des versions. L'annulation ne supprime rien : elle crée une nouvelle version à partir d'un instantané précédent, de sorte que l'historique complet et la piste d'audit sont préservés.
Quand utiliser le contrôle de version
Publiez une version avant d'exécuter une tâche de production afin que celle-ci soit épinglée selon une logique révisée. Utilisez la fonction d'annulation lorsqu'une modification produit un résultat inattendu, et comparez pour confirmer ce qu'une modification a réellement modifié.
Agent IA de transformation des données
L'agent Data Transformation AI supprime l'effort manuel de création et de maintenance des mappages FHIR. Au lieu d'écrire la logique de conversion à la main, vous décrivez le résultat souhaité et l'agent produit ou met à jour la logique sous-jacente : modèles Velocity pour C-CDA, configuration de mappage YAML pour CSV. L'agent est intégré dans l'éditeur de profil du Console de gestion AWS et est également disponible via l' UpdateProfileWithAgent API et en tant qu'outil MCP. Vous pouvez donc l'utiliser à partir du Console de gestion AWS code, ou d'un MCP-compatible IDE.
Ce que fait l'agent
L'agent Data Transformation AI effectue les tâches suivantes :
-
Génère une logique de conversion à partir de vos données. Pour le format CSV, l'agent analyse les exemples de fichiers que vous avez fournis lors de la création du profil et produit un profil de base : en déduisant les ressources et les champs FHIR cibles, vous pouvez donc partir d'un brouillon plutôt que d'un profil vide. En C-CDA effet, il adapte le profil de AWS démarrage à vos documents.
-
Modifie la logique de conversion à partir du langage naturel. Décrivez un changement en langage clair et l'agent met à jour le modèle ou le mappage sous-jacent. Par exemple :
-
« Ajoutez une cartographie pour la ressource sur les médicaments. »
-
« Mappez la langue préférée du patient dans la section LanguageCommunication. »
-
« Définissez l'État par défaut sur Washington pour les ressources destinées aux patients. »
-
« Associez la colonne RACE_CD à une extension FHIR. »
-
« Ignorez les enregistrements dont le statut a été saisi par erreur. »
-
-
Explique et revoit avant de postuler. L'agent présente la modification proposée sous la forme d'une différence du modèle ou du mappage concerné pour que vous puissiez la consulter, et ne l'applique qu'une fois que vous l'avez acceptée. Rien ne change silencieusement sur le profil publié, l'agent n'apporte des modifications qu'à la version préliminaire.
-
S'affine de manière itérative. Travaillez avec l'agent sur plusieurs tours pour ajuster un mappage jusqu'à ce que la sortie convertie soit correcte, en prévisualisant les résultats par rapport à des échantillons de données entre les tours grâce à l'API de transformation de synchronisation.
C-CDA flux de travail (modèles Velocity)
L'agent édite les modèles Velocity qui définissent la façon dont les C-CDA sections sont mappées aux ressources FHIR. Demandez-lui d'ajouter un mappage de ressources, de modifier la façon dont une section est interprétée, de définir des valeurs par défaut ou de gérer une variation de document, et il met à jour les modèles et renvoie une différence. Vous pouvez prévisualiser la conversion par rapport à C-CDA des exemples de documents avant de publier.
Flux de travail CSV (mappage YAML)
Lorsque vous créez un profil CSV avec des exemples de fichiers, puis que vous appelez l'agent, celui-ci analyse les en-têtes, les valeurs d'échantillon et les modèles de données de vos fichiers, puis propose une configuration de mappage YAML qui inclut :
-
mappages de champs de colonne à FHIR,
-
détection du format de date et reformatage au format FHIR, date/time
-
traductions de valeurs (par exemple, M → homme, PATIENT HOSPITALIER → IMP),
-
primary/foreign-relations clés entre les tables,
-
règles d'agrégation qui replient les lignes de la table enfant en tableaux FHIR sur la ressource parent,
-
toutes les hypothèses formulées par l'agent et toutes les questions qu'il a concernant vos données.
Vous acceptez, rejetez ou affinez chaque mappage proposé, et vous pouvez demander des ajustements supplémentaires à l'agent. L'agent déduit le mappage à partir d'un échantillon de vos fichiers plutôt que de l'ensemble de données complet. Fournissez donc des échantillons représentatifs de vos données et examinez le mappage proposé avant de procéder à une conversion à grande échelle.
Entrées acceptées par l'agent
Vous pouvez communiquer avec l'agent au moyen de saisies en langage naturel. Certaines combinaisons incluent :
-
instructions,
-
exemples de données sources (C-CDA sections ou schémas CSV),
-
documentation des schémas,
-
Erreurs de validation FHIR lors d'une conversion précédente.
Édition manuelle
Vous n'êtes pas obligé d'utiliser l'agent. Vous pouvez modifier les modèles Velocity et les mappages YAML directement à tout moment, et associer des modifications manuelles à des modifications créées par l'agent sur le même profil.
Transformation et aperçu synchrones (en temps réel)
La transformation synchrone convertit une entrée unique et renvoie immédiatement le résultat FHIR, au lieu d'exécuter une tâche asynchrone sur Amazon S3. Il existe pour deux raisons : tester un profil pendant que vous le créez et exécuter de petites transformations interactives dans un request/response flux.
Comment ça marche
Une transformation synchrone traite une seule entrée comme suit :
-
Vous soumettez une entrée (un C-CDA document ou un ensemble de fichiers CSV) par rapport à un profil et recevez les ressources FHIR converties sous forme d'un ensemble FHIR dans la réponse.
-
L'opération est disponible uniquement via l'API REST : elle n'est pas exposée en tant que commande AWS CLI ou SDK. Consultez Accès à l'agent de transformation des données.
-
Vous pouvez activer la détection de dérive lors d'un appel de synchronisation en réglant sur true DriftDetectionEnabled pour voir, dans la réponse, quels éléments source un profil ne capture pas encore : utile lors d'une itération sur un mappage.
Limites de taille
La transformation synchrone accepte C-CDA des entrées jusqu'à 1 Mo et des entrées CSV combinées jusqu'à 1 Mo par demande. Pour les ensembles de données plus volumineux, utilisez une tâche de transformation en bloc.
Aperçu dans le Console de gestion AWS
Lorsque vous créez un profil dans le Console de gestion AWS, la transformation synchrone active l'aperçu en direct : vous voyez la source d'un côté et la sortie FHIR convertie de l'autre, et l'aperçu est mis à jour à mesure que vous affinez le mappage. Utilisez-le pour vérifier que la sortie est correcte avant de publier.
Quand utiliser la synchronisation par rapport au mode groupé
Utilisez la transformation synchrone pour valider un profil par rapport à des documents représentatifs et pour les conversions sensibles à la latence, par exemple un flux en direct qui convertit les documents au fur et à mesure de leur arrivée. Utilisez une tâche de transformation en bloc (ci-dessous) pour les grands ensembles de données et pour les ingérer directement dans une HealthLake banque de données.
Tâches de transformation en masse (asynchrones)
Une tâche de transformation en bloc convertit un jeu de données volumineux depuis Amazon S3 à l'aide d'un profil publié, en s'exécutant de manière asynchrone pendant que vous surveillez la progression. Il s'agit du chemin de production pour les migrations et pour le chargement de données dans une HealthLake banque de données. Reportez-vous à cette page pour la configuration des autorisations IAM.
Comment ça marche
Une tâche de transformation en bloc fonctionne comme suit :
-
Pointez une tâche vers un préfixe Amazon S3 de fichiers sources, choisissez un profil publié et choisissez une destination de sortie. Le job analyse l'entrée, convertit chaque fichier (C-CDA) ou ensemble de lignes (CSV) et écrit les résultats.
-
Il n'y a aucune infrastructure à mettre en place : le job évolue automatiquement.
Modes de sortie
Une tâche groupée prend en charge les modes de sortie suivants :
-
Autonome : écrivez le FHIR converti dans un emplacement Amazon S3. Utilisez l' StartDataTransformationJob API.
-
Composite (conversion et ingestion) : convertissez les fichiers sources et ingérez les ressources FHIR qui en résultent directement dans une HealthLake banque de données en une seule étape, de sorte que les données soient immédiatement interrogeables. Utilisez l' StartFHIRImportJob API avec les DriftDetectionEnabled paramètres ProfileId InputFormat, et éventuellement. La banque de données doit être à l'état ACTIF. Consultez Étape 7 : Convertir et ingérer dans une HealthLake banque de données pour un exemple complet.
Gestion élégante des défaillances
Les entrées mal formées sont ignorées et enregistrées au lieu d'échouer dans le traitement par lots. Ainsi, un seul fichier défectueux n'arrête jamais une tâche volumineuse. Les entrées ayant échoué sont écrites sous forme de fichiers d'erreur JSON avec le chemin du fichier d'entrée et le message d'erreur, afin que vous puissiez les consulter et les retraiter.
Disposition de sortie
Le service crée un dossier délimité par tâche sous votre URI Amazon S3 de sortie à l'aide de l'ID de tâche. Dans ce dossier :
-
converted/ : fichiers de sortie FHIR NDJSON (un par fichier d'entrée, par exemple, -record.ndjson). converted/patient
-
ERROR/ : détail de l'erreur pour les entrées ayant échoué (fichiers JSON avec champs InputFile et ErrorMessage, par exemple). ERROR/bad-file.json
-
Manifest.json: résumé de la tâche avec statistiques agrégées (fichiers scannés, convertis, échecs, ressources générées).
-
job LevelDriftResult.json : le rapport de dérive agrégé pour la tâche, si la détection de dérive était activée.
-
driftDetectionPerFileResults/: pour les C-CDA tâches pour lesquelles la détection de dérive est activée, rapports de dérive par fichier (par exemple, driftDetectionPerFileResults/patient -record_driftMetrics.json), afin que vous puissiez inspecter la couverture d'un fichier source individuel plutôt que uniquement l'agrégat au niveau de la tâche.
Contrôle
Suivez une tâche en cours via la page détaillée de la Console de gestion AWS tâche ou l' DescribeDataTransformationJob API : état, fichiers traités (lignes pour CSV), ressources générées et échecs. Les statistiques et les journaux des tâches sont également disponibles sur Amazon CloudWatch.
Validation
L'agent de transformation des données effectue des validations à plusieurs moments du cycle de vie de conversion, de sorte que les problèmes sont détectés avant qu'ils ne deviennent des échecs de conversion ou des résultats non conformes.
-
Validation de la source : vérifie que les C-CDA entrées sont bien formées et conformes à la C-CDA spécification. Les erreurs incluent des informations de localisation et des conseils de correction, afin que vous puissiez résoudre les problèmes à la source avant d'exécuter une tâche importante. L' ValidateSource opération est disponible via l'API REST pour filtrer les entrées dès le départ.
-
Validation du modèle/du mappage : valide les modèles Velocity (C-CDA) ou le mappage YAML (CSV) d'un profil indépendamment de toute donnée, afin que vous puissiez vous assurer que la logique de conversion est bien définie avant de publier ou d'exécuter une tâche.
-
Validation FHIR de sortie : vérifie que les ressources générées sont conformes à la norme FHIR R4, de sorte que les API FHIR et les banques de données en aval acceptent la sortie.
Ensemble, cela signifie qu'une tâche échoue moins souvent pour des raisons évitables : la validation de la source détecte les mauvaises entrées, la validation du mappage détecte la mauvaise logique et la validation des sorties confirme que le résultat est conforme aux normes.
OID-to-URI cartographie
C-CDA les documents identifient les systèmes de code à l'aide d'OID (Object Identifiers) : des identifiants numériques traditionnels tels que 2.16.840.1.113883.6.1 (LOINC). FHIR attend des URI de systèmes modernes tels que. http://loinc.org Si les OID sont transmis sans mappage, les valeurs du système qui en résultent ne sont pas interopérables et l'outillage FHIR en aval ne peut pas résoudre les codes. L'agent de transformation des données établit des mappages entre eux lors de la conversion.
-
Pre-built mappages : les mappages pour les OID de santé courants (par exemple, LOINC, SNOMED CT, RxNorm) sont appliqués automatiquement ICD-10, sans configuration.
-
Mappages personnalisés : ajoutez vos propres OID-to-URI mappages pour les systèmes de code spécifiques à vos sources, afin que les systèmes propriétaires ou locaux soient résolus correctement.
Cela s'applique aux C-CDA sources, où les OID sont la manière native d'identifier les systèmes de code.
Provenance
Les flux de travail réglementés du secteur de la santé doivent répondre à la question « d'où proviennent ces données et comment ont-elles été produites ? » pour n'importe quelle ressource. Lorsque la provenance est activée sur une tâche, l'agent de transformation des données génère une ressource de provenance FHIR pour chaque conversion, donnant à chaque ressource de sortie un lignage complet et interrogeable remontant à sa source.
La chaîne de provenance
Provenance → DocumentReference → fichier source. La ressource Provenance fait référence à un DocumentReference, qui enregistre l'URI Amazon S3 du fichier source et une SHA-1 somme de contrôle. La somme de contrôle vous permet de prouver que la sortie provient d'un fichier source spécifique non modifié. Une ressource de périphérique représentant la transformation AWS HealthLake des données en tant qu'entité est également fournie si ces informations sont nécessaires.
Record-level localisateurs
La provenance ne se rapporte pas uniquement au fichier source, mais à l'emplacement exact qu'il contient, et le localisateur diffère selon le format de source :
-
C-CDA: un XPath pointant vers l'élément source dont est issue la ressource.
-
CSV : nom de la table, clé primaire et numéro de ligne de l'enregistrement source.
Champs capturés
Chaque ressource Provenance enregistre l'URI et la somme de contrôle du fichier source, la version du profil utilisée pour la conversion, un horodatage et le localisateur au niveau de l'enregistrement.
Conformité et utilisation
Les ressources de provenance sont conformes au profil de provenance de base américain, de sorte qu'elles interagissent avec l' Core-aware outillage américain. Activez la provenance lorsque vous avez besoin d'auditabilité pour des raisons de conformité, ou lorsque vous devez retracer une ressource de sortie douteuse jusqu'à l'élément source exact qui l'a produite. La provenance est activée par défaut ; définissez-la ProvenanceEnabled sur False pour la désactiver.
Détection des écarts
Une conversion peut réussir tout en supprimant silencieusement les données sources qu'un profil n'a pas encore mappées. Surfaces de détection de dérive qui s'écartent. Il s'agit d'un rapport : lorsqu'il est activé, il compare le contenu de la source à ce que le profil a réellement produit et enregistre ce qui a été laissé.
Ce que contient le rapport
Le rapport de dérive contient les informations suivantes :
-
Le taux de couverture global pour la conversion.
-
Une liste classée de sections et d'éléments sources non mappés, afin que vous puissiez hiérarchiser les lacunes les plus importantes.
-
Toutes les ressources attendues qui n'ont pas été produites.
-
Traçabilité complète jusqu'au fichier source et à l'emplacement de l'élément (nom du fichier et OID pour C-CDA, ligne pour CSV).
Comment utiliser la détection de dérive
La détection de dérive est disponible dans les deux modes de conversion. Vous pouvez donc l'utiliser, que vous itériez sur un seul fichier ou que vous validiez un ensemble de données complet :
-
Synchronisation (en temps réel) : définissez DriftDetectionEnabled sur true lors d'une TransformData demande visant à exécuter la détection de dérive sur un seul fichier et à récupérer les résultats dans la réponse de l'API. C'est le moyen le plus rapide de vérifier la couverture pendant que vous créez un profil : convertissez un document représentatif, voyez exactement ce que le profil a oublié, affinez le mappage, puis réessayez.
-
En masse (asynchrone) : activez la détection de dérive sur une tâche de transformation pour mesurer la couverture de l'ensemble de données. Le rapport est écrit en tant que tâche LevelDriftResult.json dans l'emplacement de sortie Amazon S3 de la tâche. Pour les C-CDA jobs, les rapports de dérive par fichier sont également écrits dans le dossier driftDetectionPerFileResults/, afin que vous puissiez identifier les lacunes de couverture dans un fichier source individuel.
Accès MCP
Le Model Context Protocol (MCP) expose l'agent de transformation des données aux agents d' IDE-based IA en tant qu'outils appelables, afin qu'un développeur puisse créer des profils, exécuter des conversions et enquêter sur les échecs d'un assistant dans son IDE : sans passer au. Console de gestion AWS
-
API de gestion des profils et des tâches : toutes les API de gestion des profils et des tâches des agents de transformation des données sont disponibles sous forme d'outils MCP, ce qui vous permet de créer, modifier, publier et exécuter des tâches depuis n'importe quel MCP-compatible client.
-
Tout client MCP : fonctionne avec les MCP-compatible IDE et les assistants, notamment Kiro et Cursor.
-
Sessions durables : prend en charge les sessions à plusieurs tours, de sorte qu'une conversation de débogage ou de création conserve son contexte.
Note
L'opération de conversion de synchronisation (TransformData) et la validation de la source (ValidateSource) sont REST-only et peuvent ne pas apparaître en tant qu'outils MCP. Votre agent peut créer et exécuter les appels REST en votre nom : voir Étape 3 : Test avec conversion synchronisée pour le format de demande.
Étant donné que MCP partage la même surface d'API que les SDK AWS CLI et pour les opérations de profil et de tâche, il n'y a aucun écart de capacité pour ces flux de travail entre le travail dans votre IDE et l'utilisation de code ou de. Console de gestion AWS Consultez Commencer à utiliser MCP la configuration et un exemple de flux de travail.
