Fermer

janvier 14, 2022

Corticon contribue au respect de la transparence dans la règle de couverture4 minutes de lecture



Le moteur de règles Progress Corticon fournit une voie alternative pour se conformer à la règle finale sur la transparence de la couverture.

Au grand soulagement des responsables de la mise en œuvre des systèmes pour les plans de santé collectifs et les assureurs maladie, les Centers for Medicare and Medicaid Services des États-Unis. (CMS) a annoncé en août 2021 qu'il retarderait l'application de la Règle finale sur la transparence de la couverture de six mois.

Pour tous les articles et services de santé couverts, la règle impose que la plupart des plans de santé collectifs et des émetteurs d'assurance maladie offrant une couverture d'assurance maladie sur les marchés individuels et collectifs rendent accessibles aux patients les informations personnalisées sur les frais remboursables et les tarifs négociés sous-jacents.

Le système de santé américain largement privatisé, en particulier depuis le début de la pandémie de COVID-19, a enseveli les Américains sous la dette médicale. La somme totale de la dette médicale des Américains en juillet 2021 était de 140 milliards de dollars, selon le Journal of the American Medical Association. La règle finale sur la transparence de la couverture est une étape vers la démystification des coûts des services et procédures médicaux individuels, qui ont tendance à être inconnus des patients jusqu'à ce qu'ils reçoivent la facture, et peuvent fluctuer énormément d'un patient à l'autre.

Comme pour la plupart des mesures réglementaires liées à la technologie visant à assurer la protection des consommateurs, le respect de la règle exige que les entités commerciales distinctes adoptent une norme de données ouverte commune. Compte tenu des nombreuses parties impliquées dans une seule facture médicale, l'absence de normalisation produit rapidement un labyrinthe de codes médicaux d'origine inconnue – un nœud qui s'est avéré trop immense pour que les vendeurs puissent le dénouer à temps pour la date à laquelle CMS initialement prévu pour commencer l'application de la règle, le 1er janvier 2022.

Le moteur de règles Progress Corticon offre une autre voie vers la conformité aux normes de données que de déployer l'effort nécessaire pour dénouer ce nœud. Avec Corticon, nous pouvons importer automatiquement une norme de données, telle que définie dans son schéma, garantissant ainsi qu'aucune logique mise en œuvre ne sortira des lignes de la norme prescrite.

Le texte de la règle finale de transparence dans la couverture illustre un va-et-vient de ses auteurs à savoir. quel format lisible par machine, le cas échéant, serait requis pour représenter ces données –

Les règles finales exigent que chaque fichier lisible par machine utilise un format ouvert non propriétaire. Les départements ont envisagé d'exiger des émetteurs et des TPA qu'ils publient les tarifs en réseau, les montants autorisés payés pour les services hors réseau et les informations sur les médicaments sur ordonnance en utilisant un format de fichier spécifique, à savoir JSON. Cependant, les départements sont d'avis qu'être trop normatif concernant le type de fichier imposera des coûts inutiles aux émetteurs et aux TPA malgré les avantages de JSON, à savoir que les fichiers JSON sont téléchargeables et lisibles pour de nombreux consommateurs de soins de santé, et le potentiel pour JSON pour simplifier la capacité des développeurs d'outils de transparence des prix à accéder aux données. Par conséquent, les départements exigent que les émetteurs et les TPA publient les informations sur le tarif du réseau, le montant autorisé et le prix des médicaments sur ordonnance dans trois fichiers distincts lisibles par machine en utilisant un format ouvert non exclusif.

Parce que les services de décision créés avec Corticon sont entièrement sans état, cela nous permet d'implémenter rapidement une logique conforme au schéma, quel que soit le format requis – il n'est pas nécessaire d'adapter Corticon en modifiant la norme de données prescrite.

Voici comment procéder :

Tout d'abord, je vais créer mon projet de règle et mon vocabulaire de règle :

Ensuite, j'ai pris les schémas JSON pour les cas d'utilisation respectifs du guide de transparence des prix CMS référentielet je les ai copiés dans mon dossier de projet de règle :

Générer un vocabulaire à partir d'un JSON document de schéma, Corticon examine le contenu du document pour identifier les entités dans le document, leurs attributs et leurs associations. Lorsque les types de données ne sont pas définis avec JSON, Corticon déduit le type de données des attributs en fonction des valeurs actuelles. Plus d'informations sur la façon dont Corticon déduit le schéma peuvent être trouvées ici.

