One of the most reliable facts in enterprise software is that the standard workflow is never quite standard enough.

A customer wants one extra menu action on the client. Another wants outbound documents scrubbed before they leave the organisation. Another wants filed mail marked with an internal rule. Another needs matter or workspace rules enforced differently for a legal team. Someone else needs a different mail, fax or content provider because that is what their estate already uses, whether that means Exchange, GroupWise, Lotus Notes or something equally entrenched.

I saw this very clearly in the WorkSite mobility product I eventually sold to Interwoven. Looking back, one of the best product decisions we made was not any one feature. It was treating extensibility as part of the design, rather than as an awkward concession after the first large customer asked for changes.

This post covers what that taught me, and why the custom bit should live in a hook, not in a fork of the product.

Enterprise products do not stay generic for long

A team can persuade itself that version one should stay clean and opinionated, and that special cases can wait. That can work for consumer products. It rarely works for enterprise software.

Enterprise customers already have policy, tooling, compliance rules and operational habits before your product arrives. They do not replace all of that to match your neat default flow. They ask where your product can bend.

That does not mean every request is sensible, or that every request should be accepted. It means the product needs a clear answer to three questions:

• Which parts of the workflow are invariant?
• Which parts are likely to vary by customer or deployment?
• How can that variation happen without turning upgrades into a rewrite?

If you cannot answer those questions, the next large deal will answer them for you, usually by asking for a branch that never rejoins the main line.

Forks solve the short-term problem and create the long-term one

At first glance, a customer fork looks pragmatic. You duplicate the code, make the requested changes, ship the deal and promise yourself you will clean it up later.

The trouble is that a fork moves the cost, rather than removing it. Every future fix, security patch and enhancement now has to be merged, translated or reimplemented. The more successful the product becomes, the worse the economics get.

That is why I have become suspicious of any design that depends on remembering which customer has which behaviour. If the variation matters enough to sell, support and operate, it matters enough to model explicitly.

A hook does exactly that. It says: this workflow is stable, but this step is allowed to vary. This is where you plug policy in. This is the contract you must honour. This is what the core system promises not to break casually.

That is a much healthier promise than “we can patch your copy”.

Good extension points start with boundaries

The useful question is not “where can we add plugins?” It is “where does local policy naturally belong?”

In the mobility product, that often meant looking for moments where the core workflow had done its job and customer-specific behaviour could safely take over. After an email had been filed into the right matter or workspace, a post-processing hook made sense. Before a document left the system, a transformation hook made sense. On the client, a menu extension made sense because it added behaviour without redefining navigation.

Those hooks worked because the surrounding workflow stayed owned by the product. Authentication, queue handling, retries, status transitions, accurate filing to the right matter or workspace, and the main integration path remained centralised. The extension saw a narrow contract, not the whole internals of the system.

That is the balance to aim for. If a hook is too narrow, nobody can do anything useful with it. If it is too wide, you have exported your internal architecture and made it someone else’s dependency.

Configuration is part of the architecture

One lesson I learned slowly is that extensibility is not only about code. It is also about selection.

If a system can talk to different providers, choose different handlers or enable different policies per deployment, that choice has to live somewhere durable and legible. In practice, that usually means configuration.

I do not mean magical configuration that can express an entire programme in XML and becomes impossible to reason about. I mean a simpler rule: put stable choices in configuration, and put variable business logic behind explicit interfaces.

That split matters because it changes the operational model.

• A new provider can be selected without editing core code.
• A deployment-specific rule can be added without cloning the workflow.
• An operator can inspect how a system is wired without reading the source.

Configuration is often treated as secondary to architecture diagrams. In integration-heavy products, it is architecture. It tells you which parts are meant to move and which parts are meant to stay put.

Extensibility needs operational discipline

There is a trap here. Once a product has hooks, every new requirement looks like one more extension point.

That is not always right. Every hook becomes part of the support burden. You have to version it, document it, test it, and think about what happens when an extension fails in production.

So I prefer a stricter standard now:

• add a hook only where multiple customers are likely to vary in the same place
• make the contract explicit and narrow
• define what happens when the hook fails
• keep extension code out of the control flow that maintains system integrity

That last point matters most. If an extension decides whether the queue can advance, whether a user can recover a failed item, or whether core state remains consistent, you no longer have an extension. You have a second product living inside the first one.

