A confidentiality checklist for health and human services systems

Reference article · 7 min read

Health and human services agencies hold some of the most sensitive records government keeps: child protection reports, substance use treatment histories, HIV and other communicable disease results, reproductive health services, domestic violence safety information, immigration status, and full household income and composition. Much of it sits in one eligibility or case management system, where a worker who legitimately needs to verify a household's income may also be two clicks from a case file the law says they must not open. Confidentiality in these systems is not a single control. It is a set of design decisions, configuration settings, and review habits.

The proof matters as much as the control. When a state quality review, a federal program reviewer, or a breach investigator arrives, the question is rarely whether you have role-based access. It is closer to: show me everyone who viewed this record in the last two years, what role they held, what justification they gave, and who reviewed that access afterward. Build the system so that answer takes an afternoon, not a vendor ticket.

Map the record types before you design the roles

Start with an inventory of data categories in the system and the legal regime attached to each one. A generic sensitivity scale is not enough, because several categories carry their own consent, disclosure, and redisclosure rules that sit on top of general privacy law.

• Categories to enumerate. Substance use disorder treatment, HIV and STI results, mental and behavioral health, reproductive health, child welfare and adult protective services investigations, domestic violence and address confidentiality program participants, juvenile records, federal tax information received for eligibility determination, and criminal history.
• Note the governing rule for each. HIPAA's minimum necessary standard, the federal confidentiality rules for substance use disorder patient records, IRS safeguarding requirements for federal tax information, program safeguarding rules attached to public assistance benefits, and state statutes covering HIV information and child welfare files. These rules change, and several have been amended in recent years. Confirm the current text with the official source and your agency counsel rather than relying on an internal summary.
• Record redisclosure conditions. Some categories travel with a notice prohibiting further disclosure. Decide now how that notice follows an export, a printed packet, or an interface to another system.

Design roles against minimum necessary

• Build roles from job duties, not the org chart. Two people with the same title in different units often need different data.
• Scope by relationship, not only by role. The strongest control in case systems is assignment: a worker sees cases on their caseload, unit, or county, and everything else requires an explicit action that is logged.
• Separate the verbs. View, edit, export, run reports, and bulk download should be distinct entitlements. Export and reporting are where large disclosures actually happen.
• Control the field level. Screen-level control is coarse. Sensitive fields should be suppressible within an otherwise visible record.
• Name every account. No shared logins, no generic unit accounts, and contractors identified as contractors with end dates set at creation.
• Constrain administrators. Application administrators should not be able to grant themselves program data access silently, and their configuration changes should log like any other action.

Segment programs and handle sealed records properly

Program segmentation means a user with general case access does not see protected program content by default. Access to those modules is granted separately, documented, and reviewed on its own cycle.

Sealing and expungement deserve their own test. A flag on a screen is not sealing. Confirm that a sealed or expunged case disappears from search results, worklists, standard reports, the data warehouse, outbound interfaces, and generated correspondence, while the sealing action itself remains in the audit trail. Ask what happens in backups and in any downstream copy the agency does not directly control.

Break-the-glass access with real reason capture

Emergency override is legitimate in child safety and clinical situations. It becomes a liability when it is quiet.

• Decide which categories permit override and which never do.
• Require both a structured reason code and free text before the record opens.
• Make the grant time-limited and automatically expiring, scoped to one record.
• Display an on-screen attestation that the use will be reviewed.
• Route every use to a monitored queue with a named reviewer and a recorded disposition. An override queue nobody reads is worse than no override at all, because it documents unreviewed access.

Detect self-lookups, relative lookups, and browsing

Most confidentiality incidents in these systems are curiosity, not intrusion. Build detection for the patterns that curiosity produces.

• Self-lookup. Match the viewing user against the subject record on name, date of birth, address, and any employee identifier carried in the data.
• Relative and neighbor lookup. Flag matches on surname, household address, or phone number between viewer and subject.
• High-profile records. Allow privacy staff to mark records for heightened monitoring without telling general users which ones are marked.
• Behavioral signals. Access without a case assignment, views with no subsequent case action, unusual volume, and off-hours patterns.
• Tell staff monitoring exists. An annual confidentiality acknowledgment that names the specific prohibited behaviors, paired with consistently applied consequences, prevents more incidents than detection does.

Audit trails and the proof an investigator will ask for

Log reads, not only writes. An access record should capture user, role in effect, record and data category viewed, timestamp, source address or device, access path, and any justification given. Store logs where application administrators cannot alter or purge them.

Set retention to the longest applicable requirement across the programs in the system, and confirm it against your state records retention schedule and program guidance rather than the vendor default. Then verify you can actually produce, without engineering help, a per-record access history, a per-user activity report for a defined period, a break-the-glass report with dispositions, and a point-in-time roster of who held what access. Run each report once while nothing is wrong, so you learn its gaps before an investigation does.

The access review, and what to ask vendors

Recertify access on a fixed cycle. Supervisors confirm each person's entitlements in writing, the review is dated and retained, and the resulting removals are tracked to completion. Tie deprovisioning to the HR system so separations are same day, and treat transfers as a role change rather than a role addition, which is how permissions quietly accumulate over a career. Sweep for dormant accounts and for entitlements that have never been used.

Questions worth putting to a vendor and into the contract:

1. Can staff generate a complete access history for one record, including read events, without vendor involvement?
2. Are audit logs protected from modification by application administrators, and how is that enforced?
3. How are sealed and expunged records suppressed across search, reporting, warehouse, interfaces, and correspondence?
4. Is break-the-glass configurable by data category, with mandatory reason capture and expiry?
5. What is the audit retention limit, and can logs be exported in an open format for retention beyond it?
6. Under what conditions may vendor personnel access production data, and are those sessions named, approved, time-limited, and logged to the same standard as agency staff?

HQT works with state and local agencies on software development, systems engineering, and security work for case and eligibility systems, including access control design and audit reporting.

Frequently asked questions