What each NurseSuite tool records, where that record is kept, and who can reach it — written product by product, because the products genuinely differ.
Effective August 21, 2026Supersedes the July 16, 2026 versionNurseSuite LLC, a Maryland limited liability company
NurseSuite LLC (“NurseSuite,” “we,” “us”) builds readiness and workflow tools for nurses and nurse leaders. This policy explains what each tool records, where that record is stored, who can reach it, and how long it lives. It covers this website, the NurseSuite applications listed in section 3, and the services behind them (together, the “Service”).
We have written it product by product on purpose. A single blanket paragraph would be wrong about most of these tools: two of them never send anything off the device, one accepts photographs, and exactly one can be switched into a mode that handles clinical detail. Where a signed agreement or Business Associate Agreement (BAA) covers your organization, that agreement governs over this page to the extent they conflict.
These are readiness and workflow tools, not medical devices. They do not diagnose, treat, screen, stage, grade, or score a patient, and no measurement, stage, or risk score is ever computed from a photograph. They record what a clinician did and what a clinician assessed.
Your facility's own record is the system of record. NurseSuite sits beside it. It does not replace the medical record, the incident-reporting system, or your grievance, infection-reporting, or accreditation obligations.
This page is not legal advice to you. It describes our practices so that your privacy officer and your counsel can evaluate them. Route any BAA through your own counsel before signing.
1. Who we are, and what this policy covers
NurseSuite LLC is a Maryland limited liability company. We build the tools listed in section 3. Anything on this page can be raised with us at customer@nursesuite.com.
This policy covers the marketing site at nursesuite.com, the NurseSuite products described in section 3, and the servers behind them. It does not cover your own facility's systems, your electronic health record, or a third-party service you reach from ours.
The Audits Tool currently ships inside RN PocketPal, an iOS app published by a different company. This policy describes what that tool does with data. The app it is distributed in has its own publisher and its own privacy policy, and both apply.
There are two kinds of information here and they work differently. For business contact details and staff account details, we decide how the information is used, and this page is that decision written down. For the operational records your organization creates inside the Service — audits, rounds, findings, device records, turn logs — your organization decides what goes in; we handle it on your instructions and under whatever agreement we have signed with you. Where a signed agreement or a Business Associate Agreement conflicts with this page, that agreement governs.
2. The short version
We do not sell personal information, we do not share it for advertising, and we do not use your content to train any AI model.
No NurseSuite product contains an advertising, analytics or crash-reporting SDK, and none collects an advertising or device identifier. There are no third-party tracking scripts or cookies anywhere in the suite or on this site.
Most of the suite is built to run with no patient identifiers at all. Beds, rooms, units, device types, checklist items, timestamps and staff accounts are enough to do the work, so that is what the tools are designed around — several of them have no patient field in the database at all.
The Audits Tool keeps its records on your phone. It contains no networking code of any kind. (The app it ships inside sends an anonymous “this tool was opened” ping — see its entry in section 3.)
One tool has a clinical mode, and it stays off unless we switch it on for an organization with a signed Business Associate Agreement. See section 4.
One tool accepts photographs and free-text notes from the floor and does not screen them. If someone photographs a chart or types a patient's name into a note, that is what gets stored. We would rather say so than let you assume otherwise. Also section 4.
Some AI features send text to a provider operating in China by default. If that matters to your organization — and it may well — read section 6 before anyone uses them.
3. What each product records
Here is the whole suite at a glance, and then each product in detail. Every product heading below has its own permanent link, so an app listing or a security questionnaire can point straight at the relevant one.
Web application at surveyready.nursesuite.com with a mobile companion. Runs on an AWS Lightsail server in the US East region; its PostgreSQL database is on that same server and uploaded files sit in a Lightsail object-storage bucket.
What it stores
Your organization, facilities, departments and staff accounts; accreditation requirements and the evidence mapped to them; policies and their uploaded versions, including the extracted text of the document; audits, tracers and rounds with their responses; findings, corrective action plans, sentinel-event records, tasks, equipment records, competency records, and named staff members.
Free text
Extensive, and not filtered. Around forty fields across the product take free narrative — audit and tracer notes, finding descriptions, root-cause and corrective action text, sentinel-event summaries, photo captions, competency and equipment notes. Whatever is typed is stored as typed.
Photos and files
Yes. PDF, Word, PNG, JPEG and HEIC up to 25 MB, uploaded as evidence, as policy documents, or as photos attached to audit responses, tracer responses and findings — each with an optional free-text caption. Nothing inspects the contents of an uploaded image, and image metadata is not stripped.
Tracers
Tracer types include a patient tracer, which by design follows one patient's care through the organization. The tool records the observation and has no patient-identifier field — but it is the workflow where someone is most likely to type one anyway. See section 4.
Who can reach a file
Uploads are private and never publicly readable. They are served only through a signed link that expires after five minutes, issued after a permission check that scopes every read to your organization.
Access logging
Changes only. There is a trail of who created, edited, deleted, closed or reassigned something. There is no record of who merely viewed or downloaded a finding, a photo or an evidence file. We will not call this ePHI access auditing, because it is not.
Accounts and cookies
Email and password — hashed by the authentication library, never stored readable — or optional Google sign-in where your organization turns it on. Session records hold the IP address and browser user-agent. Two cookies, both functional: the sign-in session, and a year-long cookie holding the ID of the organization you are working in. No analytics or advertising cookie exists in the product.
Third parties
AWS (server, database, file storage); an AI provider for the optional AI features — read section 6, it matters; Resend for invitation, password-reset and digest email; Stripe for subscription billing; Google where OAuth sign-in is enabled. Card details never reach us.
One automatic patient-identifier check exists, and it is narrow. When the mobile app syncs, audit-response notes are scanned for text shaped like a Social Security number, a date of birth, a phone number, a long ID number, an “MRN/DOB/SSN” label, or a name with a title — and the whole batch is refused if any is found. That check does not run on notes typed in the web application, on tracer notes, on finding descriptions, on photo captions, or on any image. Treat it as a backstop on one path, not as protection.
Deleting a record does not yet delete the underlying file. Evidence, policy documents and photos remain in the storage bucket after the row referencing them is gone. This is a known gap; see section 8.
HapiHelper No PHI by default · BAA-gated tier
iOS and Android apps talking to a Cloudflare Worker, with the database and photo storage configured to Cloudflare's Eastern North America region. Pressure-injury prevention: per-bed turn intervals, rotation, and holds.
Standard tier — what it stores
Organization, facility, unit, room and bed records — a bed is a label such as “18A” plus a scannable token; turn events with position, reason code, timestamp and which staff member recorded them; skin-check flags; holds with a reason code; staff accounts and roles.
Standard tier — free text
Accepted by the app but not kept. The server writes the literal placeholder “[note]” in place of any note text, so free-text content does not persist server-side in this tier.
Clinical tier — what it adds
Only when enabled (see section 4): Braden subscales, nurse-recorded skin and wound findings with a body site and a nurse-chosen stage, free-text clinical notes, nurse-entered wound measurements in millimetres, and wound photographs.
Photos
Clinical tier only. JPEG, up to 8 MB and six per finding, taken through the app's own camera so that no copy lands in the phone's photo library. Location and other image metadata are stripped on the device and again on the server. Photos are encrypted individually — see section 9.
Measurements
Typed in by the nurse. Nothing is measured, staged, scored or inferred from a photograph. The photo-derived measurement path was removed on August 21, 2026 and the server now rejects it outright; there is no image-analysis model anywhere in either app.
Access logging
Yes, for the clinical tier. Every clinical read, write, export and permission change — including refused attempts — is written to a dedicated access log before any data is returned; if the log cannot be written, the request fails instead. IP addresses in that log are stored as a keyed hash, never in the clear.
Accounts
An emailed sign-in link or a six-character facility join code. There are no passwords. We store a display name, an optional email address (a join-code user can have none), last-login time, and — on session and sign-in-link records — the IP address and browser or device user-agent in the clear.
Third parties
Cloudflare for all storage and Resend to send the sign-in email. Nothing else: no analytics, no crash reporting, no advertising, no push service, no in-app purchases and no payment processing. Android uses Google's on-device barcode library to read bed labels; it runs locally and never sees a photo.
Two things in the standard tier are clinical observations, and we would rather name them than let “no PHI” imply otherwise. A bed carries a Braden risk tier (low, moderate, high, very high), and skin checks record whether skin was inspected, moisture managed, heels offloaded, and whether nutrition was flagged. Neither is attached to a patient identifier, and both are visible to any signed-in member of that facility without the clinical tier being switched on.
On Android the sign-in token currently sits in the app's private preferences rather than encrypted storage, and the app permits Android system backup. On iOS it is held in the Keychain. We are changing the Android side; until we have, it is stated here.
DeviceGuard No patient identifiers
iOS and Android apps talking to a Cloudflare Worker with a Cloudflare database. Central-line and urinary-catheter lifecycle: indication, device days, necessity review, maintenance and removal.
What it stores
Facilities, units, rooms and beds; a device record anchored to a bed — kind, status, indication, insertion and removal times, review and maintenance times; device events; exception dispositions; approved protocols with their citation and the named clinical leaders who approved them; staff accounts and roles.
Patient identifiers
None. There is no patient field in the schema at all — no name, no medical record number, no date of birth, no encounter. A device belongs to a bed, and that is the whole design.
Free text
Yes, in four places: the reason recorded on an exception disposition, the reason given when a device is removed, a note of up to 2,000 characters on any device event, and the note on a protocol approval. Unit, room and bed labels are free text too. None of it is filtered, so the guidance in section 4 applies here as well.
Photos
None. DeviceGuard has no photo capture, no image upload and no file storage of any kind. The camera is used only to decode a barcode; frames are never saved or transmitted.
Access logging
Changes and sign-ins. Device registrations, removals, dispositions, sign-ins and the scheduled sync are recorded with the staff member, their email, the action, the IP address and a timestamp. Reads are not logged. Device events themselves are an append-only lifecycle history.
Accounts
As HapiHelper: an emailed sign-in link, an invitation, or a facility join code. No passwords. Email, display name, IP address, user-agent and last-login time are stored; a join-code user can have no email at all.
Third parties
Cloudflare for storage and Resend for the sign-in email — those are the only two outbound connections the server makes. No analytics, crash reporting, advertising, push notifications or payments. Android uses Google's on-device barcode library.
Free-text reasons and notes never leave DeviceGuard. The query that feeds the Command Center cannot reach the removal reason, the disposition reason, the event note or the event metadata — the column list deliberately excludes them, and an automated test fails the build if that ever changes.
Neither mobile app is released. The server is live; the iOS and Android clients are not yet configured for release and are not in any app store.
NurseSuite Command Center Nine allowlisted fields
The leadership view that the other tools feed. It runs inside JC Survey Ready, on the same AWS server in the US East region.
What crosses the bridge
Exactly nine fields, and the list is enforced in code: the sending product, your organization identifier for that connection, a reference for de-duplicating repeat deliveries, a title, a description, a priority, a due date, a unit identifier, and a status. Nothing else is serialized.
Patient data
None, structurally. No field carries a patient identifier, and none carries a clinical value. In both sending products the title and description are assembled from fixed templates — HapiHelper composes a location such as “4 West – Bed 12A”, DeviceGuard sends a unit name and a count and deliberately never sends a bed or a device. The free text a nurse types stays in the product it was typed into.
What is user-typed
The unit and bed labels inside the title, because your staff named those units and beds. They are place labels, not people.
Verification
Both sending products run an automated check that fails their build if the payload gains a field outside the nine, or if the serialized body contains words such as patient, MRN, DOB, diagnosis, Braden, wound or stage.
Access logging
Changes only, as elsewhere in JC Survey Ready. Ingested work items are recorded with no user attached, because a machine sent them.
One honest limitation. The checks above run on the sending side. The receiving endpoint validates the shape and length of the nine fields but does not itself scan the title and description for patient information, and a single shared secret currently authenticates every sending tool for every customer. Per-connection credentials are the next piece of work, and until they exist we will not describe this bridge as tenant-isolated at the credential level.
Audits Tool Stays on the phone
An iOS tool, currently distributed inside the RN PocketPal app. Built-in and custom audit templates, scored item by item and exported as a PDF.
Where the data lives
On the device. The tool contains no networking code whatsoever — no HTTP, no sockets, no CloudKit, no sync. We hold no copy, and there is no server to hold one on.
What it stores
Audit runs with the template used, a unit name, a location, the auditor's initials, start and finish times and free-text summary notes; per-item responses with a compliance status, a free-text note, and a room and bed label; the room list; and any custom templates you write.
Patient identifiers
There is no field for one. But the note boxes are free text, so nothing stops someone typing a name into one. A local check warns when it spots text shaped like an MRN, an SSN, a date of birth, a phone number or a titled name — it warns, it does not block, and it runs entirely on the phone.
Photos
None. The tool has no camera or photo-library access.
How it is protected
Stored in the app's database with iOS Data Protection at its strongest setting, so the file is unreadable while the device is locked. It is not synced to iCloud and is excluded from device backup.
Exporting
You can share a completed audit as a PDF or as plain text through the iOS share sheet. The text export contains everything, including every free-text note. The privacy check runs first and warns you, but offers a “share anyway” option. Once you send it, where it goes is up to you.
Deleting
Delete an audit run in the app and it and its responses are removed.
One thing does leave the device, and it is not audit content. The app this tool ships inside records an anonymous “this tool was opened” event to its publisher's own endpoint, carrying a platform, app version, country and a random install identifier. No audit data, no notes, no room labels and no account are attached. That app has its own publisher and its own privacy policy, which also applies.
RoundRescue In development
A RoundRescue iOS application is in development. It is not available to customers or connected to production services.
Status
RoundRescue is in development and does not hold customer data. Its data-handling description will be published before customer access begins.
RoundRescue is designed to support a facility's service-recovery workflow; it is not a substitute for the facility's formal grievance process or record.
Organization and staff accounts; facilities, units, assets, tags, inventory events, and asset location labels. It is designed not to store patient identifiers.
Photos
None.
Access
Organization-scoped staff access and an audit history for inventory activity.
Nursing AI Assistant Sends text to an AI provider
Not a separate application — it is the set of AI features inside JC Survey Ready.
What it is
The compliance question-and-answer assistant, policy gap analysis, drafting help for corrective action plans and policy revisions, and plain-language search over your own analytics.
What leaves our servers
The text needed to answer the request, sent to a third-party large-language-model provider. Read section 6 before using these features — it names the default provider, says where that provider operates, and is specific about which paths redact and which do not.
Storage
The answers and any findings they produce are stored in your organization's Survey Ready account so you can review them.
This website (nursesuite.com) No cookies, no trackers
A static marketing site on the same AWS server in the US East region.
What it collects
Only what you type into the contact form: your name, work email, organization, role, the workflow you picked, and your message. It is written to a file on our server and, where email notification is configured, sent to us.
Cookies
None. The site sets no cookies and runs no analytics or tracking script.
Third parties
The typography is loaded from Google Fonts, which means your browser requests those font files from Google. That is the only third-party request the page makes.
Server logs
The web server keeps standard access logs — IP address, page requested, timestamp, browser user-agent — used to run and secure the site.
4. Patient information, the clinical tier, and BAAs
The design principle. Nearly all of this work can be done without knowing who the patient is. A turn belongs to a bed. A central line belongs to a bed. An audit item belongs to a unit and a moment. So the tools are built around beds, rooms, units, device types, checklist items, timestamps and staff accounts, and most of them have no column for a patient's name, medical record number or date of birth. There is nowhere to type one.
That principle has two real exceptions, and naming them is the point of this page.
Exception one — HapiHelper's clinical tier.
HapiHelper can be switched into a clinical mode that records Braden subscales, skin and wound findings with a body site and a nurse-chosen stage, free-text clinical notes, nurse-entered measurements, and wound photographs. It is off for every organization unless we turn it on, and turning it on requires both a flag set by us and a recorded Business Associate Agreement signature date that is not in the future. If either is missing, or ambiguous, the request is refused. Facility administrators and owners cannot enable it themselves. The apps refuse to send clinical data unless the server has confirmed the mode is on, and every clinical read, write, export and permission change — including refusals — is logged before any data is released.
Today, no organization has that mode enabled and no BAA is in force. The photo storage behind it is not yet covered by a Business Associate Agreement with the storage vendor, so by our own standing decision it holds test images only. We will not enable the clinical tier for a real facility until that agreement exists.
Exception two — what people type and photograph in JC Survey Ready.
Survey Ready has no patient-identifier field either. But it has around forty free-text boxes and it accepts photographs with captions, and it does not inspect them. Photograph a med cart with a name band in frame and that photograph is stored. Type a patient's name into a finding description and that is stored too. One narrow automatic check runs on one path — audit notes syncing from the mobile app — and refuses the batch if it spots something shaped like an SSN, a date of birth, a phone number, a long ID number, an MRN/DOB/SSN label, or a name with a title. Web notes, tracer notes, finding descriptions, captions, and every image pass straight through.
Survey Ready also offers a patient tracer, a workflow that by its nature follows one patient's care through the organization. The tool records the observation rather than the person — but it is exactly the workflow in which someone is most likely to type an identifier anyway.
The same caution, in a smaller way, applies to DeviceGuard's four free-text fields and to the notes in the two on-device tools. Those tools warn when they see text that looks like an identifier, but the warning can be dismissed and the record saved. No product in this suite prevents a determined person from typing a patient's name into a note.
So, plainly: please do not put patient identifiers into the Service, and tell your staff the same. Photograph the process, the equipment, the environment and the documentation gap — not the patient, the wristband, the chart or the whiteboard.
Survey Ready's storage is not currently covered by a Business Associate Agreement. If your organization needs one in place before it uses these features, write to customer@nursesuite.com and we will work through it with you — and have your own counsel review any BAA before you sign it.
The Command Center is no-PHI by construction, in both directions and regardless of what tier a sending product is in.
5. What we do with it
We use the information described above to run the Service, and for nothing else. Concretely:
Running the product — signing you in, showing your unit its work, recording what was done, producing the exports and PDFs you ask for.
Keeping it secure and working — server logs, error diagnosis, and the access logs described in section 9.
Answering you — support, demo requests, and security questionnaires.
Meeting legal obligations, and enforcing our Terms of Use.
We do not sell personal information, share it for advertising, build profiles, use it to train any AI model, or mine the operational records inside one customer's account to build something for anyone else. If we ever want to use customer data for anything beyond running the Service, we will ask that customer first.
6. AI features, and where that text goes
Some features in JC Survey Ready use a third-party large-language-model service. These are the features described on our site as the Nursing AI Assistant: the compliance question-and-answer assistant, policy gap analysis, drafting help for corrective action plans and policy revisions, and plain-language search over your own analytics. They are optional, they do nothing unless an AI key is configured, and the rest of the product works without them.
When you use one, text is sent to that provider's API and the answer comes back. Depending on the feature, that text can include your question, requirement and standard references, the titles of open findings, finding descriptions, and — for policy gap analysis — the full extracted text of the policy document you uploaded.
The default AI provider is DeepSeek, which operates in China. The product also supports Zhipu / Z.ai (China) and OpenAI (United States), and the provider is configurable per deployment. Ask us at customer@nursesuite.com which provider your organization's instance points at, and tell us if you need it changed. For many healthcare customers this will matter, and we would rather you learned it here than from a security review.
Redaction on these paths is partial. The drafting features and the public gap scan strip text matching two narrow patterns — an MRN-style label and a Social-Security-shaped number — before sending. The policy analyzer and the assistant apply no redaction at all. Do not paste patient information into an AI feature.
AI answers and any findings they generate are stored in your organization's account so you can review them. We do not use your content to train any model, and we do not send it to a provider for any purpose other than answering the request you made. AI output is drafting help and decision support — it can be wrong, it is never clinical advice, and a qualified person has to check it before it is relied on.
Where the public gap-scan tool on our website is enabled, it accepts pasted policy text from anonymous visitors and sends up to 16,000 characters of it to the same provider. That text is not stored. Do not paste anything confidential into it.
7. Who else touches the data
We do not sell personal information and we do not share it for advertising. We share it with the service providers below, which process it on our behalf under contract, and with anyone the law requires. That is the whole list, current as of the effective date; we update this page when it changes.
Provider
What it does
Which products
Where
Amazon Web Services
Server, PostgreSQL database and object storage for uploaded files
JC Survey Ready, Command Center, this website
United States (US East)
Cloudflare
Application servers, database, and encrypted object storage for wound photos
HapiHelper, DeviceGuard
United States / global edge
DeepSeek (default), Zhipu / Z.ai, OpenAI
The language model behind the optional AI features — see section 6
JC Survey Ready
China (DeepSeek, Zhipu) · United States (OpenAI)
Resend
Sends sign-in links, invitations, password resets and digest email
JC Survey Ready, HapiHelper, DeviceGuard
United States
Stripe
Subscription billing. Card details go straight to Stripe and never reach us — we keep only its customer and subscription identifiers
JC Survey Ready
United States
Google
Optional “sign in with Google” where an organization enables it; and the web fonts on this marketing site
JC Survey Ready · this website
United States
Let's Encrypt
TLS certificates for our domains
All web services
United States
Not on this list, deliberately: no analytics provider, no advertising network, no crash-reporting service, no session-replay tool, no customer data platform, and no third-party tracking script or cookie anywhere in any NurseSuite product or on this website.
One first-party exception to name. The Audits Tool ships inside RN PocketPal, and that app records an anonymous “this tool was opened” event to its own publisher's endpoint. It carries a platform, an app version, a country and a random install identifier — no audit content, no rounding content, no room labels and no account. It is that publisher's collection, described in that app's own privacy policy, and we mention it here so the “stays on the phone” claim above is not read more broadly than it should be.
We may also disclose information where the law requires it, to enforce our Terms of Use, or to protect the safety and security of the Service and its users. If a government or a third party demands customer data, we will tell the affected customer unless we are legally forbidden from doing so.
8. How long we keep things — and what deletion really does
We keep operational records for as long as your organization has an account, because readiness work is longitudinal: the point of last year's audit is comparing it with this year's. Where a signed agreement sets a different retention or return-and-destroy term, that agreement wins.
The rest of this section is deliberately specific, because retention is where privacy policies most often promise what the software does not do.
What
What actually happens today
Website enquiries
Name, email, organization, role and message from the contact form, kept until the enquiry is resolved and no longer than 24 months, and deleted sooner on request.
HapiHelper wound photos
The one genuinely automatic purge in the suite. A retention window set per organization — minimum 30 days, maximum 365, 90 by default — starts when the finding is resolved, not when the photo was taken. A job runs every five minutes; it deletes the encrypted object from storage first, then marks the record purged. Photos on an open finding are never auto-deleted, and a legal hold suspends the whole process.
HapiHelper clinical records and turn history
Deleting a finding or a photo record marks it deleted; the record itself is retained. There is no automatic purge of clinical records or turn history yet.
JC Survey Ready records
Retained for the life of the account. There is no scheduled deletion job.
JC Survey Ready uploaded files
Deleting the record does not yet delete the file. Evidence, policy documents and photos stay in the storage bucket after the row referencing them is gone. This is a known gap we are closing; until then, assume an uploaded file persists.
DeviceGuard records
Retained. Device records, events, dispositions and logs are never purged, and there is no user-facing deletion. Expired sign-in links are the one thing that is automatically removed.
Audits Tool (on your phone)
You can delete an audit run in the app and its responses go with it. Nothing expires automatically. Deleting the app removes everything.
Access and audit logs
Retained without a set expiry. HapiHelper's clinical access log in particular grows without a retention limit today.
Sign-in records
Session records, including IP address and browser user-agent, are retained. HapiHelper's and DeviceGuard's sign-in links are hard-deleted within minutes of being used or expiring; Survey Ready invitations expire after seven days.
Account deletion
There is no self-service account deletion in the products today. A member can be deactivated, which ends their access. To have an account or an organization's data removed, write to customer@nursesuite.com and we will do it manually.
Backups
We keep no backups of our own beyond what the hosting platforms retain as part of their managed database and storage services.
We would rather publish that list than write “we retain data only as long as necessary” and leave you to fill in the rest. Several of those gaps are already on the fix list; if one of them blocks a review, tell us and we will tell you where it stands.
9. Security — what is actually in place
Security differs between products, so this section is written per product rather than as one paragraph of reassurance. It lists what is implemented, and leaves out the things that sound good but are not true of our code.
Everywhere
All traffic runs over TLS.
Every read and write is scoped to your organization in the data layer, not merely in the interface.
Uploaded files are private, never publicly readable, and reachable only through short-lived signed links issued after a permission check.
Where passwords exist at all, they are hashed by the authentication library and never stored readable. HapiHelper and DeviceGuard have no passwords — they sign in by emailed link or facility join code, the link is stored only as a hash, and it is single-use and short-lived.
HapiHelper
Wound photographs are encrypted with AES-256-GCM under a unique key for each photo, and that key is itself encrypted with a versioned master key held as a platform secret. The encrypted image and the encrypted key are stored separately, and the plaintext key is wiped from memory after use. Master keys are versioned so they can be rotated without touching the stored images.
Photos are never public and are never handed out as a direct storage link. Every byte passes back through our server, so the permission gate and the access log cannot be bypassed.
Image metadata, including any location tag, is stripped on the device and again on the server.
The clinical access log records reads, writes, exports and refusals, stores IP addresses only as a keyed hash, and is written before data is released — if the log write fails, the request fails.
Sign-in tokens are held in the iOS Keychain. On Android they are currently in the app's private preferences rather than encrypted storage, and the app permits Android system backup. We are changing that, and we are not going to claim otherwise in the meantime.
DeviceGuard
No photos, no file uploads and no object storage — there is simply less to protect.
Free-text reasons and notes are structurally excluded from the Command Center bridge, and an automated test fails the build if that changes.
Sign-in tokens are in the iOS Keychain, and on Android in encrypted preferences — with a silent fallback to ordinary private preferences if encrypted storage cannot be initialised on that device. Android system backup is disabled.
JC Survey Ready
Sessions are stored server-side and validated on every request; cookies are HTTP-only.
Object keys are namespaced per organization, and signed download links expire after five minutes.
The audit trail covers changes. It does not cover views or downloads — there is no read logging, and we will not describe what exists as ePHI access auditing.
Encryption at rest is whatever the hosting platform provides by default. The application sets no server-side-encryption or key-management configuration of its own on the storage bucket, and the database runs on the server's own disk. We are not going to claim application-managed encryption at rest that the code does not configure.
The two on-device tools
Records are held in the app's database with iOS Data Protection at its strongest setting, so the file is unreadable while the device is locked. This is the operating system's encryption, not an additional application-managed key.
Nothing syncs to iCloud, and the database is excluded from device backup. Note that a PDF or text file you export and save is backed up wherever you put it, and small app preferences — including the last rounder's initials — are ordinary app settings and are included in device backup.
The Command Center bridge
The receiving endpoint requires a bearer secret, compares it in constant time, and refuses everything if the secret is unset. Repeat deliveries are idempotent, and a sending product must be explicitly connected and unit-mapped before anything is written.
One shared secret currently covers every sending tool and every customer organization, and the endpoint is not rate-limited. Per-connection credentials are the next hardening step; until they exist we will not describe this bridge as tenant-isolated at the credential level.
No system is perfectly secure. We hold no security certification — we are not SOC 2 or HITRUST certified and we do not claim to be. If you are running a security review, write to customer@nursesuite.com; we would rather answer your questionnaire honestly than have you infer the answers from marketing copy.
10. Your rights, and how to use them
Depending on where you live, you may have the right to ask what personal information we hold about you, to have it corrected or deleted, to receive a copy, and to object to certain uses. We do not sell personal information and we do not process it for targeted advertising, so there is nothing to opt out of on that front.
Write to customer@nursesuite.com. We will confirm who you are before acting, and respond within the time the applicable law allows. There is no charge, and we will not treat you differently for asking.
Two honest limits. First, if what you are asking about is an operational record inside your employer's NurseSuite account, we will route the request to your employer rather than act on it ourselves — the record is theirs. Second, see section 8: several products have no self-service deletion yet, so some requests we carry out by hand rather than by pressing a button that does not exist.
11. Children's data
Not applicable. The Service is for licensed clinicians, healthcare staff, and the people who manage them, at work. It is not directed to children, we do not knowingly collect personal information from children, and nothing in any product is aimed at a child user. If you believe a child has created an account, write to customer@nursesuite.com and we will remove it.
That is about the people who use the software. Whether a patient on the unit is a minor is a different question, and the answer is section 4: the tools are built not to carry patient identifiers of any age.
12. Where your data is processed
JC Survey Ready, the Command Center and this website run on a server in Amazon's US East region, in the United States. HapiHelper and DeviceGuard run on Cloudflare, whose application servers operate from a global network of locations; HapiHelper's database and photo storage are configured to Cloudflare's Eastern North America region. We have not pinned a region for DeviceGuard's database and so we will not claim one.
The one deliberate exception is section 6: if your instance uses the default AI provider, text you send to an AI feature is processed in China. Providers operating in the United States are also supported, and we will tell you which one your instance uses.
If you use the Service from outside the United States, your information will be processed in the United States. We do not currently offer regional data residency.
13. Changes to this policy
This version takes effect on August 21, 2026 and replaces the version dated July 16, 2026, which predated most of the products described here and named none of them.
When a product's behaviour changes, this page changes with it. We update the effective date at the top, and for a change that materially affects how information is handled we also notify account administrators directly. The section and product links on this page are stable, so an app listing or a security questionnaire can point at the part it cares about and keep working.
14. Contact
customer@nursesuite.com — privacy questions, data requests, security reviews, questionnaires and BAA discussions all reach us there.
NurseSuite LLC, a Maryland limited liability company. Mailing address on request. See also our Terms of Use.
Nothing on this page is legal advice to you. It is a factual description of how our software behaves, written so that your privacy officer and your counsel can assess it. Have your own counsel review any Business Associate Agreement before you sign it.
Questions, requests, or a security review: customer@nursesuite.com. NurseSuite LLC, a Maryland limited liability company; mailing address on request.