Single-endpoint report

22 Health (Community Care Plan) Patient Access API: endpoint report

Everything this project observed about this one endpoint, everything it did not observe, and what would change the result. Free to read, link, print and hand on; there is nothing here behind a sign-in and nothing to buy.

Built to print. Use your browser’s print or “Save as PDF” to keep a dated copy; the page carries its own address and observation date.

What was observed, and what was not

This report covers 9 checks. 9 ran. 0 were asked from every reporting vantage and answered by none. 0 were never asked, because nothing was retrieved for them to read. The three are different facts and none of them is a zero: a check that did not run publishes no number, no mark against this endpoint, and nothing below to act on.

What would change this

Ordered by the points each would recover. Every item below comes from a check that actually ran on this run; nothing derived from a check that did not run appears here. The three dimensions are weighted, so recovering points does not guarantee a different letter — how we grade gives the weights.

1. Declare the implementation guide's canonical URLs. Any of five conformance elements is read: rest.resource.supportedProfile, rest.resource.profile, instantiates, imports, or meta.profile. The finding above names where this project looked and what it found there.

   Worth up to 40 of the 100 points in Interop readiness.

   This run observed: no profile canonical declared in rest.resource.supportedProfile, rest.resource.profile, instantiates, imports, or meta.profile

   I1: what this check isSpec ↗

2. Give each declared resource its rest.resource[].interaction list. A resource listed with no interactions tells a client nothing it can act on.

   Worth up to 25 of the 100 points in Capability transparency.

   This run observed: 0/24 declared resources document their interactions

   T4: what this check isSpec ↗

3. Declare what is running, in software.name and software.version. Both are needed; one without the other does not pass.

   Worth up to 20 of the 100 points in Capability transparency.

   This run observed: software name/version missing

   T2: what this check isSpec ↗

If this does not match what you see

Every number here describes two public documents at one moment, read from the vantages listed above. If it does not match what you serve, the difference is worth knowing.

Correct or dispute this record. There is no sign-in, no fee, and nothing to buy: this report is free to read, link, print and hand on, and this project collects nothing about the people who read it.

Where this came from

live CapabilityStatement fetch. The base URL is printed verbatim, in a table headed 'Base URLs for connecting to these APIs are', on the issuer's own /api/ page; the host is the vendor's (ZeOmega HealthUnity), so attribution rests on the plan printing this exact string on its own domain. Two things the document declares are recorded rather than tidied: fhirVersion is 4.0.0, not the 4.0.1 every other listed endpoint declares, and it carries no software element, identifying itself only as 'ZeOmega FHIR R4 Implementation' dated 2021-01-01. The Drug Formulary base URL printed in the same table answers 404 and is in the candidate log (recorded 2026-08-19). No later re-check is recorded, so the date above is the last time anyone checked this entry against the live endpoint.

The same run, as data: this endpoint's JSON, what its CapabilityStatement declares, resource by resource, and every observation on record for it, with the dates it answered and the dates it did not.