Traitement intelligent des documents avec AWS AI et les services d'analyse dans le secteur de l'assurance : partie 2

In Partie 1 de cette série, nous avons discuté du traitement intelligent des documents (IDP) et de la manière dont l'IDP peut accélérer les cas d'utilisation du traitement des réclamations dans le secteur de l'assurance. Nous avons discuté de la manière dont nous pouvons utiliser les services AWS AI pour catégoriser avec précision les documents de réclamation ainsi que les pièces justificatives. Nous avons également discuté de la manière d'extraire différents types de documents dans un dossier de réclamation d'assurance, tels que des formulaires, des tableaux ou des documents spécialisés tels que des factures, des reçus ou des pièces d'identité. Nous avons examiné les défis des processus de documents hérités, qui prennent du temps, sont sujets aux erreurs, coûteux et difficiles à traiter à grande échelle, et comment vous pouvez utiliser les services AWS AI pour vous aider à mettre en œuvre votre pipeline IDP.

Dans cet article, nous vous présentons les fonctionnalités avancées d'IDP pour l'extraction, l'interrogation et l'enrichissement de documents. Nous examinons également comment utiliser davantage les informations structurées extraites des données de réclamation pour obtenir des informations à l'aide d'AWS Analytics et des services de visualisation. Nous soulignons comment les données structurées extraites de l'IDP peuvent aider à lutter contre les réclamations frauduleuses à l'aide des services AWS Analytics.

Vue d'ensemble de la solution

Le schéma suivant illustre les phases si IDP utilise les services AWS AI. Dans la partie 1, nous avons discuté des trois premières phases du flux de travail IDP. Dans cet article, nous développons l'étape d'extraction et les phases restantes, qui incluent l'intégration d'IDP aux services AWS Analytics.

Nous utilisons ces services d'analyse pour obtenir des informations et des visualisations supplémentaires, et pour détecter les réclamations frauduleuses à l'aide de données structurées et normalisées d'IDP. Le diagramme suivant illustre l'architecture de la solution.

Les phases dont nous discutons dans cet article utilisent les services clés suivants :

• Amazon Comprehend Medical est un service de traitement du langage naturel (NLP) éligible à la HIPAA qui utilise des modèles d'apprentissage automatique (ML) qui ont été pré-formés pour comprendre et extraire des données de santé à partir de textes médicaux, tels que des ordonnances, des procédures ou des diagnostics.
• Colle AWS fait partie de la pile de services AWS Analytics et est un service d'intégration de données sans serveur qui facilite la découverte, la préparation et la combinaison de données pour l'analyse, le ML et le développement d'applications.
• Redshift d'Amazon est un autre service de la pile Analytics. Amazon Redshift est un service d'entrepôt de données entièrement géré à l'échelle du pétaoctet dans le cloud.

Pré-requis

Avant de commencer, consultez Partie 1 pour un aperçu de haut niveau du cas d'utilisation de l'assurance avec IDP et des détails sur les étapes de capture et de classification des données.

Pour plus d'informations sur les exemples de code, reportez-vous à notre Repo GitHub.

Phase d'extraction

Dans la partie 1, nous avons vu comment utiliser les API Amazon Textract pour extraire des informations telles que des formulaires et des tableaux à partir de documents, et comment analyser des factures et des documents d'identité. Dans cet article, nous améliorons la phase d'extraction avec Amazon Comprehend pour extraire les entités par défaut et personnalisées spécifiques aux cas d'utilisation personnalisés.

Les compagnies d'assurance rencontrent souvent du texte dense dans les demandes de réclamation d'assurance, comme la lettre récapitulative de sortie d'un patient (voir l'image d'exemple suivante). Il peut être difficile d'extraire automatiquement des informations de ces types de documents lorsqu'il n'y a pas de structure définie. Pour résoudre ce problème, nous pouvons utiliser les méthodes suivantes pour extraire les informations commerciales clés du document :

Extraire les entités par défaut avec l'API Amazon Comprehend DetectEntities

Nous exécutons le code suivant sur l'exemple de document de transcription médicale :

comprehend = boto3.client('comprehend') 

