DEV Community: easysolutions906

Why MCP Servers Matter for Healthcare Integration Engineers

easysolutions906 — Wed, 18 Mar 2026 02:59:44 +0000

Why MCP Servers Matter for Healthcare Integration Engineers

If you've been doing healthcare integration work for any amount of time, you've probably tried asking ChatGPT or Claude to help you write a Mirth transformer. And you've probably gotten back JavaScript that uses template literals, destructuring and arrow functions in places where Rhino's ES6 support falls apart. The AI doesn't know what Mirth actually supports. It doesn't have context about your channels, your mappings or your environment.

MCP servers fix this.

What an MCP server actually is

Model Context Protocol is a standard that lets AI assistants call external tools. Instead of the AI guessing, it can call a function that does the actual work and returns real results. Think of it like giving the AI a set of specialized instruments instead of asking it to guess what the X-ray shows from a description.

An MCP server is just a process that exposes these tools over a standard protocol. Any AI assistant that supports MCP (Claude Desktop, Cursor, Windsurf and others) can connect to it and use the tools.

Why this matters for integration work

Healthcare integration is full of tasks that are tedious, detail-oriented and follow patterns. Parsing HL7 messages. Reviewing channel configurations. Writing JavaScript that has to run in Rhino's specific flavor of ES6. Debugging error messages that tell you almost nothing useful.

These are things an AI can help with, but only if it has the right tools. Without them, you're copying and pasting channel XML into a chat window and hoping the AI figures out the context. With MCP tools, the AI can:

Parse a channel export and tell you what it does in plain English
Generate transformer code that actually runs in Rhino
Diff two channel configurations and show you what changed
Look up ICD-10 codes, NPI numbers or NDC drug data without you leaving your editor
Flag issues in your channel like hardcoded IPs, SQL injection risks or missing error handling

A real example

Say you've exported a channel XML from your dev environment and you need to review it before promoting to production. Without MCP tools, you're reading through hundreds of lines of XML manually or pasting chunks into a chat window.

With the healthcare MCP server connected, you can just ask your AI assistant to parse and analyze the channel. It calls the parse tool, gets back structured JSON, runs the analysis tool and tells you "this channel has a hardcoded database IP in the destination connector, the transformer is using a deprecated Rhino pattern and there's an unhandled error path in the response transformer." That's five minutes of work instead of thirty.

The tools I built

I've published MCP servers for the areas I work in most:

Healthcare MCP: ICD-10 lookups, NPI provider search, NDC drug data and DEA number validation. Ten tools total.
HL7 Tools MCP: Parse HL7 messages, validate structure, convert segments to FHIR resources. Nine tools.
Web Tools MCP: Email validation, IP geolocation, URL metadata, sentiment analysis. Eleven tools.
OFAC Screening MCP: Sanctions screening with fuzzy matching. Five tools.

They all install through npm and connect to Claude Desktop or Cursor with a few lines of config.

This isn't about replacing anyone

I want to be clear about something. These tools don't replace integration engineers. They make integration engineers faster. The AI still doesn't know your organization's business rules, your vendor relationships or why that one channel has a weird filter that everyone is afraid to touch. That's your expertise. The MCP tools just handle the mechanical parts so you can focus on the parts that actually require thinking.

If you spend your days writing Mirth transformers, reviewing channel configs and looking up healthcare codes, give these a try. The setup takes about five minutes and you'll know pretty quickly whether they fit into your workflow.

OFAC Screening Is Not Optional and Your Fintech Probably Isn't Doing It Right

easysolutions906 — Wed, 18 Mar 2026 02:54:17 +0000

OFAC Screening Is Not Optional and Your Fintech Probably Isn't Doing It Right

If your application moves money, processes payments or onboards customers, you need to screen against the OFAC SDN list. This isn't a suggestion. The Office of Foreign Assets Control can fine you $356,579 per violation and they don't care if you missed a match because your string comparison was case-sensitive.

I built an OFAC screening API because I kept seeing the same problem: companies either weren't screening at all, were doing naive exact-match lookups that miss obvious variations, or were paying enterprise vendors five figures a year for what amounts to fuzzy string matching against a publicly available XML file.

What most people get wrong

The SDN list is just XML. Treasury publishes it freely. The hard part isn't getting the data. The hard part is matching against it in a way that actually catches the people it's supposed to catch.

Here's an example. "Vladimir Vladimirovich PUTIN" is on the list. He also appears as "Vladimir PUTIN." If a customer enters "V. Putin" on your onboarding form and your system does an exact match, congratulations, you just cleared a sanctioned individual.

This is why you need multiple matching strategies working together:

Jaro-Winkler similarity catches typos and transpositions
Token-set matching handles reordered words ("BANK OF IRAN" vs "IRAN BANK")
Phonetic matching catches different spellings of the same-sounding name
Substring containment for partial queries

Each of these on its own misses things. Together they produce a confidence score that actually means something.

The DIY trap

I've talked to developers who say "we'll just download the XML and do our own matching." Sure, you can do that. Here's what you're signing up for:

Parsing 18,000+ entries with multiple aliases per entry
Handling name transliterations across scripts
Updating the data every time Treasury publishes a change (which is frequent)
Tuning match thresholds so you catch real hits without drowning your compliance team in false positives
Documenting all of this for your auditors

Most teams get halfway through this list and realize they should have just used an API.

What good screening looks like

A screening call should take a name (and optionally a country, entity type or sanctions program filter) and return matches ranked by confidence. Each match should include the SDN entry details, the match score and which matching strategy flagged it.

Your compliance team needs to review anything above a certain threshold. The API should make it obvious what to review and what to ignore. If everything comes back as a 73% match, that's useless. You need clear tiers: exact match, strong match, partial match, weak match.

The system also needs to handle batch screening. If you're onboarding thousands of customers or processing payroll for a multinational, you can't make one API call at a time.

How I built it

The OFAC Screening API embeds the full SDN list locally and updates it regularly. No dependency on Treasury's servers at query time. Responses come back fast because there's no upstream call.

It uses weighted scoring across all four matching strategies I mentioned above. Results come back with a confidence tier and the full SDN entry details so your compliance team has everything they need to make a decision.

There's also an MCP server version if you're using AI assistants for compliance workflows. An agent can screen a list of names, review the results and flag the ones that need human attention.

The bottom line

OFAC screening is one of those things where the cost of getting it wrong is catastrophic and the cost of getting it right is pretty low. You don't need an enterprise contract. You need fuzzy matching, regular data updates and clear confidence scoring. That's it.

If you're not screening today, start. If you're doing exact-match only, fix it. The Treasury Department is not going to accept "our string comparison was case-sensitive" as a defense.

Your Mirth Connect Channels Should Be in Git. Here's How to Make That Happen.

easysolutions906 — Wed, 18 Mar 2026 02:54:15 +0000

Your Mirth Connect Channels Should Be in Git. Here's How to Make That Happen.

I've been doing healthcare integration work for over a decade now. In that time I've seen exactly one constant across every shop I've worked at: nobody has version control on their Mirth channels when I walk in the door.

Think about that. You've got channels processing thousands of HL7 messages a day, moving patient data between your EHR, your lab, your pharmacy, your billing system. If somebody makes a bad change on a Friday afternoon, your options are "remember what it looked like before" or "restore from a backup that may or may not exist." That's not a plan. That's hope.

Why this keeps happening

It's not because integration engineers are lazy. It's because Mirth doesn't make it easy. Channels live inside the application. The configuration is XML blobs stored in a database. There's no "save to file system" button that slots into a normal Git workflow.

So teams do what teams do when something is hard. They skip it. Maybe someone keeps a folder of exported channel XMLs on a shared drive somewhere. Maybe there's a naming convention like ADT_Inbound_v3_FINAL_actual_final.xml. We've all been there.

The approach that actually works

At a previous role I inherited over a hundred channels on a legacy Mirth instance with zero version control. Here's what I put in place:

1. Automated channel exports on a schedule. A script hits the Mirth REST API, exports every channel as XML and commits to a Git repo. This runs on a cron. No human has to remember to do it.

2. One channel per file, named by channel ID and name. The file name includes both so you can find things by either. The XML is formatted consistently so diffs are actually readable.

3. Pull requests for production changes. Before a channel change goes to prod, the export captures it and a PR gets opened. Another engineer reviews the diff. This is table stakes in software development but it feels revolutionary in the Mirth world for some reason.

4. Environment-specific branches. Dev, test and prod each have their own branch. Promoting a change means merging forward. You can diff between environments to see exactly what's different.

The hard part nobody talks about

Getting the tooling set up is the easy part. The hard part is getting your team to actually use it.

If your team has been doing Mirth work without version control for years, you're asking them to change their workflow. You're adding steps. Some people will see this as overhead. You need to show them the first time it saves someone's neck after a bad deployment. That converts people fast.

The other thing is that Mirth channel XML is verbose. A simple channel can be hundreds of lines of XML. The diffs can be noisy. Invest time in making your exports consistent (alphabetized properties, stable formatting) so that the diffs show real changes, not just reordering noise.

What this looks like in practice

A developer makes a change to a channel in the test environment. The export cron picks it up within the hour. A PR gets auto-created against the test branch. The developer adds context in the PR description about what they changed and why. Another engineer reviews it. When it's approved and merged, the same change gets applied to prod through the same process.

Is it more work than just clicking deploy in the Mirth admin console? Yes. Is it worth it the first time you need to roll back a change or figure out who changed what and when? Absolutely.

Tools that help

If you're using AI assistants like Claude or Cursor for development, the MCP Healthcare server and Mirth Connect MCP tools can parse channel XMLs, diff between environments and generate Rhino-compatible JavaScript. It doesn't replace the version control workflow but it makes the review process a lot faster when you can ask an AI to explain what a 500-line channel XML actually does.

Just start

If you take one thing from this: just start. Export your channels today. Put them in a repo. Even if you don't have the full PR workflow yet, having a history of your channel configurations will save you. I guarantee you'll need it sooner than you think.

OFAC Screening for Payroll Companies: Automate Compliance Before Every Pay Run

easysolutions906 — Tue, 17 Mar 2026 02:01:07 +0000

OFAC Screening for Payroll Companies: Automate Compliance Before Every Pay Run

Payroll companies process millions of payments every cycle. Each one of those payments is a US financial transaction, and every US financial transaction falls under OFAC jurisdiction. That includes direct deposits to employees, payments to contractors, and disbursements to vendors. If any of those recipients appear on the Specially Designated Nationals (SDN) list, you are legally prohibited from sending them money -- and ignorance is not a defense. Penalties start at $356,579 per violation.

Most payroll platforms have robust tax calculation engines, time-tracking integrations, and ACH batch processing. What many lack is automated sanctions screening. This article covers why payroll companies are in scope, how to screen your roster programmatically, and how to build screening into your pay run pipeline.

Why payroll companies must screen

OFAC regulations apply to all US persons and entities engaging in financial transactions. "Financial transactions" is interpreted broadly -- it covers wire transfers, ACH payments, check disbursements, and yes, payroll deposits. The Treasury Department has made clear that the obligation extends to any company facilitating payments, not just banks.

Here is the practical risk for a payroll company:

You process payroll for a client. That client has an employee or contractor whose name matches an SDN entry.
You send the payment. The ACH transfer clears. The funds reach a sanctioned individual.
OFAC investigates. They do not care that you are "just the payroll processor." You facilitated the transaction. You are liable.

Payroll processors sit in the same enforcement category as payment processors, money service businesses, and neobanks. If you move money, you screen. Period.

The entities you need to screen include:

Employees on every client's payroll roster
Independent contractors and 1099 recipients
Vendors receiving payments through your platform (benefits providers, garnishment recipients, tax authorities are exempt but third-party vendors are not)
Client companies themselves -- you should not process payroll for a sanctioned entity

Screening a single name

The OFAC screening API at https://ofac-screening-production.up.railway.app accepts a name and returns scored matches against the full SDN list. Here is a basic screen:

curl -X POST https://ofac-screening-production.up.railway.app/screen \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: YOUR_API_KEY' \
  -d '{"name": "Ali Hassan", "threshold": 0.85}'

The response includes match scores, confidence levels, and the sanctions programs involved:

{
  "query": { "name": "Ali Hassan" },
  "threshold": 0.85,
  "matchCount": 2,
  "matches": [
    {
      "entity": {
        "name": "Ali HASSAN",
        "sdnType": "Individual",
        "programs": ["SDGT"]
      },
      "score": 0.97,
      "matchType": "exact",
      "matchedOn": "primary"
    },
    {
      "entity": {
        "name": "Hassan ALI",
        "sdnType": "Individual",
        "programs": ["IRAN"]
      },
      "score": 0.88,
      "matchType": "strong",
      "matchedOn": "alias"
    }
  ],
  "listVersion": "03/13/2026",
  "screenedAt": "2026-03-16T14:30:00.000Z"
}

The listVersion and screenedAt fields are your audit trail. Regulators expect to see when you screened and which version of the SDN list you screened against.

Screening a payroll roster in JavaScript

In practice, you are not screening one name at a time. You have a roster of employees and contractors that needs to be screened before every pay run. The /screen/batch endpoint accepts up to 100 names per request.

const API_URL = 'https://ofac-screening-production.up.railway.app';
const API_KEY = process.env.OFAC_API_KEY;

const screenBatch = async (names) => {
  const res = await fetch(`${API_URL}/screen/batch`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': API_KEY,
    },
    body: JSON.stringify({ names, threshold: 0.85 }),
  });

  if (!res.ok) {
    throw new Error(`Screening failed: ${res.status} ${await res.text()}`);
  }

  return res.json();
};

