Infrastructure as code for healthcare and revenue cycle products, where the value is reviewable change and reproducible environments rather than the fact that infrastructure is written in a file.
Most healthcare product companies have adopted infrastructure as code partially. The core platform is defined, and around it sits an accumulation of things somebody created in a console during an incident, a migration or a demo, which nobody tracked and nobody has removed. That estate is where cost hides, where drift originates and where protected information sits in environments nobody remembers creating.
The goal is not infrastructure written in code. It is infrastructure you can explain and recreate. Automation is the visible benefit and reviewable change is the actual one.
Infrastructure as code adoption in healthcare products is usually partial. The production platform is defined and reviewed, while databases, buckets, demo environments and test instances created outside the repository continue to run, cost money and sometimes hold protected information under weaker controls.
The Untracked Estate Is Invisible and Expensive
Resources created outside the definition accumulate cost, access and data, and nothing surfaces them except a bill nobody can decompose.
Partial Adoption Gives Neither Benefit
Half a defined estate cannot be reproduced and cannot be fully reviewed. Coverage matters more than tooling.
State Is the Thing Nobody Thinks About
Where it lives, who can modify it, what happens when it is corrupted or locked, and whether losing it means losing the ability to manage the estate.
Drift Is Treated as a Defect
Somebody changed production by hand because the process did not let them do what they needed. That reason is the useful finding.
Environments Have No Lifecycle
Created for a purpose, kept because deleting felt risky, and still running years later with data, cost and access nobody reviews.
Disaster Recovery Assumes an Untested Repository
The plan says rebuild from code, nobody has tried, and the parts created by hand are not in there.
Compare what is running against what is defined.
List everything in the cloud estate and compare it with what the repository actually creates. The difference is the untracked estate: resources nobody is reviewing, costing or securing to the standard of the defined platform.
Implementations that begin by writing definitions produce a well-defined new estate alongside an undefined old one. Starting from reconciliation produces coverage, which is the property that makes Infrastructure as Code useful.
Step 1
Inventory what is actually running, across every account and region, and compare it against what the repository defines.
Step 2
Define what should exist before encoding what does. Do not make inherited mistakes permanent.
Step 3
Decide the disposition of the untracked estate: bring under definition, retire, or accept with a documented reason and an owner.
Step 4
Establish the state architecture deliberately, covering where state lives, who can change it, how it is locked and how it is recovered.
Step 5
Design the module structure around what actually repeats, not imagined reuse.
Step 6
Separate configuration from definition, so environments differ by parameters rather than parallel copies that diverge.
step 7
Make change reviewable with a plan step somebody reads before applying.
Step 8
Detect drift continuously and resolve every instance: revert reality to the definition, or update the definition to capture a legitimate change.
Step 9
Give every environment a lifecycle: purpose, owner, data policy, expiry and cost limit.
Step 10
Test reproduction by rebuilding something real. A definition never used to create an environment is a description.
Drift is not a failure of discipline. It is a finding.
When somebody changes production by hand, they usually had a legitimate need and the defined path did not let them meet it quickly enough. Every drift incident answers a useful question: what did somebody need to do that the system made hard, and should it be easy?
The definition work is straightforward. What determines whether Infrastructure as Code is an asset or a second system to maintain is state handling, coverage and lifecycle discipline.
Define and Structure
Estate Reconciliation
what exists against what is defined.
Module and Template Design
reusable components around patterns that genuinely repeat.
Environment Parameterization
one definition with environment-specific configuration.
Import and Adoption
bring existing resources under definition without recreating them.
Control
State Architecture
storage, locking, access, backup and recovery.
Change Review
a plan step somebody actually reads.
Drift Detection
continuous comparison between defined and actual.
Policy as Code
 encryption, tagging, network exposure, region and resource type checked before provisioning.