Comme indiqué dans le GIF ci-dessous, la génération d'un vocabulaire de règles à partir d'un fichier JSON ne prend qu'un instant, remplissant automatiquement le modèle de données à partir duquel nous pouvons ensuite créer une logique métier. Une charge utile JSON peut également être utilisée pour la même fonction de génération de vocabulaire, mais l'utilisation du schéma offre un avantage essentiel : la création de types de données énumérés.

Une fois le vocabulaire de la règle généré, nous allons le glisser-déposer directement pour définir les règles métier dans Feuilles de règles Plus tard, une fois que nous serons prêts à passer aux tests, nous glisserons et déposerons du vocabulaire de règles sur Ruletests, et attribuerons des valeurs aux éléments de vocabulaire de règles représentant les données "d'entrée" pour la décision prise, ou importerons simplement cas de test existants.

En passant à une feuille de règles que j'ai créée dans le même projet de règles, nous pouvons voir l'avantage dérivé de ces types de données personnalisés qui ont été générés. Les types de données personnalisés sont essentiellement des améliorations apportées aux types de données "de base", comme des chaînes alphanumériques, des décimales ou des nombres entiers. Par exemple, le référentiel précédemment lié indique que le type de données de base de Billing_class est une chaîne, mais pas n'importe quelle chaîne :

Comme décrit dans la clarification technique FAQ de la règle, « Les tarifs négociés pour les réclamations professionnelles sont associés à un code de service. Le L'attribut de code de service dans le schéma permet de signaler différents tarifs négociés en fonction de la valeur de cet attribut. Les tarifs négociés pour les réclamations institutionnelles peuvent ne pas avoir de code de service CMS immédiatement associé au service… Pour permettre le signalement de divers tarifs négociés, CMS a ajouté un attribut contextuel appelé "billing_class" au schéma en réseau pour signaler si un tarif négocié est basé sur une réclamation professionnelle ou institutionnelle."

s changement dans le schéma a donc été reflété avec une balise enum sur cet attribut contextuel. Cette balise, dans le même fichier de schéma à partir duquel le vocabulaire a été généré, a demandé à Corticon de créer un type de données personnalisé : une chaîne énumérée appelée Billing_classEnumeration, avec les deux valeurs autorisées :

Maintenant, nous pouvons écrire des règles à l'aide de ce type de données Billing_classEnumeration, qui a été attribué comme type de données pour le attribut "Billing_class". Comme expliqué dans la FAQ liée ci-dessus, les tarifs négociés pour les réclamations intuitives peuvent ne pas toujours être accompagnés d'un code de service CMS, mais une réclamation professionnelle en aura toujours au moins un. Ainsi, nous pouvons vouloir créer une règle de validation des données qui affiche un avertissement s'il y a 0 service_codes associés à une réclamation où billing_type = professional. Nous pouvons implémenter cette logique dans Corticon via divers modèles de modélisation de règles : ici, nous le ferons wi th l'opérateur de règle de collecte "taille".

Les opérateurs de collecte sont beaucoup plus faciles à comprendre lorsque l'on considère comment le vocabulaire de la règle est "mappé" à une charge utile JSON. Lorsqu'un service de décision est appelé, Corticon mappe la charge utile JSON au modèle de données interne du vocabulaire Corticon pour permettre aux règles de s'exécuter dessus. Pour effectuer ce mappage, Corticon doit d'abord examiner la charge utile JSON pour identifier les objets de niveau supérieur dans le JSON et les entités de vocabulaire auxquelles ils correspondent. Une fois que les objets de niveau supérieur de la charge utile JSON sont mappés au modèle de vocabulaire, Corticon peut mapper tous les objets imbriqués dans le JSON aux associations du vocabulaire.

En générant le vocabulaire de règles à partir d'un schéma JSON, Corticon crée automatiquement un top l'entité de niveau supérieur qu'elle appelle la "racine", et toutes les autres entités créées ont reçu des associations qui montrent comment elles se rapportent à cette racine de niveau supérieur. Comme le montre l'un des exemples du guide de mise en œuvre, les données transmises concernant les tarifs dans le réseau, lorsqu'elles sont transmises au format JSON, seront structurées de manière similaire de manière hiérarchique. Ci-dessous, dans une autre visualisation du même exemple, les champs mis en surbrillance sont les objets de niveau supérieur mappés en tant qu'entités dans le vocabulaire de la règle Corticon. ="Achieving Compliance with the Transparency in Coverage Rule with Corticon body photo 6"/>