// Chunk an array into groups of a given size
const chunk = (arr, size) =>
  Array.from({ length: Math.ceil(arr.length / size) }, (_, i) =>
    arr.slice(i * size, i * size + size)
  );

const screenPayrollRoster = async (employees) => {
  const names = employees.map((emp) => ({
    name: `${emp.firstName} ${emp.lastName}`,
    country: emp.country || null,
  }));

  const batches = chunk(names, 100);
  const allResults = [];

  for (const batch of batches) {
    const data = await screenBatch(batch);
    allResults.push(...data.results);
  }

  const flagged = allResults.filter((r) => r.matchCount > 0);
  const clear = allResults.filter((r) => r.matchCount === 0);

  return { flagged, clear, total: allResults.length };
};

For a payroll company with 500 employees on a client's roster, this sends 5 batch requests. Each batch returns in under a second. The entire roster screens in a few seconds.

Integrating screening into your pay run pipeline

Screening should happen at two points in your workflow:

Employee onboarding. When a new employee or contractor is added to any client's roster, screen them immediately. Do not wait for the first pay run.
Before every pay run. The SDN list updates frequently. Someone who was clear last month may be sanctioned today. Screen the full roster before you submit the ACH batch.

Here is how that looks in a pay run pipeline:

const processPayRun = async (clientId, payPeriod) => {
  // 1. Pull the roster
  const employees = await getActiveEmployees(clientId);

  // 2. Screen everyone against OFAC
  const screening = await screenPayrollRoster(employees);

  // 3. If anyone is flagged, halt the pay run for review
  if (screening.flagged.length > 0) {
    await flagPayRunForReview(clientId, payPeriod, screening.flagged);
    await notifyComplianceTeam(clientId, screening.flagged);

    console.log(
      `PAY RUN HELD: ${screening.flagged.length} potential OFAC match(es) for client ${clientId}`
    );

    screening.flagged.forEach((result) => {
      result.matches.forEach((m) => {
        console.log(
          `  ${result.query.name} -> ${m.entity.name} (score: ${m.score}, program: ${m.entity.programs.join(', ')})`
        );
      });
    });

    return { status: 'held', reason: 'ofac_review_required' };
  }

  // 4. Log the clear screening for audit purposes
  await saveScreeningRecord(clientId, payPeriod, {
    screenedAt: new Date().toISOString(),
    totalScreened: screening.total,
    matchCount: 0,
  });

  // 5. Proceed with ACH batch submission
  const achResult = await submitAchBatch(clientId, payPeriod, employees);

  return { status: 'submitted', achResult };
};

The key design decision here is that a flagged result halts the pay run. You do not skip flagged employees and pay everyone else. You hold the entire batch until compliance reviews the matches. This is the conservative approach and the one regulators expect.

Automating screening on a schedule

Beyond the per-pay-run screen, you should also run screening on a regular schedule to catch SDN list updates between pay cycles. Many payroll companies run biweekly pay runs, but the SDN list can update multiple times per week.

// Run nightly at 2 AM — catches SDN updates between pay runs
const nightlyScreening = async () => {
  const clients = await getAllActiveClients();

  for (const client of clients) {
    const employees = await getActiveEmployees(client.id);
    const screening = await screenPayrollRoster(employees);

    if (screening.flagged.length > 0) {
      await notifyComplianceTeam(client.id, screening.flagged);
      await markClientForReview(client.id);
    }

    // Always log the screening, even when clear
    await saveScreeningRecord(client.id, 'nightly', {
      screenedAt: new Date().toISOString(),
      totalScreened: screening.total,
      matchCount: screening.flagged.length,
    });
  }
};

For a cron-based setup, trigger this with your task scheduler. If you are on Railway, Render, or a similar platform, use their cron job feature. On AWS, a Lambda triggered by EventBridge on a schedule works well.

The frequency depends on your risk profile:

Daily: recommended for payroll companies processing payments for financial services clients
Weekly: acceptable for most payroll companies
Per pay run: the minimum. Never skip this one.

What to do when you get a match

A match does not mean you have a sanctioned individual on your payroll. The SDN list contains roughly 18,000 entries, and common names produce false positives. "Ali Hassan," "Mohammed Ali," and "Carlos Garcia" will all generate potential matches. Here is the process:

1. Do not process the payment

The moment a screening returns a match above your threshold, freeze the payment for that individual. Do not release funds until the match is resolved. This is not optional -- processing a payment to a confirmed SDN match is a federal violation.

2. Escalate to compliance

Your compliance team (or compliance officer, or if you are a smaller shop, whoever owns compliance) reviews the match. They compare the matched SDN entry's identifying details -- date of birth, nationality, address, aliases -- against your employee record. Most matches resolve as false positives at this stage.

3. Document the resolution

Whether the match is a true positive or a false positive, document the review. Record who reviewed it, when, what data points they compared, and what they concluded. This documentation is your evidence of a functioning compliance program.

const resolveScreeningMatch = async (matchId, resolution) => {
  const record = {
    matchId,
    resolvedBy: resolution.reviewerEmail,
    resolvedAt: new Date().toISOString(),
    determination: resolution.isTruePositive ? 'true_positive' : 'false_positive',
    notes: resolution.notes,
    sdnFieldsCompared: resolution.fieldsCompared, // e.g., ['dob', 'nationality', 'address']
  };

  await saveMatchResolution(record);

  if (resolution.isTruePositive) {
    await blockEmployee(resolution.employeeId);
    await fileSuspiciousActivityReport(resolution);
    await notifyLegalCounsel(resolution);
  } else {
    await releasePayment(resolution.employeeId, resolution.payPeriod);
  }
};

4. True positive: block and report

If the match is confirmed, you must:

Block the payment permanently. Do not release funds.
File a Suspicious Activity Report (SAR) with FinCEN. You have 30 days from the date you determine the activity is suspicious.
File a blocking report with OFAC within 10 business days if you have blocked property or funds.
Notify legal counsel. A confirmed SDN match is a serious matter that may involve law enforcement coordination.
Do not notify the sanctioned individual. Tipping off an SDN match is itself a violation.

5. False positive: release and whitelist

If your compliance team determines the match is a false positive, release the held payment and add the employee to an internal whitelist so the same false positive does not halt future pay runs. The whitelist should be re-reviewed periodically -- quarterly is standard practice.

Building an audit trail

Regulators do not just want to know that you screen. They want to see proof. Every screening event should produce a record that includes:

The date and time of the screening
The version of the SDN list used (the API returns this as listVersion)
The names screened
The threshold used
The results (matches and clears)
For matches: the resolution and who resolved it

The API's response already includes listVersion and screenedAt in every response. Store these alongside your payroll records. When an examiner asks "How do you verify your employees are not on the SDN list?", you hand them the screening log.

Cost and scaling

For a payroll company processing 10,000 employees across all clients, a nightly screen plus per-pay-run screens for biweekly payroll works out to roughly 40,000 screens per month. The Pro plan at $4.99/month covers 5,000 screens, and the Ultra plan at $29.99/month covers 25,000. For larger volumes, the Mega plan at $99.99/month includes 100,000 screens -- still a fraction of what enterprise compliance platforms charge.

Compare that to Dow Jones Risk & Compliance or LexisNexis, which start at $10,000/year and go up from there. For a payroll company that needs sanctions screening and nothing else, a purpose-built API at $30-100/month is the right tool.

Next steps

REST API: POST /screen for single names, POST /screen/batch for up to 100 names per request at https://ofac-screening-production.up.railway.app
MCP server: Run npx @easysolutions906/mcp-ofac for conversational screening in Claude Desktop or Cursor
Data freshness: Hit /data-info to verify the SDN list version and publish date before each pay run

Sanctions screening is not a feature you add after launch. It is a requirement before you process your first payment. The good news is that with a batch screening endpoint and a few lines of integration code, you can screen your entire payroll roster in seconds -- every single pay run, automatically, with a full audit trail.

How AI Agents Are Replacing Manual Compliance Workflows in 2026

easysolutions906 — Tue, 17 Mar 2026 01:56:06 +0000

How AI Agents Are Replacing Manual Compliance Workflows in 2026

A compliance analyst at a mid-size fintech starts their morning with a list of 40 new customer applications. Each one needs an OFAC sanctions screening. Several involve healthcare providers who need NPI and DEA verification. A few wire transfers need routing number validation before release.

In the old workflow, this means opening four or five different web portals, copying names between browser tabs, formatting results into spreadsheets, and pasting screenshots into case files. It takes most of the morning. It is tedious, and tedious work produces mistakes -- a misspelled name here, a skipped re-check there.

In 2026, that same analyst opens Claude Desktop or Cursor, types what they need in plain English, and gets structured, auditable results in seconds. The difference is not a better dashboard. It is a fundamentally different model: AI agents that call compliance tools directly.

The manual compliance problem

Manual compliance workflows fail in predictable ways.

They are slow. Screening a single name against the OFAC SDN list through a web portal takes 30-60 seconds including page loads, form entry, and result interpretation. Multiply that by 200 names per day and you have lost a full-time employee to copy-paste.

They are error-prone. When a human types "Mohammad" into one portal and "Mohammed" into another, they get different results. When they screen at 4:45 PM on a Friday, they miss things. Fuzzy matching and phonetic algorithms catch name variations that tired humans do not.

They fragment the audit trail. Results live in screenshots, spreadsheets, email threads, and portal histories. When an examiner asks "show me every screening you ran on this counterparty in Q2," reconstructing the record takes hours.

They do not compose. A real compliance decision often requires multiple data sources -- screen the name against OFAC, verify their NPI is active, confirm their DEA registration matches the prescribing state, check the routing number on the payment. Each lookup lives in a different system with a different interface. No portal connects them.

How MCP servers change the model

The Model Context Protocol (MCP) is a standard that lets AI assistants call external tools. An MCP server is a lightweight process that exposes a set of functions -- each with a name, description, and typed parameters. When you connect an MCP server to Claude Desktop, Cursor, or any MCP-compatible client, the AI assistant can call those tools during a conversation.

This is not a chatbot that searches the web and summarizes what it finds. The AI agent calls a specific, deterministic tool with structured parameters and gets structured results. The OFAC screening tool runs the same fuzzy matching algorithm whether a human calls the API or Claude calls it through MCP. The results are identical and auditable.

The key shift: the AI agent becomes the orchestration layer that compliance officers always needed but never had. It connects multiple tools, formats results consistently, and maintains context across a multi-step verification workflow.

Real workflow examples

Screening a customer list against OFAC

A compliance officer pastes a list of names into Claude Desktop:

Screen these new customers against the OFAC SDN list:

Ahmad Al-Rashid, Syria

Petromax Trading LLC, UAE

Maria Santos, Brazil

Dong Feng Industrial Co., China

James Robertson, United States

Claude calls the ofac_screen tool from the OFAC MCP server (@easysolutions906/mcp-ofac) for each name and returns a summary:

Name	Matches	Highest Score	Recommended Action
Ahmad Al-Rashid	2	0.91 (strong)	Escalate for review
Petromax Trading LLC	0	--	Clear
Maria Santos	0	--	Clear
Dong Feng Industrial Co.	1	0.87 (strong)	Escalate for review
James Robertson	0	--	Clear

The officer reviews the flagged entries: "Tell me more about the matches for Ahmad Al-Rashid." Claude calls ofac_entity and returns the full SDN entry with aliases, programs, addresses, and identification documents. The officer makes a disposition decision with full context, in the same conversation, with a complete audit trail.

Total time: under two minutes for five screenings including follow-up review. The manual process would have taken 15-20 minutes and required switching between two or three browser tabs.

Verifying a healthcare provider's credentials

A health plan's credentialing team needs to verify a new provider before adding them to the network. The analyst types:

Verify Dr. Sarah Chen, NPI 1234567890. Also validate her DEA number BC1234567 and look up diagnosis code E11.9 that she listed as her primary specialty area.

Claude calls three tools from the healthcare MCP server (@easysolutions906/mcp-healthcare):

npi_lookup -- Returns Dr. Chen's full NPI record: name, taxonomy, practice address, enumeration date, whether the NPI is active
validate_dea -- Validates the DEA number's check digit algorithm and returns the registration details
icd10_lookup -- Returns "Type 2 diabetes mellitus without complications" for E11.9

The analyst gets a unified view of the provider's credentials in one response. If the NPI shows a different name or an inactive status, or if the DEA check digit fails, Claude flags the discrepancy immediately.

In the traditional workflow, this requires the NPI registry website (NPPES), the DEA verification portal, and a separate ICD-10 lookup tool. Three tabs, three searches, three sets of results to reconcile manually.

Validating a routing number for a wire transfer

A payment operations team processes wire transfers. Before releasing a $50,000 payment, the analyst verifies the routing number:

Look up routing number 021000021 and confirm it belongs to JPMorgan Chase.

Claude calls the routing number lookup tool and returns the institution name, location, phone number, and routing number type (ABA, ACH, wire). The analyst confirms the routing number matches the expected institution and approves the transfer.

This takes five seconds. The manual process -- searching the Federal Reserve's E-Payments directory or calling the bank -- takes minutes. For a team processing hundreds of wire transfers per day, the time savings compound.

The cost math

Enterprise compliance platforms charge based on the scale of what they promise, not the complexity of what they deliver. A typical pricing structure:

