Non-modal MEDITECH (Greenfield Workspace + production fleet) cluster: 95 of 549 production endpoints (17%) deploy this shape, concentrated in OH (8), KS (7), TX (5). This cluster advertises 36 US Core 6.1 profiles in its CapabilityStatement, distinguishing it from the modal cluster.
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.
e0b59cee6ff82efd…AllergyIntolerance · CarePlan · CareTeam · Condition · Device · DiagnosticReport · DocumentReference · Encounter · Goal · Immunization · Location · MedicationRequest · Observation · Organization · Patient · Practitioner · PractitionerRole · Procedure · Provenance
Group · ValueSet
OH (8) · KS (7) · TX (5) · WI (5) · OK (5) · CT (4) · FL (4) · NE (4) · CO (3) · AZ (3)
Greenfield's public SMART configuration leaks roughly 165 internal infrastructure scope names (`infr-*`, `iops-*`) alongside the FHIR US Core scopes Two consequences. (1) Dev-portal hygiene: SMART App Launch STU 2.2 §5.1 specifies `scopes_supported` as a hint to dev-portal UX about what an application can request. These internal scopes pollute that signal and could mislead an integrator into believing capabilities are available that are not. (2) Surface-area disclosure: each leaked scope name is a free sketch of MEDITECH's internal cloud architecture — taken together, `infr-database-config`, `infr-redis-config`, and `infr-cluster-join` describe a clustered, Redis-backed config store with a vendor-onboarding workflow. Among the EHRs in this map, no other vendor exposes this much internal namespace through its public SMART configuration — Epic and Oracle Health (Cerner) both advertise only the FHIR scopes their app classes can actually request.
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-B/ 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.