Security
Access control, encryption, audit trails, and HIPAA-minded tools for spiritual care teams — summarized for leadership and IT reviewers. Production workspaces open only after a signed Business Associate Agreement and owner provisioning.
Data protection at a glance
How Chaplain's Assistant layers security for spiritual care records — without exposing implementation secrets.
Protection stack
| Layer | Protects | What you get |
|---|---|---|
| In transit | Data moving between browsers and the service | Industry-standard TLS encryption on application traffic |
| At rest | Data stored in the cloud database and files | Cloud-provider encryption for stored records and objects |
| Application fields | Sensitive free-text spiritual care content | Optional field-level encryption for high-sensitivity text so plain names/notes are not left exposed in console views when enabled |
| Access & tenancy | Who can see which communities and records | Signed-in workforce accounts, roles, and company/community scoping so users only reach authorized sites |
| Platform boundary | Operator tools vs customer clinical data | Platform owner tools are designed to stay isolated from tenant clinical records |
| Integrity & audit | Trust in completed documentation | Attributable entries, policy-driven edit windows, and amendment reasons when clinical content is changed after the fact |
| AI PHI anonymization | Spiritual notes sent to optional AI helpers | Real-time de-identification pipeline (known-name pseudonyms, NER-style redaction, and identifier scrubbing) before any model request |
| AI zero-data retention | Chaplain reflections and visit notes in enterprise AI | Vertex AI under your GCP BAA — customer content is not used to train foundation models; prompts and responses are not logged by the app and context caching is disabled |
| Session & admin hygiene | Unattended workstations and privileged accounts | Idle session controls and multi-factor options for admins, configurable by organization policy |
| Shared responsibility | Overall program readiness | You control user provisioning, training, documentation policy, and any Business Associate Agreement with cloud providers required for your use case |
These controls support privacy-conscious, healthcare-adjacent spiritual care workflows. They are not a HIPAA certification claim. Organizations remain responsible for configuration, workforce access, training, and any agreements required for their regulatory posture.
Security commitment
Chaplain's Assistant is built for organizations that treat spiritual care documentation with the same rigor as clinical records. Security is a shared responsibility between MyMinistry.Help, your IT leadership, and day-to-day users.
Access control
The platform enforces role-based access at multiple levels:
- Firebase Authentication with email verification for workforce accounts
- Optional Microsoft Entra (Azure AD) single sign-on for work-account login per company
- Company and community scoping — users see only authorized communities
- Corporate admin, community admin, chaplain, and volunteer roles
- System owner tools isolated from tenant clinical data
Audit trails and documentation integrity
Visit logs, profile changes, and amendments are attributable and time-stamped according to your documentation policy. Original entries are preserved; governed edits require documented reasons when policy dictates. Empty draft sessions may be cancelled freely; content-bearing notes require an audit reason to cancel.
Anonymize mode
For trainings, screenshots, and shared screens, chaplains can toggle anonymize mode to mask resident names in the UI. See our Privacy Policy for limitations. We recommend using demo data for marketing captures.
Optional AI features
When enabled, AI helpers (Spiritual Trends, weekly debriefs, library reflections, visit prayer suggestions) run through a PHI anonymization pipeline before inference: known resident names are pseudonymized, NER-style heuristics redact person titles and addresses, and regex passes scrub phones, emails, MRNs, and similar identifiers. Residual high-risk tokens trigger an extra scrub pass.
Inference uses Google Cloud Vertex AI under your executed Business Associate Agreement. Customer spiritual care content is not used to train or improve Google foundation models. The application does not log prompt or response bodies for model calls and does not use context caching for clinical prompts.
Infrastructure
Application hosting and data storage use industry-standard cloud providers with encryption in transit (TLS) and at rest. Optional field-level encryption protects sensitive free text and identifiers when enabled for your organization. API keys for optional AI features are server-side secrets — never exposed in client bundles. Google Cloud Business Associate Agreement is executed for our production environment; customer organizations download and execute our BAA package from Admin → Company Settings.
Data retention
See our Privacy Policy for the retention schedule. In summary: clinical records follow the customer subscription and organizational policy; administrative audit logs are retained for at least 24 months by default; support tickets about 12 months; backups on a short rolling window.
Incident response
Report suspected security issues through your account manager or the contact form at /demo. We investigate validated reports promptly and coordinate with affected organizations per our incident response plan.
Your responsibilities
Enforce MFA for administrators (and all users when policy requires), revoke access promptly when staff depart, configure documentation and session security policy before go-live, train chaplains on anonymize mode and amendment workflows, complete our Business Associate Agreement package, and complete any additional cloud BAAs required for your regulatory posture.
Related: Privacy Policy · Terms of Service · Contact / demo