Good extension models preserve the recoverability of the core system.

The architecture benefit is not only customer flexibility

There is another reason to invest in this early: the architecture gets cleaner for the team as well.

Once you start asking “is this core behaviour or local policy?”, design decisions become easier. Teams stop hiding customer-specific rules in random parts of the codebase. You can see which modules should be generic, which should adapt an external dependency, and which should exist only as examples or samples.

That makes testing easier too. The core workflow can be tested for invariants. Extensions can be tested against a contract. Support teams get a clearer picture of whether a fault lives in the product, the deployment, or a custom component.

It also improves product management. If a requested change can fit an existing hook, it is a deployment concern. If it needs a new hook, that is a product decision. If it needs a fork, something in the architecture has already gone wrong.

What I would do the same now

I would still design extension points early in any enterprise product that sits between several systems and several customers.

I would still prefer adapters and hooks to customer branches. I would still separate invariant workflow from local policy. I would still treat configuration as first-class design. And I would be even firmer about documenting failure behaviour, because extensions are easy to sell and much harder to operate.

Modern stacks change the mechanics, not the principle. Today the hook might be a webhook, an event consumer, a policy engine or a small internal service rather than a loaded assembly. The question is unchanged: can the customer-specific behaviour live behind a stable contract, while the core product remains upgradeable?

If the answer is yes, you have an extensible product. If the answer is no, you have a future maintenance bill.

The general lesson

Enterprise products need to bend without splitting. Put variation behind a deliberate hook, keep the main workflow invariant, and never make a fork your customisation model. The short-term convenience of a branch is rarely worth the long-term drag on every release that follows.

Originally published at www.shirleyconsulting.co.uk/architecture/2026/11/04/the-custom-bit-should-be-a-hook-not-a-fork.html on 4 November 2026.

The Custom Bit Should Be a Hook, Not a Fork: Extensibility in Enterprise Products was originally published in Notes from the build on Medium, where people are continuing the conversation by highlighting and responding to this story.

When people hear “enterprise mobility” now, they tend to picture responsive web apps, iPhones, push notifications and cloud APIs. That is not the world we were building for.

The mobility product I sold to Interwoven was aimed at WorkSite users who needed documents and email workflows away from their desks. The client side mattered, but the older I get the less I think the handset was the clever bit. The hard part was making awkward enterprise systems behave well enough, and predictably enough, that a mobile user could trust them.

This post covers what that product taught me, and why mobile software often succeeds or fails on the server-side seams that users never see.

The device was the visible part, not the difficult part

The visible feature list sounded straightforward. Browse folders. Search for documents. Manage matters and workspaces. View profiles. Open or download files. Email, print or fax a document. File a message back into WorkSite.

On the device, those capabilities showed up as menus, forms, lists and document views. In that era, that often meant BlackBerry clients and small, constrained screens. Everything had to be explicit. You could not assume a wide display, rich browser support or a patient network connection.

It was not a document viewer with a few shortcuts bolted on. The client and server together supported proper matter and workspace workflows, including viewing documents and filing email back to the right place in WorkSite. In legal environments, it was not enough to move content around. The system had to preserve where correspondence belonged.

Those constraints forced discipline. You kept flows short, avoided unnecessary round trips, and decided quickly which operations should feel immediate and which should become background work.

Data costs mattered as well. If a device downloaded a document over the air and then sent that same document back out as an email attachment, the user had effectively paid for the transfer twice. That changed the design.

That is also why wire encryption and compression mattered so much. Encryption protected sensitive legal documents and correspondence. Compression improved speed on poor links and cut data usage at the same time. Security, performance and cost reduction were all bound up together.

The difficult part sat behind the client. Every simple user action crossed at least one boundary into a system we did not control.

Every feature was really an integration problem

A user saw a button labelled email or file. We saw a chain of dependencies.

To make that button work, we had to bridge a mobile client, the WorkSite server, mail systems such as Exchange, GroupWise and Lotus Notes, rendering services, print services, fax providers and a set of Windows processes that could run unattended for long periods. Each system had its own API style, its own failure modes and its own operational habits.

The real unit of work was often not a file but a matter or workspace context. A useful mobile workflow had to preserve where a document came from, where a message should be filed, and how a piece of correspondence related to a case. That is why legal mobility was harder than generic mobile content access.

