Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Funktionen zur Datentransformation
Jede der folgenden Funktionen ist dokumentiert, was sie ist, wie sie funktioniert, welche Unterschiede zwischen C-CDA CSV-Quellen bestehen und wann sie verwendet werden sollte.
Transformationsprofile und Versionierung
Ein Transformationsprofil ist die wiederverwendbare Definition, wie ein Quellformat in FHIR R4 konvertiert wird. Es enthält die Konvertierungslogik (Velocity-Vorlagen für C-CDA, eine YAML-Mapping-Konfiguration für CSV) und wird einmal erstellt und für alle Datenspeicher und Transformationsjobs in Ihrem Konto wiederverwendet. Wenn Sie die Definition (Profil) von der Ausführung (Job) trennen, müssen Sie eine Konvertierung einmal erstellen und testen und dann dieselbe veröffentlichte Version auf eine beliebige Anzahl von Jobs anwenden.
Erstellen eines -Profils
Sie erstellen ein Profil auf eine von drei Arten:
-
Von einem Starter- oder Basisprofil aus: Beginnen Sie mit einem Arbeitsprofil und nicht mit einem leeren Profil. Denn C-CDA das AWS Starter-Profil ist ein vorgefertigtes AWS-defined Profil, das gängige C-CDA Dokumentformate sofort verarbeitet. Für CSV stellen Sie bei der Erstellung des Profils Beispieldateien in Amazon S3 bereit und rufen dann den AI-Agenten auf, um sie zu analysieren und eine YAML-Mapping-Konfiguration zu generieren.
-
Durch Klonen: Klonen Sie ein vorhandenes Profil als Ausgangspunkt für ein neues.
-
Aus einem Roh-Mapping: Geben Sie Velocity-Vorlagen (C-CDA) oder ein YAML-Mapping (CSV) direkt an. Dies ist der Pfad für die Bereitstellung versionskontrollierter Profile über eine CI/CD Pipeline (siehe). Erste Schritte mit dem SDK und AWS CLI
Wichtig
Beim Erstellen eines CSV-Profils mit wird der Beispielspeicherort SampleData registriert, der AI-Agent wird jedoch nicht ausgeführt. Um das YAML-Mapping zu generieren, müssen Sie es UpdateProfileWithAgent nach der Erstellung aufrufen. Der Agent analysiert zu diesem Zeitpunkt Ihre Beispieldateien und erstellt das Basisprofil.
Der Versionslebenszyklus
Ein Profil kann maximal einen Entwurf und bis zu 99 veröffentlichte Versionen enthalten:
-
Ein neues Profil beginnt als Entwurf (Version 0): eine veränderbare Arbeitskopie, die Sie frei bearbeiten können.
-
Durch die Veröffentlichung des Entwurfs wird eine unveränderliche, nummerierte Version erstellt (v1, v2 usw., bis zu v99). Veröffentlichte Versionen ändern sich nie.
-
Transformationsaufträge werden immer mit der neuesten veröffentlichten Version ausgeführt. Da es sich um einen separaten Entwurf handelt, können Sie die Bearbeitung fortsetzen, während Produktionsaufträge weiterhin mit der zuletzt veröffentlichten Version ausgeführt werden: In Bearbeitung befindliche Änderungen wirken sich nie auf laufende Konvertierungen aus.
-
Ein Profil mit einer veröffentlichten Version und neueren unveröffentlichten Änderungen befindet sich im Status „Unveröffentlichte Änderungen“. Die veröffentlichte Version bleibt live, bis Sie sie erneut veröffentlichen.
Vergleichen und Rollback
Da jede veröffentlichte Version beibehalten wird, können Sie genau sehen, wie sich die Konvertierungslogik im Laufe des Versionsverlaufs geändert hat. Beim Rollback wird nichts gelöscht: Es wird eine neue Version aus einem vorherigen Snapshot erstellt, sodass der gesamte Verlauf und der Prüfpfad erhalten bleiben.
Wann sollte die Versionierung verwendet werden
Veröffentlichen Sie eine Version, bevor Sie einen Produktionsauftrag ausführen, damit der Auftrag an die überprüfte Logik angeheftet wird. Verwenden Sie Rollback, wenn eine Änderung zu einer unerwarteten Ausgabe führt, und vergleichen Sie, um zu überprüfen, was durch eine Änderung tatsächlich geändert wurde.
KI-Agent zur Datentransformation
Der Data Transformation AI-Agent macht das manuelle Erstellen und Verwalten von FHIR-Zuordnungen überflüssig. Anstatt die Konvertierungslogik von Hand zu schreiben, beschreiben Sie das gewünschte Ergebnis und der Agent erstellt oder aktualisiert die zugrunde liegende Logik: Velocity-Vorlagen für C-CDA, eine YAML-Mapping-Konfiguration für CSV. Der Agent ist in den Profileditor von eingebettet AWS-Managementkonsole und auch über die UpdateProfileWithAgent API und als MCP-Tool verfügbar, sodass Sie ihn von der AWS-Managementkonsole, vom Code oder von einer MCP-compatible IDE aus bearbeiten können.
Was macht der Agent
Der Data Transformation AI-Agent führt die folgenden Aufgaben aus:
-
Generiert Konvertierungslogik aus Ihren Daten. Für CSV analysiert der Agent die Beispieldateien, die Sie bei der Profilerstellung angegeben haben, und erstellt ein Basisprofil. Dabei werden die FHIR-Zielressourcen und -felder abgeleitet, sodass Sie mit einem funktionierenden Entwurf beginnen und nicht mit einem leeren Profil. Denn C-CDA es passt das AWS Starter-Profil an Ihre Dokumente an.
-
Bearbeitet die Konvertierungslogik aus natürlicher Sprache. Beschreiben Sie eine Änderung im Klartext und der Agent aktualisiert die zugrunde liegende Vorlage oder das Mapping. Beispiel:
-
„Fügen Sie eine Zuordnung für die Medikationsressource hinzu.“
-
„Ordnen Sie die bevorzugte Sprache des Patienten im Bereich Sprache/Kommunikation zu.“
-
„Stellen Sie Washington als Standardstaat für Patientenressourcen ein.“
-
„Ordnen Sie die Spalte RACE_CD einer FHIR-Erweiterung zu.“
-
„Überspringe Datensätze, bei denen der Status fehlerhaft eingegeben wurde.“
-
-
Erklärt und überprüft es vor der Bewerbung. Der Agent präsentiert die vorgeschlagene Änderung als Unterschied zu der betroffenen Vorlage oder dem betroffenen Mapping, sodass Sie sie überprüfen können, und wendet sie erst an, nachdem Sie sie akzeptiert haben. Am veröffentlichten Profil ändert sich nichts im Hintergrund, der Agent nimmt nur Änderungen an der Entwurfsversion vor.
-
Verfeinert iterativ. Arbeiten Sie mit dem Agenten über mehrere Umdrehungen hinweg zusammen, um ein Mapping anzupassen, bis die konvertierte Ausgabe korrekt ist, und lassen Sie sich zwischen den einzelnen Zügen mithilfe der Sync-Transform-API eine Vorschau der Ergebnisse anhand der Beispieldaten anzeigen.
C-CDA Arbeitsablauf (Velocity-Vorlagen)
Der Agent bearbeitet die Velocity-Vorlagen, die definieren, wie C-CDA Abschnitte den FHIR-Ressourcen zugeordnet werden. Bitten Sie ihn, eine Ressourcenzuordnung hinzuzufügen, die Interpretation eines Abschnitts zu ändern, Standardwerte festzulegen oder eine Dokumentvariation zu bearbeiten, und es werden die Vorlagen aktualisiert und ein Diff zurückgegeben. Vor der Veröffentlichung sehen Sie sich eine Vorschau der Konvertierung anhand von C-CDA Beispieldokumenten an.
CSV-Workflow (YAML-Zuordnung)
Wenn Sie ein CSV-Profil mit Beispieldateien erstellen und dann den Agenten aufrufen, analysiert er die Header, Beispielwerte und Datenmuster aus Ihren Dateien und schlägt dann eine YAML-Zuordnungskonfiguration vor, die Folgendes umfasst:
-
Zuordnungen von Feldern von Spalte zu FHIR,
-
Erkennung von Datumsformaten und Neuformatierung in FHIR-Formate, date/time
-
Übersetzungen von Werten (z. B. M → männlich, STATIONÄR → IMP),
-
primary/foreign-wichtige Beziehungen zwischen Tabellen,
-
Aggregationsregeln, die Zeilen untergeordneter Tabellen in FHIR-Arrays auf der übergeordneten Ressource zusammenfassen,
-
alle Annahmen, die der Agent getroffen hat, und alle Fragen, die er zu Ihren Daten hat.
Sie akzeptieren, verwerfen oder verfeinern jede vorgeschlagene Zuordnung und können den Agenten um weitere Anpassungen bitten. Der Agent leitet die Zuordnung aus einer Stichprobe Ihrer Dateien und nicht aus dem gesamten Datensatz ab. Stellen Sie also Stichproben bereit, die für Ihre Daten repräsentativ sind, und überprüfen Sie die vorgeschlagene Zuordnung, bevor Sie sie maßstabsgetreu konvertieren.
Eingaben, die der Agent akzeptiert
Sie können mit dem Agenten in natürlicher Sprache kommunizieren. Einige Kombinationen beinhalten:
-
Anweisungen,
-
Beispielquelldaten (C-CDA Abschnitte oder CSV-Schemas),
-
Schema-Dokumentation,
-
FHIR-Validierungsfehler aus einer früheren Konvertierung.
Manuelles Bearbeiten
Sie müssen den Agenten nicht verwenden. Sie können Velocity-Vorlagen und YAML-Zuordnungen jederzeit direkt bearbeiten und manuelle Änderungen mit vom Agenten erstellten Änderungen an demselben Profil kombinieren.
Synchrone Transformation und Vorschau (in Echtzeit)
Die synchrone Transformation konvertiert eine einzelne Eingabe und gibt das FHIR-Ergebnis sofort zurück, anstatt einen asynchronen Job über Amazon S3 auszuführen. Sie dient zwei Zwecken: zum Testen eines Profils, während Sie es erstellen, und zum Ausführen kleiner, interaktiver Transformationen in einem Flow. request/response
Funktionsweise
Eine synchrone Transformation verarbeitet eine einzelne Eingabe wie folgt:
-
Sie senden eine Eingabe (ein C-CDA Dokument oder eine Reihe von CSV-Dateien) anhand eines Profils und erhalten die konvertierten FHIR-Ressourcen als FHIR-Paket in der Antwort.
-
Der Vorgang ist nur über die REST-API verfügbar: Er wird nicht als AWS CLI oder SDK-Befehl bereitgestellt. Siehe Zugreifen auf den Data Transformation Agent.
-
Sie können die Drift-Erkennung bei einem Sync-Aufruf aktivieren, indem Sie den Wert auf true setzen DriftDetectionEnabled , um in der Antwort zu sehen, welche Quellelemente ein Profil noch nicht erfasst. Dies ist nützlich, wenn Sie ein Mapping iterieren.
Größenbeschränkungen
Die synchrone Transformation akzeptiert C-CDA Eingaben bis zu 1 MB und kombinierte CSV-Eingaben bis zu 1 MB pro Anfrage. Verwenden Sie für größere Datensätze einen Massentransformationsauftrag.
Eine Vorschau finden Sie im AWS-Managementkonsole
Wenn Sie ein Profil in der synchronen Transformation AWS-Managementkonsole erstellen, wird die Live-Vorschau aktiviert: Sie sehen auf der einen Seite die Quelle und auf der anderen Seite die konvertierte FHIR-Ausgabe, und die Vorschau wird aktualisiert, wenn Sie das Mapping verfeinern. Verwenden Sie es, um vor der Veröffentlichung zu überprüfen, ob die Ausgabe korrekt ist.
Wann sollte Sync statt Bulk verwendet werden
Verwenden Sie die synchrone Transformation, um ein Profil anhand repräsentativer Dokumente und für latenzempfindliche Konvertierungen pro Anfrage zu validieren, z. B. einen Live-Feed, der Dokumente konvertiert, sobald sie eintreffen. Verwenden Sie einen Massentransformationsauftrag (unten) für große Datensätze und für die direkte Aufnahme in einen Datenspeicher. HealthLake
(asynchrone) Massentransformationsaufträge
Ein Massentransformationsauftrag konvertiert einen großen Datensatz aus Amazon S3 mithilfe eines veröffentlichten Profils und läuft asynchron, während Sie den Fortschritt überwachen. Dies ist der Produktionspfad für Migrationen und das Laden von Daten in einen Datenspeicher. HealthLake Informationen zur Einrichtung von IAM-Berechtigungen finden Sie auf dieser Seite.
Funktionsweise
Ein Massentransformationsauftrag funktioniert wie folgt:
-
Verweisen Sie einen Job auf ein Amazon S3-Präfix von Quelldateien, wählen Sie ein veröffentlichtes Profil und ein Ausgabeziel. Der Job scannt die Eingabe, konvertiert jede Datei (C-CDA) oder jede Gruppe von Zeilen (CSV) und schreibt die Ergebnisse.
-
Es muss keine Infrastruktur bereitgestellt werden: Der Job skaliert automatisch.
Ausgabemodi
Ein Bulk-Job unterstützt die folgenden Ausgabemodi:
-
Eigenständig: Schreiben Sie das konvertierte FHIR an einen Amazon S3-Speicherort. Verwenden Sie die StartDataTransformationJob API.
-
Zusammengesetzt (konvertieren und aufnehmen): Konvertiert Quelldateien und importiert die resultierenden FHIR-Ressourcen in einem einzigen Schritt direkt in einen HealthLake Datenspeicher, sodass die Daten sofort abfragbar sind. Verwenden Sie die StartFHIRImportJob API mit den Parametern, und optional. ProfileId InputFormat DriftDetectionEnabled Der Datenspeicher muss sich im Status ACTIVE befinden. Ein vollständiges Beispiel finden Sie unter Schritt 7: Konvertierung und Aufnahme in einen HealthLake Datenspeicher.
Ordnungsgemäßer Umgang mit Ausfällen
Falsch formatierte Eingaben werden übersprungen und protokolliert, sodass der Batch nicht fehlschlägt, sodass eine einzelne fehlerhafte Datei niemals einen großen Auftrag beendet. Fehlgeschlagene Eingaben werden als JSON-Fehlerdateien mit dem Eingabedateipfad und der Fehlermeldung geschrieben, sodass Sie sie überprüfen und erneut verarbeiten können.
Layout der Ausgabe
Der Service erstellt unter Ihrer Amazon S3-Ausgabe-URI mithilfe der Job-ID einen auftragsbezogenen Ordner. In diesem Ordner:
-
converted/: FHIR NDJSON-Ausgabedateien (eine pro Eingabedatei, z. B. -record.ndjson). converted/patient
-
ERROR/: Fehlerdetails für fehlgeschlagene Eingaben (JSON-Dateien mit den Feldern InputFile und ErrorMessage, z. B.). ERROR/bad-file.json
-
Manifest.json: Auftragszusammenfassung mit aggregierten Kennzahlen (gescannte, konvertierte, fehlgeschlagene Dateien, generierte Ressourcen).
-
JobLevelDriftResult.json: Der aggregierte Drift-Bericht für den Job, falls die Drift-Erkennung aktiviert war.
-
driftDetectionPerFileResults/: Für C-CDA Jobs mit aktivierter Drift-Erkennung werden Abweichungen pro Datei gemeldet (z. B. driftDetectionPerFileResults/patient -record_driftMetrics.json), sodass Sie die Abdeckung für eine einzelne Quelldatei und nicht nur für das Aggregat auf Jobebene überprüfen können.
Überwachen
Verfolgen Sie einen laufenden Job über die AWS-Managementkonsole Jobdetailseite oder die DescribeDataTransformationJob API: Status, verarbeitete Dateien (Zeilen für CSV), generierte Ressourcen und Fehler. Auftragsmetriken und -protokolle sind auch bei Amazon verfügbar CloudWatch.
Validierung
Der Data Transformation Agent validiert an mehreren Stellen im Konvertierungszyklus, sodass Probleme erkannt werden, bevor sie zu fehlgeschlagenen Konvertierungen oder nicht konformer Ausgabe werden.
-
Quellenvalidierung: prüft, ob die C-CDA Eingaben wohlgeformt sind und der Spezifikation entsprechen. C-CDA Zu den Fehlern gehören Standortangaben und Anleitungen zur Problembehebung, sodass Sie die Quellprobleme beheben können, bevor Sie einen großen Auftrag ausführen. Der ValidateSource Vorgang ist über die REST-API verfügbar, um Eingaben im Voraus zu überprüfen.
-
Validierung von Vorlagen/Mappings: Validiert die Velocity-Vorlagen (C-CDA) oder das YAML-Mapping (CSV) eines Profils unabhängig von Daten, sodass Sie vor der Veröffentlichung oder Ausführung eines Jobs überprüfen können, ob die Konvertierungslogik korrekt ist.
-
FHIR-Validierung der Ausgabe: Überprüft, ob die generierten Ressourcen FHIR R4 entsprechen, sodass nachgelagerte FHIR-APIs und Datenspeicher die Ausgabe akzeptieren.
Zusammengenommen bedeutet dies, dass ein Job aus vermeidbaren Gründen seltener fehlschlägt: Die Quellvalidierung fängt fehlerhafte Eingaben ab, die Mapping-Validierung fängt schlechte Logik ab und die Ausgabevalidierung bestätigt, dass das Ergebnis standardkonform ist.
OID-to-URI Kartierung
C-CDA Dokumente identifizieren Codesysteme mithilfe von OIDs (Object Identifiers): ältere numerische Identifikatoren wie 2.16.840.1.113883.6.1 (LOINC). FHIR erwartet moderne System-URIs wie. http://loinc.org Wenn OIDs ohne Zuordnung übertragen werden, sind die resultierenden Systemwerte nicht kompatibel und die nachgeschalteten FHIR-Tools können die Codes nicht auflösen. Der Data Transformation Agent ordnet sie während der Konvertierung zu.
-
Pre-built Zuordnungen: Zuordnungen für gängige OIDs im Gesundheitswesen (z. B. LOINC, SNOMED CT ICD-10, RxNorm) werden automatisch und ohne Konfiguration angewendet.
-
Benutzerdefinierte Zuordnungen: Fügen Sie Ihre eigenen OID-to-URI Zuordnungen für Codesysteme hinzu, die für Ihre Quellen spezifisch sind, damit proprietäre oder lokale Systeme korrekt aufgelöst werden.
Dies gilt für C-CDA Quellen, bei denen OIDs die systemeigene Methode zur Identifizierung von Codesystemen sind.
Provenienz
Regulierte Arbeitsabläufe im Gesundheitswesen müssen die Frage beantworten: „Woher stammen diese Daten und wie wurden sie produziert?“ für jede Ressource. Wenn Provenance für einen Job aktiviert ist, generiert Data Transformation Agent für jede Konvertierung eine FHIR Provenance-Ressource, sodass jede Ausgaberessource eine vollständige, abfragbare Herkunft zurück zu ihrer Quelle erhält.
Die Provenienzkette
Provenienz → DocumentReference → Quelldatei. Die Provenance-Ressource verweist auf a DocumentReference, die den Amazon S3-URI der Quelldatei und eine SHA-1 Prüfsumme aufzeichnet. Mit der Prüfsumme können Sie nachweisen, dass die Ausgabe aus einer bestimmten, unveränderten Quelldatei abgeleitet wurde. Eine Geräteressource, die die AWS HealthLake Datentransformation als Einheit darstellt, wird ebenfalls bereitgestellt, falls diese Informationen erforderlich sein sollten.
Record-level Locatoren
Provenance wird nicht nur in der Quelldatei, sondern auch in der genauen Position darin aufgelöst, und der Locator unterscheidet sich je nach Quellformat:
-
C-CDA: ein XPath, der auf das Quellelement zeigt, von dem die Ressource abgeleitet wurde.
-
CSV: der Tabellenname, der Primärschlüssel und die Zeilennummer des Quelldatensatzes.
Erfasste Felder
Jede Provenance-Ressource zeichnet den URI und die Prüfsumme der Quelldatei, die für die Konvertierung verwendete Profilversion, einen Zeitstempel und den Locator auf Datensatzebene auf.
Konformität und Verwendung
Die Ressourcen von Provenance entsprechen dem US Core Provenance Profile, sodass sie mit US-Geräten kompatibel sind. Core-aware Aktivieren Sie Provenance, wenn Sie eine Überprüfbarkeit zur Einhaltung der Vorschriften benötigen oder wenn Sie eine fragwürdige Ausgaberessource bis zu dem exakten Quellelement zurückverfolgen müssen, aus dem sie hervorgegangen ist. Provenance ist standardmäßig aktiviert; setzen Sie den Wert ProvenanceEnabled auf False, um es zu deaktivieren.
Erkennung von Abweichungen
Eine Konvertierung kann erfolgreich sein, während Quelldaten, die einem Profil noch nicht zugeordnet sind, stillschweigend gelöscht werden. Die Drift-Erkennung deckt diese Lücke auf. Es handelt sich um einen Bericht: Wenn diese Option aktiviert ist, vergleicht er den Inhalt der Quelle mit dem, was das Profil tatsächlich erstellt hat, und zeichnet auf, was zurückgeblieben ist.
Was der Bericht enthält
Der Drift-Bericht enthält die folgenden Informationen:
-
Die Gesamtabdeckungsrate für die Konvertierung.
-
Eine Rangliste von Quellabschnitten und Elementen, die noch nicht zugeordnet wurden, sodass Sie die Lücken mit den größten Auswirkungen priorisieren können.
-
Alle erwarteten Ressourcen, die nicht produziert wurden.
-
Vollständige Rückverfolgbarkeit bis zur Quelldatei und zum Speicherort der Elemente (Dateiname und OID für C-CDA, Zeile für CSV).
Wie benutzt man die Drift-Erkennung
Die Drift-Erkennung ist in beiden Konvertierungsmodi verfügbar, sodass Sie sie unabhängig davon verwenden können, ob Sie an einer einzelnen Datei iterieren oder einen vollständigen Datensatz validieren:
-
Sync (Echtzeit): Bei einer TransformData Anfrage auf true setzen DriftDetectionEnabled , um die Drift-Erkennung für eine einzelne Datei auszuführen und die Ergebnisse in der API-Antwort zurückzugeben. Dies ist der schnellste Weg, um die Reichweite zu überprüfen, während Sie ein Profil erstellen: Konvertieren Sie ein repräsentatives Dokument, sehen Sie genau, was im Profil übersehen wurde, verfeinern Sie die Zuordnung und versuchen Sie es erneut.
-
Bulk (asynchron): Aktivieren Sie die Drift-Erkennung bei einem Transformationsjob, um die Abdeckung des gesamten Datensatzes zu messen. Der Bericht wird als Job LevelDriftResult.json am Amazon S3-Ausgabespeicherort des Jobs geschrieben. Bei C-CDA Aufträgen werden Drift-Berichte pro Datei ebenfalls in den Ordner driftDetectionPerFileResults/geschrieben, sodass Sie Lücken in der Abdeckung in einer einzelnen Quelldatei lokalisieren können.
MCP-Zugriff
Das Model Context Protocol (MCP) stellt den Data Transformation Agent IDE-based KI-Agenten als aufrufbare Tools zur Verfügung, sodass Entwickler von einem Assistenten in ihrer IDE aus Profile erstellen, Konvertierungen durchführen und Fehler untersuchen können: ohne zur. AWS-Managementkonsole
-
Profil- und Jobverwaltungs-APIs: Alle Profil- und Job-Management-APIs für Data Transformation Agents sind als MCP-Tools verfügbar, sodass Sie Jobs von jedem Client aus erstellen, bearbeiten, veröffentlichen und ausführen können. MCP-compatible
-
Jeder MCP-Client: funktioniert mit MCP-compatible IDEs und Assistenten, einschließlich Kiro und Cursor.
-
Dauerhafte Sitzungen: Unterstützt Sitzungen mit mehreren Durchgängen, sodass eine Debugging- oder Authoring-Konversation den Kontext enthält.
Anmerkung
Die Sync-Konvertierungsoperation (TransformData) und die Quellvalidierung (ValidateSource) sind MCP-Tools REST-only und werden möglicherweise nicht als solche angezeigt. Ihr Agent kann die REST-Aufrufe in Ihrem Namen erstellen und ausführen: siehe Schritt 3: Testen Sie das Anforderungsformat mit Synchronisierungskonvertierung.
Da MCP dieselbe API-Oberfläche AWS CLI und SDKs für Profil- und Auftragsoperationen verwendet, besteht für diese Workflows keine Funktionslücke zwischen der Arbeit in Ihrer IDE und der Bearbeitung von Code oder der. AWS-Managementkonsole Informationen Erste Schritte mit MCP zur Einrichtung und einem Beispiel-Workflow finden Sie unter.
