Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Funciones de transformación de datos
Cada una de las siguientes funciones está documentada con lo que es, cómo funciona, las diferencias entre las fuentes CSV C-CDA y cuándo utilizarlas.
Perfiles de transformación y control de versiones
Un perfil de transformación es la definición reutilizable de cómo un formato fuente se convierte a FHIR R4. Contiene la lógica de conversión (para C-CDA plantillas de Velocity y una configuración de mapeo de YAML para CSV) y se crea una vez y se reutiliza en todos los almacenes de datos y trabajos de transformación de la cuenta. Separar la definición (perfil) de la ejecución (trabajo) implica crear y probar una conversión una vez y, a continuación, aplicar la misma versión publicada a cualquier número de trabajos.
Crear un perfil
Puedes crear un perfil de una de estas tres maneras:
-
Desde un perfil inicial o básico: comience desde un perfil de trabajo en lugar de uno en blanco. Para C-CDA, el perfil de AWS inicio es un AWS-defined perfil prediseñado que gestiona los formatos de C-CDA documentos comunes de forma inmediata. En el caso del formato CSV, proporciona archivos de muestra en Amazon S3 al crear el perfil y, a continuación, invoca al agente de IA para analizarlos y generar una configuración de mapeo en YAML.
-
Mediante la clonación: clona cualquier perfil existente como punto de partida para crear uno nuevo.
-
A partir de un mapeo sin procesar: suministre directamente plantillas de Velocity (C-CDA) o un mapeo de YAML (CSV). Este es el camino para implementar perfiles controlados por versiones a través de una CI/CD canalización (consulte). Cómo empezar a usar el SDK y AWS CLI
importante
Al crear un perfil CSV SampleData se registra la ubicación de la muestra, pero no se ejecuta el agente de IA. Para generar el mapeo YAML, debes llamar UpdateProfileWithAgent después de crearlo. El agente analiza los archivos de muestra en ese momento y produce el perfil base.
El ciclo de vida de la versión
Un perfil puede tener como máximo un borrador y hasta 99 versiones publicadas:
-
Un perfil nuevo comienza como un borrador (versión 0): una copia de trabajo mutable que puedes editar libremente.
-
Al publicar el borrador, se crea una versión numerada e inmutable (v1, v2, etc., hasta la v99). Las versiones publicadas nunca cambian.
-
Los trabajos de transformación siempre se ejecutan con la última versión publicada. Como el borrador es independiente, puede seguir editándolo mientras los trabajos de producción siguen ejecutándose con la última versión publicada: las ediciones en curso nunca afectan a las conversiones en curso.
-
Un perfil con una versión publicada y ediciones más recientes no publicadas se encuentra en el estado de cambios sin publicar; la versión publicada permanece activa hasta que se publique de nuevo.
Comparar y deshacer
Como se conservan todas las versiones publicadas, puedes ver exactamente cómo ha cambiado la lógica de conversión a lo largo del historial de versiones. La reversión no elimina nada: crea una nueva versión a partir de una instantánea anterior, por lo que se conservan el historial completo y el registro de auditoría.
¿Cuándo usar el control de versiones
Publica una versión antes de ejecutar un trabajo de producción para que el trabajo quede anclado a la lógica revisada. Utilice la reversión cuando un cambio produzca un resultado inesperado y compárelo para confirmar qué es lo que realmente alteró el cambio.
Agente de IA para la transformación de datos
El agente de IA de transformación de datos elimina el esfuerzo manual de crear y mantener las asignaciones del FHIR. En lugar de escribir la lógica de conversión a mano, usted describe el resultado que desea y el agente produce o actualiza la lógica subyacente: Velocity templates for C-CDA, una configuración de mapeo de YAML para CSV. El agente está integrado en el editor de perfiles del Consola de administración de AWS y también está disponible a través de la UpdateProfileWithAgent API y como una herramienta MCP, por lo que puedes trabajar con él desde Consola de administración de AWS, desde el código o desde un MCP-compatible IDE.
Qué hace el agente
El agente de IA de transformación de datos realiza las siguientes tareas:
-
Genera una lógica de conversión a partir de sus datos. En el caso del CSV, el agente analiza los archivos de muestra que proporcionaste al crear el perfil y crea un perfil base: deduce los recursos y campos del FHIR de destino, por lo que puedes empezar a partir de un borrador de trabajo en lugar de un perfil en blanco. C-CDAEn efecto, adapta el perfil AWS inicial a sus documentos.
-
Edita la lógica de conversión a partir del lenguaje natural. Describa un cambio en un lenguaje sencillo y el agente actualizará la plantilla o el mapeo subyacente. Por ejemplo:
-
«Agregue un mapeo para el recurso de medicamentos».
-
«Mapee el idioma preferido del paciente en la sección Lenguaje/Comunicación».
-
«Establezca como estado predeterminado Washington para los recursos para pacientes».
-
«Asigne la columna RACE_CD a una extensión FHIR».
-
«Omita los registros en los que se introduzca el estado por error».
-
-
Explica y revisa antes de presentar la solicitud. El agente presenta el cambio propuesto como un diferencial de la plantilla o mapa afectado para que lo revises y lo aplica solo después de que lo aceptes. Nada cambia silenciosamente en el perfil publicado, el agente solo realiza cambios en la versión preliminar.
-
Refina de forma iterativa. Trabaje con el agente durante varios turnos para ajustar una asignación hasta que la salida convertida sea correcta, previsualizando los resultados comparándolos con los datos de muestra entre turnos con la API de transformación sincronizada.
C-CDA flujo de trabajo (plantillas de Velocity)
El agente edita las plantillas de Velocity que definen cómo se asignan C-CDA las secciones a los recursos del FHIR. Si se le pide que añada una asignación de recursos, cambie el modo en que se interpreta una sección, establezca valores predeterminados o gestione una variante del documento, actualizará las plantillas y devolverá una diferencia. Previsualice la conversión comparándola con C-CDA documentos de muestra antes de publicarla.
Flujo de trabajo en CSV (mapeo en YAML)
Al crear un perfil CSV con archivos de muestra y, a continuación, invocar al agente, este analiza los encabezados, los valores de muestra y los patrones de datos de los archivos y, a continuación, propone una configuración de mapeo en YAML que incluye:
-
Mapeos de campos de columna a FHIR,
-
detección del formato de fecha y reformateo a formatos FHIR, date/time
-
traducciones de valores (por ejemplo, M → hombre, PACIENTE HOSPITALIZADO → IMP),
-
primary/foreign-relaciones clave entre tablas,
-
reglas de agregación que agrupan las filas de tablas secundarias en matrices FHIR del recurso principal,
-
cualquier suposición que haya hecho el agente y cualquier duda que tenga sobre sus datos.
Aceptas, rechazas o refinas cada mapeo propuesto y puedes pedirle al agente que realice más ajustes. El agente deduce el mapeo a partir de una muestra de tus archivos y no del conjunto de datos completo, por lo que debes proporcionar ejemplos que sean representativos de tus datos y revisar el mapeo propuesto antes de realizar la conversión a escala.
Entradas que acepta el agente
Puede comunicarse con el agente mediante entradas en lenguaje natural. Algunas combinaciones incluyen:
-
instrucciones,
-
datos fuente de muestra (C-CDA secciones o esquemas CSV),
-
documentación del esquema,
-
Errores de validación del FHIR de una conversión anterior.
Edición manual
No es necesario que utilice el agente. Puedes editar las plantillas de Velocity y las asignaciones de YAML directamente en cualquier momento y combinar las ediciones manuales con los cambios creados por el agente en el mismo perfil.
Transformación y previsualización sincrónicas (en tiempo real)
La transformación sincrónica convierte una sola entrada y devuelve el resultado del FHIR inmediatamente, en lugar de ejecutar un trabajo asincrónico en Amazon S3. Existe para dos propósitos: probar un perfil mientras lo crea y ejecutar pequeñas transformaciones interactivas en un flujo. request/response
Funcionamiento
Una transformación sincrónica procesa una sola entrada de la siguiente manera:
-
Envías una entrada (un C-CDA documento o un conjunto de archivos CSV) comparándola con un perfil y, en la respuesta, recibes los recursos del FHIR convertidos en un paquete del FHIR.
-
La operación solo está disponible a través de la API REST: no se expone como un comando AWS CLI ni como un comando del SDK. Consulte Acceso al agente de transformación de datos.
-
Puedes habilitar la detección de desviaciones en una llamada de sincronización configurándola como true DriftDetectionEnabled para ver, en la respuesta, qué elementos de origen aún no captura un perfil, lo que resulta útil cuando se itera en una asignación.
Límites de tamaño
La transformación sincrónica acepta C-CDA entradas de hasta 1 MB y entradas CSV combinadas de hasta 1 MB por solicitud. Para conjuntos de datos más grandes, utilice un trabajo de transformación masiva.
Obtenga una vista previa en el Consola de administración de AWS
Al crear un perfil en la versión preliminar Consola de administración de AWS, la transformación sincrónica potencia la vista previa dinámica: se ve la fuente en un lado y la salida FHIR convertida en el otro, y la vista previa se actualiza a medida que se refina el mapeo. Utilízala para confirmar que la salida es correcta antes de publicarla.
Cuándo usar la sincronización en lugar de hacerlo de forma masiva
Usa la transformación sincrónica para validar un perfil comparándolo con documentos representativos y para realizar conversiones por solicitud en función de la latencia, como una transmisión en directo que convierte los documentos a medida que llegan. Usa un trabajo de transformación masiva (más abajo) para conjuntos de datos de gran tamaño y para incorporarlos directamente a un almacén de datos. HealthLake
Trabajos de transformación masivos (asincrónicos)
Un trabajo de transformación masiva convierte un conjunto de datos grande de Amazon S3 mediante un perfil publicado y se ejecuta de forma asincrónica mientras se monitorea el progreso. Esta es la ruta de producción para las migraciones y para cargar datos en un almacén de datos. HealthLake Consulte esta página para ver la configuración de los permisos de IAM.
Funcionamiento
Un trabajo de transformación masiva funciona de la siguiente manera:
-
Dirija un trabajo a un prefijo de archivos fuente de Amazon S3, elija un perfil publicado y elija un destino de salida. El trabajo escanea la entrada, convierte cada archivo (C-CDA) o conjunto de filas (CSV) y escribe los resultados.
-
No hay infraestructura que aprovisionar: el trabajo se escala automáticamente.
Modos de salida
Un trabajo masivo admite los siguientes modos de salida:
-
Independiente: escriba el FHIR convertido en una ubicación de Amazon S3. Utilice la API. StartDataTransformationJob
-
Compuesta (conversión e ingesta): convierte los archivos fuente e ingiere los recursos FHIR resultantes directamente en un HealthLake almacén de datos en un solo paso, de modo que los datos se puedan consultar de inmediato. Utilice la StartFHIRImportJob API con los parámetros y, de forma opcional. ProfileId InputFormat DriftDetectionEnabled El almacén de datos debe estar en estado ACTIVO. Consulte el paso 7: Convertir e introducir en un HealthLake almacén de datos para ver un ejemplo completo.
Gestión eficiente de los fallos
Las entradas con formato incorrecto se omiten y se registran en lugar de fallar en el lote, por lo que un solo archivo incorrecto nunca detiene un trabajo grande. Las entradas fallidas se escriben como archivos de error JSON con la ruta del archivo de entrada y el mensaje de error, para que puedas revisarlas y volver a procesarlas.
Diseño de salida
El servicio crea una carpeta con el ámbito del trabajo en la URI de Amazon S3 de salida mediante el ID del trabajo. Dentro de esa carpeta:
-
converted/: archivos de salida FHIR NDJSON (uno por archivo de entrada, por ejemplo, -record.ndjson). converted/patient
-
ERROR/: detalle del error en las entradas fallidas (archivos JSON con los campos InputFile y ErrorMessage, por ejemplo). ERROR/bad-file.json
-
Manifest.json: resumen del trabajo con métricas agregadas (archivos escaneados, convertidos, fallidos, recursos generados).
-
trabajoLevelDriftResult.json: el informe de desviaciones agregadas del trabajo, si la detección de desviaciones estaba habilitada.
-
driftDetectionPerFileResults/: para los C-CDA trabajos con la detección de desviaciones habilitada, informes de desviaciones por archivo (por ejemplo, driftDetectionPerFileResults/patient -record_driftMetrics.json), para que puedas inspeccionar la cobertura de un archivo fuente individual en lugar de solo el agregado a nivel de trabajo.
Supervisión
Realice un seguimiento de un trabajo en ejecución a través de la página de detalles del Consola de administración de AWS trabajo o la DescribeDataTransformationJob API: estado, archivos procesados (filas para CSV), recursos generados y errores. Las métricas y los registros de los trabajos también están disponibles en Amazon CloudWatch.
Validación
El agente de transformación de datos se valida en varios puntos del ciclo de vida de la conversión, de modo que los problemas se detectan antes de que se conviertan en conversiones fallidas o en resultados no conformes.
-
Validación de la fuente: comprueba que C-CDA las entradas estén bien formadas y se ajusten a la especificación. C-CDA Los errores incluyen detalles sobre la ubicación y directrices para corregirlos, de modo que pueda solucionar los problemas de origen antes de ejecutar un trabajo de gran tamaño. La ValidateSource operación está disponible a través de la API REST para filtrar las entradas desde el principio.
-
Validación de plantillas o mapas: valida las plantillas de Velocity (C-CDA) o la asignación de YAML (CSV) de un perfil independientemente de los datos, de modo que puedes confirmar que la lógica de conversión está bien estructurada antes de publicar o ejecutar un trabajo.
-
Validación del FHIR de la salida: comprueba que los recursos generados cumplen con el FHIR R4, de modo que las API y los almacenes de datos del FHIR posteriores aceptan la salida.
En conjunto, esto hace que un trabajo falle con menos frecuencia por motivos evitables: la validación de la fuente detecta las entradas incorrectas, la validación del mapeo detecta la lógica incorrecta y la validación de la salida confirma que el resultado cumple con los estándares.
OID-to-URI mapeo
C-CDA los documentos identifican los sistemas de códigos mediante OID (identificadores de objetos): identificadores numéricos antiguos, como 2.16.840.1.113883.6.1 los (LOINC). El FHIR espera que los URI de los sistemas modernos sean como. http://loinc.org Si los OID se transfieren sin mapear, los valores del sistema resultantes no son interoperables y las herramientas posteriores del FHIR no pueden resolver los códigos. El agente de transformación de datos se mapea entre ellos durante la conversión.
-
Pre-built mapeos: los mapeos de los OID de atención médica comunes (por ejemplo, LOINC, SNOMED CT, RxNorm) se aplican automáticamente ICD-10, sin configuración.
-
Mapeos personalizados: añada sus propios OID-to-URI mapeos para los sistemas de código específicos de sus fuentes, de modo que los sistemas propietarios o locales se resuelvan correctamente.
Esto se aplica a C-CDA las fuentes, donde los OID son la forma nativa en que se identifican los sistemas de código.
Procedencia
Los flujos de trabajo regulados en el sector sanitario deben responder a la pregunta «¿de dónde provienen estos datos y cómo se han producido?» para cualquier recurso. Cuando se habilita la procedencia en un trabajo, Data Transformation Agent genera un recurso de procedencia FHIR para cada conversión, lo que proporciona a cada recurso de salida un linaje completo y consultable que lo lleva a su origen.
La cadena de procedencia
Procedencia → DocumentReference → archivo fuente. El recurso de procedencia hace referencia a a DocumentReference, que registra el URI de Amazon S3 del archivo fuente y una SHA-1 suma de comprobación. La suma de comprobación le permite demostrar que el resultado se derivó de un archivo fuente específico e inalterado. También se proporciona un recurso de dispositivo que representa la transformación de AWS HealthLake datos como una entidad en caso de que esa información sea necesaria.
Record-level localizadores
La procedencia se refiere no solo al archivo fuente, sino también a la ubicación exacta que contiene, y el localizador varía según el formato de origen:
-
C-CDA: un XPath que apunta al elemento fuente del que se derivó el recurso.
-
CSV: el nombre de la tabla, la clave principal y el número de fila del registro de origen.
Campos capturados
Cada recurso de Provenance registra el URI y la suma de comprobación del archivo fuente, la versión del perfil utilizada para la conversión, una marca de tiempo y el localizador a nivel de registro.
Conformidad y uso
Los recursos de procedencia se ajustan al perfil de procedencia principal de EE. UU., por lo que interactúan con las herramientas estadounidenses. Core-aware Habilite la procedencia cuando necesite auditar para garantizar el cumplimiento o cuando necesite rastrear un recurso de salida cuestionable hasta el elemento de origen exacto que lo generó. La procedencia está habilitada de forma predeterminada; establézcala en false ProvenanceEnabled para deshabilitarla.
Detección de desviaciones
Una conversión se puede realizar correctamente si se eliminan silenciosamente los datos de origen que un perfil aún no ha mapeado. La detección de desviaciones deja al descubierto esa brecha. Se trata de un informe: cuando está activado, compara lo que contiene la fuente con lo que realmente produjo el perfil y registra lo que quedó.
Qué contiene el informe
El informe de deriva contiene la siguiente información:
-
La tasa de cobertura general de la conversión.
-
Una lista ordenada de secciones y elementos de origen no mapeados, para que puedas priorizar las brechas de mayor impacto.
-
Cualquier recurso esperado que no se haya producido.
-
Trazabilidad total hasta el archivo de origen y la ubicación del elemento (nombre de archivo y OID para C-CDA, fila para CSV).
Cómo usar la detección de desviaciones
La detección de desviaciones está disponible en ambos modos de conversión, por lo que puedes usarla tanto si estás iterando en un solo archivo como si estás validando un conjunto de datos completo:
-
Sincronización (en tiempo real): se establece DriftDetectionEnabled como verdadera en una TransformData solicitud para ejecutar la detección de desviaciones en un solo archivo y obtener los resultados en la respuesta de la API. Esta es la forma más rápida de comprobar la cobertura mientras creas un perfil: convierte un documento representativo, comprueba exactamente lo que falta en el perfil, refina el mapeo e inténtalo de nuevo.
-
Masivo (asincrónico): habilita la detección de desviaciones en una tarea de transformación para medir la cobertura de todo el conjunto de datos. El informe se escribe como un trabajo LevelDriftResult.json en la ubicación de salida de Amazon S3 del trabajo. En el caso de los C-CDA trabajos, los informes de errores por archivo también se escriben en la carpeta driftDetectionPerFileResults/, de modo que puede identificar las brechas de cobertura en un archivo fuente individual.
Acceso a MCP
El Model Context Protocol (MCP) expone el agente de transformación de datos a los agentes de IDE-based IA como herramientas a las que se puede recurrir, de modo que un desarrollador puede crear perfiles, ejecutar conversiones e investigar los errores desde un asistente de su IDE, sin tener que cambiar al. Consola de administración de AWS
-
API de administración de perfiles y trabajos: todas las API de administración de perfiles y trabajos de Data Transformation Agent están disponibles como herramientas de MCP, por lo que puede crear, editar, publicar y ejecutar trabajos desde cualquier cliente. MCP-compatible
-
Cualquier cliente de MCP: funciona con MCP-compatible IDE y asistentes, incluidos Kiro y Cursor.
-
Sesiones duraderas: admite sesiones de varios turnos, por lo que una conversación de depuración o creación contiene contexto.
nota
La operación de conversión sincronizada (TransformData) y la validación de la fuente (ValidateSource) son herramientas de REST-only MCP y es posible que no aparezcan. Su agente puede crear y ejecutar las llamadas REST en su nombre: consulte el paso 3: Probar la conversión sincronizada para el formato de solicitud.
Como MCP comparte la misma superficie de API que los AWS CLI SDK para las operaciones de perfil y trabajo, no hay ninguna brecha de capacidad para esos flujos de trabajo entre trabajar en su IDE y trabajar con código o con. Consola de administración de AWS Consulte Cómo empezar con MCP la configuración y un ejemplo de flujo de trabajo.
