Replaced emailed lab orders and shared spreadsheets with an API (a secure system-to-system connection). Results read in under 90ms and duplicates are never applied twice.
Overview
What this is and why it matters, in plain English.
Replaced emailed lab orders and shared spreadsheets with an API (a secure system-to-system connection). Results read in under 90ms and duplicates are never applied twice.
A secure connection between clinics and the lab: orders go in, results come back fast, and each clinic sees only its own.
The situation
What was going on before, and why it needed fixing.
Lab orders traveled by email and shared spreadsheets. Results arrived late, and a loose query could show one clinic another clinic’s panel.
Orders lived in email and shared spreadsheets. Results arrived late, and one clinic could see another clinic’s panel if the query was loose.
What it needed to do
The outcomes the project had to deliver.
- A versioned API for placing orders and receiving results.
- Strict tenant isolation on every token.
- Idempotent result intake and signed notifications.
What I did
My part of the work and who I worked with.
I designed the API contract and built the Laravel endpoints, Node.js result-intake workers, Redis caching and locks, token scopes, and webhook signing on AWS.
How it works
The main building blocks, from the screen people use to the data underneath.
Shipped a versioned Laravel API with Node workers for result intake, Redis for hot reads, and tenant scopes so a token only opens its own orders.
- 01
Versioned Laravel API
Orders and results endpoints with scoped tokens; a token only opens its own clinic’s orders.
- 02
Node.js intake workers
Receive result payloads from labs and write them idempotently.
- 03
Redis
Serves hot result reads and provides short locks keyed by order and idempotency key.
- 04
Signed webhooks
Notify the ordering clinic, with signatures that remain valid on retry.
Key choices and trade-offs
Every build involves trade-offs. These are the important ones and what each one cost.
| Decision | Trade-off |
|---|---|
| Idempotency keys on result posts. | Labs must send a key, but duplicate posts become harmless no-ops. |
| Tenant scope in the token, not the query string. | Token management is stricter, but clients cannot ask for another clinic’s data. |
Under the hood
Implementation details for technical readers, with a code sample.
- Result reads under 90ms.
- Zero duplicate posts applied.
- Zero tenant leaks in review.
public function storeResult(Request $request, LabOrder $order) {
abort_unless($request->user()->tokenCan('results:write'), 403);
$key = $request->header('Idempotency-Key');
return Cache::lock("result:{$order->id}:{$key}", 10)->block(3, function () use ($request, $order, $key) {
return LabResult::firstOrCreate(
['order_id' => $order->id, 'idempotency_key' => $key],
['panel' => $request->validated('panel')]
);
});
}Problems solved
What got in the way, and how each problem was fixed.
- 01
Result payloads arrived twice. Idempotency keys had to make the second post a no-op.
A lock on order plus idempotency key and a firstOrCreate write, so the second identical post returns the existing result.
- 02
A clinic token could not be allowed to enumerate another site’s patients.
Token scopes bound to the clinic, enforced on every query, so enumeration across sites is impossible.
- 03
Webhook retries had to stay signed after the original request was gone.
Webhook signatures computed per delivery attempt, so retries stay verifiable after the original request is gone.
Security, speed and growth
How data is protected, and how the system stays fast as usage grows.
Security
Scoped tokens per clinic, permission checks such as results:write, and signed webhooks.
Speed & growth
Redis-backed hot reads keep result retrieval under 90ms when a panel posts.
Quality and releases
How changes were tested and shipped safely.
Contract tests per version, duplicate-post tests, and cross-tenant access tests that must fail.
Tech stack
The tools and technologies used, for recruiters and technical reviewers.
Results
Measured outcomes recorded for this project.
| Metric | Result |
|---|---|
| Result read | <90 ms |
| Duplicate posts | 0 applied |
| Tenant leak | 0 in review |
Questions
Plain answers first, then the detail a technical reviewer would ask about.
Common questions
- What did this replace?
- Lab orders sent by email and tracked in shared spreadsheets. Now orders and results move automatically and securely between clinics and the lab.
- Can clinics see each other’s data?
- No. Each clinic can only see its own orders and results.
For your tech lead
- What if a lab posts the same result twice?
- The idempotency key makes the second post a no-op that returns the original result.
- Can one clinic read another’s orders?
- No. Tokens are scoped to a clinic and every query enforces that scope.
Key takeaways
- •A secure connection between clinics and the lab: orders go in, results come back fast, and each clinic sees only its own.
- •Built with Laravel, Node.js, MySQL, Redis, REST, AWS.