That changes how you think about product design. The question stops being “can we add this feature?” and becomes “which systems need to co-operate, what can fail, and where do we recover?”

That is why I still like provider-style architectures for integration-heavy products. We hid vendor-specific detail behind internal abstractions because enterprise products live longer than any one SDK. If you tie the whole product directly to a mail API, a content API or a fax API, every external change becomes an internal rewrite.

That lesson has aged well. Today it might be SaaS APIs, webhooks and OAuth scopes instead of COM objects and Windows services, but the design pressure is the same.

A simple way to picture the product is as a small client sitting in front of a large integration surface:

Asynchronous work was product design, not plumbing

The biggest architectural shift was realising that many actions should not be synchronous at all.

If someone wants to send a document by email, file a message into WorkSite, or route a document to print or fax, there is little value in making the handset wait for every back-end step to complete. What the user needs is confidence that the request was accepted, that it is progressing, and that failure will be visible rather than silent.

One of the clearest examples was document email from the BlackBerry client. Doing it naively would have meant downloading the document to the handset and then sending it back out again as an attachment, which doubled the mobile data cost. To avoid that, I extended BlackBerry Enterprise Server so it could connect directly to WorkSite. The client inserted a specialised mail header, and the server-side integration used that to fetch and attach the document without sending the binary over the mobile network twice.

That was not only about cost. The integration was aimed at legal correspondence, where messages needed to stay tied to the right matter or case. Server-side handling gave us a better path to accurate filing and more dependable correspondence records than a purely device-led workflow.

So we leaned on queued work. That gave us room for retries, logging, status reporting and cleanup policies. It also let the front end stay small. A mobile client could submit intent and poll for outcome, rather than carrying the complexity of every downstream operation.

A document email flow looked more like this than like a direct handset-to-mail-server call:

This mattered more than any client-side flourish. A slightly plain interface is forgivable. A button that sometimes works, sometimes hangs and sometimes loses work is not.

I still see teams treat queues as implementation detail. In systems like this, they are part of the user experience. Reliability is a feature, even when it looks like background plumbing.

Internal tools tell the truth about a product

Years later, one of the most interesting things in the old repositories is not the main application code. It is the test harnesses, crash tools, Exchange diagnostics and helper utilities around it.

Those tools show what the team actually struggled with: which failures were common enough to deserve their own utility, which dependencies were awkward enough to need a reproduction app, and which administrative tasks were painful enough to automate.

I have become much more respectful of that kind of code over time. In integration-heavy products, internal tools are often where operational knowledge becomes durable. If a system needs bespoke tools to observe it, debug it or recover it, that is not necessarily a sign of poor engineering. Sometimes it is a sign that the team understood the real work well enough to support it.

What I would carry forward now

If I were building the same kind of product today, the stack would be different. The architectural instincts would not.

I would still keep the client thin. I would still isolate external systems behind adapters and push long-running work into queues with explicit status. I would also spend even more time on observability, because complex integrations fail in ways that only become obvious once the product is in production.

What I would be less likely to do now is believe that a polished demo proves the hard part is done. In enterprise software, demos reward the visible path. Production rewards the recovery path.

The general lesson

When software sits between several other systems, the user interface is only the tip of the problem. The real product is the set of boundaries you make dependable. If the seams are clear, the background work is resilient and the customisation points are deliberate, the front end can stay simple. If those things are weak, no amount of mobile polish will save it.

Originally published at www.shirleyconsulting.co.uk/engineering/2026/10/28/mobile-was-never-the-hard-part.html on 28 October 2026.

Mobile Was Never the Hard Part: Enterprise Mobility Was Integration was originally published in Notes from the build on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before AirTag, before Find My accessories, and before Bluetooth Low Energy turned proximity into a mainstream product primitive, I worked on a child-tracking idea for shopping trips.

The pitch was simple enough to explain in one sentence. Put a small Bluetooth token into a pouch in a child’s shoe, link it to an iPhone app, and let parents know where their child was if they wandered off in a shopping centre.

This was not only a sketch on a whiteboard. For the proof of concept, I repurposed pre-existing Bluetooth headphone chips to build rudimentary tracking devices and tested them with my own children while we were on holiday. That was enough to validate some basics about signal, handling, and the shape of the user experience, even if it was still far from a production-ready product.

