dWell-KC manages protected information, sensitive financial records, and case data for vulnerable people. Every layer of the platform — from the database to the browser — is built with security and privacy as a first principle.
dWell-KC handles Protected Health Information (PHI) including Social Security Numbers, health and disability records, and income data. The most sensitive fields are encrypted one by one, every protected field is limited by role and organization, and SSNs are left out of every data export.
How SSNs are handled
Encryption at rest
SSNs, diagnoses and medical notes on client and family records are encrypted individually with AES-256-GCM (Lockbox), so a database dump or backup shows only ciphertext. Their change history keeps only the ciphertext too. The rest of the database and its backups are encrypted at rest by our hosting provider, and the application only connects to it over TLS.
Duplicate-client checks match SSNs through a keyed blind index (BlindIndex), so lookups never decrypt stored values.
Access is never assumed. Every request is authenticated and every action is authorized based on the user's role and organizational context before a single database row is touched.
Powered by Devise — an industry-standard authentication framework used by thousands of production applications. All routes require authentication by default. Staff get access to an organization only through that organization's administrators, usually by a secure email invitation.
Role-based access control enforces what each user can do. Roles are scoped per organization — a user can be an admin at one agency and a case manager at another. Abilities are evaluated server-side on every request; there is no client-side gate to bypass.
Every query is scoped to the current organization. Beyond a client's basic identity, another organization's data is never accessible unless an explicit access grant exists or a record's Visibility level includes you. Parent organizations can manage their child orgs.
Defense in depth — not just one gate
Authorization is checked at multiple layers: the request authentication filter, the role-based ability check, and the scoped database query. A misconfigured route cannot expose data from another org because the query itself will return zero rows for an unauthorized scope.
PaperTrail audit logging is active on all major models in dWell-KC. Every create, update, and destroy records the exact change, the user who made it, and the timestamp — automatically, with no extra developer effort required.
Models with full PaperTrail audit logging
DataSnapshot — locked enrollment records
HMIS enrollment data is frozen into a DataSnapshot at entry and exit, automatically
or on the schedule set in Region Settings. Each snapshot locks a set number of days after entry
or exit (by default, 3 days after exit), enforced by a daily job in the region's time zone —
preserving the exact state of the record for HUD reporting and audit purposes.
Email audit logging
Every outbound email is BCC'd to an internal EmailLog record. Delivery, open,
and bounce events are captured via webhook so there is a permanent record of all
system communications to users.
Access log — logins & page views
Every sign-in and every page a signed-in user visits is recorded to an internal
AccessLog — user, organization context, path, IP address, and timestamp —
reviewable by super-administrators for security investigation and HIPAA audit-control
purposes.
Security controls applied to every request
before_action :authenticate_user! on every controller. Public pages are explicitly allowlisted — everything else requires a valid session.Additional protections
Multi-agency coordination requires controlled sharing — not open access. dWell-KC's Visibility Permissions and the ClientAccessGrant model give staff simple, precise control over exactly what gets shared and with whom.
Visibility Permissions — one level per record
Narrowest to widest. "Network" means the organization's parent, child and sibling organizations, the organizations it shares clients with, and the organizations of people on its teams. Only the creator and the organization's admins can edit or delete a restricted record.
Enforced everywhere the record appears
A restricted record is checked on its own page and also left out of lists, activity feeds, dashboard lists, pickers and search results for anyone outside its level. Notifications about it go only to people who can see it, and an observation's photos and notes are never copied into a report that more people can read.
ClientAccessGrant — consent-based cross-agency sharing
When a client needs services from multiple agencies, their primary agency creates a ClientAccessGrant to share the profile with a second organization. A grant records the grantor's certifications — HIPAA always, plus the ROI wording when the agency's Shared Access settings require an ROI on file — and it is time-stamped and revocable. A pipeline's Access Grant stage can make the grant: an admin certifies the stage once, the grant waits until the agency's requirements are on file, runs Full Access for one year, and names the pipeline and certifier. Without a grant, another agency can look up only a client's basic identity — name, aliases, contact details, current housing and agency contact — never case notes, HUD data or protected information.
Victim service providers (VAWA)
Domestic violence and other victim service providers can flag their organization as a VSP. Other organizations then see it only as "Protected Agency" — in client records, chats, referrals, the ledger and notifications — and its staff names are hidden in shared chats. Its clients are left out of other agencies' HUD reports, the Data Center and the Data Explorer, and with the region's Full VSP Exclusion setting, out of client search too.
Security doesn't stop at the application layer. Transport encryption, payment security, and background job isolation are all first-class concerns.
TLS enforced on all connections. Plain HTTP requests are automatically redirected to HTTPS. HSTS headers instruct browsers to never connect over plaintext.
Rent payments and CoC transfers run through Stripe Connect. Card data never touches dWell-KC servers. Stripe handles PCI DSS compliance; dWell-KC stores only payment intents and receipts.
PostgreSQL on encrypted storage, reached only over TLS, with SSN, diagnosis and medical notes columns encrypted by the application. Encryption keys and the SSN hashing salt are kept in the environment, never in source code.
Async jobs (geocoding, pipeline auto-advance, APR generation) run in isolated Sidekiq workers backed by Redis. Jobs carry only IDs — no PHI is serialized into the queue.
Documents, photos, and attachments are stored via ActiveStorage with content-type validation, in private cloud storage. Files are reached only through unguessable signed links shown on pages you're authorized to see, and the storage links behind them expire within minutes.
WebSocket connections authenticated via the same Devise session as the HTTP layer.
Chat channels are scoped to their ChatMember list — subscription to
a channel requires explicit membership, verified server-side.
Outbound email via Resend with SPF/DKIM/DMARC configured to prevent spoofing.
Every sent email is BCC'd to an internal EmailLog. Delivery, open,
and bounce events are tracked via signed webhook payloads.
Have a security concern or question?
Security disclosures and questions can be sent directly to our team. We take every report seriously and respond promptly.
info@dwell-kc.org • Privacy Policy