Dual jurisdiction
One core, two countries, and no country conditionals in between
Health software is where products go to fork. A second country arrives, a branch appears in the clinical code, and two years later there are two products with one name. The decision here was to put every jurisdictional concern behind a single set of interfaces, selected per facility, and to keep the clinical core, the pharmacy, the agents and the sign-off machine entirely country-agnostic.
United States
Primary
The primary jurisdiction, and the demanding one: certification criteria that specify the interfaces rather than the outcomes, an information-blocking regime, a claims format older than most of the software that speaks it, and controlled-substance prescribing with its own credentialling. Building here first is what makes the second country an adapter rather than a rewrite.
India
Compatible
The same core behind a different set of adapters: the national health-account identity and consent flow, the national profile set, the health-information provider and user roles, the national claims exchange and the public scheme’s pre-authorisation, and a data-protection regime with residency expectations that decide where inference is allowed to run.
The matrix
Eleven concerns, eleven interfaces, two implementations each
Every row is one interface with an implementation per country, resolved from the facility the request belongs to. The interface column is there so this is a claim you can ask us to show you rather than an adjective.
| Concern | Adapter | United States | India |
|---|---|---|---|
| Identity and consent | Identity & consent | SMART-on-FHIR over OAuth2 with scoped tokens; authorisation under the federal privacy rule | National consent manager, and the national health account as the patient identifier |
| Profile validation | Profile validator | The US core implementation guide and the required core data set | The national digital-health FHIR profiles |
| Exchange | Exchange | Patient and population access, bulk export of the electronic health information, and the national network arrangements | Health-information provider and health-information user roles on the national network |
| Claims and prior authorisation | Claims / prior auth | The X12 claim, remittance and eligibility formats, plus the FHIR prior-authorisation rules | The national claims exchange, and pre-authorisation for the public insurance scheme |
| Terminology and coding | Terminology | The American diagnosis and procedure code sets, drug identifiers and lab codes | The Indian diagnosis coding and the national terminology service |
| Provider directory | Directory | The national provider identifier registry | The health facility and healthcare professional registries |
| e-Prescribing | e-Prescribe | The national prescribing standard over the pharmacy network, with electronic controlled-substance prescribing and its credential requirements | Pharmacy dispense and retail sale |
| Telehealth | Telehealth | A video provider covered by a business-associate agreement, in-region | An India-hosted provider, so the consultation stays in-country under the data-protection regime |
| Patient matching | Patient matcher | Probabilistic weighted-demographic matching, because there is no national identifier to match on | Deterministic matching on the national health account |
| Payment | Payment | Card and bank transfer, by external reference | The national instant-payment rails and bank transfer, by external reference |
| Compliance profile | Compliance profile | The federal privacy and security rules, the certification criteria, and information blocking | The data-protection act, the national digital-health requirements, and the mandated security audit |
Why an interface and not a branch
A conditional is cheap once and expensive forever
The first country conditional in a clinical service is always defensible. It is one line, it is obviously correct, and it ships. The problem is that it teaches the codebase that country is something you check, and the twentieth one is in a pharmacy safety path where nobody expected to find it.
So the constraint here is absolute rather than aspirational: there is no country check in the clinical core, the pharmacy, the agent graph, the sign-off machine or the layering. Everything jurisdictional is one of the interfaces above, with an implementation per country, resolved from the facility the request belongs to. A tenant carries its jurisdiction, and multi-tenant therefore means multi-jurisdiction on the same deployment.
That has a cost worth naming. An adapter boundary is more work than a conditional, and it forces a decision early about what the two countries actually share — which is the uncomfortable design conversation that a branch lets you postpone indefinitely. The payoff is that a third jurisdiction is a known quantity: a new implementation of a list you can read, rather than an archaeology exercise across a codebase looking for everywhere the second one leaked.
It also has a clinical payoff. The safety machinery — draft, critic, sign, and the absence of a rejected draft from the record — is the same code in both countries. A jurisdiction cannot be the reason a sign-off gate behaves differently, because a jurisdiction never reaches it.
Regulatory ground
What each regime asks for, and where it is answered
This is a map of requirements to the parts of the product that address them. It is not a claim to hold any of these certifications — the two are different things and a page like this is exactly where they get blurred.
| Scoped clinical authorisation | United States | Discovery and scope enforcement on tokens issued elsewhere. The platform verifies; it never mints. |
|---|---|---|
| Core data set and profile conformance | United States | Validation on write, against the profile the facility’s jurisdiction selects. |
| Patient and population access, and export | United States | Read directly off the stored resources rather than rebuilt for the requirement. |
| Prior authorisation over an API | United States | The payer exchange, driven by an agent that tracks status and drafts nothing clinical. |
| Controlled-substance prescribing | United States | Schedule-aware refill rules in the deterministic pharmacy engine, not in a prompt. |
| Privacy, security and audit controls | United States | Access control, an immutable audit log, encryption, minimum-necessary scoping and break-glass with a recorded reason. |
| National health account and consent | India | Identity and consent adapters, with consent lifecycle and withdrawal as first-class records. |
| Health-information provider and user roles | India | The exchange adapter, over the same stored resources the American paths read. |
| National claims exchange | India | The claims adapter, assembling from codes a human confirmed. |
| Data protection and residency | India | Consent lifecycle, data-subject rights, and inference deployed in-region rather than routed abroad. |
Where a requirement is met by the product, that is a property you can test. Where it requires an audit, an assessor or a regulator to say so, only they can — and this page will say which is which rather than letting the table imply otherwise.
A third country
The honest version of “it is extensible”
Adding a jurisdiction means implementing the interfaces in the matrix above and registering them against a jurisdiction key. That is genuinely the work — but the work is not small, because the hard part of a new country is never the code. It is the terminology set, the identity flow, the claim format and the regulator, and a vendor who tells you otherwise has not done a second country. What the architecture buys you is that the effort is bounded and visible, and that none of it lands in the clinical core.
Which side of the matrix are you on?
It is the first thing that changes what we would show you — identity, coding, claims, prescribing and where your data is allowed to live all follow from it. If your country is not one of the two, tell us which it is.
Get in touch
Talk to the people building it
No chatbot and no ticket queue. Tell us what your hospital or practice actually looks like — how many beds, which departments, what the doctors are doing twice, what your billing team keeps chasing — and someone who works on the software will reply.
info@legosphere.com