NCPDP to JSON: Modernizing Pharmacy Claims
The NCPDP Telecommunication Standard was designed in the 1990s for dial-up modems and fixed-width terminal screens. It uses a binary, pipe-delimited format that predates JSON, REST, and the modern web by decades. Every pharmacy claim in America still flows through this format. Starlight translates it to JSON so you don't have to.
What raw NCPDP actually looks like
NCPDP Telecom D.0 uses field separators (FS, GS, and AM characters, which are ASCII control codes) to delimit segments and fields. Each field is identified by a two-character code. The result is a dense, obfuscated binary string that looks like this:
It's an opaque, obfuscated format designed for 1990s dial-up modems, not modern software development. Two-character codes like C2, CB, and D7 map to BIN number, PCN, and NDC respectively. You need the NCPDP spec document (hundreds of pages, behind a paywall) to decode any of it.
The same claim in JSON
Here's the exact same claim expressed as a Starlight JSON request:
{
"header": {
"bin": "610014",
"pcn": "OHCARD",
"transactionCode": "B1",
"serviceProviderId": "PHAR01"
},
"insurance": {
"cardholderFirstName": "JOHN",
"cardholderLastName": "DOE",
"dateOfBirth": "19850115",
"personCode": "01"
},
"claim": {
"productServiceID": "00378395105",
"quantityDispensed": 30,
"daysSupply": 30,
"ingredientCostSubmitted": 45.00,
"dispensingFeeSubmitted": 2.50,
"usualAndCustomaryCharge": 47.50,
"grossAmountDue": 47.50,
"dispenseAsWritten": "0"
},
"prescriber": {
"prescriberID": "1122334455"
}
}Self-documenting. Human-readable. Zero ambiguity. Every field has a descriptive name. You can read the request without a spec document. Your IDE autocompletes it. Your tests are readable. Your logs make sense.
Why the format matters more than you think
The NCPDP binary format isn't just ugly. It actively creates engineering problems:
Debugging is painful
When a claim fails, you're staring at binary data trying to figure out which field is wrong. With JSON, the field name tells you exactly what's missing.
No standard tooling
You can't use Postman, curl, or any standard HTTP tool to test NCPDP claims. With JSON REST, every developer tool in existence works out of the box.
Custom parsers break
Every team writes their own NCPDP parser. They all have edge cases. Field length overflows, encoding issues, segment ordering bugs. JSON parsers are battle-tested in every language.
Onboarding takes months
New engineers need weeks just to understand the protocol. JSON is something every developer already knows.
How Starlight translates between worlds
Starlight maintains a complete NCPDP Telecom D.0 implementation internally. When you send a JSON request:
- 1.Your JSON is validated against the NCPDP field definitions and payer-specific requirements
- 2.Fields are mapped to their NCPDP field identifiers and encoded into the binary format
- 3.The encoded claim is routed through the pharmacy switch network to the correct PBM
- 4.The PBM's binary response is decoded back into structured JSON
- 5.You receive a clean JSON response with pricing, reject codes, and DUR information
All of this happens in under 2 seconds. The latency overhead of the JSON translation is negligible. The PBM adjudication itself is the bottleneck.
Built for developer experience
Moving from NCPDP binary to JSON isn't just a format change. It unlocks the entire modern development workflow:
- • Type safety: full TypeScript definitions for every request and response
- • Validation: meaningful error messages that tell you exactly which field failed and why
- • Testing: use any HTTP testing framework. No custom protocol test harnesses needed
- • Logging: claims are readable in your logs without a decoder ring
- • Documentation: OpenAPI spec, interactive API docs, code examples in every language
- • Versioning: standard API versioning instead of NCPDP version negotiation
Leave the binary behind
Starlight translates NCPDP Telecom to JSON so you can build pharmacy software with modern tools. No spec documents. No custom parsers.