Menu

VC use case

Verify practitioner credentials

This use case allows a visiting practitioner to verify their credentials at a hospital.

  • Health
Issuer authoritative source creates the claim
Holder person or organization presents proof
Verifier service checks status and makes a decision

Overview

Hospitals and clinics can verify a visiting practitioner’s credentials instantly using verifiable, issuer-signed claims.

The hospital does not need to manually chase every regulator or training body before a practitioner can provide care. It needs to know whether the presented licenses, registrations, and certifications are trusted and current.

Why it matters

Credential verification is critical to patient safety but often slow and manual. In time-critical or remote settings, delays can affect access to care, while weak checks create clinical, legal, and reputational risk.

Verifiable Credentials create a cleaner model:

  • regulators and training bodies issue trusted practitioner credentials
  • practitioners carry evidence in a wallet
  • hospitals verify status and scope of practice at onboarding or arrival
  • access decisions can be audited without re-collecting source documents

Ecosystem roles

  • Issuer: Regulatory bodies and training organizations issuing certifications.
  • Holder: The practitioner storing credentials in a wallet.
  • Verifier: The hospital or clinic validating credentials on arrival.
  • Trust governance: The rules that define accepted regulators, credential types, scope of practice, status checks, and exception handling.

Trust decision

The verifier decision is narrow: can this practitioner provide this type of care at this facility right now?

That decision may depend on registration, certification, specialty, scope of practice, facility policy, expiry, and status.

Privacy and assurance

The verifier should request only credentials needed for the clinical role and facility access decision. It should not need unrelated employment or personal history.

Assurance depends on checking issuer trust, status, expiry, scope of practice, and binding between the practitioner and credentials.

Implementation notes

  • Separate license, specialty, training, and facility-access claims where different issuers control them.
  • Define emergency and temporary access processes without bypassing auditability.
  • Keep verification results available to clinical governance and access control systems.
  • Include fallback handling for unsupported issuers, expired credentials, and manual clinical governance review.
Objective
Enable a hospital to verify the credentials of a visiting practitioner.
Description
A visiting practitioner presents license and certification credentials so the hospital can confirm scope and eligibility.
Actors
Visiting medical practitioner; regulator; training body; hospital or clinic verifier.
Dependencies
The practitioner holds relevant certifications in their wallet, and the hospital can check issuer trust and credential status.
Preconditions
The visiting practitioner is expected to provide health care services at the hospital.
Postconditions
The hospital permits, denies, or escalates the practitioner's access based on verified credentials and policy.
The regulator issues a license credential and the training body issues a certification credential to a wallet. The wallet presents the credentials to the hospital or verifier, which checks their status with the credential registry.
The regulator and training body issue license and certification credentials to the wallet. The practitioner stores them and presents the license and certification to the hospital or verifier. The verifier checks the credential registry, which confirms validity, and grants access to the practitioner.

Talk to UNIFY

Explore how this use case could work in your trust ecosystem.

Share the scenario you are testing and we will help map the issuers, holders, verifiers, and policy decisions involved.
Looks good!
Please enter your name.
Looks good!
Please enter your company.
Looks good!
Please enter your e-mail address so we can contact you.
This form uses Google ReCaptcha to ensure interactions with our site are from legitimate users. Please accept the use of recommended storage before submitting the form. Find out more at the Privacy Centre.
Your message could not be sent. Try again later.