Public health wants open-data consumers to see encounter counts by clinic without exposing row-level PII. Which object should they publish?
Select an answer to reveal the explanation.
Short Explanation
You can publish a de-identified aggregate view with encounter counts by clinic, keeping the data useful without exposing patient-level details. Temporal history that retains names and ledger narratives still disclose PII, while keeping PII in RAM does not protect it.
Full Explanation
Public health can meet the goal by publishing a view that returns de-identified encounter counts aggregated by clinic. This gives open-data consumers useful clinic-level totals without exposing row-level PII, such as patient names or encounter narratives. A temporal history table that retains patient names in every version is still identifying; preserving past versions does not de-identify the information. A ledger table that makes full encounter narratives available to anonymous users exposes sensitive details rather than limiting access to counts. An in-memory OLTP table is also not a privacy safeguard: keeping PII in RAM neither masks nor aggregates it, so the data remains exposed. Exam caveat: even clinic-level counts can create re-identification risk when a count is very small, so apply any required disclosure controls. Practical check: access the published view as the open-data role and confirm it returns only clinic-level counts; then try to read patient-level columns using that same role and verify access is denied.