dWell-KC's case managers and property partners work with electronic protected health information (ePHI) every day — diagnoses, disability status, SSNs, health insurance, domestic violence history. This page describes how that data is tokenized, scoped, consented to, and audited across the platform.
A client's most sensitive fields — SSN, diagnosis, disability details, domestic violence records — live behind a dedicated Protected Information view, separate from the general client profile. Reaching it requires a fresh, single-use access token minted for that specific staff member, that specific client, in that specific moment.
How a Protected Info view is generated
SSN identity matching without exposing raw values
Cross-organization duplicate-client detection runs on a SHA-256 digest of the SSN (salted with an application secret), so the platform can recognize the same person across agencies without any organization seeing another organization's raw client data.
A client record has ordinary case-management fields visible to anyone with basic client access — and two additional tabs that carry the actual regulated data. Both require the viewing user to hold a role that's explicitly permitted to see them.
The HMIS 2.02 compliance workspace for a client: project enrollments, household composition, income sources, chronic homelessness assessments, and data snapshots used for HUD APR/CAPER reporting. This is agency-facing HMIS data, not general case notes.
SSN, date of birth, diagnosis, disability responses, and domestic violence details. This tab is deliberately separated from the rest of the client record so that "can view a client" and "can view a client's ePHI" are never the same permission.
Minimum necessary, by default
A role that can manage a client's housing case doesn't automatically inherit access to that client's ePHI. Organizations grant HUD Hub and Protected Info visibility to the roles that actually need it — case managers and medical staff, typically — while leaving general case-management roles scoped to non-clinical fields.
A single client record is assembled differently depending on who's looking. Here's what each audience sees of a client's engagement history, case activity, HMIS data, and ePHI.
| Audience | Directory (Name, Org, Contact) |
Engagement & Check-In History |
Case Notes, Activity Feed |
HUD Hub (HMIS Data) |
Protected Info (SSN, Diagnosis, DV) |
Can Edit |
|---|---|---|---|---|---|---|
| Admin & Case Managers — Primary Agency [1] | Full | Full | Full | Full | Full | Full |
| Other Users — Primary Agency [2] | Full | Full | Full | Full | Full | Full (today) |
| Users with Search All permissions [3] | Full | None | None | None | None | None |
| Users belonging to another Agency [4] | Directory only | None | If granted | Own projects, if granted | None | Contact info only |
| Users belonging to a Property Manager [5] | None | None | Own property only | None | None | Own property only |
| The Client / Tenant [6] | Own record only | None | Own record only | None | None | Own record only |
[1] Admin & Case Managers
Full agency-view profile: engagement/check-in history, visits, notes, cases, referrals, messages, documents, and forms in one activity feed — plus the HUD Hub tab and a tokenized Protected Info view for SSN, diagnosis, and domestic violence details.
[2] Other Users — Primary Agency
Any staff member with a membership in the client's primary agency — case manager or not — reaches the same client profile, HUD Hub, and Protected Info views today. Organization membership is the access boundary; role does not further narrow what's visible inside that org. Edit rights on HUD Hub / enrollment fields can still be more limited by role.
[3] Search All permissions
A super-admin-only grant. Directly, it surfaces a system-wide directory — name, primary agency, case worker, last known location — for every client, across every organization. From there, "View as Agency" steps into the client's primary agency context, which then grants the same full access as row [1] for that client. Because of that escalation path, this permission should be reserved for a small, audited set of users.
[4] Users belonging to another Agency
Without a grant, a staff member at a different agency can look up a client's basic
identity — name, aliases, phone/email on file, current tenancy, agency contact — and,
like any agency, add or update the client's aliases, emails and phone numbers. When the
client's primary agency issues a ClientAccessGrant — by hand, or through a
pipeline Access Grant stage an admin certified once (Full Access for one year, only after
the agency's Shared Access requirements are on file) — that agency gets the
client page and a read-only profile; each note, report and case still follows its
Visibility level, so only records set to Agency Org Network or wider reach them. HUD Hub
opens only when the client is enrolled in one of the agency's own projects, and shows
only those enrollments. Protected Info and identity documents are never shared.
[5] Property Management
Only tenants with an active tenancy or placement request on that PM's own properties appear at all. What's visible is scoped to the housing relationship: lease, unit, rent ledger, housing history, and visit observations shared under a property_management-audience policy — never SSN, diagnosis, HUD Hub data, or the agency's internal case notes.
[6] Client / Tenant
Sees their own record through the tenant portal: contact info, date of birth, emergency contact, family members, their own lease/voucher/case status, and any note or report a staff member has explicitly marked visible to them. No HUD Hub tab, no self-service edit of SSN or diagnosis — those fields are staff-entered only.
dWell-KC tracks client authorization to share information as first-class, auditable records — not a checkbox buried in an intake form. Each consent type follows the same lifecycle: versioned language, a signed record, and the ability to revoke or let it expire.
HIPAA Release — one record per recipient, not one per client
A HIPAA authorization is legally tied to a specific recipient and purpose (45 CFR §164.508), so a client can have several active at once — one to share records with a new provider, another with a partner agency — each independently revocable. HMIS Privacy Notice and ROI stay single-active by design.
| Field | Captured |
|---|---|
| Recipient / Purpose | Who the release authorizes disclosure to, and why |
| Consent method | Electronic, in-person, verbal, or mailed |
| Signed by | Client (self-service or in-person) or staff on the client's behalf |
| Witness & interpretation | Witness name, interpreter used and language, whether a copy was given to the client |
| Administered by | The staff member who ran an in-person signing, when applicable |
| Expiration | Time-limited — treated as inactive once expired |
| Revocation | Targets the single release — other active releases are unaffected |
Self-service signing, or staff-administered — both fully attributed
Staff can send a client any of the three authorizations to review and sign themselves through their portal — it appears as a to-do item and a notification, and the language is shown in full before signing. Staff can also record a signature directly, on the client's behalf, capturing witness and interpreter details for an in-person session. Either path produces the same audit-quality record, distinguishing a self-signed authorization from one a staff member administered.
A per-client Authorization Certificate can be downloaded as a PDF at any time — a chronological, printable record of every consent and release on file, including revoked and expired ones.
Why three separate consent records instead of one
HMIS data sharing, general releases of information, and HIPAA-covered health disclosures are legally distinct authorizations. Keeping them as separate, independently revocable records means revoking one — say, a specific ROI to a former partner agency, or a single HIPAA release to one recipient — never silently affects the others.
What gets logged, automatically
Organizational & role boundaries
Whether you're an agency evaluating dWell-KC for a HIPAA-covered program, or a client with a question about a consent or release on file, reach out and we'll follow up directly.
Authentication, authorization, and infrastructure-level protections across the platform.
View Security PageWhat information is collected, how it's used, and client rights over their own data.
View Privacy Policy