1.Who we are
Kalamazoo Care Network ("KzooCare", "we", "us") operates the website at www.kzoocare.org and a partner portal used by community organizations serving Kalamazoo County, Michigan. KzooCare provides shared software and a public service directory. KzooCare does not itself deliver housing, food, medical, legal, or other direct services.
Participating organizations are independent. Each remains responsible for its own services, its own records, and its own obligations to the people it serves.
2.Information from public website visitors
You can browse the service directory, guides, crisis resources, and the help finder without creating an account and without telling us who you are.
- Optional email sign-up. If you ask to be kept updated, we store the first name and email address you enter, when you subscribed, and which page you subscribed from.
- Help finder answers. Answers you give the guided help finder are used in your browser to suggest services. They are not saved to a resident record.
- Map tiles. The service map loads map images from OpenStreetMap. Your browser contacts OpenStreetMap directly, which means OpenStreetMap receives your IP address and the map area you are viewing.
We do not run advertising trackers, third-party web analytics, or cross-site tracking on the public site.
3.Information from agency representatives and other account holders
When someone creates a partner account we handle:
- Name, email address, and optionally a phone number, job title, and profile photo.
- Sign-in information. Accounts may be created with an email address and password or through Google, Microsoft, or Apple sign-in. If you sign in with Microsoft and grant permission, we retrieve your work profile photo once and store it as your avatar.
- Multi-factor authentication enrollment (an authenticator app secret held by our authentication provider).
- Organization membership and role, invitations you send or receive, notification preferences, saved searches, and records of role changes.
- Content you create in the portal: service listings, referrals, notes, consent records, announcements, poll responses, feedback tickets, and support messages.
4.Demo access requests
If you request demo access we store the contact name, email address, organization name, role, and the page you requested from, and we email you sign-in instructions. Activity inside the demo sandbox is recorded for product feedback — session identifier, page views, the last page visited, browser user-agent string, and any name, organization, or email you voluntarily enter in the demo prompt. The demo environment contains fictional sample data only and is technically separated from real resident data.
5.Organization applications and verification
When an organization applies to join, we collect the organization name, description and mission, service categories, address and/or service area, public website or other public presence, contact email and phone, hours, languages served, organization type, nonprofit registration status, and any existing systems you tell us about. Most of this becomes part of your public directory listing once approved.
Our internal review adds a vetting checklist, internal notes, requests for more information, decisions, and an event history of who did what and when. Internal notes and checklist details are visible only to KzooCare Network staff. Applicants see their application status and any information we specifically request from them.
6.Resident information the platform actually holds
When a participating organization records that it is helping someone, the platform stores a deliberately limited record:
- A one-way identity code (described in section 7), plus the person's initials, birth year, the first three digits of a ZIP code, household size, a veteran indicator, and preferred language.
- Which organization first entered the person.
- Recorded needs: a category (for example housing or food), an urgency level, a status, and a short free-text summary written by agency staff.
- Encounters: the organization, the service, the type and optional dollar value of assistance, and the date it occurred.
- Encounter notes written by agency staff. These are readable only by the organization that wrote them.
- Referrals between organizations: category, urgency, reason, notes, status history, assignment, and due dates.
- Consent records and their full change history.
An important limitation. Free-text fields — need summaries, encounter notes, referral reasons and notes — are typed by agency staff. The software does not inspect or filter what they contain. If staff type identifying or sensitive details into those fields, that text is stored as written. Participating organizations are instructed to keep free text limited to what is necessary for coordination.
We do not ask for or provide a field for Social Security numbers, street addresses, or full dates of birth in the resident record.
7.How identity matching works
To let two organizations recognize that they are helping the same person without exposing who that person is, the person's first name, last name, and date of birth are combined with a secret key held only on our servers and converted into a fixed-length code using a one-way cryptographic hash (SHA-256). Only that code is stored. The name and date of birth are not written to the database.
Being one-way means the code cannot simply be turned back into a name. It does not mean the code is anonymous: the same person entered the same way always produces the same code, and someone who already knew a specific name and date of birth and had access to the secret key could confirm whether that person exists in the system. The secret key is therefore treated as a sensitive credential.
Initials, birth year, and ZIP prefix are stored so staff can tell records apart. Combined with other information, these can narrow down who a record refers to. Treat them as indirect identifiers, not as anonymous data.
Every match attempt is logged, including which organization and user searched, the purpose, and whether a match was found. Where we log the network source of a lookup, it is stored as a hash rather than as a readable IP address.
8.Consent and information-sharing controls
Cross-organization sharing is controlled by a consent record for each person, with three separate switches: service history, recorded needs, and referrals. A consent record can also carry an expiration date and a list of specific organizations that must be excluded.
The system fails closed. If there is no consent record, if it has expired, or if no sharing switch is turned on, other organizations see nothing.
Consent is normally recorded by agency staff on the person's behalf, after they speak with that person. The record captures whether consent was given verbally or in writing, or was declined, along with who recorded it, for which organization, and when. Residents do not currently sign in to KzooCare and click a consent button themselves. Every change is written to an audit trail that cannot be edited from the application. Consent can be narrowed, expanded, expired, or withdrawn at any time by telling any participating organization.
9.Referrals
When one organization refers a person to another, the receiving organization sees the referral only if the referral sharing switch is on for that person. Both organizations then see the referral's category, urgency, reason, notes, status changes, assignment, and timing. Referral notes are written by staff, so the same free-text caution in section 6 applies.
10.Email and notifications
We send transactional email: account and password messages, agency application and verification updates, invitations, referral and consent alerts, announcements, and responses to requests you submit. Email is sent through our hosting provider's managed email service using the notify.kzoocare.org sending domain.
Notification emails are written to avoid resident identifying details; they generally tell you that something needs attention and link you into the secure portal rather than describing the case. In-app notifications are stored in the database and may reference a referral or resident record by its internal identifier.
The portal contains a setting for SMS alerts. SMS delivery is not currently wired to any provider, so no text messages are sent even if the setting is enabled.
11.Technical and security logging
Our hosting, database, and authentication providers keep operational logs, which can include IP addresses, timestamps, and request details, for reliability and abuse prevention. Within the application we keep our own records of resident lookups, consent changes, referral status changes, role and membership changes, verification decisions, and Network staff actions. These records exist for accountability and are retained with the data they describe.
12.Cookies and similar technologies
We do not use advertising or cross-site tracking cookies. We use only what the site needs to work:
- A session cookie from our authentication provider once you sign in.
- A cookie that remembers whether the portal sidebar is expanded.
- Browser local storage for your chosen language, your active organization, whether you have finished the walkthrough, demo-mode state, and referral view preferences.
13.How we use information
We use information to:
- Publish and maintain the public service directory and crisis resources.
- Let organizations coordinate care — recognize a shared client, see consented history, and send and track referrals.
- Surface coordination signals such as repeat assistance within a recent window, so staff can talk with the person about what they actually need.
- Operate accounts, permissions, verification, and security.
- Send the notifications described above.
- Produce aggregate and organization-level reporting on referral volume, response times, and service categories.
- Investigate misuse and improve the product.
We do not sell, rent, or trade information, and we do not share it with advertisers or data brokers.
14.When information is shared with participating organizations
- Directory and service information you publish is public by design once your organization is approved.
- Resident information is shared with another organization only where a current consent record permits that category of sharing, that organization is not excluded, and the organization has a service relationship with the person or is a party to the referral. These rules are enforced by the database itself, not only by the interface.
- Encounter notes are readable only by the organization that wrote them. Referral details are readable only by the sending and receiving organizations.
- KzooCare Network staff administer the network: organizations, users, roles, verification, announcements, and support. Network staff can also read resident records and encounter history where the applicable consent permits history sharing, in order to support and troubleshoot the network. Network staff do not have access to another organization's encounter notes or to referral records they are not a party to.
- We may disclose information if required by law, or where we reasonably believe it is necessary to prevent imminent harm.
15.Service providers
We rely on a small number of vendors that process data on our behalf:
- Lovable — application hosting, deployment, transactional email delivery, and an AI gateway used for internal translation tooling.
- Supabase — managed PostgreSQL database, authentication, and file storage.
- Google, Microsoft, and Apple — optional single sign-on for partner accounts. Microsoft is additionally contacted once to retrieve a profile photo if you allow it.
- OpenStreetMap — map tiles, contacted directly by your browser.
Internal translation tooling sends interface text — not resident records — to a language model through the AI gateway.
16.Retention and deletion
Describing this accurately matters more than sounding tidy:
- Resident records, needs, encounters, notes, referrals, consent records, and audit trails are retained indefinitely today. There is no automatic purge job.
- Consent expiration stops further sharing, but it does not delete the underlying records.
- If an organization is removed, records that cascade from the organization are deleted with it; audit and event history that documents network administration is retained.
- Account deletion removes the account and its profile. Content already contributed — referrals, notes, audit entries — remains, because other organizations rely on it.
Formal retention periods have not yet been set. If you have a question about a specific record, contact us at jason@kzoocare.org.
17.Security
Traffic between your browser and KzooCare uses HTTPS/TLS. Our database provider encrypts data at rest and takes automated backups. Passwords are stored as salted hashes by our authentication provider. Access to resident data is enforced by row-level security policies inside the database, so the rules apply even to direct data access, and the database additionally refuses resident data to sessions that have not completed multi-factor authentication. Multi-factor authentication with an authenticator app is required for Network staff and for staff of approved partner organizations; demo sandbox accounts, which can only reach fictional data, are exempt.
No system is perfectly secure. See our Security & Privacy page for more detail, and report suspected issues to security@kzoocare.org.
18.Responsibilities of participating organizations
Organizations and their staff are responsible for obtaining and honestly recording resident consent, for entering only information that is necessary, for keeping credentials private, for using multi-factor authentication, for looking up resident information only when there is a genuine service-related reason, and for reporting suspected misuse. These obligations are set out in the Partner Agreement.
19.Children and minors
The public website is not directed to children, and we do not knowingly collect information directly from children online. Participating organizations serve households that include minors, and a household record may reflect that. Organizations should follow their own policies and applicable law when recording information about a minor, and should not enter a minor as a separate resident record unless their program requires it.
20.Legal frameworks
KzooCare does not claim compliance with HIPAA, 42 CFR Part 2, FERPA, or any other specialized regulatory framework. Some participating organizations may themselves be subject to those rules. Whether a particular organization may place particular information into KzooCare is a decision for that organization and its own counsel.
21.Changes to this policy
We will update this page when our practices change, and we will revise the effective, last-updated, and version values at the top. Material changes affecting partner organizations will also be communicated in the portal.
22.Contact
Privacy questions: jason@kzoocare.org
Security reports: security@kzoocare.org
If you are looking for help right now, start at Find help or see crisis resources.