How Aetsoft helped a US credentialing software company
Test reusable verification on a healthcare credentialing blockchain
Aetsoft integrated a permissioned ledger into the client's existing credentialing platform, so a clinic could confirm a work history once and have that confirmation serve later requests.
Every employer that hires a clinician verifies the same work history, and each verification stops with whoever asked for it. Our client wanted to know whether a healthcare credentialing blockchain could change that.
Aetsoft delivered the integration between their platform and a Hyperledger Sawtooth network on Azure. We also built the projection service behind search, and a gated portal where approved third parties could inspect a confirmed record. Their back-office systems read and batch-updated those records too. The pilot ran across twelve clinics and completed in early 2020.
001
ClientA US healthcare software company working in provider credentialing
002
ChallengeThe same work history is verified again by every employer, inside a process that can run 90 to 120 days
003
SolutionA permissioned ledger inside the client's platform, with a gated portal where approved third parties inspect the confirmation
Engagement lead
Pavel Sivayeu
CTO, Aetsoft Inc
Ran delivery and led the Aetsoft team across the engagement, 2019 to 2022
Credentialing runs on verification that nobody can reuse
Before a clinician can bill, someone confirms where they worked, when, and in what role. Credentialing a provider can take 90 to 120 days, and primary source verification sits in the middle of that window. It is one of the slowest administrative processes in healthcare, and one of the most repeated.
What makes it slow is that a human at the previous employer has to find the record and answer. Once they do, the result belongs to whoever asked.
So the clinic that confirms a nurse's dates in March confirms them again in July for a different employer, and again in November for a third. Same clinic, same record, same answer. The work is not hard, and the repetition is what the calendar pays for.
Solution
What we built
Nothing here replaced the client's platform.
The ledger, the projection and the portal were added to software that already worked, which is why nine weeks and two engineers were enough.
We had run the same Sawtooth topology a year earlier on an agricultural traceability ledger, and that shortened the setup considerably.
How a verified record moves through the system
The clinic confirms once, and that entry goes to the ledger
Verification itself stayed as it was. What changed is where a verified record lands: only confirmed entries reach the chain, and once written they are readable by everything downstream. The rules governing what a valid job record looks like live in a Sawtooth transaction family, the platform's equivalent of smart contract development.
Capturing it at that moment matters. The confirmation comes from the party that knows, while they are looking at the entry, rather than being reconstructed later from a file.
Approved third parties inspect the record without repeating the check
Access to the portal runs through an approval queue. Someone requests an account, an administrator approves or declines, and the outcome goes out by email. A searchable index of who employed whom is a different object from a public register, so the client keeps the say over who runs those queries.
Inside, a reader searches by NPI. Each result carries the verifying organisation, and the reader can filter by it. That is what removes the second request: they can see whose confirmation it is and judge whether that organisation is authoritative for their purposes.
Their own systems read and update those records in batch
The second success measure needed a different path. Aetsoft built an API taking JSON from the client's platform, validating the structure, and translating to Protocol Buffers before submitting to the chain.
Expected traffic was below 500 chain calls on an ordinary day, rising to roughly 10,000 on the monthly reconciliation with those systems. Those are design figures rather than measured load. A path that idles at 500 and absorbs twenty times that is a different design from one averaging 5,000.
Callers wait ten seconds for an answer, then treat the service as unavailable. Every path through the API ends in something the caller can store: accepted, rejected as malformed, rejected by the chain, or timed out. Designing that contract is most of what ledger integration work actually involves. A request left hanging gives the calling system nothing to record, which is worse than a refusal.
A projection service gives the portal database search over ledger records
Sawtooth stores state in a Merkle radix trie. It answers "what is at this address" quickly and "which records mention this NPI" slowly, so it makes a poor place to run a portal query.
So Aetsoft wrote a Distributed Ledger Watcher, a service built for this engagement rather than a Sawtooth component. It follows the chain and projects every committed record into SQL for the application and into Elasticsearch for search. The portal reads the projection and never touches the validators, and every row on screen still traces back to a block.
Corrections append to the record rather than overwrite it
Credentialing data gets corrected constantly: a wrong end date, a disputed role, a clinic that verified the wrong entry. The client's administrators needed to be able to put those right, and on a ledger they can.
What they cannot do is make the earlier version disappear. A correction is a new entry superseding the old one, and both stay readable with their timestamps and their authors. That is the reason an outside reader can trust the record at all.
Ordered, append-only history is the same property we work with at protocol level. It also governs the verifiable credentials network we later built with Velocity Career Labs, where a revoked credential stays visible as revoked.
Credentialing data gets corrected constantly: a wrong end date, a disputed role, a clinic that verified the wrong entry. The client's administrators needed to be able to put those right, and on a ledger they can.
than overwrite it
What they cannot do is make the earlier version disappear. A correction is a new entry superseding the old one, and both stay readable with their timestamps and their authors. That is the reason an outside reader can trust the record at all.
Ordered, append-only history is the same property we work with at protocol level. It also governs the verifiable credentials network we later built with Velocity Career Labs, where a revoked credential stays visible as revoked.
Key decisions
001
Where the shared record lives
Expose the existing database through an API
A permissioned ledger, so the history is correctable without being rewritable, under governance that can extend past one company
002
Ledger platform
Hyperledger Fabric
Hyperledger Sawtooth, because business logic runs as separate transaction processors on their own release cycles, which suited a schema still moving
003
Custom logic
A transaction family per record type
One family for job records, reusing Sawtooth's core identity, settings and block info families as shipped
004
Record payload
Hash on chain, record off chain
The whole record in the transaction, correct for three validators in one environment with no external node operator, and the first thing to change if that stops being true
005
Consensus
PoET or Raft
The devmode engine, since consensus was outside what the pilot set out to test and PoET-SGX expects SGX-capable CPUs on every validator
006
Portal queries
Query the validators directly
A projected read layer, because NPI search and filtering are unworkable against a Merkle radix trie
007
Portal access
Open read access
An approval queue, since a searchable employment index is not a public register
Each row above was a live argument during scoping rather than a default
Choosing between a ledger and a database is the first question our blockchain consulting team works through with a client, and it does not always end with a ledger.
Results
“Both success measures were delivered inside nine weeks with two engineers. Third parties with approved accounts could search by NPI and see the confirming organisation. The client's back-office systems could read the same records and update them in batch.”
What changed is narrower than a faster process, and more useful. A confirmation that previously served the organisation that requested it became a record other approved organisations could inspect for themselves, without going back to the clinic. Corrections stayed possible throughout, appended rather than applied over the top.
This pilot also produced the harder answer. Three validators ran in the client's Azure environment.
That established the mechanics without changing the trust position, since all three nodes belonged to one company.
At the close, Aetsoft's proposed production design was a permissioned network with nodes held by organisations independent of each other. That is where this architecture starts doing something a database cannot. It is also the design we went on to build at scale with Velocity Career Labs, where around fifteen independent organisations operate nodes.
Frequently asked questions about credentialing on a ledger
-
When is a database the better answer?
Whenever one organisation publishes its own attestations and no outside party will run a node. A signed hash chain inside an existing database gives tamper evidence at a fraction of the cost, provided readers hold a checkpoint outside the operator’s control. Without that, the same party holds the data and every copy of the head.
-
What would a production version change?
Three things would change. The record moves off the chain, with a hash committed in its place, so no external node operator holds a copy of every clinician’s employment history. Consensus moves off devmode, and either candidate needs testing against the caller timeout, since leader election and finality change what a write costs. Governance comes before both, meaning node membership and correction rights get settled first, along with what happens when two participants disagree.
-
Does the clinician's personal data go on the chain?
In this pilot the record went into the transaction, on a private network inside a single Azure environment with no external node operators. Once independent validators join, the record moves off the chain. Storage location and key custody become design decisions the ledger no longer makes for you.
-
Is Hyperledger Sawtooth still the right choice for a healthcare credentialing blockchain?
It would not be our choice for a new project. Hyperledger archived Sawtooth on 1 February 2024. The pluggable transaction processor model does not transfer cleanly to other enterprise frameworks, so anyone starting today makes that trade-off again. Our own later credential infrastructure work runs on permissioned Ethereum.
We have been building permissioned ledgers since 2017, from pilots like this one to production networks run by independent organisations. If a record several organisations have to trust sits in your roadmap, we will tell you whether a ledger or a database fits the problem. Sometimes the answer is your database.
