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.

Opération FHIR R4 $davinci-data-export pour HealthLake

Il s'agit d'une $davinci-data-export opération FHIR asynchrone à partir de laquelle vous pouvez exporter des données de santé. AWS HealthLake Cette opération prend en charge plusieurs types d'exportation, notamment l'attribution de membres (ATR), l'accès aux fournisseurs PDEx et Payer-to-Payer les API d'accès aux membres. Il s'agit d'une version spécialisée de l'$exportopération FHIR standard, conçue pour répondre aux exigences des guides de mise DaVinci en œuvre.

Fonctionnalités principales

Opération Endpoint

GET [base]/Group/[id]/$davinci-data-export
POST [base]/Group/[id]/$davinci-data-export

Paramètres de demande

Types de ressource pris en charge

Les types de ressources pris en charge dépendent du type d'exportation que vous spécifiez. Pour les exportations ATR, les types de ressources suivants sont pris en charge :

Pour les exportations PDex (accès fournisseur et accès membre), tous les types de ressources cliniques et de réclamations sont pris en charge en plus des types précédents. Payer-to-Payer Pour une liste complète des types de ressources pris en charge, consultez le US Core Implementation Guide (STU 6.1), le CARIN Blue Button Implementation Guide et le Da Vinci Prior Authorization Support Implementation Guide.

Types d'exportation

L'$davinci-data-exportopération prend en charge les types d'exportation suivants. Vous spécifiez le type d'exportation à l'aide du exportType paramètre.

ATR (hl7.fhir.us.davinci-atr)

Avec le type d'exportation ATR, vous pouvez exporter les données de la liste d'attribution des membres. Utilisez ce type d'exportation pour récupérer les ressources liées à l'attribution pour les membres d'un groupe. Pour plus d'informations, consultez l'opération d'exportation de Da Vinci ATR.

Types d'exportation PDex

Tous les types d'exportation PDex partagent les mêmes profils pris en charge et la même logique de filtrage. Pour plus d'informations, consultez l'API Da Vinci PDex Provider Access. Les profils suivants sont pris en charge :

Pour les exportations PDex, les ressources cliniques et de gestion des sinistres sont automatiquement découvertes pour chaque patient du groupe. Il n'est pas nécessaire de faire explicitement référence à ces ressources dans la ressource Groupe. L'opération recherche toutes les ressources du compartiment patient (telles que ObservationCondition,Coverage,RelatedPerson,MedicationRequest, etExplanationOfBenefit) appartenant aux patients attribués. Seuls Patient les types d'ATR (GroupPractitioner,,,Location) et ceux qui ne concernent pas le compartiment du patient nécessitent des références explicites dans le groupe. PractitionerRole Organization

Support du profil et logique d'inclusion

Pour les exportations PDex, l'$davinci-data-exportopération utilise des déclarations de profil dans l'meta.profileélément pour déterminer les ressources à inclure dans l'exportation.

ExplanationOfBenefit Gestion des ressources

ExplanationOfBenefitLes ressources (EOB) sont incluses ou exclues des exportations PDex en fonction de leurs meta.profile déclarations :

Transformation des données financières

Lorsque vous le définissez_includeEOB2xWoFinancial=true, l'opération transforme les ExplanationOfBenefit ressources CARIN BB 2.x en leurs profils de base correspondants en supprimant les données financières. Par exemple, une C4BB ExplanationOfBenefit Oral ressource est transformée enC4BB ExplanationOfBenefit Oral Basis, ce qui supprime les données financières de l'enregistrement conformément à la spécification FHIR.

L'opération supprime les éléments de données financières suivants dans deux scénarios : lorsqu'elle transforme une ressource financière CARIN BB 2.x en son profil de base (en utilisant_includeEOB2xWoFinancial=true), et lorsqu'elle supprime les données financières résiduelles d'une ressource CARIN BB 2.x Basis :

L'opération met également à jour les métadonnées du profil lors de la transformation :

Règles de détection des profils

L'opération utilise les règles suivantes pour détecter et valider les profils :

Filtrage temporel pour les exportations PDex

HealthLake applique un filtre temporel de 5 ans pour les types d'exportation Payer-to-Payer (hl7.fhir.us.davinci-pdex.p2p) et Member Access (hl7.fhir.us.davinci-pdex.member). Le filtre est basé sur la date de dernière mise à jour de la ressource. Les types d'exportation (hl7.fhir.us.davinci-pdexethl7.fhir.us.davinci-pdex#provider-snapshot) de Provider Access ne sont soumis à aucune limite temporelle. Pour les types d'exportation limités dans le temps, le filtre s'applique à toutes les ressources, à l'exception des types de ressources d'attribution de base suivants, qui sont toujours exportés quel que soit leur âge :

Ces ressources administratives et démographiques sont exemptées car elles fournissent un contexte essentiel pour les données exportées. Les exportations ATR ne sont soumises à aucun filtrage temporel.

Exemple de demandes

Les exemples suivants montrent comment démarrer des tâches d'exportation pour différents types d'exportation.

Exportation ATR

GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr

POST https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
Content-Type: application/json

{
  "DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
  "JobName": "attribution-export-job",
  "OutputDataConfig": {
    "S3Configuration": {
      "S3Uri": "s3://your-export-bucket/EXPORT-JOB",
      "KmsKeyId": "arn:aws:kms:region:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    }
  }
}

Exportation de l'accès au fournisseur avec suppression des données ExplanationOfBenefit financières

GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,MedicationRequest,ExplanationOfBenefit&exportType=hl7.fhir.us.davinci-pdex&_includeEOB2xWoFinancial=true

Exportation d'instantanés avec Provider Access

GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?exportType=hl7.fhir.us.davinci-pdex%23provider-snapshot

Payer-to-Payer exportation

GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Coverage,ExplanationOfBenefit,Condition,Procedure&exportType=hl7.fhir.us.davinci-pdex.p2p&_includeEOB2xWoFinancial=true

Exportation de l'accès aux membres pour un patient spécifique

GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,ExplanationOfBenefit,MedicationRequest&exportType=hl7.fhir.us.davinci-pdex.member&patient=Patient/example-patient-id

Exemple de réponse

{
  "datastoreId": "eaee622d8406b41eb86c0f4741201ff9",
  "jobStatus": "SUBMITTED",
  "jobId": "48d7b91dae4a64d00d54b70862f33f61"
}

Relations avec les ressources

L'opération exporte les ressources en fonction de leurs relations au sein de la liste d'attribution des membres :

Group (Attribution List)
├── Patient (Members)
├── Coverage → RelatedPerson (Subscribers)
├── Practitioner (Attributed Providers)
├── PractitionerRole → Location
└── Organization (Attributed Providers)

Sources de ressources

Gestion des emplois

Cycle de vie d'une tâche

Format de sortie

Gestion des erreurs

L'opération renvoie une mauvaise demande HTTP 400 avec un OperationOutcome pour les conditions suivantes :

Sécurité et autorisation

$davinci-data-exportest une opération groupée du backend autorisée via des autorisations IAM ou des scopes SMART on FHIR (OAuth 2.0) au niveau du système ; les demandes présentant des scopes au niveau du patient ou de l'utilisateur sont rejetées. L'opération n'évalue pas les ressources de consentement FHIR pour filtrer ou restreindre les données exportées.

Bonnes pratiques

Limitations

Ressources supplémentaires