We also had iPhone code, server code, scanning tools, and conversations with shopping centres about augmenting their Wi-Fi estate with Bluetooth receivers so the system would not depend only on nearby iPhones acting as repeaters. I was also accepted into Apple’s MFi programme, which felt like a meaningful step forward at the time.

The real lesson was that product viability was shaped less by code than by platform rules, hardware economics, and privacy risk.

What we actually built

Revisiting the code now is a useful reminder that this was a real prototype with real moving parts.

The iPhone side was Objective-C. It used Core Location, local Core Data models for children and tracking devices, and Apple Push Notification support. The server side was a Rails 2.3.5 application with endpoints for mobile devices, mobile locations, and notifications. There was also Bluetooth monitoring code on macOS, plus an older iPhone codebase that experimented with device discovery and peer communication.

In broad terms, the system looked like this:

The code still shows the structure clearly:

• the app modelled children as local records and linked them to tracking devices
• the app collected location updates and registered for push notifications
• the server stored mobile devices, location sightings, and notification tokens
• the monitor tools continuously scanned for Bluetooth devices
• the broader architecture allowed for both handset-based detection and fixed receiver infrastructure

None of that was especially elegant, but it was coherent. It was enough to prove there was a system here, not only an idea.

How we proved the idea to ourselves

One reason I still find this project interesting is that we did not start with custom hardware. For the proof of concept, I used pre-existing Bluetooth headphone chips to assemble rudimentary tracking devices and tried them out with my own children while we were on holiday.

That sounds slightly improvised because it was. The point was not to prove manufacturability. It was to answer earlier questions more cheaply:

• could we detect something reliably enough to be useful?
• could a small token fit naturally into the routine?
• what would a parent-facing experience need to show?
• where did the idea break down in ordinary movement through public spaces?

That sort of test is often enough to separate an interesting architecture problem from a plausible product. In our case, it did both. It suggested there was something there technically, and it also pushed the commercial and privacy questions much closer to the front.

What we thought the hard part would be

At the start, I would probably have said the hardest part was software integration.

Could the phone discover the token reliably enough? Could we keep location reasonably fresh? Could we push alerts quickly enough? Could the backend correlate a token, a child, a parent account, and a last known position?

Those were real questions, but they were not the decisive ones.

The iPhone app was old-fashioned, but workable. The Rails backend was hardly elegant, but it had the right primitives. The architecture even had a sensible next step: if handsets could not do enough on their own, fixed receivers in shopping centres could observe nearby tokens and send sightings back to our servers.

That venue-assisted version looked more like this:

That was an important change in shape. We were no longer relying purely on iPhones acting as repeaters. We were trying to use the shopping centre’s own physical estate to improve coverage and reliability.

In product terms, that was the right instinct. It also exposed the real dependency more quickly.

The real dependency was hardware economics

One of the main tenets of the idea was that the token had to be cheap enough to disappear into the retail flow. Not cheap in the vague sense that founders often promise to optimise later. Cheap in a way that changed what category of product this was.

Our target was under $5 per token.

That figure was not arbitrary. The proof-of-concept hardware was good enough to test the idea, but the intended product was never “ship modified headphone electronics”. It was a cheap insertable token that could be bundled into children’s shoes at retail scale.

That threshold shaped almost everything:

• it needed to be cheap enough to bundle with shoes
• cheap enough to lose without drama
• cheap enough to replace without a support saga
• cheap enough that a brand partner could treat it as an accessory, not a premium electronic device
• cheap enough that a parent would not handle it like something precious

If the token could not be treated as near-disposable, the product premise started to collapse.

This is where the MFi story became more interesting than the software. Getting accepted into Apple’s MFi programme felt like progress, and it was. It reduced one kind of uncertainty. But it also made another constraint impossible to ignore.

The licensed Bluetooth encryption chips we needed were cost-prohibitive for the unit economics we were aiming at. Once the accessory path required hardware with that cost profile, the rest of the model stopped fitting together commercially.

This was not a matter of shaving a few points off a margin model. It changed the category of the thing we were building.

A sub-$5 insertable token can be treated almost like packaging. A materially more expensive device becomes a gadget. The retail conversation changes. The replacement conversation changes. The support conversation changes. Parent expectations change. The whole model shifts from “simple safety add-on” to “consumer electronics programme”.

Software could not rescue that.

Platform limits were broader than APIs

The cost problem was the decisive one, but it was not the only platform constraint.