Dans l'exemple, nous pouvons voir que la racine de niveau supérieur a une entité enfant associée, In_network, qui a une entité enfant, Negotiated_prices, qui a une entité enfant, service_code, qui contient trois codes de service discrets.

Nous appelons ces trois codes de service une « collection » dans Corticon : tout nombre du même type d'entité (service_code) avec un Entité parent en commun (negotiated_prices) Pour écrire des règles à l'aide de collections, nous utilisons une syntaxe qui indique à Corticon d'évaluer cette collection de codes de service uniquement dans le contexte de l'entité parent commune, Negotiated_prices, et de tout autre objet parent ts jusqu'à l'objet racine. Chaque niveau parent/enfant est séparé par un simple point (.) :

Root.in_network.negotiated_rates.negotiated_prices.service_code

Pour faire la distinction entre les autres collections et pour garder les choses épurées, nous pouvons ensuite attribuer aux collections un alias

Maintenant, nous pouvons définir une règle qui comptera le nombre de codes de services au sein de cette collection spécifique (étant donné l'alias de collection négociationServiceCode), et si l'entité parente de cette collection, négociationPrices, a un attribut billing_class avec une valeur de 'professionnel', Corticon va envoyer un message de violation de données. L'attribut billing_class a reçu un type de données de Billing_classEnumeration, donc Corticon pré-remplira la liste déroulante conditionnelle de la règle avec les deux types de données énumérés s :

Corticon's vérificateur d'exhaustivité lorsqu'il est exécuté sur une feuille de règles dans laquelle des valeurs conditionnelles ont été définies pour un attribut avec un type de données énumérées, remplira automatiquement tous les autres scénarios potentiels. Ci-dessous, Corticon dit essentiellement : "Vous avez défini une règle à déclencher lorsque a) 'billing_class' a une valeur de 'professionnel' et b) la taille de 'negotiatedServiceCode' est inférieure ou égale à zéro. Sur la base des types de données de ces deux attributs, il existe au moins deux autres scénarios, qui ont été renseignés automatiquement dans les colonnes 2 et 3, pour lesquels vous n'avez défini aucune action. Rule with Corticon body photo 9" title="Atteindre la conformité avec la règle de transparence dans la couverture avec Corticon body photo 9"/>

Une autre illustration de la façon dont Corticon peut fonctionner sur des normes de données qui sont entièrement développées en dehors du champ d'application de Corticon est la possibilité d'importer des données de test pour tester les règles au fur et à mesure. Dans l'exemple d'implémentation précédemment référencél'objet JSON est structuré pour être conforme au schéma défini et spécifie des valeurs pour les différents champs de données dans le manière dont ils pourraient être communiqués de manière lisible par machine conformément à la norme.

Envisagez un scénario étendu où cet objet JSON est en fait la charge utile JSON "d'entrée" qu'une application appelante transmettra à un C service de décision orticon, dans lequel la charge utile contient les données à évaluer par rapport aux règles du service de décision. Dans ce scénario, le fait d'avoir des données de test hébergées sous la forme de fichiers JSON comme celui-ci signifie que nous pouvons directement importer ce JSON en tant qu'entrée dans un ruletest :

Résumé

Il serait difficile de trouver un détracteur particulièrement bruyant de la règle finale sur le prix transparence des coûts des soins de santé, qui oblige les prestataires à fournir aux patients des estimations de bonne foi pour les traitements et les procédures médicales.Cependant, le délai repoussé pour sa mise en œuvre par les prestataires indique le nombre de pièces mobiles impliquées dans les modifications architecturales nécessaires pour s'adapter à la normalisation requise.[19659003]Les implémenteurs peuvent concevoir de manière à étendre la portée de leurs systèmes de facturation actuels et de leurs dépendances, avec des investissements supplémentaires visant simplement à su face aux données de coût que la règle spécifie qu'ils fournissent aux patients. Les implémenteurs de Corticon peuvent adopter une approche différente, qui atténue le risque d'exposition future aux implémentations d'exercices d'incendie et aux dommages-intérêts punitifs en cas de non-conformité. En extrayant les composants d'un modèle de données dans le même vocabulaire de règles Corticon avec lequel la logique métier est modélisée, la conformité aux normes de données peut être traitée comme la première étape et marquée comme terminée après quelques clics.

En savoir plus sur Progress Corticon moteur de règles




Source link

0 Partages