How Encrypted Decisions Could Change Healthcare

Every clinical decision support system in use today reads patient data in plaintext. When a physician orders a medication, the CDS system reads the patient's current medication list to check for interactions. When a nurse enters vital signs, the system reads the values to check against clinical thresholds. When a surgeon schedules a procedure, the system reads the patient's allergy list, medication list, and problem list to generate pre-operative alerts. The system needs to understand the data to make recommendations about the data.

This model has been the only option for as long as clinical decision support has existed. The data must be readable for the rules to be evaluable. A drug interaction database cannot check for interactions between two encrypted medication codes if it cannot read the codes. A clinical threshold cannot be compared against an encrypted lab value if the threshold engine cannot read the value. Decision support requires data comprehension, and data comprehension requires decryption.

This assumption is wrong. Fully homomorphic encryption enables computation on encrypted data that produces results mathematically equivalent to the same computation on plaintext data. A drug interaction check can be performed on encrypted medication codes. A lab value threshold comparison can be performed on encrypted results. An eligibility determination can be performed on encrypted insurance records. The decision system never reads the data. It processes encrypted values and produces encrypted results. And the results are correct.

This is not a theoretical possibility. H33's FHE platform performs these computations at latencies compatible with real-time clinical workflows. What follows is an examination of what encrypted decision systems mean for healthcare, where they apply, and what changes when the systems that advise clinicians can no longer see the patients they are advising about.

The Data Exposure Surface of Clinical Decision Support

Clinical decision support has grown from simple drug interaction checking to a pervasive layer of clinical intelligence that touches nearly every aspect of healthcare delivery. Modern CDS systems provide alerts for drug-drug interactions, drug-allergy interactions, dose range checking, duplicate therapy detection, clinical guideline compliance, sepsis screening, fall risk assessment, venous thromboembolism prophylaxis, and dozens of other clinical scenarios.

Each of these functions requires access to different categories of patient data. Drug interaction checking requires the medication list. Dose range checking requires the medication, the dose, and often the patient's weight and renal function. Sepsis screening requires vital signs, lab results, and clinical documentation. Fall risk assessment requires age, mobility status, medication list, and cognitive assessment results.

In an integrated EHR system, the CDS engine typically has access to the entire patient record. The engine may only query specific data elements for a given rule, but the underlying system has the technical capability to read everything. The access controls that limit CDS data access are software controls, not cryptographic controls. A compromised CDS engine has access to every patient record in the system.

This becomes particularly concerning as CDS systems move to cloud-based and third-party-hosted models. Smaller healthcare organizations that cannot build and maintain their own CDS rule sets subscribe to cloud-based CDS services. Patient data is transmitted to the cloud service for evaluation. The service reads the data, evaluates its rules, and returns recommendations. The cloud service is a business associate that handles plaintext PHI for millions of patients across hundreds of healthcare organizations.

The concentration of patient data at cloud CDS vendors creates high-value targets. A breach at a major CDS vendor could expose patient records from every healthcare organization that uses the service. The clinical data transmitted for decision support is among the most sensitive in healthcare: active medication lists, current diagnoses, recent lab results, allergy histories. This is the data that reveals what conditions a patient has, what treatments they are receiving, and what their clinical trajectory looks like.

Encrypted Drug Interaction Checking

Drug interaction checking is one of the most common CDS functions. When a prescriber orders a new medication, the system checks the new medication against all current medications for known interactions. The interaction database typically contains hundreds of thousands of drug-drug interaction pairs, each classified by severity and clinical significance.

In an encrypted interaction checking system, the process works differently. The patient's current medication list is encrypted. Each medication is represented as an encrypted code. The newly ordered medication is also encrypted. The interaction database is structured for encrypted lookup: each interaction pair is stored as encrypted code pairs.

The FHE engine performs an encrypted comparison. For each medication on the patient's encrypted list, it evaluates whether the encrypted pair (current medication, new medication) matches any encrypted pair in the interaction database. The comparison produces an encrypted result: match or no match, and if match, the encrypted severity classification.

The prescriber's system decrypts the result and receives the same alert they would have received from a plaintext system: "Severe interaction between [medication A] and [medication B]. Consider alternative." But the system that performed the check never knew what medication A or medication B was. It processed encrypted codes and produced encrypted results.

The performance requirements for drug interaction checking are modest. An alert must appear within a few seconds of the order being entered. H33's FHE engine processes a batch of 32 encrypted comparisons in under 1.4 milliseconds. A patient with 15 current medications requires 15 comparisons against the new order. This completes in well under the latency budget for clinical alerting.

