Opinion • Health IT Policy – Imagine a hospital’s privacy policy so precise that software can enforce it in real time, or a clinical guideline that an app can execute without ambiguity. In a data-driven world, if a policy cannot be computed, should it exist at all? This article argues yes – policies in health systems must be computable by design, or we risk having rules that are merely wishful thinking on paper. We’ll compare traditional policy-making with computable policies (with a handy chart), explore how Amazon’s automated reasoning is turning abstract rules into enforceable code, and dive into how standards like FHIR make health policies machine-executable. The goal: show why computable policies aren’t just tech fantasy, but an urgent necessity for modern healthcare.

Traditional vs. Computable Policies: What’s the Difference?

Policies govern everything in healthcare – from patient data sharing and privacy, to clinical workflows and insurance rules. Traditionally, these policies live in binders and PDFs, written in natural language by committees and lawyers. They’re human-readable guidelines that rely on training and trust for implementation. Computable policies, on the other hand, are defined in a format that software can understand and act on automatically. Let’s contrast the two approaches:

     Enhancing narrative clinical guidance with computer-readable artifacts: Authoring FHIR implementation guides based on WHO recommendations - PMC
    ](<https://pmc.ncbi.nlm.nih.gov/articles/PMC8524423/#:~:text=Narrative%20clinical%20guidelines%20often%20contain,planning%20and%20sexually%20transmitted%20infections>)). | *Clarity:* Unambiguous and explicit – defined by formal syntax, leaving little room for interpretation. |

| Enforcement: Relies on people to interpret and follow (or manual audits for compliance). | Enforcement: Automatically enforced by software in real time (systems can compute compliance). | | Scalability: Difficult to scale – humans must read/remember/apply the rules (error-prone) (Custom policy checks help democratize automated reasoning - Amazon Science). | Scalability: Highly scalable – rules can be evaluated by computers across thousands of transactions consistently. | | Testing & Updates: Hard to test outcomes; changes require retraining humans. | Testing & Updates: Easy to simulate and verify outcomes with software; update the code and all systems adhere immediately. | | Consistency: Implementation may vary by individual or department, leading to inconsistency. | Consistency: One canonical version of the rule ensures the same decision everywhere, every time. |

In short: Traditional policies are written for people, computable policies are written for people and machines. As an old saying in software goes, “the code is the single source of truth.” For policies, making them code means the intended truth and the applied truth finally match.

Why Policies Should Be Computable (or Why Have Them at All?)

Let’s address the bold claim: if a policy cannot be computed, it should not exist. This doesn’t mean we abolish every high-level principle, but it does mean any operational policy should be defined precisely enough that a computer could execute it. Why is this so important?

• Eliminating Ambiguity: Natural language is wonderfully expressive – and terribly ambiguous. In healthcare, ambiguity can lead to errors or loopholes. A study of clinical guidelines noted they “contain assumptions, knowledge gaps, and ambiguities that make translation into an electronic computable format difficult” ( Enhancing narrative clinical guidance with computer-readable artifacts: Authoring FHIR implementation guides based on WHO recommendations - PMC ). In other words, if we leave policies as prose, different people or software might implement them differently, reducing their reliability. A computable policy forces us to pin down exact meanings (no more vague “appropriate measures” and “as soon as possible” phrases).
• Ensuring Consistent Enforcement: When policies are computable, you don’t have to hope everyone interprets the rules the same way – you can guarantee it. For example, in the cloud security world, AWS found that relying on manual review of access policies is “error prone and is not scalable” (Custom policy checks help democratize automated reasoning - Amazon Science). Simple text-based checks (like scanning for certain keywords) can miss subtle interactions in rules (Custom policy checks help democratize automated reasoning - Amazon Science). The same applies in healthcare: a privacy rule with multiple clauses might be consistently enforced only if a machine can evaluate all conditions every time. Computable policies let us apply the exact same logic across all instances, leaving no room for individual guesswork.
• Speed and Scalability: Health systems are large and complex. It’s impractical for a compliance officer to review every data access or for a clinician to manually ensure every step of a care pathway follows policy. Computable policies enable real-time decision-making. Software can instantly check if a data access request or a treatment plan complies with all applicable rules. This is how modern systems like electronic health records (EHRs) or health information exchanges can enforce consent directives or clinical protocols on the fly. With automation, scaling up doesn’t increase the risk of human oversight – the logic just runs as often as needed.
• Exhaustive Coverage and Safety: Perhaps the biggest advantage: a formal, computable policy can be analyzed exhaustively. Unlike a human who might think of a few scenarios or test cases, an algorithm can consider all possible combinations of conditions to see if any violate the intended rules. For instance, AWS’s automated reasoning tool (Zelkova) translates cloud policies into mathematical formulas and uses solvers to check them against all potential requests (Custom policy checks help democratize automated reasoning - Amazon Science) (Custom policy checks help democratize automated reasoning - Amazon Science). It’s effectively a proof, not a spot-check. In healthcare, this could mean verifying that no combination of patient attributes and requester roles would wrongfully expose sensitive data, for example. If we can’t articulate a policy in a way that supports this kind of rigorous check, that policy might hide corner cases that could be dangerous.
• Transparency and Accountability: Paradoxically, making policies computable can also make them more transparent. When a policy is coded, we can simulate scenarios (“what if” tests) and see exactly what decision would result, and why. This makes it easier to explain decisions (“the system denied access because rule X in the policy forbids sharing mental health notes with an external researcher without explicit consent”). Over time, these explanations build trust that the policy is being applied fairly and correctly. It’s hard to argue with a policy when its logic is literally laid out and consistently executed.
• Interoperability of Rules: In a digital health ecosystem, policies that are computable can be shared and standardized. An access rule encoded in a standard format could be ported from one hospital’s system to another’s or even published as part of regulations. This is analogous to the “Rules as Code” movement in government, which advocates that laws and regulations be published in both human language and code. As one government expert put it, “Rules as Code is an approach to create and publish regulations, legislation and policies as machine and human readable” (Four things you should know about Rules as Code). If multiple organizations adopt the same computable policy standard (say for patient consent), it ensures a common understanding and enforcement of that policy across the board – a huge win for interoperability and compliance.

Bottom line: A policy that isn’t precisely defined and executable might as well be a suggestion. In high-stakes environments like healthcare, suggestions aren’t good enough. Either we make the rule clear enough for a computer to apply, or we probably haven’t thought it through well enough to rely on it. As harsh as “should not exist” sounds, it’s a push to say: don’t put policies on paper and assume the job is done – encode them so the intent becomes reality.

Real-World Example: AWS’s Automated Reasoning – Abstracting Rules into Code

This all sounds great in theory, but is anyone actually doing it? Yes, and one pioneer is Amazon. Outside of healthcare, Amazon Web Services (AWS) has heavily invested in “automated reasoning” to turn policies and configurations into mathematical models that machines can analyze. Why? Because their scale and stakes (think security) demand nothing less.

One example is AWS Identity and Access Management (IAM) policies – essentially rules that govern who can do what in a cloud environment. AWS developed an internal tool called Zelkova that takes an IAM policy (written in JSON) and converts it into a precise logical formula (Custom policy checks help democratize automated reasoning - Amazon Science). For instance, imagine a simple storage bucket policy that says “Allow anyone to add objects to Bucket XYZ.” Zelkova will represent that policy as something like:

(Action = "s3:PutObject") ∧ (Resource = "arn:aws:s3:::BucketXYZ")