Corticon contribue au respect de la transparence dans la règle de couverture

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 :

référentielet je les ai copiés dans mon dossier de projet de règle :

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.

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 :

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—

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 :

En savoir plus sur Progress Corticon moteur de règles