docs(data-integration): let each dataset name its own key - #73
Merged
Conversation
Row keys said every row carries record_id, which was never true of the Provider Directory feed and sat awkwardly beside the keys four datasets already had: patients kept PT-0001 next to an MRN, encounters and diagnostic_reports carried record_id equal to encounter_id and report_id on every row, and documents ended up with record_id twice, in columns one and five, because the page listed it mid-table as well. Each dataset now names its own key, listed first: allergy_id, condition_id, observation_id and the rest, keeping encounter_id, location_id, report_id and patient_identifier where they already existed. Fourteen tables gained the row that names it — until now only six said what keyed them — and the foreign keys name the column they resolve against, which is the same name in most cases. The convention keeps only what is not per-dataset: the key must stay stable because the resource id derives from it, and is_deleted retracts the row.
added 2 commits
August 27, 2026 22:18
The site serves assets/** with `cache-control: max-age=31536000, immutable` while the pages get max-age=60, so an edited template never reaches anyone: the edge froze the pre-16:12 CSVs and would have served them until 2027. A query string does not help, since it is not part of the cache key. That header is right for content-addressed files and wrong for permanent ones, so the filenames now carry the content hash — new content, new URL, fresh fetch. The file widget keeps the URL and the label on separate lines, so a reader still sees clinical_observations.csv. `bun assets:hash` recomputes them; run it after touching a template.
…ionship Sixteen bespoke key names — device_id, coverage_id, goal_id — were one idea wearing sixteen labels: the dataset is already known from the file, so the name carried nothing the column did not. They are record_id again. Only patients and encounters keep their own, because patient_identifier and encounter_id pair with a _system and become the resource's identifier. practitioners and care_team lose the key entirely. A row there is a relationship — a clinician at a location in a role, a member on a patient's team — and no roster has a primary key for one, so record_id could only be minted, and a minted key that is regenerated each export churns every resource it names. Both are keyed by the columns that define the relationship, which is how the Provider Directory feed already keys the same grain.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.