Reproduce and Govern
Environment Lifecycle
purpose, owner, data policy, expiry and cost limit.
Secrets Handling
credentials referenced rather than defined.
Disaster Recovery Through Definition
rebuild tested rather than assumed.
Cost and Tagging Governance
attribution enforced at provisioning.
What CaliberFocus does, and does not do?
A repository full of infrastructure definitions does not mean infrastructure is controlled. The objective is control coverage rather than code coverage. We start with reconciliation rather than writing definitions, treat drift as information rather than a violation, and would rather deliver a fully defined narrow estate than a partially defined broad one.
Definition effort should follow how often something is created and how much it matters when it differs. The risk carried by infrastructure outside the defined estate is where the argument for coverage lives.
| Category | How Often It Changes | The Risk When It Is Undefined |
|---|---|---|
| Core Application Platform | Frequently, and reviewed carefully | Usually well defined. The one area most teams have covered. |
| Customer-Specific Resources | Every new customer | Onboarding becomes manual, inconsistent and a bottleneck behind one person. |
| Data Platform and Warehouses | Occasionally, and expensively | Large cost, large data volumes and the least visibility into what exists. |
| Integration Infrastructure | When partners are added | Credentials, queues and endpoints created by hand and never inventoried. |
| Non-Production Environments | Constantly, informally | Where protected information accumulates with the weakest controls. |
| AI and Inference Infrastructure | As capability is added | Expensive, new, and frequently provisioned outside the platform process. |
| Incident and Investigation Resources | Rarely, under pressure | Created at three in the morning, never removed, never reviewed. |
Customer Onboarding Is the Case That Pays for This
When a new tenant becomes a parameterized application of a known definition, onboarding moves from a manual project to a repeatable operation. Variation falls, support issues caused by configuration differences fall, and there is a record of exactly what each customer has.
Infrastructure as code is worth doing for five reasons and automation is the least important of them. Teams that adopt it for speed alone can provision quickly while missing the properties that matter in a regulated environment.
| Property | What It Provides | What Is Lost Without It |
|---|---|---|
| Intent | A stated description of what should exist | Nobody can say whether the estate is correct, only what it currently is. |
| Review | A change examined before it happens | The primary benefit, and the step most often automated away for speed. |
| Version | A history of what changed, when and by whom | No way to explain a configuration or return to a known state. |
| Reproduction | The ability to rebuild an environment | Disaster recovery is a plan rather than a capability. |
| Evidence | Proof of what the infrastructure is and was | Compliance answers get reconstructed manually every time. |
Engineering Discipline
Keep the plan step human. Build modules from what repeats, not what might. Parameterize rather than duplicate, within limits. A module should remove decisions rather than add a framework. Treat state as production data. Enforce policy at provisioning. Never put secrets in definitions or state.
Environments are created for a reason and kept because removing them feels risky. Years later they carry unclear purpose, unknown data, accumulated access and recurring cost.
Purpose and Owner
Record both at creation, because neither will be easy to reconstruct later.
Data Policy
Decide and record what may exist there, especially production data in non-production.
Expiry and Renewal
Remove at a defined date unless somebody deliberately renews it.
Ephemeral Environments
Create per feature or test run and destroy automatically where the work suits it.
Cost Limits
Attach at provisioning so an environment that becomes expensive surfaces quickly.
Decommissioning
Include data removal, credential revocation and confirmation so deleted environments do not leave storage and access behind.
Infrastructure recreation does not restore business state.
Definitions do not tell you which transactions were in flight, which files were partially processed, which external acknowledgements were already sent or which jobs need restarting. The product still needs a business recovery design.
When a healthcare customer asks who changed a network rule, when encryption was enabled or what production looked like on a particular date, the answer should exist in version history rather than be reconstructed from memory and console logs.
Change Control
- Review and version infrastructure change with the same discipline as application code. Keep a human-read plan step for production, network exposure, access and data storage. Retain evidence for emergency changes and reconcile drift.
Security and Policy
- Use policy as code where the answer should always be no. Reference rather than embed secrets. Scope pipeline credentials and scan infrastructure definitions as application code is scanned.
Auditability
- Answer what infrastructure was on a given date, who changed it and who approved it. Identify untracked resources and keep the environment inventory current with purpose, owner, data policy and expiry.
Cost
- Enforce tagging at provisioning, attribute cost to environment, workload and customer, estimate material cost before deployment, and surface idle or expired resources automatically.
A resource without an owner tag is a resource nobody will ever question.
Enforcing ownership and purpose tagging at provisioning, as a blocking policy rather than a convention, determines whether a grown estate can be governed at all.
Infrastructure as code is usually reported as adoption: modules written, resources defined, pipelines built. The outcomes that matter are whether coverage is complete enough to reproduce anything and whether the estate can be explained to somebody who asks.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Delete and Recreate | Whether a non-production environment can be destroyed and rebuilt from definition, with configuration, integrations, security controls and monitoring restored, without asking anybody what was done manually | Tells you more about maturity than the number of resources in the repository. |
| Coverage | Running resources defined in code versus created outside it | The property everything else depends on, and usually lower than assumed. |
| Reproduction | Whether an environment can be rebuilt from the repository, tested | The honest test of coverage, and the basis of disaster recovery. |
| Drift | Instances detected, and what each revealed about missing platform capability | A signal rather than a failure metric. |
| Environment Hygiene | Environments with a purpose, owner, data policy and expiry | Where cost, access and protected information accumulate. |
| Customer Provisioning | Time and manual steps to onboard a new customer environment | The clearest commercial benefit and the easiest to fund. |
Honest expectation setting
An assessment may conclude that most production is already defined while changes still happen outside the process, modules are too generic, state management is a larger risk than provisioning, production and disaster recovery have drifted apart, or fewer reusable modules are needed. If the team is afraid to recreate an environment, the definition is not yet authoritative. Expect recommendations to include removing resources rather than defining them.
We will reconcile what is running against what is defined, establish actual coverage, review state handling and recovery, assess environment lifecycle and the data sitting in non-production, and design the module and policy structure that brings the untracked estate under control. The reconciliation usually produces findings in the first few days.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