Solution	Monthly Cost	What You Get
Enterprise compliance platform	$500 - $5,000/mo	OFAC screening, case management, dashboards, SSO, account manager
Mid-market screening tool	$200 - $500/mo	OFAC screening, basic reporting, email support
MCP server approach	$5 - $30/mo	Same screening algorithms, AI orchestration, natural language interface

The enterprise platforms include features that large banks need -- case management workflows, team permissions, SOC 2 reports, dedicated support. If you are a 500-person compliance department at a global bank, you probably need those features and should pay for them.

But most fintechs, health plans, and small financial institutions do not need a $3,000/month platform. They need accurate OFAC screening, provider verification, and routing number lookups. They need results they can audit. They need to move fast.

MCP servers deliver the core compliance data at a fraction of the cost because they skip the enterprise wrapper. The AI agent handles the orchestration, formatting, and workflow that you would otherwise pay a platform vendor to build.

The math is not even close for small and mid-size teams. A fintech with 10 compliance checks per day spends maybe $10/month on MCP server API calls. The same volume on an enterprise platform costs $500/month minimum, often with an annual contract.

What MCP servers do not replace

Honest framing: MCP servers are tools, not a complete compliance program.

They do not replace human judgment. A 0.87 match score on an OFAC screening requires a human to review the details and make a disposition decision. The AI surfaces the data; the compliance officer makes the call.

They do not replace policies and procedures. You still need a written BSA/AML program, risk assessments, training records, and documented procedures. MCP servers speed up the execution of those procedures, not the design of them.

They do not generate compliance reports for regulators. You need to build or buy reporting on top of the screening results. The MCP server gives you structured data; turning that into a SAR or CTR filing is a separate step.

They do not provide legal cover. Using an MCP server for OFAC screening does not by itself satisfy your regulatory obligations. Your compliance program needs to be documented, tested, and defensible on its own terms. The tool is one component.

Getting started

Setting up takes two minutes. Add this to your Claude Desktop configuration (claude_desktop_config.json):

{
  "mcpServers": {
    "ofac": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-ofac"]
    },
    "healthcare": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-healthcare"]
    },
    "finance": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-finance"]
    }
  }
}

Restart Claude Desktop. The tools appear in the tools panel. Ask Claude to screen a name, look up an NPI, or convert a currency. No API keys for the free tier, no signup, no procurement process.

For Cursor users, add the same configuration to your MCP settings. The same servers work in any MCP-compatible client.

If you need programmatic access from your own code, all the MCP servers are backed by REST APIs you can call directly:

const OFAC_BASE = 'https://ofac-screening-production.up.railway.app';

const screenCustomer = async (name, country = null) => {
  const body = { name, threshold: 0.85 };
  if (country) {
    body.country = country;
  }

  const response = await fetch(`${OFAC_BASE}/screen`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  });

  const result = await response.json();
  return {
    clear: result.matchCount === 0,
    matches: result.matches || [],
    screenedAt: result.screenedAt,
    listVersion: result.listVersion,
  };
};

The direction this is heading

Today, compliance officers type requests into Claude and review results conversationally. That is already faster than the portal-switching workflow. But the next step is obvious: automated pipelines where MCP tool calls are embedded in your onboarding flow, your payment processing queue, and your provider credentialing system.

The compliance officer shifts from executing screenings to reviewing flagged exceptions. The routine checks -- clear names, valid NPIs, matching routing numbers -- flow through automatically. Human attention focuses where it matters: the ambiguous cases, the judgment calls, the false positive dispositions.

This is not a future prediction. The tools exist today. The MCP servers are live on npm. The AI agents know how to call them. The only question is how quickly your compliance team adopts the new workflow.

Start with one use case. Screen a name. Verify a provider. Look up a code. See how long it takes compared to your current process. The difference speaks for itself.

How to Look Up NDC Drug Codes Programmatically with Node.js

easysolutions906 — Tue, 17 Mar 2026 01:51:05 +0000

How to Look Up NDC Drug Codes Programmatically with Node.js

Every drug product sold in the United States has a National Drug Code. The NDC is the FDA's universal identifier for human drugs -- it appears on every prescription bottle, pharmacy claim, insurance EOB, and formulary file. If you are building a pharmacy system, an EHR, a claims adjudication engine, or a drug interaction checker, you need programmatic access to the NDC directory.

The FDA publishes the full NDC directory as a downloadable zip file. Parsing it, normalizing the formats, and indexing it for fast search is a chore you should not have to repeat. This article covers the NDC format, how to search the directory programmatically, and how to integrate NDC lookups into a Node.js application using both a REST API and an MCP server.

What NDC codes are

A National Drug Code is a 10-digit or 11-digit numeric identifier assigned by the FDA to every drug product listed under the Federal Food, Drug, and Cosmetic Act. The code uniquely identifies three things:

Labeler -- the manufacturer, repackager, or distributor
Product -- the specific drug formulation (strength, dosage form)
Package -- the package size and type

These three segments are separated by dashes, like 0002-1433-80. The labeler is Eli Lilly (0002), the product is a specific formulation (1433), and the package is an 80-count bottle.

The NDC format problem

The NDC format is one of the most frustrating quirks in healthcare data. The FDA defines NDCs as 10 digits, but the three segments can be split in different configurations:

Format	Example	Segments
4-4-2	`0002-1433-80`	4-digit labeler, 4-digit product, 2-digit package
5-3-2	`12345-678-90`	5-digit labeler, 3-digit product, 2-digit package
5-4-1	`12345-6789-0`	5-digit labeler, 4-digit product, 1-digit package

To make things worse, HIPAA transactions require an 11-digit NDC, which means zero-padding one of the segments. A 4-4-2 NDC like 0002-1433-80 becomes 00002-1433-80 in an 11-digit format. Pharmacies, PBMs, and clearinghouses all handle this differently. Some strip dashes. Some zero-pad the wrong segment.

The NDC API normalizes all of this for you. Pass in any format -- with dashes, without dashes, 10-digit, 11-digit -- and it finds the right product.

Looking up a drug by NDC code

When you have an NDC from a claim or prescription and need the drug details:

curl "https://ndc-api-production.up.railway.app/lookup?ndc=0002-1433-80"

{
  "ndc": "0002-1433-80",
  "name": "Prozac",
  "genericName": "Fluoxetine Hydrochloride",
  "ingredients": "FLUOXETINE HYDROCHLORIDE",
  "manufacturer": "Eli Lilly and Company",
  "dosageForm": "CAPSULE",
  "route": "ORAL",
  "strength": "20mg",
  "deaSchedule": null,
  "marketingCategory": "NDA",
  "productType": "HUMAN PRESCRIPTION DRUG"
}

The response includes everything you need for claims processing: brand name, generic name, active ingredients, manufacturer, dosage form, route of administration, strength, and DEA schedule (if it is a controlled substance).

Searching by drug name

Most of the time, you do not have the NDC -- you have a drug name from a prescription or a patient record. Search by name:

curl "https://ndc-api-production.up.railway.app/search?q=metformin&limit=5"

{
  "query": "metformin",
  "count": 5,
  "results": [
    {
      "ndc": "0002-1433-80",
      "name": "Metformin Hydrochloride",
      "genericName": "Metformin Hydrochloride",
      "manufacturer": "Aurobindo Pharma Limited",
      "dosageForm": "TABLET",
      "strength": "500mg",
      "route": "ORAL"
    }
  ]
}

The search is scored by relevance. Exact name matches and generic name matches rank higher than hits on manufacturer or ingredient fields.

Searching by active ingredient

For drug interaction checking, you need to find all products containing a specific compound, regardless of brand name or manufacturer:

curl "https://ndc-api-production.up.railway.app/search?ingredient=acetaminophen&limit=5"

This returns every product in the FDA directory that lists acetaminophen as an active ingredient -- Tylenol, generic acetaminophen, combination products like Percocet, cold medicines, and more. This is essential for interaction screening and duplicate therapy detection.

Searching by manufacturer

For formulary management and supply chain work, search by manufacturer:

curl "https://ndc-api-production.up.railway.app/search?manufacturer=pfizer&limit=10"

Building an NDC lookup into a Node.js application

Here is a practical module for a pharmacy claims system that validates NDC codes and enriches claim records with drug details:

const NDC_BASE = 'https://ndc-api-production.up.railway.app';

const lookupNdc = async (ndc) => {
  const res = await fetch(`${NDC_BASE}/lookup?ndc=${encodeURIComponent(ndc)}`);

  if (!res.ok) {
    const err = await res.json();
    return { valid: false, error: err.error, ndc };
  }

  const drug = await res.json();
  return { valid: true, ...drug };
};

const searchDrugs = async (query, { limit = 25 } = {}) => {
  const params = new URLSearchParams({ q: query, limit: String(limit) });
  const res = await fetch(`${NDC_BASE}/search?${params}`);
  const data = await res.json();
  return data.results;
};

const searchByIngredient = async (ingredient, { limit = 25 } = {}) => {
  const params = new URLSearchParams({ ingredient, limit: String(limit) });
  const res = await fetch(`${NDC_BASE}/search?${params}`);
  const data = await res.json();
  return data.results;
};

Validating NDCs on incoming claims

When pharmacy claims arrive, validate that every NDC maps to a real product before adjudication:

const validateClaimNdcs = async (claims) => {
  const ndcs = claims.map((c) => c.ndc);

  const res = await fetch(`${NDC_BASE}/lookup/batch`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ ndcs }),
  });

  const { results } = await res.json();

  return claims.map((claim, i) => {
    const drug = results[i];
    const hasError = Boolean(drug.error);

    return {
      claimId: claim.id,
      ndc: claim.ndc,
      valid: !hasError,
      drugName: hasError ? null : drug.name,
      genericName: hasError ? null : drug.genericName,
      error: hasError ? drug.error : null,
    };
  });
};

// Validate a batch of incoming claims
const claims = [
  { id: 'CLM-001', ndc: '0002-1433-80' },
  { id: 'CLM-002', ndc: '9999-9999-99' },
  { id: 'CLM-003', ndc: '0069-3150-83' },
];

const validated = await validateClaimNdcs(claims);
// [
//   { claimId: 'CLM-001', valid: true, drugName: 'Prozac', ... },
//   { claimId: 'CLM-002', valid: false, error: 'Not found', ... },
//   { claimId: 'CLM-003', valid: true, drugName: 'Zoloft', ... },
// ]

Building a drug autocomplete for a prescriber UI

let timeout;

const onDrugSearch = (inputValue, renderResults) => {
  clearTimeout(timeout);
  timeout = setTimeout(async () => {
    if (inputValue.length < 2) {
      renderResults([]);
      return;
    }

    const drugs = await searchDrugs(inputValue, { limit: 10 });
    const options = drugs.map((d) => ({
      ndc: d.ndc,
      label: `${d.name} ${d.strength} (${d.dosageForm})`,
      generic: d.genericName,
      manufacturer: d.manufacturer,
    }));

    renderResults(options);
  }, 300);
};

Checking for duplicate ingredients

Before filling a new prescription, check whether the patient is already taking a drug with the same active ingredient:

const checkDuplicateTherapy = async (newNdc, currentMedications) => {
  const newDrug = await lookupNdc(newNdc);

  if (!newDrug.valid) {
    return { error: `Unknown NDC: ${newNdc}` };
  }

  const newIngredients = newDrug.ingredients.toLowerCase().split(';').map((s) => s.trim());

  const duplicates = currentMedications.filter((med) => {
    const medIngredients = med.ingredients.toLowerCase().split(';').map((s) => s.trim());
    return newIngredients.some((ni) => medIngredients.includes(ni));
  });

  return {
    newDrug: newDrug.name,
    ingredients: newIngredients,
    duplicates: duplicates.map((d) => ({
      name: d.name,
      ndc: d.ndc,
      sharedIngredient: newIngredients.find((ni) =>
        d.ingredients.toLowerCase().includes(ni)
      ),
    })),
    hasDuplicate: duplicates.length > 0,
  };
};

Using the MCP server for NDC lookups

The @easysolutions906/mcp-healthcare MCP server includes three NDC tools alongside ICD-10, NPI, and DEA tools -- 10 tools total. The NDC tools are:

ndc_lookup -- Look up a drug by its NDC code
ndc_search -- Search drugs by name, generic name, or manufacturer
ndc_search_ingredient -- Search drugs by active ingredient

Add the server to your Claude Desktop configuration:

{
  "mcpServers": {
    "healthcare": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-healthcare"]
    }
  }
}

Then ask Claude questions like:

"What drug has NDC 0002-1433-80?"
"Find all NDC codes for metformin 500mg tablets"
"What products contain acetaminophen and hydrocodone?"
"Look up the manufacturer for lisinopril NDC 0069-3150-83"

The MCP server searches the same full FDA dataset. This is useful during development when you need to verify test NDCs, explore the data model, or check whether a specific formulation is in the directory -- without leaving your editor.

Common use cases

Claims adjudication

Every pharmacy claim includes an NDC. Before paying the claim, validate that the NDC exists, check the drug's generic equivalent for MAC pricing, and verify it is on the plan's formulary. The batch lookup endpoint handles up to 50 NDCs per request.

Drug interaction checking

Search by ingredient to find all formulations containing a compound. Cross-reference a patient's active medications to flag duplicate therapy, contraindicated combinations, or therapeutic overlaps. The ingredient search is the foundation of this workflow.

Formulary management

PBMs and health plans maintain drug formularies -- lists of covered medications organized by tier. The manufacturer search helps identify all products from a specific labeler when negotiating rebate contracts or updating formulary tiers after a generic launch.

Inventory and supply chain

