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 CSV C-CDA 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 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 seule fois, puis que vous appliquez la même version publiée à autant de tâches que vous le souhaitez.
Création d'un profil
Vous pouvez créer un profil de l'une des trois manières suivantes :
-
À partir d'un profil de départ ou de base : partez d'un profil de travail plutôt que d'un profil vide. 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 tout 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 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 exemples de fichiers à ce moment-là et produit le profil de base.
Le cycle de vie des versions
Un profil peut comporter au maximum un brouillon et jusqu'à 99 versions publiées :
-
Un nouveau profil commence sous la forme d'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'à v99). Les versions publiées ne changent jamais.
-
Les tâches de transformation sont toujours exécutées par rapport à la dernière version publiée. Comme le brouillon est séparé, 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'ont aucune incidence sur les conversions en cours.
-
Un profil contenant une version publiée et de nouvelles modifications non publiées est dans un état où les modifications n'ont pas été publiées ; la version publiée reste active jusqu'à ce que vous la publiiez à nouveau.
Comparaison et annulation
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 versionnement
Publiez une version avant d'exécuter une tâche de production afin que la tâche soit épinglée selon la logique révisée. Utilisez le rollback lorsqu'une modification produit un résultat inattendu, et comparez pour confirmer ce qu'une modification a réellement modifié.
Agent AI de transformation des données
L'agent Data Transformation AI élimine les tâches manuelles liées à la création et à la 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 : des modèles Velocity pour C-CDA, une 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 code Console de gestion AWS, d'un MCP-compatible IDE ou d'un environnement de développement intégré.
Ce que fait l'agent
-
Génère une logique de conversion à partir de vos données. Pour le CSV, l'agent analyse les fichiers d'exemple 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 ainsi 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 une modification en langage clair et l'agent met à jour le modèle ou le mappage sous-jacent. Par exemple :
-
« Ajoutez un mappage pour la ressource Médication. »
-
« Cartographiez 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. »
-
« Ignorer les enregistrements dont le statut est saisi par erreur. »
-
-
Explique et passe en revue avant de postuler. L'agent présente la modification proposée sous forme de différence du modèle ou du mappage concerné afin que vous puissiez l'examiner, et ne l'applique qu'une fois que vous l'avez acceptée. Rien ne change silencieusement sur le profil publié, l'agent apporte des modifications uniquement à la version préliminaire.
-
Affine de manière itérative. Travaillez avec l'agent pendant 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 modifie 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. 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 la 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 entre colonnes et FHIR,
-
détection du format de date et reformatage aux formats FHIR, date/time
-
traductions de valeurs (par exemple, M → mâle, INPATIENT → IMP),
-
primary/foreign-les relations clés entre les tables,
-
des règles d'agrégation qui replient les lignes de la table enfant dans des tableaux FHIR sur la ressource parent,
-
toutes les hypothèses formulées par l'agent et toutes les questions qu'il se pose à propos de vos données.
Vous acceptez, rejetez ou affinez chaque mappage proposé, et vous pouvez demander à l'agent de procéder à des ajustements supplémentaires. 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 à la 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 :
-
des instructions,
-
exemples de données source (C-CDA sections ou schémas CSV),
-
documentation du schéma,
-
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 combiner des modifications manuelles avec des modifications créées par un agent sur le même profil.
Transformation et prévisualisation synchrones (en temps réel)
La transformation synchrone convertit une seule entrée et renvoie le résultat FHIR immédiatement, plutôt que d'exécuter une tâche asynchrone sur Amazon S3. Il existe pour deux raisons : tester un profil pendant sa création et exécuter de petites transformations interactives dans un request/response flux.
Comment ça marche
-
Vous soumettez une entrée (un C-CDA document ou un ensemble de fichiers CSV) par rapport à un profil et vous recevez les ressources FHIR converties sous forme de bundle FHIR dans la réponse.
-
L'opération est uniquement disponible via l'API REST : elle n'est pas exposée sous forme de commande AWS CLI ou de 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 allant 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 cadre de la transformation synchrone Console de gestion AWS, l'aperçu en direct est activé : 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 le résultat est correct avant de le publier.
Quand utiliser la synchronisation plutôt que le stockage groupé
Utilisez la transformation synchrone pour valider un profil par rapport à des documents représentatifs et pour les conversions par demande sensibles à la latence, telles qu'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 ensembles de données volumineux 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 masse convertit un ensemble de données volumineux provenant d'Amazon S3 à l'aide d'un profil publié, qui s'exécute 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
-
Pointez une tâche sur un préfixe Amazon S3 de fichiers source, choisissez un profil publié et choisissez une destination de sortie. La tâche 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 à fournir : le travail évolue automatiquement.
Modes de sortie
-
Autonome : écrivez le FHIR converti dans un emplacement Amazon S3. Utilisez l' StartDataTransformationJob API.
-
Composite (conversion et ingestion) : convertissez les fichiers source et ingérez les ressources FHIR qui en résultent directement dans une HealthLake banque de données en une seule étape, afin 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. Reportez-vous à l'étape 7 : Convertir et ingérer dans une HealthLake banque de données pour un exemple complet.
Gestion gracieuse des défaillances
Les entrées mal formées sont ignorées et enregistrées au lieu d'échouer dans le lot, de sorte qu'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 spécifique à la 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 les champs InputFile et ErrorMessage, par exemple,). ERROR/bad-file.json
-
Manifest.json: résumé des tâches avec statistiques agrégées (fichiers numérisés, convertis, échec, ressources générées).
-
job LevelDriftResult.json : le rapport de dérive agrégé pour le job, si la détection de dérive a été activée.
-
driftDetectionPerFileResults/: pour les C-CDA tâches pour lesquelles la détection de dérive est activée, des 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 : statut, fichiers traités (lignes pour CSV), ressources générées et échecs. Les statistiques et les journaux des offres d'emploi sont également disponibles sur Amazon CloudWatch.
Validation
L'agent de transformation des données effectue des validations à plusieurs étapes du cycle de vie de la conversion, ce qui permet de détecter les problèmes avant qu'ils ne se traduisent par des échecs de conversion ou une sortie non conforme.
-
Validation de la source : vérifie que les C-CDA entrées sont bien formées et conformes aux C-CDA spécifications. Les erreurs incluent les détails de localisation et les conseils de correction, afin que vous puissiez résoudre les problèmes à la source avant d'exécuter une tâche volumineuse. 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 des données, afin que vous puissiez vérifier que la logique de conversion est bien formée 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 au FHIR R4, de sorte que les API et les banques de données FHIR 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 les mauvaises logiques 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 (identificateurs d'objets) : des identifiants numériques anciens tels que 2.16.840.1.113883.6.1 (LOINC). La 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 les met en correspondance lors de la conversion.
-
Pre-built mappages : les mappages pour les OID médicaux 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 méthode native d'identification des systèmes de code.
Provenance
Les flux de travail réglementés dans le secteur de la santé doivent répondre à la question « d'où viennent 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 à a 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 a été dérivée d'un fichier source spécifique non modifié. Une ressource d'appareil 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 correspond non seulement au fichier source, mais aussi à son emplacement exact, et le localisateur varie selon le format de la source :
-
C-CDA: un XPath pointant vers l'élément source dont la ressource est dérivée.
-
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 des enregistrements.
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'une auditabilité pour garantir la 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 ProvenanceEnabled la valeur 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é. Les surfaces de détection de la dérive présentent des lacunes. 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 est resté.
Ce que contient le rapport
-
Le taux de couverture global pour la conversion.
-
Une liste hiérarchisée de sections et d'éléments source non mappés, afin que vous puissiez hiérarchiser les lacunes ayant le plus d'impact.
-
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 la valeur true sur une TransformData demande pour exécuter la détection de dérive sur un seul fichier et obtenir 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, vérifiez exactement ce que le profil a oublié, affinez le mappage et réessayez.
-
En bloc (asynchrone) : activez la détection de dérive lors d'une tâche de transformation pour mesurer la couverture de l'ensemble de données. Le rapport est écrit sous forme de tâche LevelDriftResult.json dans l'emplacement de sortie Amazon S3 de la tâche. Pour les C-CDA tâches, des rapports de dérive par fichier sont également écrits sous 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 sous forme d'outils appelables, afin qu'un développeur puisse créer des profils, exécuter des conversions et enquêter sur les défaillances 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 de l'agent de transformation des données sont disponibles sous forme d'outils MCP. Vous pouvez donc créer, modifier, publier et exécuter des tâches depuis n'importe quel MCP-compatible client.
-
N'importe quel 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 le 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 comme des 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.
Comme MCP partage la même surface d'API que les SDK AWS CLI et pour les opérations de profilage et de travail, il n'y a aucun écart de capacité entre le travail dans votre IDE et le traitement du code ou du. Console de gestion AWS Voir Commencer à utiliser MCP pour la configuration et un exemple de flux de travail.
