- Ya
- 24 Agosti 2026, 21:35 UTC
- Mwandishi
- kamo
- Ahadi ya
- bd5331b
Two specs from the pre-build analysis of ~30 repos and the 2026 ambulatory EHR market. The program design records the six decisions that bind every sub-project: PHI stays on-premises (disk encryption and backups are owner-held, and the resulting compliance gap is recorded rather than assumed away); apps gain a parent/child tree so PhiModule can split by capability; the licence and network dependencies are bought while the data model and workflow are built; certification is designed for but deferred while HTI-5 is still proposed; a patient is a new entity in a new clinical package; FHIR is stored relationally because Yugabyte's GIN indexes cannot serve the query shapes US Core mandates; and the vertical is one new service, not a fleet. SP1 resolves a live contradiction. PhiServiceTypeMapping binds POS to ECOMMERCE_SYNC (BLOCKED_NO_BAA), and the whole commerce surface hangs off POS, so an org with handlesPhi=true cannot reach /commerce or own a market at all. PhiModule is app-grained where it needs to be capability-grained. Making apps a two-level tree lets the commerce core sit PERMITTED while only the ten retail sync adapters stay blocked, and does the same for Meet and VOIP, where the blocked thing is recording rather than the app. The split is only valid alongside a call-time PhiCapabilityGuard: today PhiTenantGuard is enforced at feature-enable time and nowhere else, so reclassifying without a call-site guard would be strictly worse than the blunt refusal it replaces. CommerceType.requiredService becomes total as a side effect, which is what makes EHR appear as a market type with no new gating code.