This was a pre-BLE world. The modern assumptions people bring to proximity products did not hold. Background behaviour was more limited, scanning and discovery were clumsier, and some of the Bluetooth hooks available to us were not on the happy path for App Store software.

That showed up in the code too. Parts of the older iPhone work experimented with private Bluetooth frameworks. Other parts used GameKit peer discovery. The server handled device registration, location updates, and push notifications, but it all sat on top of an ecosystem that had not yet settled into a clean product layer for this kind of use case.

In other words, the platform was telling us something important: this was possible to prototype, but not yet natural to ship.

That distinction matters. Engineers can often build around a gap. Product teams cannot always build a business around one.

The privacy problems were real, and easier to understate then than now

There is another part of this idea that deserves much more weight now than I would have given it at the time: privacy.

Tracking children in a retail environment raises hard questions even if the intent is plainly protective. In fact, clear intent can make teams too casual about the secondary risks.

The system implied a lot of sensitive joins:

• child identity
• parent identity
• token identity
• venue presence
• approximate or inferred location
• time history
• notification events

Even the holiday proof-of-concept testing brought that into focus. Testing with my own children kept the exercise bounded and practical, but it also made the ethical weight of the idea harder to ignore. A system like this does not stay in the realm of clever radio engineering for long. Very quickly it becomes a question of who can observe whom, under what conditions, for how long, and with what safeguards.

A venue-assisted version made those questions even sharper. If shopping centres hosted Bluetooth receivers and fed sightings to our servers, then the data boundary was no longer only between parent and app. It potentially involved operators, partners, retention rules, access controls, and future commercial pressure to reuse the data for things it was never meant to support.

The awkward truth is that you do not have to build a sinister system for it to become a risky one. A benign “help me find my child in this shopping centre” flow can drift into something else if the data lasts too long, can be queried too freely, or gets repurposed by venue operators, commercial partners, or a future product team with weaker instincts.

If I were approaching this problem now, I would put privacy architecture much earlier in the sequence:

• minimise identifiers from the start
• avoid collecting more history than the use case needs
• separate ephemeral safety events from long-lived account data
• make venue data boundaries explicit
• design for deletion, not only capture
• assume misuse cases will exist, not that good intentions prevent them

Back then, I saw privacy as an important design consideration. Now I would treat it as a first-order architecture constraint.

What I took from revisiting the code

Looking back, I do not think the prototype failed because we lacked technical imagination. If anything, we had plenty. We had an app, a server, scanning tools, an MFi path, working proof-of-concept hardware, and discussions with shopping centres about supplementing Wi-Fi with Bluetooth receivers.

What we did not have was a fit between product premise and platform reality.

The premise required:

• phone platform support that was good enough
• accessory rules that were commercially survivable
• hardware cheap enough to be almost disposable
• partner infrastructure that shopping centres would actually deploy
• privacy posture strong enough for a sensitive use case

Any one of those could have caused trouble. Together, they defined the outcome more than the quality of any individual Objective-C class or Rails controller.

That is what makes the code interesting to me now. It is not evidence that we were one sprint away from an early AirTag. It is evidence that you can be directionally right about a product and still be years too early on the surrounding ecosystem.

The general lesson

When a product depends on platform-controlled hardware, the real architecture includes licensing, unit economics, partner incentives, and privacy boundaries, not only APIs and servers. We could make the software plausible. What we could not do was make the whole system fit the commercial and ethical constraints that actually mattered.

Originally published at www.shirleyconsulting.co.uk/architecture/2026/10/21/platform-limits-shape-products-more-than-ideas.html on 21 October 2026.

Platform Limits Shape Products More Than Ideas: Lessons from a Pre-AirTag Child Tracker was originally published in Notes from the build on Medium, where people are continuing the conversation by highlighting and responding to this story.

US pharmacy claims are an old world meeting a new one. The pharmacy benefit manager (PBM) wants a nightly batch file in the NCPDP format, fixed-width and positional. Your platform stores everything as HL7 FHIR resources behind a REST API. Payment arrives even later, as an X12 835 remittance.

This post describes how we modelled that lifecycle natively in FHIR, and the operational store underneath that makes it safe to retry. Most of the lessons apply to any batch integration with a partner that correlates on your identifiers.

The lifecycle

FHIR has no batch resource, so compose one