response = comprehend.detect_entities( Text=text, LanguageCode='en')

#print enitities from the response JSON

for entity in response['Entities']:
    print(f'{entity["Type"]} : {entity["Text"]}')

La capture d'écran suivante montre une collection d'entités identifiées dans le texte d'entrée. La sortie a été raccourcie pour les besoins de cet article. Se référer au GitHub repo pour une liste détaillée des entités.

Extraire des entités personnalisées avec la reconnaissance d'entités personnalisées Amazon Comprehend

La réponse du DetectEntities L'API inclut les entités par défaut. Cependant, nous souhaitons connaître des valeurs d'entité spécifiques, telles que le nom du patient (indiqué par l'entité par défaut PERSON), ou l'ID du patient (indiqué par l'entité par défaut OTHER). Pour reconnaître ces entités personnalisées, nous entraînons un modèle de reconnaissance d'entité personnalisée Amazon Comprehend. Nous vous recommandons de suivre les étapes complètes de formation et de déploiement d'un modèle de reconnaissance d'entité personnalisé dans le Repo GitHub.

Après avoir déployé le modèle personnalisé, nous pouvons utiliser la fonction d'assistance get_entities() pour récupérer des entités personnalisées comme PATIENT_NAME ainsi que PATIENT_D à partir de la réponse de l'API :

def get_entities(text):
try:
    #detect entities
    entities_custom = comprehend.detect_entities(LanguageCode="en",
                      Text=text, EndpointArn=ER_ENDPOINT_ARN) 
    df_custom = pd.DataFrame(entities_custom["Entities"], columns = ['Text',  
                'Type', 'Score'])
    df_custom = df_custom.drop_duplicates(subset=['Text']).reset_index()
    return df_custom
except Exception as e:
    print(e)

# call the get_entities() function 
response = get_entities(text) 
#print the response from the get_entities() function
print(response)

La capture d'écran suivante montre nos résultats.

Phase d'enrichissement

Dans la phase d'enrichissement des documents, nous effectuons des fonctions d'enrichissement sur les documents liés à la santé pour en tirer des informations précieuses. Nous examinons les types d'enrichissement suivants :

• Extraire la langue spécifique au domaine – Nous utilisons Amazon Comprehend Medical pour extraire des ontologies spécifiques à la médecine comme ICD-10-CM, RxNorm et SNOMED CT
• Caviarder les informations sensibles – Nous utilisons Amazon Comprehend pour expurger les informations personnellement identifiables (PII) et Amazon Comprehend Medical pour expurger les informations de santé protégées (PHI).

Extraire des informations médicales d'un texte médical non structuré

Les documents tels que les notes des prestataires médicaux et les rapports d'essais cliniques comprennent un texte médical dense. Les assureurs doivent identifier les relations entre les informations de santé extraites de ce texte dense et les relier à des ontologies médicales telles que les codes ICD-10-CM, RxNorm et SNOMED CT. Ceci est très utile pour automatiser les flux de travail de capture, de validation et d'approbation des réclamations pour les compagnies d'assurance afin d'accélérer et de simplifier le traitement des réclamations. Regardons comment nous pouvons utiliser Amazon Comprehend Medical InferICD10CM API pour détecter d'éventuelles conditions médicales en tant qu'entités et les lier à leurs codes :

cm_json_data = comprehend_med.infer_icd10_cm(Text=text)

print("nMedical codingn========")

for entity in cm_json_data["Entities"]:
      for icd in entity["ICD10CMConcepts"]:
           description = icd['Description']
           code = icd["Code"]
           print(f'{description}: {code}')

Pour le texte d'entrée, que nous pouvons transmettre depuis Amazon Textract DetectDocumentText API, le InferICD10CM L'API renvoie la sortie suivante (la sortie a été abrégée par souci de concision).

De même, nous pouvons utiliser Amazon Comprehend Medical InferRxNorm API pour identifier les médicaments et les InferSNOMEDCT API pour détecter les entités médicales dans les documents d'assurance liés aux soins de santé.

Effectuer la rédaction des PII et PHI

Les packages de réclamations d'assurance nécessitent beaucoup de conformité et de réglementation en matière de confidentialité, car ils contiennent à la fois des données PII et PHI. Les assureurs peuvent réduire le risque de non-conformité en supprimant des informations telles que les numéros de police ou le nom du patient.

Examinons un exemple de résumé de sortie d'un patient. Nous utilisons Amazon Comprehend DetectPiiEntities API pour détecter les entités PII dans le document et protéger la confidentialité du patient en masquant ces entités :

resp = call_textract(input_document = f's3://{data_bucket}/idp/textract/dr-note-sample.png')
text = get_string(textract_json=resp, output_type=[Textract_Pretty_Print.LINES])

# call Amazon Comprehend Detect PII Entities API
entity_resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en") 

pii = []
for entity in entity_resp['Entities']:
      pii_entity={}
      pii_entity['Type'] = entity['Type']
      pii_entity['Text'] = text[entity['BeginOffset']:entity['EndOffset']]
      pii.append(pii_entity)
print(pii)

Nous obtenons les entités PII suivantes dans la réponse du detect_pii_entities() API:

Nous pouvons ensuite expurger les entités PII qui ont été détectées à partir des documents en utilisant la géométrie de la boîte englobante des entités du document. Pour cela, nous utilisons un outil d'aide appelé amazon-textract-overlayer. Pour plus d'informations, reportez-vous à Superposition de texte. Les captures d'écran suivantes comparent un document avant et après la rédaction.

Similaire à Amazon Comprehend DetectPiiEntities API, nous pouvons également utiliser le DetectPHI API pour détecter les données PHI dans le texte clinique examiné. Pour plus d'informations, reportez-vous à Détecter les PHI.

Phase de révision et de validation

Dans la phase d'examen et de validation des documents, nous pouvons désormais vérifier si le dossier de réclamation répond aux exigences de l'entreprise, car nous disposons de toutes les informations recueillies à partir des documents du dossier des étapes précédentes. Nous pouvons le faire en introduisant un humain dans la boucle qui peut examiner et valider tous les champs ou simplement un processus d'approbation automatique pour les réclamations à faible coût avant d'envoyer le package aux applications en aval. On peut utiliser IA augmentée d'Amazon (Amazon A2I) pour automatiser le processus d'examen humain pour le traitement des réclamations d'assurance.

Maintenant que nous avons toutes les données requises extraites et normalisées à partir du traitement des réclamations à l'aide des services d'IA pour IDP, nous pouvons étendre la solution pour l'intégrer aux services AWS Analytics tels qu'AWS Glue et Amazon Redshift afin de résoudre des cas d'utilisation supplémentaires et de fournir des analyses et des visualisations supplémentaires.

Détecter les réclamations d'assurance frauduleuses

Dans cet article, nous mettons en œuvre une architecture sans serveur dans laquelle les données extraites et traitées sont stockées dans un lac de données et sont utilisées pour détecter les réclamations d'assurance frauduleuses à l'aide de ML. Nous utilisons Service de stockage simple Amazon (Amazon S3) pour stocker les données traitées. Nous pouvons alors utiliser Colle AWS or Amazon DME pour nettoyer les données et ajouter des champs supplémentaires pour les rendre consommables pour les rapports et le ML. Après cela, nous utilisons Amazon Redshift ML pour créer un modèle ML de détection de fraude. Enfin, nous créons des rapports à l'aide de Amazon QuickSight pour avoir un aperçu des données.

Configurer le schéma externe Amazon Redshift

Pour les besoins de cet exemple, nous avons créé un exemple de jeu de données émule la sortie d'un processus ETL (extraction, transformation et chargement) et utilise le catalogue de données AWS Glue comme catalogue de métadonnées. Tout d'abord, nous créons une base de données nommée idp_demo dans le catalogue de données et un schéma externe dans Amazon Redshift appelé idp_insurance_demo (voir le code suivant). Nous utilisons un Gestion des identités et des accès AWS (IAM) pour accorder des autorisations au cluster Amazon Redshift pour accéder à Amazon S3 et Amazon Sage Maker. Pour plus d'informations sur la configuration de ce rôle IAM avec le moindre privilège, consultez Mettre en cluster et configurer la configuration pour l'administration d'Amazon Redshift ML.

CREATE EXTERNAL SCHEMA idp_insurance_demo
FROM DATA CATALOG
DATABASE 'idp_demo' 
IAM_ROLE '<<>>'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

Créer une table externe Amazon Redshift

L'étape suivante consiste à créer une table externe dans Amazon Redshift faisant référence à l'emplacement S3 où se trouve le fichier. Dans ce cas, notre fichier est un fichier texte séparé par des virgules. Nous souhaitons également ignorer la ligne d'en-tête du fichier, qui peut être configurée dans la section des propriétés du tableau. Voir le code suivant :

create external table idp_insurance_demo.claims(id INTEGER,
date_of_service date,
patients_address_city VARCHAR,
patients_address_state VARCHAR,
patients_address_zip VARCHAR,
patient_status VARCHAR,
insured_address_state VARCHAR,
insured_address_zip VARCHAR,
insured_date_of_birth date,
insurance_plan_name VARCHAR,
total_charges DECIMAL(14,4),
fraud VARCHAR,
duplicate varchar,
invalid_claim VARCHAR
)
row format delimited
fields terminated by ','
stored as textfile
location '<<>>'
table properties ( 'skip.header.line.count'='1');

Créer des ensembles de données d'entraînement et de test

Après avoir créé la table externe, nous préparons notre ensemble de données pour ML en le divisant en ensemble d'apprentissage et en ensemble de test. Nous créons une nouvelle table externe appelée claim_train, qui se compose de tous les enregistrements avec ID <= 85000 de la table des réclamations. Il s'agit de l'ensemble de formation sur lequel nous formons notre modèle ML.

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_train
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/train'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id <= 850000

Nous créons une autre table externe appelée claim_test qui se compose de tous les enregistrements avec ID> 85000 pour être l'ensemble de test sur lequel nous testons le modèle ML :

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_test
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/test'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id > 850000

Créer un modèle ML avec Amazon Redshift ML

Maintenant, nous créons le modèle en utilisant le CRÉER UN MODÈLE commande (voir le code suivant). Nous sélectionnons les colonnes pertinentes dans le claims_train table qui peut déterminer une transaction frauduleuse. Le but de ce modèle est de prédire la valeur de fraud colonne; Donc, fraud est ajouté en tant que cible de prédiction. Une fois le modèle formé, il crée une fonction nommée insurance_fraud_model. Cette fonction est utilisée pour l'inférence lors de l'exécution d'instructions SQL pour prédire la valeur de fraud colonne pour les nouveaux enregistrements.

CREATE MODEL idp_insurance_demo.insurance_fraud_model
FROM (SELECT 
total_charges ,
fraud ,
duplicate,
invalid_claim
FROM idp_insurance_demo.claims_train
)
TARGET fraud
FUNCTION insurance_fraud_model
IAM_ROLE '<<>>'
SETTINGS (
S3_BUCKET '<<>>'
);

Évaluer les métriques du modèle ML

Après avoir créé le modèle, nous pouvons exécuter des requêtes pour vérifier l'exactitude du modèle. Nous utilisons le insurance_fraud_model fonction pour prédire la valeur de fraud colonne pour les nouveaux enregistrements. Exécutez la requête suivante sur le claims_test tableau pour créer une matrice de confusion :

SELECT 
fraud,
idp_insurance_demo.insurance_fraud_model (total_charges ,duplicate,invalid_claim ) as fraud_calculcated,
count(1)
FROM idp_insurance_demo.claims_test
GROUP BY fraud , fraud_calculcated;

Détecter la fraude à l'aide du modèle ML

Après avoir créé le nouveau modèle, à mesure que de nouvelles données sur les réclamations sont insérées dans l'entrepôt de données ou le lac de données, nous pouvons utiliser le insurance_fraud_model fonction de calcul des transactions frauduleuses. Pour ce faire, nous chargeons d'abord les nouvelles données dans une table temporaire. Ensuite on utilise le insurance_fraud_model fonction pour calculer la fraud drapeau pour chaque nouvelle transaction et insérer les données avec le drapeau dans la table finale, qui dans ce cas est le claims tableau.

Visualisez les données des sinistres

Lorsque les données sont disponibles dans Amazon Redshift, nous pouvons créer des visualisations à l'aide de QuickSight. Nous pouvons ensuite partager les tableaux de bord QuickSight avec les utilisateurs professionnels et les analystes. Pour créer le tableau de bord QuickSight, vous devez d'abord créer un jeu de données Amazon Redshift dans QuickSight. Pour obtenir des instructions, reportez-vous à Créer un jeu de données à partir d'une base de données.

Après avoir créé le jeu de données, vous pouvez créer une nouvelle analyse dans QuickSight à l'aide du jeu de données. Voici quelques exemples de rapports que nous avons créés :

• Nombre total de réclamations par État, regroupées par fraud champ – Ce graphique nous montre la proportion de transactions frauduleuses par rapport au nombre total de transactions dans un État particulier.
• Somme de la valeur totale en dollars des réclamations, regroupées par fraud champ – Ce graphique nous montre la proportion du montant en dollars des transactions frauduleuses par rapport au montant total en dollars des transactions dans un État particulier.
• Nombre total de transactions par compagnie d'assurance, regroupées par fraud champ – Ce tableau nous montre combien de réclamations ont été déposées pour chaque compagnie d'assurance et combien d'entre elles sont frauduleuses.

• Somme totale des transactions frauduleuses par État affichée sur une carte des États-Unis - Ce graphique montre simplement les transactions frauduleuses et affiche le total des frais pour ces transactions par état sur la carte. La nuance de bleu plus foncée indique des charges totales plus élevées. Nous pouvons analyser cela plus en détail par ville dans cet état et codes postaux avec la ville pour mieux comprendre les tendances.

Nettoyer

Pour éviter que des frais futurs ne soient facturés à votre compte AWS, supprimez les ressources que vous avez provisionnées lors de la configuration en suivant les instructions du Rubrique nettoyage dans notre dépôt.

Conclusion

Dans cette série en deux parties, nous avons vu comment créer un pipeline IDP de bout en bout avec peu ou pas d'expérience en ML. Nous avons exploré un cas d'utilisation du traitement des réclamations dans le secteur de l'assurance et comment IDP peut aider à automatiser ce cas d'utilisation à l'aide de services tels qu'Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical et Amazon A2I. Dans la partie 1, nous avons montré comment utiliser les services AWS AI pour l'extraction de documents. Dans la partie 2, nous avons prolongé la phase d'extraction et procédé à l'enrichissement des données. Enfin, nous avons étendu les données structurées extraites de l'IDP pour des analyses supplémentaires et créé des visualisations pour détecter les réclamations frauduleuses à l'aide des services AWS Analytics.

Nous vous recommandons de consulter les sections sur la sécurité du Extrait d'Amazon, Amazon comprendreet Amazon A2I documentation et en suivant les directives fournies. Pour en savoir plus sur la tarification de la solution, consultez les détails de tarification de Extrait d'Amazon, Amazon comprendreet Amazon A2I.

À propos des auteurs

Chinmayee Rane est architecte de solutions spécialisées en IA/ML chez Amazon Web Services. Elle est passionnée par les mathématiques appliquées et l'apprentissage automatique. Elle se concentre sur la conception de solutions intelligentes de traitement de documents pour les clients AWS. En dehors du travail, elle aime danser la salsa et la bachata.

Oudaï Narayanan est architecte de solutions spécialisées en analyse chez AWS. Il aime aider les clients à trouver des solutions innovantes aux défis commerciaux complexes. Ses principaux domaines d'intérêt sont l'analyse de données, les systèmes de mégadonnées et l'apprentissage automatique. Dans ses temps libres, il aime faire du sport, regarder des émissions de télévision et voyager.

Sonali Sahou dirige l'équipe d'architectes de solutions IA/ML pour le traitement intelligent des documents chez Amazon Web Services. Elle est une technophile passionnée et aime travailler avec les clients pour résoudre des problèmes complexes en utilisant l'innovation. Son principal domaine d'intérêt est l'intelligence artificielle et l'apprentissage automatique pour le traitement intelligent des documents.