- Ya
- 25 Agosti 2026, 21:50 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 68ad4b9
An interoperability endpoint is where a system is most likely to acquire a quiet bypass: it is machine-to-machine, nobody watches it, and "the integration needs it" is a persuasive sentence. This one does not get a bypass. Every read goes through ClinicalAccessService exactly like the chart screen — a care relationship with the specific patient, not merely a session — and writes the same per-record audit rows. Three refusals are deliberate. `patient` is REQUIRED on every search but Patient itself. A search without one is a query across the practice's entire clinical record, which is an export: a different authorization, a different audit shape and a different conversation with a compliance officer. Bulk access belongs in $export where it can be treated as what it is. A denied read and a missing record answer the same 404, and a denied SEARCH answers an empty searchset rather than an error — otherwise the result count is an oracle a caller can walk the id space with, learning which patients a practice has. Compartment resources decide access on the OWNER of the record, never on the record itself. Deciding on the resource alone would let anybody who guesses an Observation id read one. $everything caps across ALL types with the safety-critical lists first — allergies, problems, medications, immunisations — so a patient with forty thousand observations cannot push their allergies out of the answer. That ordering is the difference between a truncated record that is still safe to prescribe against and one that is not. The CapabilityStatement is the single deliberately public handler, allowed BY NAME in EhrEndpointGuardTest rather than by a pattern, with two tests around the exemption: one asserting that handler touches no patient data, one asserting the allowlist names a handler that still exists — an exemption for a renamed handler is a hole waiting to be inherited by whatever takes its name. Errors are OperationOutcomes rather than bare JSON, because a FHIR client parses the body as a resource whatever the status code: handing it {"error": "..."} produces a parse failure on top of whatever went wrong, and the real reason never reaches a human. purpose of use defaults to TREATMENT here and only here. The chart screens require it, but a FHIR client is a machine that will not be updated to send a Kamo-specific parameter, and treatment is the conservative default — §164.528 excludes it from the accounting, so a mislabelled payment query under-reports rather than over-reporting to a patient about disclosures that never happened. 1243 tests green.