Encrypted Formulary and Coverage Checks

When a prescriber selects a medication, the system frequently checks whether the medication is covered by the patient's insurance plan. This formulary check requires the system to know the medication, the patient's insurance plan, and the plan's formulary. The result determines whether the patient will face a low copay, a high copay, or need prior authorization.

A formulary check on encrypted data proceeds without the checking system knowing the medication or the insurance plan details. The encrypted medication code is compared against the encrypted formulary for the encrypted plan identifier. The result is an encrypted coverage determination: covered at tier 1, covered at tier 2, requires prior authorization, or not covered. The prescriber's system decrypts the result and displays it.

What makes this significant is that formulary checks often reveal sensitive clinical information. A prescription for antiretroviral medication reveals an HIV diagnosis. A prescription for methadone reveals opioid use disorder treatment. A prescription for specific oncology agents reveals a cancer diagnosis. When the formulary checking system processes these checks on encrypted data, it cannot determine what condition the medication treats. The coverage determination is produced without the checking system learning anything about the patient's health status.

This protection extends through the entire pharmacy benefit chain. The pharmacy benefit manager that maintains the formulary processes encrypted queries. The prior authorization system that evaluates requests against clinical criteria processes encrypted clinical data. The appeals process that reviews denied authorizations processes encrypted documentation. At no point does the PBM's decision infrastructure need to see the patient's actual medication or diagnosis to determine coverage.

Encrypted Eligibility and Authorization

Insurance eligibility verification and prior authorization are among the most data-intensive processes in healthcare administration. An eligibility check must verify that the patient is covered, that the provider is in-network, that the requested service is a covered benefit, and that any applicable benefit limits have not been exceeded. Prior authorization must evaluate clinical criteria, medical necessity guidelines, and plan-specific requirements.

These processes currently require complete access to patient insurance records, clinical documentation, and plan benefit details. The systems that perform eligibility verification and prior authorization are operated by health plans, delegated to utilization management companies, or run by clearinghouses. Each of these entities processes plaintext patient data.

An FHE-based eligibility system receives encrypted queries. The patient's encrypted member identifier is matched against the encrypted enrollment database. The encrypted service code is checked against the encrypted benefit schedule. The encrypted provider identifier is checked against the encrypted network roster. The result, eligible or not eligible, in-network or out-of-network, is produced without the eligibility system reading any plaintext values.

For prior authorization, the encrypted clinical documentation is evaluated against encrypted medical necessity criteria. The authorization system determines whether the encrypted diagnosis and encrypted procedure meet the encrypted criteria for approval. The system produces an encrypted authorization decision: approved, denied with encrypted reason code, or pended for encrypted additional information request.

The H33 Health platform handles the encryption boundaries. Clinical systems submit authorization requests in their standard format. The H33 integration layer encrypts the request, routes it through FHE-based evaluation, and returns the encrypted result to the requesting system for decryption. The workflow from the clinician's perspective is unchanged. The privacy properties of the interaction are fundamentally different.

Encrypted Clinical Scoring and Risk Assessment

Healthcare increasingly relies on clinical scoring systems. Sepsis screening tools calculate scores from vital signs, lab values, and clinical observations. Fall risk assessments combine age, medication count, mobility status, and cognitive function into a risk score. Cardiac risk calculators use blood pressure, cholesterol levels, smoking status, and diabetes status to estimate 10-year cardiovascular risk.

Each of these scoring tools reads patient data to produce a numeric result. The sepsis screening tool reads temperature, heart rate, respiratory rate, white blood cell count, and mental status. It combines these values according to a scoring algorithm and produces a score that triggers or does not trigger a clinical alert.

An encrypted scoring system performs the same calculation on encrypted values. Encrypted temperature is compared against encrypted thresholds. Encrypted heart rate is evaluated against encrypted ranges. The encrypted values are combined according to the scoring algorithm, and the result is an encrypted score. The score is decrypted at the point of care, where the clinician who has legitimate access to the patient's data receives the alert.

The encrypted scoring system is particularly valuable for cloud-based scoring services. A hospital that subscribes to a cloud-based sepsis prediction model currently sends patient vital signs and lab values to the cloud service. The cloud service processes the data and returns a prediction. With encrypted scoring, the cloud service processes encrypted data and returns encrypted predictions. The model's accuracy is preserved because FHE guarantees computational equivalence. The patient's data remains private because the cloud service never accesses plaintext values.

