Connectors
Identity, coverage, health records and messaging are different in every country. Each sits behind a small interface, so bringing a new country is a pull request instead of a fork — and running with none of them still gives you a working appointment system.
The seven things a connector can be
- Identity — verifying a person against the national identity system.
- Coverage — which insurer or public scheme a patient belongs to.
- The health record — writing appointments into the institution’s record system.
- Clinical history — reading what already exists about this patient, including archives that predate the current system.
- Professional registries — confirming a licence number is real and active.
- Messaging — the channel people in that country actually answer.
- External availability — appointment slots that live in somebody else’s system.
Argentina ships with all of them wired. Below are the four an institution usually turns on first, and exactly what it has to obtain to do it.
Identity
Lets a patient log in as themselves, verified against the national identity provider, instead of a password you have to reset by phone.
What the institution needs: to be registered with the national identity provider as a relying party, which for Argentina means the municipality’s own agreement with the registry, not ours. That registration returns a client identifier and a secret, and takes the callback address of your installation. Three values in the settings panel, and the login button appears.
Before you have it: a test mode runs the entire login flow against synthetic identities with no network call, so the screens can be reviewed and demonstrated while the paperwork is in progress. Without it: password login stays on. The product will not let an installation end up with zero usable ways to log in.
Coverage
Answers “which insurer is this person in today” from the national registry, at the moment of registration and again at the moment of the appointment. It is what makes billing recovery possible, because the patient who says they have no coverage frequently does.
What the institution needs: nothing, to start. There is a public lookup that requires no credentials and is on by default. A service account for the ministry’s registry gives higher limits and a documented interface, and is worth requesting once the volume justifies it.
Without it: the patient types their insurer and membership number by hand, as they do today at every desk.
The health record
Pushes each approved appointment into the institution’s clinical record system, so the visit exists where the clinician actually works and not only in Human Rounds.
What the institution needs: the address of its record-system instance, a service user and password created inside it, and the institution’s own identifier there. The professionals and specialties you offer have to exist on that side too — that mapping is the real work, and it is done once.
Without it, or when it is down: approving still books the appointment and still emails the patient. The write is queued and retried on its own every few minutes, and a record system that is refusing is not hammered. Nothing a patient or a receptionist does is ever blocked by the record system being unavailable. It can also be switched off deliberately, which is what an installation evaluating the product does on day one.
In much of the world this is the only channel a patient reliably reads. It carries the verification code when an account is created, the reminder the day before, and the booking conversation itself.
Two ways to connect it. A self-hosted gateway is a second container, a phone number, and a QR scanned once to pair it — no business verification, no message templates, and it is the path that works on the first afternoon. Meta’s official cloud API needs a business account, a verified number and an access token; it is more paperwork, it carries conversations rather than verification codes, and it is the durable option at scale.
What the institution needs either way: a phone number that belongs to the institution and not to a person, and a webhook address on your installation for inbound replies. That address stays closed — it returns nothing at all — until a shared secret is configured, so a half-finished setup never leaves an open endpoint.
Without it: everything falls back to email. Codes, confirmations and reminders are sent, just on a channel fewer patients open.
The rest
The professional-licence registry, the clinical-history archives and third-party availability follow the same shape: configured, they add a capability; unconfigured, the screen that used them simply does not offer that assistance. Email is not a connector but behaves like one — a domain and an API key, and without them the site never blocks, it just does not send.
Degrading is part of the contract
A capability with no connector must leave the product usable, and every connector ships with the test that proves it. No registry means the field is typed by hand. No record system means appointments live only here. A country with none of these connectors still gets a working appointment system on day one, and adds the rest as the agreements arrive.
Next: Writing a connector