Décisions basées sur les données versus formulaires dynamiques basés sur les décisions

Distinguer l’automatisation des décisions basée sur des règles à l’aide de données connues des décisions de collecte de données.

Décisions prises à partir de données connues

En utilisant d’innombrables approches, à peu près toutes les organisations ou agences gouvernementales que vous rencontrez a historiquement et est de plus en plus investi dans des logiciels qui permettent l’automatisation des décisions commerciales avec des résultats explicitement définis. Ce type d’automatisation des décisions n’est fonctionnellement qu’un calcul – le résultat est connu et peut être déterminé par un ensemble d’étapes connues. L’exemple évident est une calculatrice effectuant une équation mathématique, mais il y a une raison pour laquelle il n’y a pas eu d’évolution majeure sur le marché des calculatrices de notre vivant – les humains ont recherché et partagé des techniques mathématiques pendant cinq millénaires. L’automatisation réussie des décisions qui dépendent de prémisses mathématiques et utilisent des variables spécifiques à chaque cas nécessite l’expertise des personnes expérimentées dans cette industrie ou ce domaine d’études.

Ces résultats de décision sont d’abord documentés sous forme de règles métier par des personnes ayant une expertise dans le domaine, comme par exemple par un clinicien définissant les facteurs de risque d’un patient pour une maladie particulière, ou un ingénieur civil définissant des calculs de dégradation pour l’infrastructure municipale.

Des règles métier bien définies sont sans ambiguïté, brèves et précises. À partir de ceux-ci, des données standardisées et des modèles logiques peuvent être formulés, facilitant la communication sur les règles commerciales entre les individus (concepteurs, développeurs, rédacteurs techniques, etc.) créant des applications et des flux de travail, et les individus possédant l’expertise du domaine, tels que le clinicien ou l’ingénieur. . La mesure dans laquelle ce dernier personnage peut contribuer aux premiers’ La mise en œuvre de la logique applicative métier est donc le baromètre clé de l’utilité d’un système de gestion des règles métier, et précisément la philosophie directrice de la feuille de route historique et future de Progress Corticon.

Une caractéristique des pratiques de développement de logiciels pilotées par des modèles est l’abstraction : l’abstraction des points de données aux modèles de données, et de la logique d’application en tant que règles métier. En plus de permettre une meilleure collaboration interpersonnelle, les modèles de développement basés sur des modèles commencent par les aspects de la logique qui sont indépendants de l’endroit où le logiciel s’exécute (appareils/plates-formes/versions). Pour une application donnée, les règles métier et les données sur lesquelles les règles métier opèrent sont généralement homogènes, quel que soit l’appareil ou la plate-forme cible. Construire des applications en définissant d’abord ce que les règles vont faire avant de définir comment un modèle de conception est appelé programmation déclarative – l’acte de programmer dans des langages qui se conforment au modèle mental du développeur plutôt qu’au modèle opérationnel de la machine.i

L’applicabilité des systèmes de gestion des règles métier pour la construction de la logique d’application par le biais de la programmation déclarative est largement évidente dans les limites d’une décision explicite et confinée à prendre : lorsque Entity1.attribute a la valeur de “X,&rdquo ; affectez la valeur de Entity2.attribute à “Y.”

Plus concrètement, lorsque Patient.penicillinAllergic = “True,” affectez la valeur de Patient.therapyChoice à “Levofloxacin.” Un clinicien peut définir le modèle de données qui capturera toutes les valeurs potentielles que chaque ensemble de données patient pourrait contenir, et définir des actions basées sur des combinaisons spécifiées de ces valeurs.

Parce que nous modélisons des décisions à prendre, et non des déterminations subjectives, toutes les combinaisons potentielles des valeurs d’entrée pour Patient.penicillinAllergic ont une sortie connue. Tout ce que nous demandons à l’application lorsque nous utilisons cette logique, c’est de produire cette sortie spécifique connue – nous ne nous soucions pas nécessairement des étapes secrètes par lesquelles elle produit cette sortie. Nous tenons également pour acquis que les données d’entrée (par exemple, Patient.penicillinAllergic = “True”) sont déjà disponibles pour être utilisées avec les règles, prêtes à être transmises à un service de décision en attente de demandes.

Exemple d’un appel REST à un service de décision Corticon dans un scénario d’aide à la décision clinique

Décisions pour la collecte de données

Pour les scénarios où les données d’entrée pour un décision est saisie dans un formulaire par un utilisateur final, le paradigme des décisions à partir des données peut être étendu pour optimiser la logique de collecte de données dynamique présentée aux utilisateurs finaux.

Intéressé par la prise de décisions liées au comportement de formulaire dynamique ? Vous pouvez trouver un didacticiel complet avec des exemples en direct sur la page GitHub de Corticon.js Dynamic Forms, accessible ici.

Regardez le tutoriel

Source link