Toggle menu
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Sandbox/ModelFork/Prod/AcmeCare/PatientModel

From OHC Network Wiki
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)