ips.pdhc — technical notes

A growing collection of focused technical notes for ips.pdhc. The
fuller end-to-end description lives in description_of_IPS.md; this
file is for sections that need a stable URL inside the codebase (e.g.
audit findings, legal-confirmation paragraphs, deploy-shaped runbooks).

Spärr — historical data migration confirmation (ticket #208)

Scope. PDL Ch 4 § 4 spärr landed via IPS Renov 1 (PatientBlock,
ticket #197). Before that ticket, no PatientBlock table existed.
Ticket #208 asked whether any pre-existing "no-share" markers
elsewhere on the platform should have been converted into
PatientBlock rows when #197 shipped — so the new structured blocks
inherit any legacy patient opt-outs.

Verdict: no markers found. Negative confirmation.

What was swept (2026-06-09)

Both code and data, across every database that could plausibly carry
a patient opt-out marker:

DB	Schema column sweep	Data sweep
ips_db	information_schema.columns filtered on share, hidden, opt, nopat, exclud, spar, no_disclose	fhir_resources.resource_json for Patient rows containing NOPAT, confidentiality, restricted, or any meta.tag[]
dashboard_pdhc_db	same column-name filter	observation_cache.raw for the same security-label strings
gateway_pdhc_db	same column-name filter	n/a (no patient-shaped JSON columns)
request_pdhc_db	same column-name filter	n/a

All four schemas: 0 columns match.
IPS Patient JSON: 0 patients with meta.tag[] populated, 0
patients with NOPAT / confidentiality / restricted strings.
Dashboard cache JSON: 0 rows with security-label strings.

This is the expected result on this platform — PDHC was built
post-PDL Ch 4 § 4 with PatientBlock as the only spärr surface, and
no consumer ever wrote a legacy opt-out flag the way an older EMR
might (a do_not_share boolean on the patient row, or a
hidden_patient_list table).

What this means going forward

• No one-off migration was needed. No PatientBlock rows are
  owed from legacy data.
• The negative confirmation is documented here so a future audit
  doesn't re-ask the question. The expected scope of such an audit
  is "patient-shaped opt-out signals before #197 landed" — they
  didn't exist; this section is the canonical evidence.
• If a marker does appear in the future (e.g. via Synthea import
  with synthetic security labels, or via a future EMR migration), it
  should be converted into PatientBlock rows in the same migration
  that introduces it. The PatientBlock model has supported
  source_scope_type='caregiver' since #197 and now serves cross-
  caregiver semantics (#204), so it can carry any granularity a
  legacy marker would have expressed.

Reproducing the sweep

-- Schema sweep (one per database)
SELECT table_name, column_name
FROM information_schema.columns
WHERE table_schema = 'public'
  AND (column_name ILIKE '%share%'
       OR column_name ILIKE '%hidden%'
       OR column_name ILIKE '%opt_out%'
       OR column_name ILIKE '%nopat%'
       OR column_name ILIKE '%exclud%'
       OR column_name ILIKE '%spar%'
       OR column_name ILIKE '%no_disclose%')
ORDER BY table_name, column_name;

-- IPS Patient JSON sweep
SELECT count(*) FROM fhir_resources
WHERE resource_type = 'Patient'
  AND (resource_json::text ILIKE '%NOPAT%'
       OR resource_json::text ILIKE '%confidentiality%'
       OR resource_json::text ILIKE '%restricted%');

-- Dashboard cache JSON sweep
SELECT count(*) FROM observation_cache
WHERE raw::text ILIKE '%hidden%'
   OR raw::text ILIKE '%no_share%'
   OR raw::text ILIKE '%opt_out%'
   OR raw::text ILIKE '%confidentiality%'
   OR raw::text ILIKE '%NOPAT%';