A real credential for exchange partners, and retrieved documents

Featurekamo-shared-library
Ya
26 Agosti 2026, 06:04 UTC
Mwandishi
Kamo
Ahadi ya
b531d65

The responder endpoints have no user session — the caller is another organization's server — so a bearer credential this practice issues at onboarding is the ONLY thing between a stranger and a patient's record. The first version read the partner's identity out of an X-Exchange-Trust-Id header, which would have answered whoever typed the right OID; the OIDs are published in a directory. The HASH is stored, never the token. A leaked database must not yield working credentials for every partner a practice exchanges with. SHA-256 rather than bcrypt because the token is 256 bits this system generated — there is no low-entropy secret to slow an attacker over — and because a fast hash is looked up by index rather than tried row by row, which also leaves no timing signal. The lookup takes NO tenant. The credential identifies one partner row, which carries the practice it belongs to, so the tenant is derived — an endpoint that took one would be asking the caller which practice's records to search, and the tenant is the one part of a request a caller must never choose. ExchangeDocument keeps what crossed the boundary. Retrieved documents are KEPT, not merged: an outside summary is an assertion by another organization, and folding its problems and medications straight into the chart puts a clinician's name against facts they never reviewed. Reconciliation is a separate, deliberate act, and reconciledAt is the queue that makes retrieval useful rather than a folder nobody opens. Metadata is stored apart from the bytes because a clinician picks two documents from a list of forty, and shipping all forty is a disclosure larger than the question needed.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei