Sandbox/ModelFork/Prod/AcmeCare/PatientModel: Difference between revisions

Content deleted Content added

Inline

Latest revision as of 10:51, 6 July 2026

guideCARE 1.0+

ℹ️ Downstream fork

This is a production fork of the DevEntity PatientModel. It started from v1.0.0 and has diverged with custom fields. Upstream has since evolved to v2.0.0 — this fork has not yet synced.

AcmeCare Medical Center is a downstream consumer of the DevEntity PatientModel. It maintains its own fork to support organization-specific workflows while retaining the ability to sync improvements from upstream.

Ownership

Entity: AcmeCare Medical Center
Type: Production (downstream fork)
Upstream: DevEntity PatientModel
Forked from: v1.0.0
Last synced: v1.0.0 (behind by 1 major version)

Fields

Field	Type	Origin
`patient_id`	`UUID`	Inherited from upstream v1.0.0
`first_name`	`String(100)`	Inherited from upstream v1.0.0
`last_name`	`String(100)`	Inherited from upstream v1.0.0
`date_of_birth`	`Date`	Inherited from upstream v1.0.0
`gender`	`String(1)`	Kept — upstream removed in v2.0.0; AcmeCare still requires it
`phone`	`String(20)`	Kept as optional — upstream made required in v2.0.0
`email`	`String(254)`	Inherited from upstream v1.0.0
`address`	`Text`	Inherited from upstream v1.0.0
`insurance_provider`	`String(100)`	Custom — AcmeCare-specific
`insurance_id`	`String(50)`	Custom — AcmeCare-specific
`primary_care_physician`	`String(100)`	Custom — AcmeCare-specific

How the sync works

A sync operation pulls in upstream changes without touching custom fields. Here is the step-by-step procedure:

Step 1 — Diff upstream

Compute the delta between the upstream version you last synced from (v1.0.0) and the target version (v2.0.0):

Change	Upstream v2.0.0
Added	`blood_type`, `preferred_language`
Removed	`gender`
Modified	`phone` → required
Unchanged	`patient_id`, `first_name`, `last_name`, `date_of_birth`, `email`, `address`

Step 2 — Evaluate each change

Change	Conflict?	Decision
Add `blood_type`	None — new field, no collision	ADOPT — add to table
Add `preferred_language`	None — new field, no collision	ADOPT — add to table
Remove `gender`	Yes — AcmeCare has and uses this field	DECLINE — keep gender, document divergence
Make `phone` required	Yes — AcmeCare currently allows optional phone	PARTIAL — require for new patients only; existing stay optional
`patient_id` through `address`	None — unchanged	Inherit automatically
Custom fields (insurance_provider, insurance_id, primary_care_physician)	None — upstream doesn't know about them	Preserved automatically

Step 3 — Apply

Edit this page's field table to reflect the decisions: add the adopted fields, update the phone constraint note, and bump the "Last synced" version to v2.0.0. Custom fields stay in the table untouched. The resulting model after sync:

Field	Type	Origin
`patient_id`	UUID	Upstream v1.0.0+
`first_name`	String(100)	Upstream v1.0.0+
`last_name`	String(100)	Upstream v1.0.0+
`date_of_birth`	Date	Upstream v1.0.0+
`gender`	String(1)	Kept (upstream removed in v2.0.0)
`phone`	String(20)	Required for new patients (upstream made required)
`email`	String(254)	Upstream v1.0.0+
`address`	Text	Upstream v1.0.0+
`blood_type`	String(5)	Synced from upstream v2.0.0
`preferred_language`	String(50)	Synced from upstream v2.0.0
`insurance_provider`	String(100)	Custom — preserved
`insurance_id`	String(50)	Custom — preserved
`primary_care_physician`	String(100)	Custom — preserved

Why custom changes never break

Because each fork is its own wiki page:

Upstream fields and custom fields live in the same table — there is no separate "override file" that can get stale
A sync is just a page edit: add new rows, update notes on changed rows, leave custom rows alone
Upstream removal of a field has zero effect on the fork — the fork simply chooses not to delete the row
There is no automated merge, no rebase, no conflict markers — every decision is explicit and recorded in the page history

This is the wiki equivalent of a manual three-way merge where the fork author is the resolver.

Upstream v2.0.0 — sync decision table

Upstream change	Decision	Rationale
`blood_type` (new)	ADOPT	Valuable clinical field, no conflict
`preferred_language` (new)	ADOPT	Needed for patient communications
`gender` (removed)	DECLINE	Billing system requires it
`phone` → required	PARTIAL	Required for new patients; existing grandfathered

Diff summary vs upstream v2.0.0

Count	Type
8	Shared fields (inherited from upstream, potentially modified)
3	Custom fields (AcmeCare-only)
1	Retained field (gender — removed by upstream)
1	Modified constraint (phone — optional here, required upstream)

@@ Line 17: / Line 17: @@
 * '''Upstream:''' [[Sandbox/ModelFork/DevEntity/PatientModel|DevEntity PatientModel]]
 * '''Forked from:''' v1.0.0
-* '''Last synced:''' v1.0.0 (never synced — behind by 1 major version)
+* '''Last synced:''' v1.0.0 (behind by 1 major version)
 == Fields ==
@@ Line 36: / Line 36: @@
 |}