Hospital pharmacies and mail-order pharmacies track inventory by NDC. The lookup endpoint maps an NDC to its full product details for label printing, barcode scanning, and automated dispensing cabinet integration.

Controlled substance tracking

The /schedule/:schedule endpoint lists drugs by DEA schedule (CII through CV). This supports prescription drug monitoring program (PDMP) integrations and controlled substance inventory audits:

curl "https://ndc-api-production.up.railway.app/schedule/CII?limit=10"

FDA data source and update frequency

The NDC directory is sourced directly from the FDA's NDC text file download at https://www.accessdata.fda.gov/cder/ndctext.zip. The FDA updates this file weekly as new drug products are approved, reformulated, or discontinued.

The API embeds the full dataset locally for fast searches -- no upstream API dependency, no rate limits from the FDA. Hit the /data-info endpoint to check the current data build date and record count:

curl "https://ndc-api-production.up.railway.app/data-info"

{
  "source": "FDA NDC Directory",
  "url": "https://www.accessdata.fda.gov/cder/ndctext.zip",
  "recordCount": 137000,
  "builtAt": "2026-03-15T00:00:00.000Z",
  "updateFrequency": "weekly"
}

Getting started

Look up by NDC: GET /lookup?ndc=0002-1433-80
Search by name: GET /search?q=metformin&limit=10
Search by ingredient: GET /search?ingredient=acetaminophen&limit=10
Search by manufacturer: GET /search?manufacturer=pfizer&limit=10
Controlled substances: GET /schedule/CII?limit=25
Batch lookup: POST /lookup/batch with {"ndcs": [...]}
MCP server: npx @easysolutions906/mcp-healthcare

No API key required for the REST endpoints. The dataset is public FDA data, and the API is free to use.

How to Validate DEA Numbers Programmatically: The Check Digit Algorithm Explained

easysolutions906 — Tue, 17 Mar 2026 01:43:37 +0000

How to Validate DEA Numbers Programmatically: The Check Digit Algorithm Explained

Every prescriber of controlled substances in the United States must hold a Drug Enforcement Administration (DEA) registration number. This number appears on every controlled substance prescription, in every pharmacy dispensing system, in credentialing databases, and in electronic prescribing of controlled substances (EPCS) workflows. If you are building software that touches prescribing, pharmacy operations, or provider credentialing, you need to validate DEA numbers.

The good news: DEA numbers contain a built-in check digit that lets you verify format correctness without calling any external service. This article breaks down the DEA number format, walks through the check digit algorithm step by step, and shows how to implement validation in JavaScript.

What a DEA number looks like

A DEA number is exactly 9 characters: 2 letters followed by 7 digits.

AB1234563
^^-------
||  |   |
||  |   └── check digit (1 digit)
||  └────── registration number (6 digits)
|└───────── last name initial of the registrant
└────────── registrant type code

The first letter: registrant type

The first letter identifies the type of DEA registrant:

Letter	Registrant Type
A, B	Dispenser (hospitals, pharmacies, practitioners)
C, D, E	Manufacturer / Schedule I researcher
F	Manufacturer
G, H, J, K	Distributor
L	Reverse distributor
M	Mid-level practitioner (NP, PA, optometrist)
P, R, S, T	Narcotic treatment program
X	Suboxone/Subutex prescriber (DATA 2000 waiver)

Most DEA numbers you encounter in clinical software start with A, B, or M. If you see an F or G prefix, that is a manufacturer or distributor, not a prescriber.

The second letter: last name initial

The second character is the first letter of the registrant's last name. For a physician named Dr. Smith, the DEA number starts with AS, BS, or MS. This gives you a quick sanity check: if a provider's last name starts with "J" but their DEA number's second letter is "R", something is wrong.

The last 7 digits: registration number + check digit

The first 6 digits are the registration number assigned by the DEA. The 7th digit is a check digit computed from the preceding 6 digits using a Luhn-variant algorithm.

The check digit algorithm

The DEA check digit algorithm is a weighted sum modulo 10. Here is how it works, step by step.

Given a DEA number AB1234563:

Step 1: Extract the 7 digits: 1 2 3 4 5 6 3

Step 2: Sum the digits in odd positions (1st, 3rd, 5th):

1 + 3 + 5 = 9

Step 3: Sum the digits in even positions (2nd, 4th, 6th):

2 + 4 + 6 = 12

Step 4: Multiply the even sum by 2:

12 * 2 = 24

Step 5: Add the odd sum and the doubled even sum:

9 + 24 = 33

Step 6: The check digit is the last digit of the total:

33 % 10 = 3

Step 7: Compare. The 7th digit of the DEA number is 3, and the computed check digit is 3. They match, so the number passes the check digit validation.

If they do not match, the DEA number is structurally invalid. It was either mistyped, fabricated, or corrupted during data entry.

Implementing validation from scratch

Here is a complete DEA validator in JavaScript. It checks format, extracts the registrant type, validates the check digit, and optionally verifies the last name initial.

const REGISTRANT_TYPES = {
  A: 'Dispenser (Hospitals, Pharmacies, Practitioners)',
  B: 'Dispenser (Hospitals, Pharmacies, Practitioners)',
  C: 'Manufacturer (Schedule I Researcher)',
  D: 'Manufacturer (Schedule I Researcher)',
  E: 'Manufacturer (Schedule I Researcher)',
  F: 'Manufacturer',
  G: 'Distributor',
  H: 'Distributor',
  J: 'Distributor',
  K: 'Distributor',
  L: 'Reverse Distributor',
  M: 'Mid-Level Practitioner',
  P: 'Narcotic Treatment Program',
  R: 'Narcotic Treatment Program',
  S: 'Narcotic Treatment Program',
  T: 'Narcotic Treatment Program',
  X: 'Suboxone/Subutex Prescriber',
};

const computeCheckDigit = (digits) => {
  const oddSum = digits[0] + digits[2] + digits[4];
  const evenSum = digits[1] + digits[3] + digits[5];
  return (oddSum + evenSum * 2) % 10;
};

const validateDea = (raw, lastName = null) => {
  const dea = (raw || '').trim().toUpperCase();
  const errors = [];

  if (dea.length !== 9) {
    errors.push(`DEA number must be exactly 9 characters, got ${dea.length}`);
  }

  const letters = dea.slice(0, 2);
  const digitPart = dea.slice(2);

  if (!/^[A-Z]{2}$/.test(letters)) {
    errors.push('First two characters must be letters');
  }

  if (!/^\d{7}$/.test(digitPart)) {
    errors.push('Last seven characters must be digits');
  }

  // If format is wrong, return early
  if (errors.length > 0) {
    return { valid: false, dea, errors };
  }

  const typeCode = letters[0];
  const nameInitial = letters[1];
  const registrantType = REGISTRANT_TYPES[typeCode] || 'Unknown';

  // Check digit validation
  const digits = digitPart.split('').map(Number);
  const expected = computeCheckDigit(digits.slice(0, 6));
  const actual = digits[6];

  if (expected !== actual) {
    errors.push(`Check digit mismatch: expected ${expected}, got ${actual}`);
  }

  // Optional last name cross-check
  if (lastName) {
    const lastNameInitial = lastName.trim()[0]?.toUpperCase();
    if (lastNameInitial && lastNameInitial !== nameInitial) {
      errors.push(
        `Name initial mismatch: DEA has '${nameInitial}', last name starts with '${lastNameInitial}'`
      );
    }
  }

  return {
    valid: errors.length === 0,
    dea,
    registrantType,
    nameInitial,
    checkDigit: actual,
    errors,
  };
};

// Valid DEA number
console.log(validateDea('AB1234563'));
// { valid: true, dea: 'AB1234563', registrantType: 'Dispenser ...', ... }

// Invalid check digit
console.log(validateDea('AB1234567'));
// { valid: false, ..., errors: ['Check digit mismatch: expected 3, got 7'] }

// Cross-check with provider last name
console.log(validateDea('AB1234563', 'Baker'));
// { valid: true, ... } — second letter 'B' matches last name 'Baker'

console.log(validateDea('AB1234563', 'Smith'));
// { valid: false, ..., errors: ["Name initial mismatch: DEA has 'B', last name starts with 'S'"] }

The computeCheckDigit function is the core. It is three lines. Everything else is format validation and error reporting.

Using the MCP Healthcare server

If you do not want to maintain your own validation code, the @easysolutions906/mcp-healthcare npm package includes DEA validation as one of its 10 tools, alongside NPI lookup, ICD-10 search, and NDC drug lookup.

In Claude Desktop or Cursor

Add the server to your claude_desktop_config.json:

{
  "mcpServers": {
    "healthcare": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-healthcare"]
    }
  }
}

Then ask Claude: "Validate DEA number AB1234563" and it calls the dea_validate tool, returning the validity, registrant type, check digit, and any errors.

You can also ask "Generate a test DEA number for a provider named Smith" and it calls the dea_generate_test tool to produce a structurally valid DEA number for development use.

Programmatic usage

You can also use the MCP server as a library in Node.js. The validation tool accepts a DEA number and returns a structured result:

import { validate, generateTest } from '@easysolutions906/mcp-healthcare/src/tools/dea.js';

// Validate a real DEA number
const result = validate('AB1234563');
console.log(result);
// {
//   valid: true,
//   dea: 'AB1234563',
//   checkDigit: 3,
//   registrantType: 'Dispenser (Hospitals, Pharmacies, Practitioners)',
//   errors: []
// }

// Generate a test DEA number for development
const testDea = generateTest('Johnson');
console.log(testDea);
// {
//   dea: 'AJ7382910',
//   disclaimer: 'This is a randomly generated test DEA number ...',
//   registrantType: 'Dispenser (Hospitals, Pharmacies, Practitioners)'
// }

The generateTest function is useful when you need structurally valid DEA numbers for unit tests, seed data, or staging environments without using real registrations.

When you need DEA validation

E-prescribing (EPCS)

The DEA requires that electronic prescribing systems for controlled substances validate the prescriber's DEA number before transmitting a prescription. EPCS certification under 21 CFR Part 1311 mandates identity proofing and two-factor authentication, but the first layer of defense is structural validation: reject obviously malformed DEA numbers before they enter the workflow.

Pharmacy dispensing

When a pharmacy receives a controlled substance prescription, the dispensing system checks the prescriber's DEA number. A failed check digit means the prescription cannot be filled until the number is verified. Catching this at data entry saves a phone call to the prescriber's office.

Provider credentialing

Credentialing systems verify that a provider's DEA registration is active and matches their identity. The second-letter check against the provider's last name is a quick cross-reference that catches data entry errors and mismatched records. It is not definitive (multiple providers share initials), but it filters out obvious mismatches.

Claims and billing

Controlled substance claims require the prescriber's DEA number. Payers reject claims with invalid DEA numbers. Validating the format before submission avoids denials and resubmission delays.

Clinical data integration

If you are ingesting provider data from multiple sources (EHR, credentialing vendor, state PDMP), DEA number validation helps you identify dirty records. A DEA number that fails the check digit test is a data quality signal: either the source record is wrong, or the data was corrupted during integration.

Limitations of check digit validation

The check digit algorithm tells you whether a DEA number is structurally valid. It does not tell you whether it is:

Currently active. DEA registrations expire and can be revoked. Check digit validation cannot detect an expired or surrendered registration.
Assigned to the claimed provider. A structurally valid DEA number could belong to a different provider. Cross-checking the second letter against the last name helps, but is not conclusive.
Authorized for the relevant schedules. A DEA registration may be limited to specific controlled substance schedules. The number format does not encode this information.

For production systems that need to verify active status, the DEA's NTIS database or state Prescription Drug Monitoring Programs (PDMPs) provide authoritative lookups. But check digit validation is the first gate: fast, offline, and catches the majority of data entry errors.

Get started

Roll your own: The algorithm is 3 lines of code. Copy the computeCheckDigit function above and build validation into your existing stack.
MCP server: npx @easysolutions906/mcp-healthcare adds DEA validation (plus ICD-10, NPI, and NDC tools) to Claude Desktop or Cursor.
npm package: npm install @easysolutions906/mcp-healthcare

DEA validation is one of those rare problems where the algorithm is simple enough to implement from scratch in minutes, but important enough that getting it wrong causes real downstream failures. Whether you embed the check digit logic directly or use a tool that handles it for you, validate early and validate always.

OFAC Sanctions Screening for Crypto and DeFi: A Developer's Guide

easysolutions906 — Tue, 17 Mar 2026 01:43:01 +0000

OFAC Sanctions Screening for Crypto and DeFi: A Developer's Guide

If you build on crypto rails, OFAC compliance is not optional. The Treasury Department has made this clear through enforcement actions, guidance documents, and the Tornado Cash precedent. This guide covers what you need to screen, how to screen it, and working code to integrate sanctions screening into a crypto or DeFi application.

Why Crypto Platforms Must Screen

Three things changed the compliance landscape for crypto:

FinCEN guidance (2019). FinCEN clarified that virtual asset service providers (VASPs) -- exchanges, custodial wallet providers, and money transmitters dealing in crypto -- are money services businesses under the Bank Secrecy Act. That means the same OFAC obligations that apply to banks apply to you. If you facilitate a transaction involving a sanctioned person, entity, or wallet address, you are liable.

OFAC's wallet address designations. Starting in 2018, OFAC began adding cryptocurrency wallet addresses directly to the SDN list. These are not just names anymore. A sanctioned entity might have five Bitcoin addresses and three Ethereum addresses listed alongside their traditional identifiers. Your screening must cover both names and addresses.

