The HVC verification platform — product, process, and procedures.

HVC — Hospital Verified Competency — is a national, real-time registry that answers a single hospital question: is the person walking into my procedural environment currently a properly certified, currently authorised representative of the company on their badge? The answer is delivered in seconds, on the open internet, with no login, against an independent ISO/IEC 17024 personnel-certification scheme operated by HWASC.

Why HVC exists

There are three independent kinds of competency in healthcare procedural environments. Today, only two are systematically verified. HVC fills the gap in the third.

What HVC verifies on the public surface

A single REP Number™ lookup returns:

• Status — Active / Suspended / Inactive / Revoked of the individual.
• Sponsor — Company Number™, legal name, and its current status.
• Cascade flag — when the sponsor is not Active, the rep's record is amber-flagged in real time, regardless of the rep's own status.
• Personnel category — sales rep, clinical specialist, service engineer, distributor rep.
• Competency tiers — twelve domain × four tier matrix from the HWASC exam.
• Currency window — effective-from and effective-through dates.
• Provenance — issuer (HWASC), scheme (ISO/IEC 17024), last-updated timestamp.

What HVC never exposes publicly: date of birth, contact information, address, item-level exam scores, narrative reason text.

Audiences and primary jobs

Trust anchors

Three structural properties make this a credible registry rather than another vendor card scheme.

These map directly to the seven non-negotiable principles documented in the HVC Constitution.

HVC is a public verification site backed by a small registry of five core entities. The application surface is a single Next.js deployment serving server-rendered pages, JSON API routes, and a protected admin console.

Core entities

Application surfaces

Data flow on a public verification query

Privacy posture by field

The HVC scheme has four core operational workflows. v1 ships #4 (verification queries) fully and provides scheme-operator tooling for #1, #2, and #3 ahead of the Phase 2 portals.

1. Candidate testing and certification

2. Company certification

3. Monthly linkage refresh — the heart of cascade integrity

4. Verification query with the Cascade Principle

This is the workflow a hospital exercises every day. The Cascade Principle is enforced at read time as a JOIN — there is no fan-out write.

How a status change propagates

Operational procedures for each audience, written as the steps a person actually takes.

Hospital verification before OR access

A scheduler, vendor desk, or surveyor verifies a rep at the moment of facility access.

Survey defence. Copy the canonical URL (/verify/<repId>) into your vendor credentialing ticket. The page is stable, deep-linkable, and renders without JavaScript, so it survives Joint Commission HR.01.07.01 EP 5 evidence review.

Reporting a discrepancy

If a record looks wrong, the public discrepancy form opens a ticket for scheme operations. The form refuses any submission containing obvious protected-health-information patterns.

Scheme-operator sign-in (Azure AD)

Operators authenticate against the organisation's Microsoft Entra (Azure AD) tenant. Identity flows server-side via authorization-code + PKCE; the local session is an HMAC-signed cookie with an 8-hour TTL. Production enforces single-tenant authority and a non-empty operator allow-list — the app refuses to boot otherwise.

Scheme-operator: status change with Cascade propagation

Every state change writes an audit row attributable to the signed-in operator (<displayName> <oid:OID>). Cascade propagation happens automatically at read time — there is no batch step.

Phase-2 portal flow — rep registers, company authorises, hospital verifies

IFU uploads (Azure Blob)

The IFU repository stores manufacturer Instructions-for-Use PDFs in a private Azure Blob container. Uploads are versioned at the application layer; viewing requires a short-lived signed URL; every operation writes an audit row.

Append-only audit — by construction

A unit test asserts the module surface. An attempt to mutate or delete an audit entry through any path is itself audit-logged and returns 500.

Four JSON endpoints back the public surface. They are intentionally narrow.

| Method | Path | Purpose | | --- | --- | --- | | GET | /api/v1/public/verify/{repId} | Single-record verification | | GET | /api/v1/public/status | System status snapshot | | GET | /api/v1/public/methodology | Twelve domains, four tiers | | POST | /api/v1/public/report-discrepancy | Open a discrepancy ticket | | POST | /api/v1/public/chat | Ask the FAQ assistant | | GET | /api/v1/public/pdf/{repId} | Server-rendered verification PDF |

Sample 200 response