-== Upstream v2.0.0 — sync decision table ==
+== How the sync works ==
+A sync operation pulls in upstream changes without touching custom fields. Here is the step-by-step procedure:
-When AcmeCare decides to sync from upstream v2.0.0, each change would be evaluated independently:
+=== Step 1 — Diff upstream ===
+Compute the delta between the upstream version you last synced from (v1.0.0) and the target version (v2.0.0):
 {| class="wikitable"
+! Change !! Upstream v2.0.0
-! Upstream change !! Decision !! Rationale
 |-
+| '''Added''' || <code>blood_type</code>, <code>preferred_language</code>
-| <code>blood_type</code> (new) || '''ADOPT''' || Valuable clinical field, no conflict with existing fields
 |-
+| '''Removed''' || <code>gender</code>
-| <code>preferred_language</code> (new) || '''ADOPT''' || Needed for patient communications, no conflict
 |-
+| '''Modified''' || <code>phone</code> → required
-| <code>gender</code> (removed) || '''DECLINE''' || AcmeCare's billing system requires gender — declining upstream removal
 |-
+| '''Unchanged''' || <code>patient_id</code>, <code>first_name</code>, <code>last_name</code>, <code>date_of_birth</code>, <code>email</code>, <code>address</code>
-| <code>phone</code> → required || '''PARTIAL''' || Make required for new patients; existing patients grandfathered
 |}
+=== Step 2 — Evaluate each change ===
-This demonstrates the '''selective sync''' model: downstream consumers are not forced to accept every upstream change. They cherry-pick what works for their context and keep their own customizations.
+{| class="wikitable"
+! Change !! Conflict? !! Decision
+|-
+| Add <code>blood_type</code> || None — new field, no collision || '''ADOPT''' — add to table
+|-
+| Add <code>preferred_language</code> || None — new field, no collision || '''ADOPT''' — add to table
+|-
+| Remove <code>gender</code> || '''Yes''' — AcmeCare has and uses this field || '''DECLINE''' — keep gender, document divergence
+|-
+| Make <code>phone</code> required || '''Yes''' — AcmeCare currently allows optional phone || '''PARTIAL''' — require for new patients only; existing stay optional
+|-
+| <code>patient_id</code> through <code>address</code> || None — unchanged || Inherit automatically
+|-
+| '''Custom fields''' (insurance_provider, insurance_id, primary_care_physician) || None — upstream doesn't know about them || '''Preserved automatically'''
+|}
+=== Step 3 — Apply ===
+Edit this page's field table to reflect the decisions: add the adopted fields, update the phone constraint note, and bump the "Last synced" version to v2.0.0. Custom fields stay in the table untouched. The resulting model after sync:
+{| class="wikitable"
+! Field !! Type !! Origin
+|-
+| <code>patient_id</code> || UUID || Upstream v1.0.0+
+|-
+| <code>first_name</code> || String(100) || Upstream v1.0.0+
+|-
+| <code>last_name</code> || String(100) || Upstream v1.0.0+
+|-
+| <code>date_of_birth</code> || Date || Upstream v1.0.0+
+|-
+| <code>gender</code> || String(1) || '''Kept''' (upstream removed in v2.0.0)
+|-
+| <code>phone</code> || String(20) || Required for new patients (upstream made required)
+|-
+| <code>email</code> || String(254) || Upstream v1.0.0+
+|-
+| <code>address</code> || Text || Upstream v1.0.0+
+|-
+| <code>blood_type</code> || String(5) || '''Synced from upstream v2.0.0'''
+|-
+| <code>preferred_language</code> || String(50) || '''Synced from upstream v2.0.0'''
+|-
+| <code>insurance_provider</code> || String(100) || '''Custom — preserved'''
+|-
+| <code>insurance_id</code> || String(50) || '''Custom — preserved'''
+|-
+| <code>primary_care_physician</code> || String(100) || '''Custom — preserved'''
+|}
+=== Why custom changes never break ===
+Because each fork is its own wiki page:
+* Upstream fields and custom fields live in the same table — there is no separate "override file" that can get stale
+* A sync is just a page edit: add new rows, update notes on changed rows, leave custom rows alone
+* Upstream removal of a field has zero effect on the fork — the fork simply chooses not to delete the row
+* There is no automated merge, no rebase, no conflict markers — every decision is explicit and recorded in the page history
+This is the wiki equivalent of a '''manual three-way merge''' where the fork author is the resolver.
+== Upstream v2.0.0 — sync decision table ==
+{| class="wikitable"
+! Upstream change !! Decision !! Rationale
+|-
+| <code>blood_type</code> (new) || '''ADOPT''' || Valuable clinical field, no conflict
+|-
+| <code>preferred_language</code> (new) || '''ADOPT''' || Needed for patient communications
+|-
+| <code>gender</code> (removed) || '''DECLINE''' || Billing system requires it
+|-
+| <code>phone</code> → required || '''PARTIAL''' || Required for new patients; existing grandfathered
+|}
 == Diff summary vs upstream v2.0.0 ==
@@ Line 61: / Line 140: @@
 | 8 || Shared fields (inherited from upstream, potentially modified)
 |-
-| 3 || Custom fields (AcmeCare-only: insurance_provider, insurance_id, primary_care_physician)
+| 3 || Custom fields (AcmeCare-only)
 |-
 | 1 || Retained field (gender — removed by upstream)