A nightly submission is modelled by composing standard resources, each with a single responsibility:

One trap to avoid: don’t use Bundle of type batch as the batch tracker. That type exists for batching REST requests to a FHIR server, not for domain batches sent to a partner. A collection bundle is fine as an optional audit snapshot of the payload.

Don’t inline the manifest

The first draft put every claim reference on the batch Task or in one List. That breaks at scale:

• DynamoDB items max out at 400 KB, which is roughly 2,000–4,000 embedded references.
• Large FHIR List payloads hit practical server limits well before that.
• Deriving a count by loading and counting every entry is slow and fragile.

Instead:

• In the operational store, the batch header holds scalars only (claim count, receipt ID, status, file name, timestamps), with one child item per claim under the same partition, listed through an index.
• In FHIR, use sharded List pages and/or an inverse link: an extension on each Claim pointing to its batch Task, so “claims in batch X” is a search.
• Persist the claim count as a scalar at acknowledgement time.
• Remember that DynamoDB transactions accept at most 25 actions, so post-acknowledgement writes for large batches become idempotent chunks: header first, then membership rows and status flips in pages.

The transaction reference is your idempotency key

Each claim in an NCPDP file carries a numeric transaction reference (7–12 digits) that you generate and the PBM echoes back in the adjudication response. It’s your correlation ID and your deduplication key, so three rules apply:

1. Allocate it when the claim is created (as a draft), not at batch time. If you mint it at batch time and the batch fails before acknowledgement, a retry mints a new reference and breaks deduplication on the partner’s side.
2. Never change it. The same value goes on every resubmission of that claim.
3. Use a central, monotonic numeric allocator, such as an atomic counter or a database sequence. Don’t use random numbers, and don’t derive it from a resource ID.

At-least-once delivery, then state change

The nightly job runs in a deliberate order:

1. Extract draft pharmacy claims through an index.
2. Translate them into the fixed-width layout: product to NDC code, identifier to transaction reference, and so on.
3. Transmit the file to the partner’s gateway.
4. Only after the partner acknowledges receipt, write state: create the batch Task (receipt ID, claim count), the List pages and the inverse links, flip each Claim from draft to active, and create a queued ClaimResponse per claim linked back to the claim and the batch.

If the network drops mid-flight, nothing local has changed. The retry sends the same claims with the same references, and the partner deduplicates. That’s at-least-once delivery with idempotent receipt, which is the only honest guarantee across a file-transfer boundary.

Matching responses

When the adjudication file arrives, the batch Task moves to adjudicating. Run integrity checks before processing any records. The key one is that the number of adjudication records must equal the claim count persisted at submission. If they differ, process nothing and investigate. Only when the counts match does each row get matched to its claim by transaction reference (through an index keyed on the reference), completing the ClaimResponse with the partner’s disposition and any structured NCPDP reject codes (such as “product not covered”).

Settlement arrives later as an 835. A PaymentReconciliation is created for the remittance, keyed on the payment trace number, with one ExplanationOfBenefit per claim pointing back to the Claim and its ClaimResponse. The batch Task reaches reconciled when every claim in it has settled.

Because everything is standard FHIR, operational dashboards are plain searches: in-flight claims (ClaimResponse?outcome=queued), an ageing report of adjudicated claims with no payout yet, and tracing the claims behind a given payment.

Two stores, clear roles

The operational store (single-table DynamoDB) handles the hot path: reference allocation, claim lifecycle, batch membership and response matching, with indexes for “claim by reference”, “claims in batch” and “drafts to extract”. The FHIR store is the canonical API and audit view, synchronised at defined lifecycle boundaries. Keeping the two roles explicit avoids the temptation to run a nightly batch job through a REST API one resource at a time.

The general lessons

1. Compose standard resources before inventing custom ones, and give each a single job.
2. Never inline unbounded lists in a header item or resource. Use child rows and inverse links.
3. Generate partner correlation IDs early and make them immutable. They’re your retry safety.
4. Transmit first, then change state, and let the partner’s deduplication absorb retries.

Originally published at www.shirleyconsulting.co.uk/architecture/2026/10/07/modelling-pharmacy-claims-in-fhir.html on 7 October 2026.

Modelling Batch Pharmacy Claims in FHIR was originally published in Notes from the build on Medium, where people are continuing the conversation by highlighting and responding to this story.