Tornado Cash (August 2022). OFAC designated Tornado Cash smart contract addresses, marking the first time a decentralized protocol was sanctioned. The message was explicit: interacting with sanctioned addresses -- even through smart contracts -- can violate sanctions. Developers who integrated Tornado Cash had to remove it. Users who interacted with those addresses after designation faced potential liability. Courts have debated the scope, but the enforcement posture is clear.

The bottom line: if your platform touches fiat on-ramps, custodial wallets, KYC/KYB flows, or transaction routing, you screen. If you are building a DEX aggregator or bridge that routes through known sanctioned contracts, you screen. The cost of not screening is asset seizure, fines up to $20 million per violation, and criminal referral.

What to Screen

Crypto platforms need to screen at three points:

Customer onboarding. Screen the customer's name, aliases, and date of birth against the SDN list before account creation. This is identical to traditional finance KYC.
Wallet addresses. Screen deposit and withdrawal addresses against OFAC-designated wallet addresses. The SDN list includes addresses for Bitcoin, Ethereum, Litecoin, XRP, and others under the "Digital Currency Address" identifier type.
Transaction counterparties. For each transaction, screen the counterparty name and wallet address. If a user sends funds to or receives funds from a sanctioned address, you need to catch it.

Screening Names Against the SDN List

The @easysolutions906/mcp-ofac package embeds the full SDN list and provides fuzzy matching out of the box. Here is how to screen a customer name during onboarding:

const OFAC_BASE_URL = 'https://ofac-screening-production.up.railway.app';
const OFAC_API_KEY = process.env.OFAC_API_KEY;

const screenCustomer = async (name, options = {}) => {
  const {
    type = 'Individual',
    country = null,
    dateOfBirth = null,
    threshold = 0.85,
  } = options;

  const body = { name, type, threshold };
  if (country) { body.country = country; }
  if (dateOfBirth) { body.dateOfBirth = dateOfBirth; }

  const response = await fetch(`${OFAC_BASE_URL}/screen`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': OFAC_API_KEY,
    },
    body: JSON.stringify(body),
  });

  if (!response.ok) {
    const error = await response.json().catch(() => ({}));
    throw new Error(
      `OFAC screening failed: ${response.status} ${error.error || response.statusText}`,
    );
  }

  return response.json();
};

Usage in a crypto exchange onboarding flow:

const onboardCryptoUser = async (user) => {
  const screening = await screenCustomer(user.fullName, {
    type: 'Individual',
    country: user.country,
    dateOfBirth: user.dob,
  });

  if (screening.matchCount > 0) {
    const topScore = screening.matches[0].score;

    if (topScore >= 0.95) {
      // Near-certain match -- block account creation, escalate
      return { status: 'BLOCKED', reason: 'SDN match', screening };
    }

    // Possible match -- allow provisional access, flag for review
    return { status: 'PENDING_REVIEW', screening };
  }

  return { status: 'CLEAR', screening };
};

Screening Wallet Addresses

Wallet addresses on the SDN list are exact strings. There is no fuzzy matching for addresses -- a Bitcoin address either matches or it does not. But you still need to normalize them (case-insensitive for Ethereum, exact for Bitcoin) and check against the full set of designated addresses.

The OFAC API search endpoint lets you query by identifier type:

const screenWalletAddress = async (address, currency = 'ETH') => {
  const response = await fetch(`${OFAC_BASE_URL}/search`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': OFAC_API_KEY,
    },
    body: JSON.stringify({
      query: address,
      idType: 'Digital Currency Address',
    }),
  });

  if (!response.ok) {
    throw new Error(`Wallet screening failed: ${response.status}`);
  }

  const data = await response.json();

  return {
    address,
    currency,
    isSanctioned: data.results.length > 0,
    matches: data.results,
    screenedAt: data.screenedAt,
    listVersion: data.listVersion,
  };
};

Integrate this into your deposit and withdrawal flows:

const processWithdrawal = async (userId, toAddress, amount, currency) => {
  // Screen the destination address before sending
  const walletScreen = await screenWalletAddress(toAddress, currency);

  if (walletScreen.isSanctioned) {
    await logBlockedTransaction(userId, toAddress, amount, walletScreen);
    await notifyComplianceTeam({
      type: 'BLOCKED_WITHDRAWAL',
      userId,
      address: toAddress,
      matches: walletScreen.matches,
    });
    throw new Error('Transaction blocked: sanctioned address');
  }

  // Address is clear -- proceed with withdrawal
  await recordScreeningResult(userId, walletScreen);
  return executeWithdrawal(userId, toAddress, amount, currency);
};

const processDeposit = async (userId, fromAddress, amount, currency) => {
  // Screen the source address after receiving
  const walletScreen = await screenWalletAddress(fromAddress, currency);

  if (walletScreen.isSanctioned) {
    // Freeze the deposited funds and alert compliance
    await freezeFunds(userId, amount, currency);
    await notifyComplianceTeam({
      type: 'SANCTIONED_DEPOSIT',
      userId,
      address: fromAddress,
      amount,
      matches: walletScreen.matches,
    });
    return { status: 'FROZEN', screening: walletScreen };
  }

  await recordScreeningResult(userId, walletScreen);
  return { status: 'CREDITED', screening: walletScreen };
};

Key difference from traditional finance: for withdrawals you block before sending. For deposits you freeze after receiving, because you cannot prevent someone from sending crypto to your address. Both events require logging and compliance notification.

Batch Screening for Onboarding Flows

When you first integrate OFAC screening into an existing platform, you need to screen your entire user base and every stored wallet address. The batch endpoint handles up to 100 names per request:

const batchScreenUsers = async (users) => {
  const BATCH_SIZE = 100;
  const flagged = [];

  for (let i = 0; i < users.length; i += BATCH_SIZE) {
    const batch = users.slice(i, i + BATCH_SIZE);
    const names = batch.map((u) => ({
      name: u.fullName,
      type: 'Individual',
      country: u.country || null,
    }));

    const response = await fetch(`${OFAC_BASE_URL}/screen/batch`, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'x-api-key': OFAC_API_KEY,
      },
      body: JSON.stringify({ names, threshold: 0.85 }),
    });

    const data = await response.json();

    data.results.forEach((result, idx) => {
      if (result.matchCount > 0) {
        flagged.push({
          user: batch[idx],
          matches: result.matches,
          listVersion: data.listVersion,
          screenedAt: data.screenedAt,
        });
      }
    });

    console.log(
      `Screened ${Math.min(i + BATCH_SIZE, users.length)}/${users.length} users`,
    );
  }

  return flagged;
};

For wallet addresses, screen them separately since address matching is exact and does not use the same fuzzy logic:

const batchScreenAddresses = async (addresses) => {
  const flagged = [];

  // Wallet addresses must be screened individually since they are
  // identifier lookups, not fuzzy name matches
  const screenPromises = addresses.map(async ({ address, currency, userId }) => {
    const result = await screenWalletAddress(address, currency);
    if (result.isSanctioned) {
      flagged.push({ userId, address, currency, ...result });
    }
  });

  // Process in controlled concurrency to avoid rate limits
  const CONCURRENCY = 10;
  for (let i = 0; i < screenPromises.length; i += CONCURRENCY) {
    await Promise.all(screenPromises.slice(i, i + CONCURRENCY));
  }

  return flagged;
};

Keeping Up with SDN List Updates

OFAC updates the SDN list multiple times per week. New wallet addresses get added when Treasury designates crypto-linked actors. Your screening is only as good as the list version you are checking against.

Set up a daily job that checks for list updates and triggers re-screening:

let lastKnownListVersion = null;

const checkForSDNUpdate = async () => {
  const response = await fetch(`${OFAC_BASE_URL}/data-info`);
  const info = await response.json();

  if (lastKnownListVersion && info.publishDate !== lastKnownListVersion) {
    console.log(
      `SDN list updated: ${lastKnownListVersion} -> ${info.publishDate}`,
    );
    return { updated: true, newVersion: info.publishDate };
  }

  lastKnownListVersion = info.publishDate;
  return { updated: false, currentVersion: info.publishDate };
};

const dailyComplianceScan = async () => {
  const { updated, newVersion } = await checkForSDNUpdate();

  if (!updated) {
    console.log('SDN list unchanged, skipping re-screen');
    return;
  }

  // Re-screen all active users
  const users = await loadAllActiveUsers();
  const flaggedUsers = await batchScreenUsers(users);

  // Re-screen all stored wallet addresses
  const addresses = await loadAllStoredAddresses();
  const flaggedAddresses = await batchScreenAddresses(addresses);

  if (flaggedUsers.length > 0 || flaggedAddresses.length > 0) {
    await notifyComplianceTeam({
      listVersion: newVersion,
      flaggedUsers,
      flaggedAddresses,
      totalUsersScreened: users.length,
      totalAddressesScreened: addresses.length,
    });
  }

  console.log(
    `Re-screen complete. ${flaggedUsers.length} users flagged, `
    + `${flaggedAddresses.length} addresses flagged.`,
  );
};

In production, run this with a proper job scheduler (cron, Bull, or your cloud provider's scheduled tasks). For high-risk platforms -- those dealing in privacy coins or cross-chain bridges -- run it every six hours instead of daily.

Storing Screening Records

Every screening result must be stored for at least five years per BSA requirements. For crypto platforms, the audit record needs both name and address screening data:

const createAuditRecord = (userId, screeningType, result) => ({
  userId,
  screeningType,       // 'NAME', 'WALLET_ADDRESS', or 'TRANSACTION'
  screenedValue: result.name || result.address,
  screenedAt: result.screenedAt,
  listVersion: result.listVersion,
  matchCount: result.matchCount || (result.isSanctioned ? 1 : 0),
  decision: result.matchCount > 0 || result.isSanctioned ? 'FLAGGED' : 'CLEAR',
  matches: result.matches || [],
  reviewedBy: null,
  reviewedAt: null,
  reviewDecision: null,
});

Store these in an append-only table. No UPDATE or DELETE permissions for application users. When a FinCEN examiner or state regulator asks for your screening records for a specific user or date range, you need to produce them instantly.

Using the MCP Server for Manual Reviews

For compliance officers who need to investigate flagged transactions manually, the MCP server integrates directly into Claude Desktop or Cursor:

{
  "mcpServers": {
    "ofac": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-ofac"]
    }
  }
}

A compliance officer can then ask Claude:

Screen the name "Lazarus Group" and check if Ethereum address 0x098B716B8Aaf21512996dC57EB0615e2383E2f96 appears on the SDN list.

Claude calls the appropriate tools and returns formatted results inline. This is faster than switching between a screening portal and case management system, and the conversation log serves as a reviewable audit trail.

Architecture Recap

A production-ready crypto compliance pipeline has four layers:

Real-time screening. Every customer onboarding, every deposit address, every withdrawal address gets screened synchronously. Block or freeze if a match is found.
Batch re-screening. When the SDN list updates, re-screen your entire user and address database. New designations can flag previously clear customers.
Audit storage. Every screening result is stored immutably with the list version and timestamp. Retention is five years minimum.
Human review. Matches are never auto-rejected without review. A compliance officer evaluates flagged results and documents their decision.

The API handles layers one and two. Your database handles layer three. Your compliance team handles layer four.

Getting Started

Get an API key at ofac-screening-production.up.railway.app
Add name screening to your KYC onboarding flow
Add wallet address screening to your deposit and withdrawal handlers
Set up daily re-screening with the /data-info endpoint to detect list updates
Build the audit trail -- store every result with screenedAt and listVersion

The OFAC API documentation is available at the base URL. The /data-info endpoint returns the current SDN list publish date and record count so you always know how current your screening data is.

Crypto moves fast. OFAC enforcement moves faster. Screen everything, store everything, review everything.

What Are MCP Servers and Why Every Developer Should Care in 2026

easysolutions906 — Tue, 17 Mar 2026 01:38:34 +0000

What Are MCP Servers and Why Every Developer Should Care in 2026

You have probably seen "MCP" mentioned in developer channels, release notes, or conference talks. Maybe you skimmed the spec page and moved on. This article is the practical version: what MCP actually is, how servers work, real examples you can run today, and a quick start config that connects Claude to four tools in under five minutes.

What is the Model Context Protocol

The Model Context Protocol (MCP) is an open standard created by Anthropic that defines how AI assistants discover and call external tools. Before MCP, every AI integration was custom. You wrote a plugin for ChatGPT, a different plugin for Claude, a different one for Cursor, and none of them shared a common interface. MCP fixes that.

An MCP server is a lightweight process that exposes capabilities to any MCP-compatible client. The protocol defines three types of capabilities:

Tools -- functions the AI can call with typed parameters. "Screen this name against OFAC" or "Look up ICD-10 code E11.9" are tool calls.
Resources -- data the AI can read. A database schema, a configuration file, a dataset summary.
Prompts -- reusable prompt templates that guide the AI through specific workflows.

Tools are the most common. Most MCP servers expose a handful of tools that do one thing well.

How it works under the hood

When you start an MCP-compatible client like Claude Desktop, it reads your configuration file, launches each MCP server as a child process, and asks it: "What tools do you have?" The server responds with a list of tool names, descriptions, and parameter schemas. The client registers those tools so the AI model can call them during a conversation.

The flow looks like this:

User asks Claude a question
Claude determines it needs external data
Claude calls the appropriate MCP tool with typed parameters
The MCP server executes the tool (database query, API call, algorithm, file read)
The server returns structured results to Claude
Claude synthesizes the results into a natural language response

