Systems · Clinical credentialing
Credentialing automation forhospitals and traveling clinicians
We built and operate a credentialing platform that reads a clinician’s uploaded documents, checks them against ten verification sources, keeps watching them after the file is closed, and fills the state credentialing application for signature. This page is what that actually involves — including the parts that do not fit on a pricing table.
10
Verification sources checked
358
Fields on the first state application mapped
24/7
Enrolled licenses under continuous monitoring
A credentialing file is a moving target
Credentialing is written down as a checklist: collect the license, collect the board certification, collect the immunization record, check the exclusion lists, file it. The collecting is not the hard part. The hard part is that every item on that list is a fact with an expiry date attached, and the checklist tells you nothing about the day after you ran it.
A license verified on Monday can be suspended on Wednesday. A clinician working three states carries three renewal cycles that do not line up. A staffing agency’s roster turns over faster than a re-verification calendar built around a two-year appointment cycle. Point-in-time verification is accurate at exactly one moment, and every process built on it quietly assumes nothing has changed since.
The second problem is upstream of all of that: the documents arrive as whatever the clinician had on their phone. A photo of a wallet card at an angle. A six-page scan where page four is the immunization record. A HEIC file. An ACLS card uploaded into the BLS slot because the two look alike at a glance. Before anything can be verified, something has to reliably work out what it is actually looking at.
What gets read, and what a person still decides
The clinician uploads into a wallet. The system parses state licenses, board certifications, life-support cards (BLS, ACLS, PALS, ATLS), immunization records and titer results, government photo ID, drug screens, malpractice and insurance certificates, and the CV. What comes back is structured: document type, issuing body, identifier, and the dates.
Dates are where document parsers quietly do damage, so the rules are fixed and applied once, at write time — never reinterpreted by whatever is displaying them later:
- Exact date
- Stored as the exact day. No normalisation.
- MM/YYYY expiry
- The last day of that month. A card marked 03/2027 is good through 31 March.
- MM/YYYY issued
- The first day of that month — the opposite rounding, because the opposite error is the dangerous one.
- Year only
- No date at all. A guessed 1 January is a fact the document does not contain.
Upload also runs a content-versus-type check. If the document’s own content says ACLS and it was filed as BLS, it is refused at upload rather than counted as a credential the clinician does not hold. Misfiling is the most common way a file passes review while being wrong.
Ten verification sources, and what to do when they disagree
Ten sources are checked across a complete file. Four of them are national and answer for almost everyone: the NPI registry for identity and taxonomy, the OIG LEIE exclusion list, SAM.gov for federal exclusion and debarment, and NURSYS for nurses. The rest are the state and board-level checks that apply to a particular license in a particular jurisdiction, including the state boards that publish their license rosters as open data.
The requirements are not uniform, and treating them as uniform is its own failure mode. An NPI and a board certification are genuinely required for a CRNA, nurse practitioner, nurse midwife, physician assistant or physician — and are not required for a clinical nurse specialist. A checklist that demands all of it from everyone generates false blockers, and a credentialing team that learns to wave those through has learned to wave things through.
Sources disagree constantly, and most disagreements are boring: a married name against a maiden name, a middle initial present in one registry and absent in another, a license number that is valid but belongs to a different license type. Two rules keep that from becoming either a false clear or a false accusation:
- Grade what was claimed
- A source result is applied only to the specific license it was queried for. A hit on some other license held by the same person is not evidence about this one.
- Never auto-clear on fuzz
- A near-match on a name is a prompt for a human, in both directions — it neither clears a credential nor flags an exclusion on its own.
What NURSYS e-Notify actually costs you, operationally
NURSYS is the national nurse licensure database, run by NCSBN, and it is the reason nurse verification can be primary-source at all. It is also the integration that most changes what you can honestly promise a hospital, so it is worth being precise about how it behaves.
- Asynchronous
- The e-Notify API takes a request and returns a handle. You come back for the result. In practice that is roughly a five-minute wait, not a page-load.
- Rate ceiling
- Past about 25 requests a minute the account is refused and locked out for thirty minutes. A design that fans out one request per clinician on a roster refresh will lock the account for everybody.
- Credential rotation
- The API password expires on a 90-day cycle and the reset needs the previous one. Somebody has to own that date, and a health probe has to notice when it slips.
- No QuickConfirm API
- NCSBN has confirmed there is no API behind QuickConfirm. The public QuickConfirm website does offer a name search, but its terms of use and its CAPTCHA put it out of bounds for automation — so that path is a person with a browser, not an integration.
The upside of the asynchronous model is the part worth buying. Enrollment is not a query — it is a subscription. Once a nurse is enrolled, license status changes, disciplinary actions and expirations arrive without anybody re-running anything. That is the difference between a credentialing file and a credentialing system.
What the clinician actually has to type is small, and that matters for completion rates: the license is already in the wallet, so the request needs only the last four digits of their Social Security number and a birth year. The address block is derived rather than asked for — and it is set to the licensing jurisdiction, not the clinician’s home state, because a mismatch there is its own rejection (error 28) and looks, from the clinician’s side, exactly like a failed verification.
Why license-type inference breaks on APRNs
A NURSYS request has to declare a license type. The obvious implementation infers it from the text on the license itself, and that works fine right up until an advanced practice nurse arrives.
“Registered Nurse” infers cleanly. “APRN”, “CRNA”, “Certified Registered Nurse Anesthetist”, “Certified Nurse Midwife” and “Nurse Practitioner” do not — they are advanced practice titles sitting on top of a nursing license, and the naive inference falls back to RN. Send RN for an APRN and NCSBN rejects the request outright on a license-type mismatch — error 32. Inside the building that does not read as “we sent the wrong type”. It reads as “verification is broken”, and it reads that way only for your nurse anesthetists, which is to say for the most expensive clinicians on the roster.
The fix is unglamorous: inference returns nothing rather than guessing, and the provider type the clinician actually recorded decides. A null is more useful than a confident wrong answer, because a null can be asked about. This is the class of defect that never appears in a demo — it needs a real APRN, a real board, and a real rejection code to surface at all, which is exactly why it is still sitting in most implementations.
Filling a 358-field state credentialing application
Verification produces facts. The state still wants them on its own form, in its own order, and a credentialing application is long: the first state application mapped this way — Oregon’s — carries 358 fields.
An administrator uploads the blank PDF once. The system reads the form’s field structure and proposes a mapping from each form field to a profile field; a person curates that mapping before it is used, and it is stored as the form’s map. From then on, any clinician’s application is assembled from the profile they have already built. Nothing already in the wallet is retyped.
- Sensitive values
- Social Security number, date of birth and the like are supplied by the clinician at fill time, written into the PDF, and never stored. The assemble and load steps do not emit those keys at all — a database dump does not contain them.
- Signature
- Drawn or typed by the clinician and applied to the form itself, at the resolution the device actually has.
- Appearances
- Field values are written with per-field appearance streams and NeedAppearances set. Skip that and the form is correctly filled and visibly blank in macOS Preview — which is how a hospital will open it.
- What no registry knows
- Medicare PTAN and a state Medicaid ID are captured from the provider, because there is no lookup that returns them. Any tool that claims to source them is guessing.
The same mechanic — read a blank government form, map it once, fill it per person, then re-read the returned PDF to catch what would get it rejected — is what runs behind our security packet automation, where it covers 219 fields across five federal forms.
After the file closes: monitoring and expiration
Expiration is computed when a date is written, not when a page is rendered, so a past-dated credential reads as expired everywhere it appears — the clinician’s wallet, the hospital’s roster, the packet, the search filters. There is no view that shows a friendlier version of the same credential.
A weekly job re-checks what is expiring and re-runs what can be re-run. It preserves existing verdicts, which sounds like a detail and is not: a re-check that resets everything to “pending” each week erases every judgment a board or a reviewer has ever made, silently, on a schedule.
What the hospital sees:
- Expiring soon
- The roster surfaces what is lapsing before it lapses, per clinician and per credential.
- Monitoring alerts
- For enrolled nurses, a status or disciplinary change from the national database appears against that clinician.
- Private review marks
- Each facility can mark a profile and each credential “reviewed”. That mark is private to that facility — invisible to the clinician and to every other hospital — and it never alters the credential’s own status.
- Staleness
- A review mark goes stale only when the clinician actually edits the underlying content, not every time a row is touched.
What this is not
It does not issue verdicts that a board or a reviewer has to issue. Where neither a licensing source nor a named human has spoken, a credential shows as pending, on purpose, including to the hospital looking at it. A green check the software invented is worse than no check, because it is the one nobody re-examines.
It does not replace a medical staff office or a credentialing committee. It removes the transcription, the chasing and the calendar, and it hands a reviewer a file that is already assembled and already current. The decision stays where it is supposed to sit.
It is not a compliance certificate, and we do not describe it as one. Data-use terms from the national nurse database also govern what board-sourced material can be shared onward — a real constraint on what any credentialing product can hand to a third party, whatever its marketing says.
Who this is for
- Health systems
- Medical staff offices carrying re-verification cycles by calendar, and anyone whose credentialing evidence currently lives in a shared drive and an inbox.
- Staffing & locums
- Agencies placing clinicians across states, where roster turnover outruns any point-in-time process and the same file has to satisfy several facilities.
- Traveling clinicians
- Nurses and advanced practice clinicians who rebuild the same packet for every assignment, and who would rather carry one wallet that stays current.
- Federal buyers
- Menehune AI is an SBA-certified Service-Disabled Veteran-Owned Small Business, so this work is available through set-aside and sole-source paths. How we work with federal buyers.
We built this system, we operate it, and the numbers on this page are counted from it. If parts of it are already solved in your shop, we are just as happy to build the part that is not.
Tell us what your credentialing file looks like today.
The useful first call is a specific one: which credentials you carry, which states, where the file currently breaks, and what you would want to stop doing by hand.