Data-Driven Decisions versus Decision-Driven Dynamic Forms

Distinguishing rule-driven decision automation using known data from decisions for gathering data.

Decisions Made from Known Data

Using countless approaches, just about every organization or government agency you encounter has historically—and is increasingly—invested in software that enables automation of business decisions with explicitly defined outcomes. This type of decision automation is functionally just a calculation—the outcome is known and can be determined through a known set of steps. The obvious example is a calculator performing a mathematical equation, but there’s a reason that there hasn’t been a major evolution in the calculator market in our lifetimes—humans have researched and shared mathematical techniques for five millennia. Successfully automating decisions that are contingent upon mathematical premises and use case-specific variables requires the expertise of the individuals experienced in that industry or field of study.

These decision outcomes are first documented as business rules by individuals with domain expertise, such as by a clinician defining a patient’s risk factors for a particular ailment, or a civil engineer defining degradation calculations for municipal infrastructure.

Well-defined business rules are unambiguous, brief and precise. From these, standardized data and logical models may be formulated, facilitating communication about the business rules between the individuals (designers, developers, technical writers etc.) building applications and workflows, and the individuals with the domain expertise, such as the clinician or engineer. The degree to which the latter persona can contribute to the formers’ implementation of business application logic is thus the key barometer of the utility of a business rule management system, and precisely the guiding philosophy of Progress Corticon’s historic and future roadmap.

A characteristic of model-driven software development practices is abstraction—abstraction from data points to data models, and of application logic as business rules. Beyond enabling better interpersonal collaboration, model driven development patterns start with the aspects of the logic which are agnostic to where software runs (devices/platforms/versions). For any given application, the business rules and the data upon which the business rules operate are generally homogenous regardless of the target device or platform. Building applications by first defining what the rules will be doing before defining how is a design pattern is called Declarative Programming—the act of programming in languages that conform to the mental model of the developer rather than the operational model of the machine.

The applicability of business rules management systems for building application logic through declarative programming is largely self-evident within the confines of an explicit, confined decision to be made: When Entity1.attribute has the value of “X,” assign the value of Entity2.attribute to be “Y.”

More practically, when Patient.penicillinAllergic = “True,” assign the value of Patient.therapyChoice to be “Levofloxacin.” A clinician can define the data model that will capture all potential values that each set of patient data might contain, and define actions based upon specified combinations of these values.

Because we’re modeling decisions to be made, not subjective determinations, all potential combinations of the input values for Patient.penicillinAllergic have a known output. All we’re asking from the application when using this logic is to produce that known, specific output—we don’t necessarily care the under-the-covers steps through which it produces that output. We’re likewise taking for granted that the input data (e.g., Patient.penicillinAllergic = “True”) is already available for use with the rules, ready to be passed to a decision service awaiting requests.

Example of a REST call to a Corticon Decision Service in a Clinical Decision Support scenario

Decisions for Gathering Data

For scenarios where the input data for a decision is being entered into a form by an end user, the decisions-from-data paradigm can be extended to optimize dynamic data-collection logic presented to end users.

Interested in driving decisions related to dynamic form behavior? You can find a full tutorial with live examples at the Corticon.js Dynamic Forms GitHub page, accessible here.

Access the Tutorial