The user never sees the tool call directly. They ask a question in plain English and get back an answer that incorporates live data.

Real examples

Abstract explanations only go so far. Here are three real workflows using MCP servers that are available today.

Example 1: OFAC sanctions screening

A compliance officer types into Claude Desktop:

Screen "National Bank of Iran" against the OFAC sanctions list.

Claude calls the ofac_screen tool from @easysolutions906/mcp-ofac. The server loads the full SDN list (embedded locally, no external API call), runs fuzzy matching with Jaro-Winkler similarity and phonetic matching, and returns:

Found 3 potential matches:

1. BANK MELLI IRAN (Score: 0.92)
   - Type: Entity
   - Programs: IRAN, NPWMD
   - Addresses: Tehran, Iran

2. NATIONAL IRANIAN OIL COMPANY (Score: 0.78)
   - Type: Entity
   - Programs: IRAN

List version: 03/13/2026
Screened at: 2026-03-16T10:15:22.441Z

No browser tab. No copy-paste. The compliance officer can follow up conversationally: "Tell me more about the first match" or "Screen these five additional names."

Example 2: ICD-10 code lookup for medical billing

A medical coder asks Claude:

What is the ICD-10 code for type 2 diabetes with diabetic retinopathy?

Claude calls icd10_search from @easysolutions906/mcp-healthcare and returns the most specific billable codes:

E11.319 - Type 2 diabetes mellitus with unspecified diabetic retinopathy without macular edema
E11.311 - Type 2 diabetes mellitus with unspecified diabetic retinopathy with macular edema
E11.3211 - Type 2 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema, right eye

The coder picks the right code without leaving their workflow.

Example 3: Bank routing number validation

A fintech developer asks Claude:

Is routing number 021000021 valid? What bank is it?

Claude calls routing_lookup from @easysolutions906/mcp-routing and returns:

Routing Number: 021000021
Bank: JPMORGAN CHASE BANK, NA
City: TAMPA
State: FL
Status: Active

Every ACH integration needs this. Having it available inside the AI assistant means one less browser tab during development.

How to install MCP servers

MCP servers work with any MCP-compatible client. The two most common are Claude Desktop and Cursor.

Claude Desktop

Find your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add MCP servers to the mcpServers object:

{
  "mcpServers": {
    "ofac": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-ofac"]
    }
  }
}

Restart Claude Desktop. The tools appear in the tools panel immediately.

Cursor

Open Cursor settings, navigate to the MCP section, and add the same configuration. Cursor uses the same command + args format.

Claude Code (CLI)

If you use Claude Code in the terminal, add MCP servers to your project's .mcp.json:

{
  "mcpServers": {
    "ofac": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-ofac"]
    }
  }
}

Claude Code discovers the file automatically on startup.

Quick start: four MCP servers in one config

Here is a configuration that gives Claude access to healthcare data, OFAC sanctions screening, finance tools, and web utilities -- 30+ tools total:

{
  "mcpServers": {
    "healthcare": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-healthcare"]
    },
    "ofac": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-ofac"]
    },
    "finance": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-finance"]
    },
    "webtools": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mcp-webtools"]
    }
  }
}

What you get:

Server	Tools	Examples
`mcp-healthcare`	10	ICD-10 lookup, NPI provider search, NDC drug search, DEA validation
`mcp-ofac`	5	Sanctions screening, SDN search, entity details, program list
`mcp-finance`	4	Currency conversion, exchange rates, historical rates
`mcp-webtools`	11	Email validation, IP geolocation, URL metadata, sentiment analysis, QR codes

Paste that JSON into your config file, restart your client, and all 30 tools are live.

Why this matters for developers

You stop building one-off integrations

Before MCP, adding AI tool-use to an application meant writing custom function schemas, handling tool dispatch, parsing results, and managing conversation state. Each client (ChatGPT, Claude, custom agent) needed its own integration code. MCP standardizes all of it. Write one server, it works everywhere.

Your tools compose automatically

MCP servers are independent processes that a single client orchestrates. When a user asks a question that touches healthcare data AND sanctions screening AND currency conversion, the AI calls tools from three different servers in the same conversation. You do not need to build a mega-API that does everything. Small, focused servers compose naturally.

Distribution is built in

An MCP server published to npm is instantly installable by anyone with npx. No API keys for the free tier, no deployment, no infrastructure. The server runs locally on the user's machine. For paid tiers, Stripe billing handles the rest.

The ecosystem is growing fast

In early 2026, the MCP ecosystem has hundreds of servers covering databases, APIs, file systems, cloud providers, and domain-specific tools. Anthropic, Microsoft, and multiple open-source teams are building MCP-compatible clients. If you build a tool today as an MCP server, it works with Claude Desktop, Cursor, Claude Code, and every future client that implements the protocol.

Building your own MCP server

If you have an API, a dataset, or an algorithm that developers would find useful, wrapping it as an MCP server is straightforward. The official SDK (@modelcontextprotocol/sdk) handles the protocol layer. You define tools with their parameters and implement the handler functions:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({
  name: 'my-tool',
  version: '1.0.0',
});

server.tool(
  'lookup_thing',
  'Look up a thing by ID',
  { id: z.string().describe('The thing ID to look up') },
  async ({ id }) => {
    const result = doLookup(id);
    return {
      content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Publish to npm, add the npx config snippet to your README, and anyone can use it.

Getting started

Pick a client: Claude Desktop, Cursor, or Claude Code
Copy the quick start config JSON above into your config file
Restart the client
Try a prompt: "Screen the name Vladimir Petrov against the OFAC sanctions list" or "What is ICD-10 code J06.9?"
Browse available servers at mcp.so or search npm for @easysolutions906

MCP is the standard interface between AI assistants and external tools. The protocol is open, the SDK is free, and the ecosystem is growing. If you are building developer tools in 2026, MCP is how your users will access them.

Managing Mirth Connect with AI Agents: An MCP Server for Healthcare Integration Engines

easysolutions906 — Mon, 16 Mar 2026 21:42:36 +0000

Managing Mirth Connect with AI Agents: An MCP Server for Healthcare Integration Engines

Mirth Connect (NextGen Connect) is the most widely deployed open-source healthcare integration engine. It moves HL7 messages between EHRs, labs, pharmacies, imaging systems, and billing platforms. A typical hospital runs dozens or hundreds of Mirth channels, each with its own source connector, transformer scripts, filters, and destinations. Managing them means reading XML exports, writing Rhino-compatible JavaScript, debugging cryptic error messages, and reviewing channel configurations before promoting them across environments.

All of this is tedious, detail-oriented work. It is also exactly the kind of work that AI agents handle well -- if you give them the right tools.

The Mirth Connect MCP server exposes 18 tools that let AI assistants parse, analyze, generate, and debug Mirth channels. This article walks through what the tools do and how to use them in practice.

The 18 tools

Tool	Description
`mirth_parse_channel`	Parse a channel XML export into structured JSON
`mirth_analyze_channel`	Lint a channel for hardcoded IPs, SQL injection, missing error handling, Rhino issues
`mirth_explain_channel`	Generate a plain-English description of what a channel does
`mirth_generate_transformer`	Generate a transformer step in Rhino-compatible JavaScript
`mirth_generate_filter`	Generate a filter step (message type, field value, test patient exclusion)
`mirth_generate_channel`	Generate a complete importable channel XML
`mirth_map_fields`	Generate HL7 field mapping code (PID-5-1 to patient_last_name)
`mirth_generate_code_template`	Generate a code template using the IIFE pattern
`mirth_debug_error`	Explain a Mirth error message and suggest fixes
`mirth_validate_js`	Validate JavaScript for Rhino compatibility across Mirth versions
`mirth_diff_channels`	Compare two channel XMLs and show what changed
`mirth_migration_guide`	Generate a migration guide for upgrading channels between Mirth versions
`mirth_extract_sql`	Extract all SQL queries from a channel and flag injection risks
`mirth_dependency_map`	Map dependencies between channels (Channel Writer/Reader, router.routeMessage)
`mirth_generate_deploy_script`	Generate a bash deploy script for CI/CD pipelines
`mirth_convert_to_code_template`	Convert inline transformer JavaScript into a proper code template
`mirth_estimate_throughput`	Estimate message throughput and identify bottlenecks
`mirth_generate_test_message`	Generate a realistic test message based on source connector type

Installation

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "mirth-connect": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/mirth-mcp"]
    }
  }
}

Restart Claude Desktop. All 18 tools become available immediately.

For Cursor, add the same configuration to .cursor/mcp.json in your project. For Claude Code, run:

claude mcp add mirth-connect npx -y @easysolutions906/mirth-mcp

Scenario: Onboarding a new team member

You just joined a healthcare IT team and need to understand 30 Mirth channels you have never seen before. Someone hands you a channel XML export. Normally you would open it in the Mirth Administrator, expand each connector, read the transformer steps, look up field paths in the HL7 specification, and take notes. This takes 15-30 minutes per channel.

Instead, paste the XML into Claude and ask: "Explain this Mirth channel."

Claude calls mirth_explain_channel and returns something like:

## ADT Feed - Epic to Lab

### Source: TCP Listener
Listens on port 6661

**Source Filter** (1 rules):
- Accept ADT A01/A04/A08 only (enabled)

**Source Transformer** (3 steps):
- Extract patient demographics (enabled)
- Format MRN with facility prefix (enabled)
- Map attending physician NPI (enabled)

### Destinations (2)

**1. Lab System** (TCP Sender)
  - Target: 10.1.5.20:5000
  - Transformer: 2 steps

**2. Patient Index** (Database Writer)
  - Transformer: 1 steps

### Properties
- Initial state: STARTED
- Storage mode: PRODUCTION
- Tags: ADT, Epic, Lab

In 10 seconds you know the channel's purpose, data flow, and architecture. You can follow up with "Analyze this channel for issues" and Claude calls mirth_analyze_channel:

{
  "channelName": "ADT Feed - Epic to Lab",
  "summary": { "total": 4, "errors": 1, "warnings": 2, "info": 1 },
  "findings": [
    {
      "ruleId": "sql-injection",
      "severity": "error",
      "location": "Destination: Patient Index Transformer",
      "detail": "SQL string concatenation detected — use parameterized queries to prevent SQL injection"
    },
    {
      "ruleId": "hardcoded-ip",
      "severity": "warning",
      "location": "Destination: Lab System",
      "detail": "Hardcoded IP \"10.1.5.20\" — use configurationMap or a channel variable instead"
    },
    {
      "ruleId": "missing-error-handling",
      "severity": "warning",
      "location": "Destination: Patient Index Transformer",
      "detail": "I/O operations without try/catch — database operations should be wrapped in error handling"
    },
    {
      "ruleId": "large-inline-script",
      "severity": "info",
      "location": "Source Transformer",
      "detail": "Script is 78 lines — consider extracting to a code template for reusability"
    }
  ]
}

Now you know the channel has a SQL injection vulnerability, hardcoded IPs, and missing error handling. On your first day. Without opening the Mirth Administrator.

Writing Rhino-compatible JavaScript

Mirth runs JavaScript through Mozilla Rhino, not V8 or SpiderMonkey. This means no template literals, no destructuring, no async/await, no optional chaining, no nullish coalescing, and no ES modules. Arrow functions and const work inside IIFEs on Mirth 3.7+ with ES6 mode enabled, but const/let at root level in code templates causes cross-template scope collisions. Every integration engineer has been bitten by at least one of these.

Ask Claude: "Generate a transformer that extracts patient demographics from PID and maps them to channelMap variables."

Claude calls mirth_generate_transformer and returns:

// Transformer: Extract patient demographics from PID
// Generated for Mirth Connect (Rhino ES6)

// Access HL7 message fields via msg object
// Example: var patientName = msg['PID']['PID.5']['PID.5.1'].toString();

try {
  var patientLastName = msg['PID']['PID.5']['PID.5.1'].toString();
  var patientFirstName = msg['PID']['PID.5']['PID.5.2'].toString();
  var mrn = msg['PID']['PID.3']['PID.3.1'].toString();

  channelMap.put('patientLastName', patientLastName);
  channelMap.put('patientFirstName', patientFirstName);
  channelMap.put('mrn', mrn);
} catch (e) {
  logger.error('Transformer error: ' + e.message);
  throw e;
}

The generated code uses var at root level, string concatenation instead of template literals, and wraps everything in try/catch. It follows Rhino rules automatically.

If you already have JavaScript and want to check it, paste it in and ask Claude to validate it. Claude calls mirth_validate_js and returns a version compatibility matrix:

{
  "valid": false,
  "mirthVersion": "es5",
  "rhinoMode": "ES5 (pre-3.7 or legacy config)",
  "errors": 2,
  "violations": [
    {
      "id": "arrow-function",
      "message": "Arrow functions require Mirth 3.7+ with rhino.languageversion=es6.",
      "fix": "Replace (x) => { } with function(x) { }. Or set rhino.languageversion=es6 in mirth.properties."
    },
    {
      "id": "template-literal",
      "message": "Template literals require Mirth 3.7+ with rhino.languageversion=es6.",
      "fix": "Use string concatenation: \"hello \" + name. Safest across all versions."
    }
  ],
  "versionMatrix": {
    "es5": "incompatible",
    "3.7": "compatible",
    "4.0": "compatible",
    "4.5": "compatible"
  }
}

This is especially useful when your team supports multiple Mirth versions across different client environments. The version matrix tells you exactly where the code will work and where it will break.

Environment promotion: diffing channels