This enables a new category of clinical AI deployment. Machine learning models that predict patient outcomes can be deployed as encrypted inference services. The model processes encrypted patient features and produces encrypted predictions. The healthcare organization benefits from the model's predictive capability without sharing patient data with the model operator. The model operator benefits from being able to serve multiple healthcare organizations without the compliance burden of handling their patients' PHI.

Attestation of Encrypted Decisions

Encrypted decision systems solve the data exposure problem. But healthcare operations also require accountability. When a CDS system generates an alert, there must be a record that the alert was generated, that it was presented to the clinician, and how the clinician responded. When an eligibility system approves or denies a request, there must be a record of the decision and the criteria applied.

H33-74 attestation provides this accountability layer for encrypted decision systems. Every encrypted computation produces a 74-byte attestation that proves the computation occurred, that it applied the specified rule set, and that it produced a result. The attestation does not contain the input data or the output. It proves that the decision process was executed correctly.

For drug interaction checking, the attestation proves that the interaction database version used was current, that the correct number of medication pairs were evaluated, and that the evaluation completed without error. For eligibility determination, the attestation proves that the benefit schedule version was current, that the network roster was checked, and that the determination followed the specified evaluation logic.

These attestations serve multiple purposes. They satisfy regulatory requirements for documenting CDS activity. They provide evidence for malpractice defense if a CDS alert was generated but overridden. They enable quality measurement of CDS effectiveness by counting alerts generated and actions taken. All of this documentation is produced without including patient data in the documentation trail.

The Regulatory and Legal Landscape

The 21st Century Cures Act and its implementing regulations have placed increasing emphasis on clinical decision support transparency. CDS developers must provide information about the basis for their recommendations. Users must have the ability to evaluate whether CDS recommendations are appropriate for specific clinical situations.

Encrypted decision systems are compatible with these transparency requirements. The rules that the CDS system applies are transparent; it is the patient data that is encrypted, not the clinical logic. A drug interaction database can be fully documented and publicly reviewed. The clinical criteria for prior authorization can be published. The scoring algorithm for sepsis risk can be disclosed. What remains encrypted is the patient-specific data that the rules are applied to.

Liability frameworks also evolve in favor of encrypted decision systems. When a CDS vendor processes plaintext patient data and a breach occurs, the vendor faces liability for the data exposure. When a CDS vendor processes encrypted patient data, the vendor cannot expose data it never possessed. The risk profile of the CDS vendor relationship changes. Insurance requirements change. Business associate agreement terms change. The entire risk framework around CDS services becomes less expensive to manage because the primary risk, data exposure, is eliminated by architecture rather than controlled by policy.

Practical Considerations for Adoption

Encrypted decision support does not require replacing existing CDS infrastructure. The transition occurs at the integration layer. Existing CDS rule sets are compiled into FHE-compatible evaluation circuits. Existing clinical workflows continue unchanged. The encryption and decryption boundaries are managed by the H33 platform, transparent to both clinicians and CDS rule authors.

Performance is the primary practical concern for healthcare organizations evaluating encrypted decision support. FHE operations are computationally more intensive than plaintext operations. However, the latency budget for most CDS functions is generous by computing standards. Drug interaction alerts must appear within seconds. Eligibility responses are expected within 15 to 30 seconds. Prior authorization decisions are expected within hours or days. H33's FHE engine operates well within these latency budgets for all common CDS functions.

The cost of encrypted decision support must be evaluated against the cost of managing plaintext data exposure. The compute cost of FHE operations is higher than plaintext operations. But the compliance cost of handling plaintext PHI across multiple systems and business associates is substantial. Organizations that reduce their plaintext PHI footprint reduce their compliance burden, their breach liability exposure, and their cyber insurance premiums. The total cost comparison often favors encrypted processing when compliance costs are included.

Healthcare is moving toward a model where clinical systems are interconnected, where data flows across organizational boundaries for care coordination, and where cloud-based services provide specialized analytical capabilities. Each of these trends increases the number of systems that handle plaintext PHI. Encrypted decision support reverses this trend: more interconnection with less exposure. More capability with less risk. Better decisions without seeing the data behind them.

The systems that advise clinicians do not need to know who the patient is or what condition they have. They need to evaluate rules against values and produce results. That evaluation can happen entirely in the encrypted domain. When it does, healthcare gets the decision support it needs without the data exposure it has tolerated for too long.

Learn more: FHE Platform | H33 Health