Who needs what to become true?
Define the user, economic buyer, operating promise, measurable result, and consequence of failure.
The Atom & Bits method
Design the operating system around the healthcare transaction.
A healthcare product is not just an interface or model. It is the connected system of workflow, data, rules, human authority, transaction rails, evidence, and follow-through required to make an outcome happen reliably.
Five connected layers
The model prevents a good feature from becoming an unusable system.
Each layer answers a different failure mode. Together they create a product that can survive healthcare operations.
How does the work actually move?
Map events, inputs, exceptions, handoffs, latency, evidence, and the hidden labor people use to bridge gaps.
What may the system decide?
Separate deterministic work, model-assisted work, human judgment, policy approval, and actions the system must never take.
What crosses the boundary?
Design the data exchange, eligibility, claim, payment, referral, or fulfillment rail with explicit states and safe retries.
How will trust compound?
Record the source, decision, actor, outcome, and feedback needed to prove value and improve the next cycle.
Operational capacity
The organization can now do work reliably that previously depended on heroics, portals, memory, or one indispensable person.
Where the model came from
Built across the sides of the transaction.
BCBST
Payer and enterprise systems
Products must work for members, employers, brokers, administrators, sales teams, operations, and regulators—not one abstract user.
One to One Health
Care delivery and clinical operations
Technology scales access only when it protects the relationship, fits the clinician's work, and improves the operating outcome.
TheraMatch
Matching and access
A recommendation creates no value unless provider data, clinical fit, availability, navigation, and follow-through produce a retained connection.
TPN Match
Network, eligibility, claims, and payment
At national scale, the product must connect member access, provider participation, transaction integrity, and reimbursement.
A useful design test
Can the organization explain what happens next?
For every consequential state, the product should make four things legible: what happened, what evidence supports it, who has authority now, and what the next allowed action will do.
If those answers live in someone's head, a side spreadsheet, or a payer portal no one wants to open, the operating system is unfinished.
Use the method
Start with one consequential workflow.
Follow the work
Observe the current event, labor, decisions, evidence, handoffs, and failure states.
Set system boundaries
Choose the smallest coherent loop and make authority, transactions, and outcomes explicit.
Run it in reality
Test with accountable users, measure the operating change, and preserve what the team learns.
Bring the workflow
The best place to begin is where software, operations, trust, and revenue are already colliding.
Atom & Bits can turn that workflow into a product thesis, operating model, technical plan, or working system.