Before promoting a channel from DEV to PROD, you need to know what changed. Export both versions and ask Claude: "Compare these two channel XMLs."

Claude calls mirth_diff_channels and returns:

{
  "channel1": "ADT Feed v2.1 (DEV)",
  "channel2": "ADT Feed v2.0 (PROD)",
  "totalChanges": 3,
  "changes": [
    {
      "field": "destination.Lab System.transformer",
      "from": "2 steps",
      "to": "3 steps",
      "type": "modified"
    },
    {
      "field": "destination.Audit Log",
      "type": "added",
      "details": "New Database Writer destination"
    },
    {
      "field": "postprocessingScript",
      "type": "modified"
    }
  ],
  "summary": "1 added, 0 removed, 2 modified"
}

A clear summary of what will change when you promote. No need to manually compare XML files or click through the Mirth Administrator.

Extracting SQL for DBA review

Healthcare organizations require database changes to go through a DBA review process. If your Mirth channels contain SQL in transformer scripts, Database Reader/Writer connectors, or inline JavaScript, extracting it manually is painful.

Ask Claude: "Extract all SQL from this channel and flag any injection risks."

Claude calls mirth_extract_sql and returns every query with its location and a flag for potential injection vulnerabilities:

{
  "channel": "Patient Sync",
  "totalQueries": 5,
  "injectionRisks": 1,
  "queries": [
    {
      "source": "Source connector query",
      "sql": "SELECT patient_id, mrn, last_name, first_name FROM patients WHERE updated_at > ${date}",
      "potentialInjection": false
    },
    {
      "source": "Dest[Patient Index] transformer: Update MPI",
      "sql": "UPDATE patient_index SET last_name = '" ,
      "potentialInjection": true
    }
  ],
  "warning": "1 queries may be vulnerable to SQL injection. Use parameterized queries instead of string concatenation."
}

Hand this to your DBA. They get the SQL without needing to open Mirth or understand channel XML structure.

Mapping channel dependencies

In a large Mirth environment with 50+ channels, channels route messages to each other via Channel Writer destinations and router.routeMessage calls. Understanding the dependency graph is critical before you disable, rename, or redeploy a channel.

Pass all your channel XMLs to Claude and ask: "Map the dependencies between these channels."

Claude calls mirth_dependency_map and returns:

{
  "totalChannels": 12,
  "totalDependencies": 8,
  "dependencies": [
    { "from": "ADT Router", "to": "Lab Feed", "type": "Channel Writer", "connector": "Lab Destination" },
    { "from": "ADT Router", "to": "Radiology Feed", "type": "Channel Writer", "connector": "Rad Destination" },
    { "from": "ADT Router", "to": "Audit Logger", "type": "router.routeMessage", "connector": "script" },
    { "from": "Lab Feed", "to": "Results Notifier", "type": "Channel Writer", "connector": "Notify" }
  ],
  "orphans": ["Test Channel", "Old Migration Channel"]
}

You can see which channels feed into which, and which channels are orphaned with no connections -- candidates for cleanup.

Generating complete channels

Need a new channel quickly? Describe it and Claude generates importable XML.

Ask: "Generate a Mirth channel called 'Lab Results Inbound' with a TCP Listener on port 7001 and two destinations: an HTTP Sender called 'EHR API' and a Database Writer called 'Results Archive'."

Claude calls mirth_generate_channel and returns valid XML that you can import directly into Mirth Connect. The generated channel includes proper connector classes, transformer and filter placeholders, and standard channel properties.

Generating deploy scripts for CI/CD

Mirth channels are usually deployed manually through the Administrator GUI. For teams practicing CI/CD, this is a bottleneck. The mirth_generate_deploy_script tool generates a bash script that uses the Mirth REST API to log in, check if the channel exists, stop it, update or create it, deploy, and start it.

Ask Claude: "Generate a deploy script for this channel targeting https://mirth-prod.internal:8443/api."

The output is a ready-to-use bash script for your Jenkins, GitHub Actions, or GitLab CI pipeline.

Debugging errors

Mirth error messages range from helpful to inscrutable. Rhino errors are especially confusing for developers used to V8. Paste an error into Claude and ask what it means.

Ask: "Debug this Mirth error: ReferenceError: \"formatDate\" is not defined"

Claude calls mirth_debug_error and returns:

{
  "error": "ReferenceError: \"formatDate\" is not defined",
  "cause": "The variable or function \"formatDate\" is not declared in the current scope. In Mirth, code templates execute in a shared global scope — if a code template has not been loaded, its functions will not be available.",
  "fixes": [
    "Verify the code template library containing \"formatDate\" is enabled and linked to this channel.",
    "Check for typos in the function/variable name.",
    "If using ES6 syntax (let/const) at root level, switch to var for global visibility.",
    "Ensure code template libraries are listed in the correct order (dependencies first)."
  ]
}

The tool recognizes common error patterns including ReferenceErrors, TypeErrors, SQL exceptions, network connection failures, and OutOfMemoryErrors. Each match returns a specific cause and actionable fixes.

Refactoring: inline scripts to code templates

Mirth best practice is to keep transformer scripts short and put reusable logic into code templates. In practice, integration engineers write everything inline first and refactor later -- or never. The mirth_convert_to_code_template tool automates the refactoring.

Paste an inline transformer script and ask Claude to convert it to a code template. The tool extracts function definitions, wraps them in the IIFE pattern with var declarations at root level for global visibility, and generates usage examples showing how to call the functions from a transformer step.

Estimating throughput

Before going live with a high-volume channel, you want to know where the bottlenecks are. The mirth_estimate_throughput tool analyzes transformer complexity, counts database queries, detects HTTP calls in transformers (a common anti-pattern), identifies heavy regex usage, and factors in destination type overhead.

The output includes an estimated messages-per-second figure and a ranked list of bottlenecks with specific optimization suggestions -- like moving HTTP calls from transformers to HTTP Sender destinations, or replacing repeated new RegExp with pre-compiled patterns in a deploy script.

Upgrading Mirth versions

Upgrading from Mirth 3.x to 4.x, or from 4.x to 4.5, introduces breaking changes in APIs, plugin interfaces, and Rhino behavior. The mirth_migration_guide tool scans all scripts in a channel for deprecated APIs, Rhino compatibility issues, and patterns that changed between versions.

Pass a channel XML and specify the from/to versions. The tool returns a list of issues with locations, descriptions, and fixes -- a checklist you can work through before upgrading.

Generating test messages

When building or debugging a channel, you need test messages that match the source connector type. The mirth_generate_test_message tool analyzes the channel's source connector and generates an appropriate test message: an HL7 ADT^A01 for TCP/LLP sources, a JSON payload for HTTP sources, or delimited text for file reader sources.

Getting started

Add the MCP server config to Claude Desktop, Cursor, or Claude Code
Restart and verify the 18 tools appear
Export a channel from Mirth Connect (Channels > Export Channel)
Paste the XML into Claude and ask: "Explain this channel" or "Analyze this channel for issues"
Try generating code: "Generate a transformer that extracts PID-5-1 and PID-3-1 to channelMap"

Mirth Connect is powerful but demands deep knowledge of Rhino quirks, HL7 field positions, and XML channel structure. An MCP server gives AI agents that knowledge, so you can focus on the integration logic instead of fighting the tooling.

How to Look Up NCCI Workers Compensation Class Codes Programmatically

easysolutions906 — Mon, 16 Mar 2026 21:39:16 +0000

How to Look Up NCCI Workers Compensation Class Codes Programmatically

Every medical claim submitted to Medicare goes through the National Correct Coding Initiative (NCCI) edit system before payment is approved. CMS publishes tens of thousands of Procedure-to-Procedure (PTP) edits and Medically Unlikely Edits (MUE) that define which CPT/HCPCS code pairs can be billed together and how many units of a given code are reasonable per encounter. If your billing system does not check claims against these edits before submission, you are going to get denials.

This article explains what NCCI edits are, how PTP bundling and MUE limits work, and how to validate claims programmatically.

What are NCCI edits

The NCCI was established by CMS in 1996 to promote correct coding and prevent improper payment for Medicare Part B claims. There are two types of edits:

PTP (Procedure-to-Procedure) edits define pairs of CPT/HCPCS codes that should not normally be billed together on the same claim. One code in the pair is the "comprehensive" code (the broader procedure) and the other is the "component" code (a procedure that is considered part of the comprehensive one). For example, if a surgeon performs a total knee replacement, certain ancillary procedures performed during the same session are bundled into the primary code and should not be billed separately.

MUE (Medically Unlikely Edits) set the maximum number of units that can be reported for a single CPT/HCPCS code per line, per day, or per encounter. An MUE of 1 for a bilateral procedure means you cannot bill 3 units of that code on a single claim line without triggering a denial.

CMS publishes updated NCCI edit files quarterly. Each quarterly release adds, modifies, or deletes edit pairs. A code pair that was billable together last quarter may not be this quarter.

The modifier indicator

Not every PTP edit is an absolute block. Each edit has a modifier indicator that determines whether the bundling can be overridden:

Modifier Indicator 0: Not allowed. No modifier will unbundle this pair. The component code simply cannot be billed with the comprehensive code.
Modifier Indicator 1: Modifier allowed. If the services are truly distinct (different anatomic site, different encounter, different practitioner), you can append modifier 25, 59, XE, XS, XP, or XU to the component code to unbundle the edit.
Modifier Indicator 9: Not applicable.

The -59 modifier and the newer X{ESPU} modifiers are the most commonly used unbundling modifiers. CMS introduced the X modifiers (XE, XS, XP, XU) to provide more specificity than the broad -59, and many payers now prefer them.

Why this matters for billing teams

The financial impact of NCCI edits is significant:

Denied claims cost money to rework and resubmit. The average cost to rework a denied claim is $25-$50.
Improper unbundling -- billing codes separately that should be bundled -- is one of the top reasons for Medicare audits. OIG recoveries for unbundling violations run in the millions annually.
MUE violations are an automatic denial. If the MUE for a code is 2 and you bill 3 units, the excess units are denied with no appeal path.
Quarterly updates mean your edit logic must stay current. A code pair that was clean in Q1 might have a new edit in Q2.

Validating a code pair

The MCP server @easysolutions906/ncci-api embeds the full CMS NCCI PTP edit table and MUE data, updated quarterly.

Check if two codes can be billed together

Validating codes 99213 (office visit) and 36415 (venipuncture):

{
  "code1": "99213",
  "code2": "36415",
  "canBillTogether": false,
  "hasEdit": true,
  "comprehensiveCode": "99213",
  "componentCode": "36415",
  "modifierIndicator": 1,
  "modifierIndicatorDescription": "Modifier allowed — use modifier 25, 59, XE, XS, XP, or XU to unbundle",
  "modifierApplied": null,
  "unbundledByModifier": false,
  "rationale": "Standards of medical/surgical practice",
  "message": "NCCI edit: 99213 bundles 36415. Apply modifier 25/59/XE/XS/XP/XU to 36415 if services are distinct."
}

The response tells you exactly what is happening: 99213 is the comprehensive code, 36415 is the component, and modifier indicator 1 means you can unbundle with the appropriate modifier. If the venipuncture was for a separately identifiable service, appending modifier 59 to 36415 resolves the edit.

Applying a modifier to unbundle

If modifiers are included in the request, the API evaluates whether they resolve the edit:

{
  "code1": "99213",
  "code2": "36415",
  "canBillTogether": true,
  "hasEdit": true,
  "comprehensiveCode": "99213",
  "componentCode": "36415",
  "modifierIndicator": 1,
  "modifierApplied": ["59"],
  "unbundledByModifier": true,
  "message": "Edit exists but unbundled by modifier 59 on 36415. These codes can be billed together."
}

This is the key workflow: check the pair, see if an edit exists, check the modifier indicator, and if modifier is allowed, apply the correct one.

Validating a full claim

Real claims have more than two codes. The ncci_validate_claim tool checks every code pair combination on a claim and also verifies MUE limits.

Submitting a claim with codes 99213, 36415, 80053, and 85025:

{
  "codesSubmitted": ["99213", "36415", "80053", "85025"],
  "pairsChecked": 6,
  "editIssues": 2,
  "mueIssues": 0,
  "blocked": 2,
  "unbundled": 0,
  "clean": false,
  "issues": [
    {
      "code1": "99213",
      "code2": "36415",
      "canBillTogether": false,
      "comprehensiveCode": "99213",
      "componentCode": "36415",
      "modifierIndicator": 1
    },
    {
      "code1": "80053",
      "code2": "85025",
      "canBillTogether": false,
      "comprehensiveCode": "80053",
      "componentCode": "85025",
      "modifierIndicator": 0
    }
  ],
  "summary": "Claim has 2 blocked edit pair(s) and 0 MUE violation(s)."
}

The first issue (99213/36415) can be resolved with a modifier. The second issue (80053/85025) has modifier indicator 0, meaning it cannot be unbundled -- one of those codes must be removed from the claim.

Looking up MUE limits

The ncci_mue tool returns the maximum units allowed for a code:

{
  "code": "99213",
  "found": true,
  "description": "Office or other outpatient visit",
  "practitionerMue": 1,
  "facilityMue": 1,
  "rationale": "Nature of Service/Procedure",
  "adjudicationIndicator": 2,
  "adjudicationDescription": "Per Day Edit — applies per beneficiary per day"
}

An MUE of 1 with adjudication indicator 2 means this code can only be billed once per beneficiary per day. Submitting 2 units on the same date of service will trigger an automatic denial.

The adjudication indicator matters:

1 (Claim Line Edit): The limit applies per claim line. You cannot split the units across multiple lines to avoid the edit.
2 (Per Day): The limit applies per beneficiary per day, across all claim lines.
3 (Per Encounter): The limit applies per encounter, which is more restrictive than per day.

Browsing edits for a code

The ncci_edits tool returns all PTP edits associated with a specific code:

{
  "code": "99213",
  "editCount": 47,
  "edits": [
    {
      "pairedCode": "36415",
      "role": "comprehensive",
      "modifierIndicator": 1,
      "rationale": "Standards of medical/surgical practice",
      "pairedCodeDescription": "Collection of venous blood by venipuncture"
    },
    {
      "pairedCode": "36416",
      "role": "comprehensive",
      "modifierIndicator": 1,
      "rationale": "Standards of medical/surgical practice",
      "pairedCodeDescription": "Collection of capillary blood specimen"
    }
  ]
}

This is useful for building billing rules engines or populating a reference table in your practice management system.

Searching edits by keyword

The ncci_search tool lets you search across the entire edit database by code, procedure name, or category:

{
  "query": "arthroscopy",
  "ptpEdits": {
    "total": 312,
    "results": [...]
  },
  "mue": {
    "total": 24,
    "results": [...]
  }
}

Setting up the MCP server

Add to your Claude Desktop or Cursor configuration:

{
  "mcpServers": {
    "ncci": {
      "command": "npx",
      "args": ["-y", "@easysolutions906/ncci-api"]
    }
  }
}

After restarting, you can ask natural language questions like:

"Can I bill 99213 and 36415 together?"
"What is the MUE limit for 99213?"
"Show all NCCI edits for CPT 27447"
"Validate this claim: 99213, 36415, 80053, 85025"
"Will modifier 59 on 36415 unbundle the edit with 99213?"

The server exposes five tools: ncci_validate_pair, ncci_validate_claim, ncci_edits, ncci_mue, and ncci_search.

Practical integration example

Here is a common pattern for a claims scrubber that checks a claim before submission:

const scrubClaim = async (codes, modifiers = {}) => {
  const res = await fetch('https://your-api-url.com/validate/claim', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': process.env.NCCI_API_KEY,
    },
    body: JSON.stringify({ codes, modifiers }),
  });
  const result = await res.json();

  if (result.clean) {
    return { pass: true, message: 'Claim passes NCCI validation' };
  }

  const actionItems = result.issues
    .filter((issue) => !issue.canBillTogether)
    .map((issue) => {
      if (issue.modifierIndicator === 1) {
        return `Add modifier 59/XE/XS/XP/XU to ${issue.componentCode} to unbundle from ${issue.comprehensiveCode}`;
      }
      return `Remove ${issue.componentCode} — it cannot be billed with ${issue.comprehensiveCode} (no modifier override)`;
    });

  const mueItems = result.mue.map((m) =>
    `Reduce ${m.code} from ${m.unitsOnClaim} units to ${m.mueLimit} (MUE limit)`
  );

  return {
    pass: false,
    actionItems: [...actionItems, ...mueItems],
  };
};

// Check a claim before submission
const result = await scrubClaim(
  ['99213', '36415', '80053'],
  { '36415': '59' }
);
// { pass: true, message: 'Claim passes NCCI validation' }

Run this before every claim submission. Flag blocked pairs for coder review, auto-suggest modifiers where indicator 1 allows it, and hard-stop any MUE violations.

Batch validation

For high-volume billing operations, the REST API supports batch validation of multiple claims in a single request:

const batchScrub = async (claims) => {
  const res = await fetch('https://your-api-url.com/validate/batch', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': process.env.NCCI_API_KEY,
    },
    body: JSON.stringify({ claims }),
  });

  const { results } = await res.json();

  const flagged = results.filter((r) => !r.clean);
  return {
    total: results.length,
    clean: results.length - flagged.length,
    flagged: flagged.length,
    details: flagged,
  };
};

// Scrub an entire day's claims
const dayResults = await batchScrub([
  { codes: ['99213', '36415'], modifiers: { '36415': '59' } },
  { codes: ['27447', '27486'] },
  { codes: ['99214', '80053', '85025'] },
]);

Data freshness

CMS publishes NCCI edit updates quarterly (January, April, July, October). Each update can add new edits, delete existing ones, or change modifier indicators. The @easysolutions906/ncci-api package includes a data-info endpoint that returns the CMS quarter, build date, and record counts so you can verify the data is current. The embedded data is rebuilt from CMS source files with each package update.

NCCI validation is one of those problems that every medical billing system needs to solve but few handle well. The edit tables are large, the quarterly updates are easy to miss, and the modifier logic has enough nuance that getting it wrong costs real money in denials and rework. Having the full CMS edit dataset available as both MCP tools and a REST API means you can integrate claims scrubbing wherever it is needed -- inside an AI coding assistant, a practice management system, or a standalone claims review workflow.

How to Integrate OFAC Screening into Your Application in 5 Minutes

easysolutions906 — Mon, 16 Mar 2026 21:28:03 +0000

How to Integrate OFAC Screening into Your Application in 5 Minutes

You need OFAC screening in your application. You do not need a six-month enterprise integration project to get it. This guide takes you from zero to production-ready sanctions with working code.

Quick Start: Your First Screening Call

The fastest way to verify the API works:

curl -X POST https://ofac-screening-production.up.railway.app/screen \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{"name": "Mohammad Ali", "threshold": 0.85}'

That is it. You send a name, you get back a list of matches with scores. If matchCount is 0, the name is clear.

JavaScript / Node.js Integration

Here is a production-ready screening module with error handling and retries:

const OFAC_BASE_URL = 'https://ofac-screening-production.up.railway.app';
const OFAC_API_KEY = process.env.OFAC_API_KEY;

const screenName = async (name, options = {}) => {
  const {
    type = null,
    dateOfBirth = null,
    country = null,
    threshold = 0.85,
  } = options;

  const body = { name, threshold };
  if (type) { body.type = type; }
  if (dateOfBirth) { body.dateOfBirth = dateOfBirth; }
  if (country) { body.country = country; }

  const response = await fetch(`${OFAC_BASE_URL}/screen`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': OFAC_API_KEY,
    },
    body: JSON.stringify(body),
  });

  if (!response.ok) {
    const error = await response.json().catch(() => ({}));
    throw new Error(
      `OFAC screening failed: ${response.status} ${error.error || response.statusText}`,
    );
  }

  return response.json();
};

// Usage in an onboarding flow
const onboardCustomer = async (customer) => {
  const screening = await screenName(customer.fullName, {
    type: 'Individual',
    dateOfBirth: customer.dob,
    country: customer.country,
  });

  if (screening.matchCount > 0) {
    // Flag for compliance review -- do not auto-reject
    await flagForReview(customer.id, screening);
    return { status: 'PENDING_REVIEW', screening };
  }

  return { status: 'CLEAR', screening };
};

Two important patterns here. First, never auto-reject based on a match. Flag it for human review. False positives happen, and rejecting legitimate customers without review creates legal and reputational risk. Second, always store the full screening response, not just the pass/fail decision.

Python Integration

import os
import requests

OFAC_BASE_URL = "https://ofac-screening-production.up.railway.app"
OFAC_API_KEY = os.environ["OFAC_API_KEY"]


def screen_name(name, entity_type=None, date_of_birth=None,
                country=None, threshold=0.85):
    payload = {"name": name, "threshold": threshold}

    if entity_type:
        payload["type"] = entity_type
    if date_of_birth:
        payload["dateOfBirth"] = date_of_birth
    if country:
        payload["country"] = country

    response = requests.post(
        f"{OFAC_BASE_URL}/screen",
        json=payload,
        headers={
            "Content-Type": "application/json",
            "x-api-key": OFAC_API_KEY,
        },
        timeout=10,
    )
    response.raise_for_status()
    return response.json()


def screen_batch(names, threshold=0.85):
    """Screen up to 100 names in a single request."""
    response = requests.post(
        f"{OFAC_BASE_URL}/screen/batch",
        json={"names": names, "threshold": threshold},
        headers={
            "Content-Type": "application/json",
            "x-api-key": OFAC_API_KEY,
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()


# Usage
result = screen_name(
    "Vladimir Putin",
    entity_type="Individual",
    country="Russia",
)

print(f"Matches found: {result['matchCount']}")
for match in result["matches"]:
    print(f"  {match['entity']['name']} — score: {match['score']} "
          f"({match['matchType']})")

Handling Results: Match vs Clear

Every screening response includes a matchCount field. Your application logic branches on it:

const processScreening = (screening) => {
  if (screening.matchCount === 0) {
    // No matches -- customer is clear
    return {
      decision: 'CLEAR',
      screenedAt: screening.screenedAt,
      listVersion: screening.listVersion,
    };
  }

  // Matches found -- classify by highest score
  const topMatch = screening.matches[0];

  if (topMatch.score >= 0.95) {
    // Near-certain match -- block and escalate immediately
    return {
      decision: 'BLOCK',
      reason: `High-confidence match: ${topMatch.entity.name} (score: ${topMatch.score})`,
      screenedAt: screening.screenedAt,
      listVersion: screening.listVersion,
      requiresReview: true,
    };
  }

  if (topMatch.score >= 0.85) {
    // Strong match -- hold for compliance review
    return {
      decision: 'HOLD',
      reason: `Possible match: ${topMatch.entity.name} (score: ${topMatch.score})`,
      screenedAt: screening.screenedAt,
      listVersion: screening.listVersion,
      requiresReview: true,
    };
  }

  // Below 0.85 but above your threshold -- log and flag
  return {
    decision: 'FLAG',
    reason: `Weak match detected: ${topMatch.entity.name} (score: ${topMatch.score})`,
    screenedAt: screening.screenedAt,
    listVersion: screening.listVersion,
    requiresReview: true,
  };
};

Batch Screening for Existing Customer Databases

When you first integrate OFAC screening, you need to screen your entire existing customer base. The batch endpoint handles up to 100 names per request:

const screenExistingCustomers = async (customers) => {
  const BATCH_SIZE = 100;
  const flagged = [];

  for (let i = 0; i < customers.length; i += BATCH_SIZE) {
    const batch = customers.slice(i, i + BATCH_SIZE);
    const names = batch.map((c) => ({
      name: c.fullName,
      type: 'Individual',
      dateOfBirth: c.dob || null,
      country: c.country || null,
    }));

    const response = await fetch(
      `${OFAC_BASE_URL}/screen/batch`,
      {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'x-api-key': OFAC_API_KEY,
        },
        body: JSON.stringify({ names, threshold: 0.85 }),
      },
    );

    const data = await response.json();

    data.results.forEach((result, idx) => {
      if (result.matchCount > 0) {
        flagged.push({
          customer: batch[idx],
          matches: result.matches,
          listVersion: data.listVersion,
          screenedAt: data.screenedAt,
        });
      }
    });

    console.log(
      `Screened ${Math.min(i + BATCH_SIZE, customers.length)}/${customers.length}`,
    );
  }

  return flagged;
};

For 10,000 customers, this makes 100 API calls. At typical response times of 100-200ms per batch, the full scan completes in under 30 seconds.

Setting Up Re-Screening When the List Updates

Treasury updates the SDN list multiple times per week. You need a job that checks for updates and re-screens when the list changes:

let lastKnownListVersion = null;

const checkForListUpdate = async () => {
  const response = await fetch(`${OFAC_BASE_URL}/data-info`);
  const info = await response.json();

  if (lastKnownListVersion && info.publishDate !== lastKnownListVersion) {
    console.log(
      `SDN list updated: ${lastKnownListVersion} -> ${info.publishDate}`,
    );

    // Trigger a full re-screen of your customer database
    const customers = await loadAllActiveCustomers();
    const flagged = await screenExistingCustomers(customers);

    if (flagged.length > 0) {
      await notifyComplianceTeam(flagged);
    }
  }

  lastKnownListVersion = info.publishDate;
};

// Run daily (or more frequently for high-risk programs)
// In production, use a proper job scheduler (cron, Bull, etc.)

Storing Results for Audit Compliance

Every screening result must be stored. When a regulator examines your compliance program, they will ask to see screening records for specific customers and date ranges.

A minimal audit record schema:

const auditRecord = {
  // Who was screened
  customerId: 'cust_12345',
  screenedName: 'John Smith',
  screenedDob: '1985-03-15',
  screenedCountry: 'US',

  // When and against what
  screenedAt: '2026-03-16T14:30:00.000Z',  // from API response
  listVersion: '2026-03-14',                 // from API response

  // Result
  matchCount: 0,
  decision: 'CLEAR',
  matches: [],                               // store full match details if any

  // Review (if matches were found)
  reviewedBy: null,
  reviewedAt: null,
  reviewDecision: null,                      // TRUE_POSITIVE or FALSE_POSITIVE
  reviewNotes: null,
};

Store these records in a tamper-evident way. An append-only database table with no UPDATE or DELETE permissions for application users is the standard approach. Retention period is five years minimum per BSA requirements.

Next Steps

Get an API key: Visit ofac-screening-production.up.railway.app to get started
Test with the interactive tool: easysolutions906.github.io/screen.html
Integrate into onboarding: Add screening to your customer signup flow
Set up batch re-screening: Run against your existing database
Build the audit trail: Store every screening result with timestamps and list versions

The API documentation is available at the base URL. The /data-info endpoint shows the current SDN list version and record count so you always know how fresh your screening data is.

Five minutes to integrate. Years of compliant screening records to show your regulators.