Security at AdmitScore™.

AdmitScore is built with administrative, technical and audit safeguards intended to help support the HIPAA obligations of the organizations we work with. This page describes how the software is built and is not a guarantee about any live environment or customer setup. The commitments that apply to your organization are set out in your agreement and BAA.

Contact us See the sample report

No PHI or patient records by email.

Security controls built into the software

Signing in and who can see what

  • Accounts are created by an administrator. There is no public self-sign-up.
  • Passwords must be at least 12 characters and include upper- and lower-case letters, a number and a symbol. They are stored only as salted bcrypt hashes (a one-way password hash).
  • New accounts are set up to require an authenticator-app code (multi-factor authentication, or MFA). Administrators enter a code at every sign-in. Staff may choose to trust a browser for up to 30 days.
  • The software is built to lock an account for 30 minutes after five failed sign-ins, and to rate-limit sign-in, password-reset and MFA requests to slow down password guessing.
  • Sessions end after 15 minutes of inactivity, and signing out revokes the session on the server. Deactivating a user or changing a password cuts off that user's existing sessions.
  • Every record belongs to an organization. Each request for patient-related data is checked against the user's role, organization and facility, and staff see only their own facility's cases.

Uploaded referral packets

  • Only PDF, Word (.docx), PNG, JPEG and plain-text files are accepted, up to 50 MB each, and PDF, image and Word files must match their declared type.
  • Every upload is streamed to ClamAV (an open-source malware scanner) before it is stored. If the scanner is unavailable or cannot finish, the upload is rejected, and hosted environments have no override.
  • Malware detections are recorded in the audit trail. A clean upload must also get a saved audit record, or the stored file is removed or queued for removal.
  • Files are stored under random names, and the original filename is not used in storage keys or logs.
  • The application deletes each uploaded packet after processing. A deletion that cannot be confirmed is recorded for follow-up cleanup, and the storage platform may keep a deleted file recoverable for a period set by its settings.

AI analysis

  • Referral text is sent for AI analysis only to Microsoft Azure OpenAI, and only to model deployments on a short approved list kept in our source code. Any other deployment name is refused before a request is made. Large or fax-quality PDFs can also go to a Microsoft Azure document text recognition service.
  • The public OpenAI service is not used for patient documents.
  • When it processes packets, the application signs in to Azure OpenAI with a managed identity (an identity Azure issues to the application itself) and uses no API key.
  • Uploaded documents are treated as untrusted input. The packet text sits in its own marked section of each request, the model is told to ignore instructions inside it, and the output is checked against a fixed format. These safeguards reduce the risk of hidden instructions (prompt injection) and cannot rule it out.
  • Packet text goes to the model as written, so it is not de-identified first. The model's output passes a PHI-redaction step before it is stored.

Encryption, keys and the audit trail

  • In production, the application redirects plain HTTP to HTTPS and tells browsers to use HTTPS only. Database connections use encryption in transit by default.
  • The application encrypts these stored fields with a separate key: the decision-evidence record, free-text decision reasons, feedback notes and authenticator secrets.
  • The production application refuses to start without its encryption and signing keys.
  • Access to patient-related records and administrative changes are recorded in an audit trail. The software is built to refuse to return patient-related data if it cannot first record the access.
  • Application logs are designed to exclude patient content, with record identifiers scrubbed. Monitoring data is built to pass through a PHI-scrubbing filter before it leaves the application.
  • Pilot reporting stores aggregate counts only. It rejects patient identifiers, packet text, quotes and filenames.

Web protections

  • Only our own web application is permitted to call the API from a browser. The production application refuses to start without its list of allowed websites.
  • The application sends standard browser security headers that block clickjacking (hiding a page inside another to trick a click) and content-type sniffing (a browser guessing at a file's type).
  • Requests are built to be rate-limited per user and per network address.
  • Error messages return a generic message and a request ID. They do not expose internal system details or stack traces.
  • Debug routes are never registered in production, and the detailed health endpoint is limited to administrators.

How we build and release

  • The release process is built to block a production release if automated scans find known vulnerabilities in our Python dependencies, or known high-severity vulnerabilities in our front-end dependencies, apart from a short list of reviewed exceptions recorded in the release configuration.
  • Pull requests that change dependencies run a blocking vulnerability scan. Every code change is built to be scanned for accidentally committed secrets and for patient-data field names, and tests use synthetic data only.
  • Production releases are built to require a named human approval tied to an exact code version.
  • The application runs as a non-administrative user in a container built from a base image pinned to an exact version, and the build's automation steps are pinned to exact commits.

Forms and examples on this website

Checks on public forms

  • Server-side validation rejects messages that contain obvious patient identifiers, such as labeled MRNs, dates of birth, SSNs, and Medicare or member IDs.
  • A honeypot (a hidden form field that only bots fill in) filters automated submissions.
  • These checks cannot catch everything, so never include patient details in a message.

What the site is for

  • The forms on this website are for business inquiry details only.
  • Examples on this website, including the sample report, use made-up data only.

Reporting a security issue

What we do not claim

  • AdmitScore is not "HIPAA certified" (no such certification exists). We do not hold SOC 2, HITRUST or ISO 27001 certification, and we do not cite a third-party penetration test.
  • AdmitScore is not a PHI-free or de-identified product. The admission record keeps clinical findings and short redacted evidence excerpts. Real patient data is processed only under an executed agreement and BAA.
  • We do not offer an uptime SLA unless one is written into your agreement.
  • Data residency, retention periods and breach-notification timelines are governed by your agreement and BAA.

AdmitScore supports staff review of referral packets. Staff verify extracted details against the source documents and make every admission decision, and AdmitScore does not guarantee payer approval or reimbursement.

Questions from your IT or compliance team: security@verisightanalytics.com.