{
  "repId": "TEST-ACTV-01",
  "identity": { "displayName": "Jane D.", "fullName": null },
  "status": "Active",
  "effectiveFrom": "2025-05-19",
  "effectiveThrough": "2029-05-18",
  "personnelCategory": "Clinical Specialist",
  "domains": [
    { "code": "PATIENT_SAFETY", "name": "Patient Safety", "tier": "Foundational" }
  ],
  "sponsor": {
    "companyNumber": "ACME-MEDC",
    "name": "Acme Medical",
    "status": "Active"
  },
  "sponsorFlagged": false,
  "provenance": {
    "issuer": "HWASC",
    "scheme": "ISO/IEC 17024",
    "lastUpdated": "2026-05-19T20:00:00.000Z"
  }
}

Response semantics

Cache and freshness

Enumeration defence

A defining behaviour of the API: all error responses are constant-time relative to a successful response, and 404 pages are noindex. The verify handler measures elapsed time and pads with constantTimePad(start, 150ms) before responding. Combined with per-IP rate limiting and a CAPTCHA challenge above the threshold, this denies the registry-wide enumeration threat enumerated in the threat model.

Authenticated API (Phase 2)

Phase 2 introduces /api/v1/authenticated/* endpoints for hospital and VCO integrators under a usage agreement: single-record full field set, bulk verification, webhook subscriptions for status changes on a watched set, monthly linkage roster push for companies, and a signature-verified inbound feed from the testing provider.

Two state machines govern the registry. They are independent — but linked at read time by the Cascade Principle.

Individual (REP Number™) status

Company (Company Number™) status

Cascade Principle illustration

The Individual's own status does not change when the Company changes. The query response carries a sponsorFlagged boolean computed at read time.

Linkage state

A linkage is closed, never deleted, when a rep moves between companies. The historical record stands as scheme audit evidence.

Monthly linkage refresh badge

The Company's refresh cadence becomes a visible compliance flag for any scheme-aware view.

• HVC — Hospital Verified Competency. The platform and the name of the verification surface.
• HWASC — the organisation that operates the certification scheme behind HVC. Accredited as the issuing body for the REP Number™ and the Company Number™.
• REP Number™ — a portable, scheme-issued identifier for a certified non-hospital procedural worker. Format XXXX-XXXX-XX, 10 characters from Crockford Base32 (no I, L, O, U).
• Company Number™ — the corresponding identifier for a certified sponsoring organisation. Format YYYY-YYYY, 8 characters from the same alphabet.
• ISO/IEC 17024 — the personnel-certification standard the REP Number™ scheme is operated under.
• ISO/IEC 17065 — the product/process certification standard the Company Number™ scheme is operated under.
• Cascade Principle — Company Number™ status changes (Suspension/Withdrawal/Revocation) propagate to flag every linked REP Number™ in every public query response, in real time, without changing the individual's own status.
• Linkage — the relationship that an Individual is currently authorised to represent a Company. Composite key of REP Number™, Company Number™, and effective-from. Closed by setting effectiveThrough; never deleted.
• Monthly linkage refresh — the obligation that each Active Company updates its authoritative roster every calendar month. Indicators: current (≤30d), late (30–60d), lapsed (>60d).
• JTA — Job Task Analysis. The empirical foundation of an ISO/IEC 17024 scheme; re-validated at least every five years.
• Twelve competency domains — Patient Safety, Infection Prevention, Procedural Conduct, Sterile Environment Protocols, Surgical Workflow, Data and Documentation, Ethical Conduct, Regulatory Awareness, Operational Accountability, Emergency Response, Communication and Escalation, Technology and AI Governance.
• Four proficiency tiers — Foundational, Proficient, Advanced, Specialist. A given personnel category certifies at one tier per domain.
• VCO — Vendor Credentialing Organisation. Owns Access Competency under ANSI/NEMA SC 1-2020.
• SC 1-2020 — ANSI/NEMA standard for administrative credentialing of supplier reps entering healthcare facilities. Covers Access Competency, not Hospital Competency.
• Three-layer competency model — Product (manufacturer/employer), Hospital (HVC, the layer this platform addresses), Access (VCO).
• Crockford Base32 — the human-friendly alphabet HVC uses for identifiers. Digits 0–9 and letters A–Z excluding I, L, O, U.
• Cascade flag (sponsorFlagged) — a boolean on the public verification response, set when the sponsoring Company's status is anything other than Active.
• Constant-time 404 — the verification endpoint pads response time so a 404 cannot be timing-distinguished from a 200 by an enumeration attacker.
• Append-only audit log — every state change writes one row to audit_logs. No update, no delete. The application data layer exposes a frozen collection helper with only find and insertOne.