Modal MEDITECH (Greenfield Workspace + production fleet) cluster: 220 of 549 production endpoints (40%) deploy this exact CapabilityStatement shape, concentrated in CA (20), IL (17), TX (13). This cluster advertises 36 US Core 6.1 profiles in its CapabilityStatement.
A CapabilityStatement shape cluster groups production FHIR endpoints by the exact CapabilityStatement they serve at runtime. MEDITECH (Greenfield Workspace + production fleet) publishes one reference CapabilityStatement, but production hospitals deploy several distinct shapes of it — each cluster is one of those shapes.
401d772a1b3570e9…AllergyIntolerance · CarePlan · CareTeam · Condition · Device · DiagnosticReport · DocumentReference · Encounter · Goal · Immunization · Location · MedicationRequest · Observation · Organization · Patient · Practitioner · PractitionerRole · Procedure · Provenance
Group · ValueSet
CA (20) · IL (17) · TX (13) · MA (11) · PR (10) · OK (8) · MO (8) · NE (7) · PA (7) · TN (6)
Greenfield consent fails with bare `error=access_denied` — issued credentials are bound to a Google identity through an opaque, support-mediated provisioning step with no self-service path to inspect or modify the binding MEDITECH is the only EHR in this map (Epic, Cerner/Oracle Health, MEDITECH) that requires human-mediated provisioning for sandbox credentials AND offers no self-service afterward to inspect or recover from a misaligned binding. Compare: Epic (asymmetric Backend Services, instant), Cerner (`client_secret_basic`, instant). When MEDITECH's binding is wrong — and developers have no way to detect that until OAuth fails at consent — the only recovery is a support email round-trip. This is a process gap, not a code defect: standard SMART tooling (authorization_code + `client_secret_post` + PKCE S256) runs unchanged once the binding is correct.
From the public MEDITECH (Greenfield Workspace + production fleet) overlay finding sweep (2026-04-27). Full vendor overlay has 4 findings with verbatim quotes and source URLs.
This outlier cluster has too few production endpoints for us to host a dedicated mock under /v/cluster/meditech-cluster-A/ today. The modal MEDITECH (Greenfield Workspace + production fleet) cluster is the wire shape that most production deployments use — that's the right starting point for integration testing.
MEDITECH Greenfield Workspace publishes a US Core STU6 v2.0.0 implementation (dated 2023-05-25) that is anonymous-readable for CapabilityStatement and SMART configuration. Authenticated probing is gated by an authorization_code flow with PKCE S256 and `client_secret_post`; identity is bound to a single operator-provisioned Google ID per client_id with no self-service management. As of 2026-04-27 the consent step rejects developer Google identities at Greenfield's user-to-client allowlist with a bare `error=access_denied` and no diagnostic body; the only documented recovery path is an email round-trip with greenfieldinfo@meditech.com. The Greenfield sandbox runs a US Core version (STU6) in use by almost no MEDITECH production customer per Phase F's harvest of 542 customer endpoints — most customers remain on the frozen R4 v1.0.0 baseline from 2021. Synthetic sandbox modeled after observed MEDITECH (Greenfield Workspace + production fleet) deployment shapes. Not affiliated with the vendor or any listed hospital. Trademarks used for identification only.