Pharmacy
A claims data model built from scratch, because nothing off the shelf fit
Three custom object types, actions gated on conditions across related records, and a deduplication design where nothing is ever deleted or overwritten.
Client: A pharmacy group handling workers' compensation and motor-accident claims
System flow and narrative
Conditions at execution: All met. Record: Qualifying. Path: Case or Rx event, then Records resolved, then Conditions checked, then Action executes, then Deduplication, then Surfaces in reporting.
A claims data model built from scratch, because nothing off the shelf fit: system flow
Edges: live is a thicker, full-opacity, travelling dashed line; not taken is a thinner, dimmed, solid line. Nodes: live is a thicker, full-opacity outline; not taken is a thinner, dimmed outline. Color is never the only signal.
01
Three object types, designed rather than adopted
The system tracks patient cases, prescription events, touch activity and legal escalations across workers' compensation and motor-accident claims. Nothing off the shelf covered that shape, so the data model was built from scratch: three custom object types with their whole relationship model, permission structure and automation logic designed from the ground up. Choosing to build the model rather than bend an existing one is the decision everything else here depends on.
02
An action that will not half-run
Business-critical actions are gated on a combination of conditions across related records, and if any one of those conditions is not met at execution time the system exits cleanly without changing anything. The important word is cleanly. A workflow that checks its conditions at the start and acts at the end can find the world has moved in between, and the result is a record updated in one place and not the other. Re-checking at execution and exiting whole is what prevents that.
03
Clean reporting without destroying the record
Deduplication keeps qualifying records for reporting separate from raw records retained for audit, so clean data surfaces while nothing is ever deleted or overwritten. In claims work those two needs genuinely conflict: a report is only useful if each case appears once, and an audit is only defensible if everything that was ever received is still there. Separating the two views rather than resolving them in favour of one is what lets both be true.
04
Three tiers, each scoped to its own work
Three permission tiers were scoped to exactly what each role needs and nothing beyond it. In a system holding patient cases alongside legal escalations, least privilege is not a hardening step applied at the end; it is part of the data model, because deciding who can see a legal escalation is the same decision as deciding what a legal escalation is related to.
The branch logic, as a table.
| Condition | Then | Why |
|---|---|---|
| Conditions at execution is All met | Action executes | |
| Conditions at execution is One unmet | Exits, nothing changed | no half-committed state is left behind |
| Conditions at execution is All met | Deduplication | |
| Conditions at execution is All met, and Record is Qualifying | Surfaces in reporting | |
| Conditions at execution is All met, and Record is Raw duplicate | Retained for audit | retained, never deleted or overwritten |
The stack.
| Layer | Tools |
|---|---|
| CRM | Zoho CRM |
| Data model | Three custom object types and their relationship model |
| Access control | Three scoped permission tiers |
Compliance notes.
- Business-critical actions are gated on a combination of conditions across related records, and exit cleanly without changing anything if one is unmet at execution time.
- Deduplication keeps qualifying records for reporting separate from raw records retained for audit, so nothing is deleted or overwritten.
- Three permission tiers are scoped to exactly what each role needs and nothing beyond it.
- Visual documentation for this engagement is withheld under client confidentiality, so the decision logic is published without it.
Before and after.
- Data model
- Before: Off-the-shelf objects that did not fit claims workAfter: Three custom object types with their relationship model designed from the ground up
- Half-committed actions
- Before: An action could fire with a condition no longer metAfter: Re-checked at execution, exiting cleanly when one is unmet
- Reporting against audit
- Before: Deduplication meant deleting or overwriting the originalAfter: Qualifying records surface for reporting while raw records are retained
- Access
- Before: Broad access, because scoping it properly was workAfter: Three tiers scoped to exactly what each role needs
This is one delivered system, published in full. See how we build AI automation
Start a conversation
Tell us what you’re building.
Share the essentials and we’ll reply within 4 hours with a real next step, not an auto-responder.
What happens next
- We reply within 4 hours, from a real person, not an auto-responder.
- A short scoping call to understand the goal, constraints, and timeline.
- A fixed-scope discovery sprint: a working prototype and a written estimate.
- info@irenictech.com
- Office
- Austin, TX, United States
- Hours
- Mon–Fri · Async + scheduled calls