Dígito de control NPI
La base 123456789 lleva el dígito de control 3, así que el NPI completo es 1234567893. Escriba nueve cifras para completar el identificador de un proveedor sanitario de Estados Unidos, o diez para confirmar su último dígito antes de una reclamación o un directorio. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Número
- 123456789
- Modo de cálculo
- Compute
- Entrada
- 123456789
- Prefijo
- 80840
- Con prefijo
- 80840123456789
El National Provider Identifier de Estados Unidos es un número de diez dígitos que identifica a clínicos individuales y a proveedores organizacionales en reclamaciones, altas y directorios bajo HIPAA. Los nueve primeros dígitos son el identificador base emitido mediante NPPES; el décimo es un dígito de control producido por el algoritmo de Luhn tras aplicar el prefijo constante 80840 a la base. Esa regla hace que un NPI se comporte como un identificador de estilo ISO a efectos de checksum, sin pretender que sea una tarjeta de pago. Esta capacidad implementa únicamente esa regla de CMS: el modo compute acepta exactamente nueve dígitos base y devuelve el dígito de control más el NPI completo de diez; el modo validate acepta un NPI completo de diez dígitos e indica si el dígito final coincide con el valor esperado recalculado.
Cómo se calcula el dígito de control NPI con el prefijo 80840
Según la especificación de los Centers for Medicare & Medicaid Services, un NPI tiene siempre diez dígitos decimales. Las posiciones uno a nueve forman el identificador base (los individuos suelen empezar por uno y las organizaciones por dos, aunque esta herramienta no impone el tipo de emisor). La posición diez es el dígito de control.
Para calcularlo, concatene la constante fija de cinco dígitos 80840 delante de la base de nueve, produciendo una cadena de catorce dígitos que imita la carga de un cálculo Luhn al estilo de número de tarjeta. Aplique el algoritmo clásico double-add-double de Luhn desde la derecha de esa cadena de catorce: duplique cada segundo dígito empezando por el dígito base más a la derecha, porque una vez añadido el de control ese dígito base ocupa la posición dos desde la derecha de la secuencia completa de quince al estilo ISO.
Cuando el doble de un dígito es mayor que nueve, reste nueve (de forma equivalente, sume las decenas y las unidades del producto). Sume cada valor ponderado; el dígito de control es diez menos esa suma módulo diez, módulo diez otra vez, para que la secuencia completa incluyendo el de control tenga un total Luhn divisible por diez. La validación recalcula el dígito esperado a partir de los nueve primeros caracteres tras el mismo prefijo 80840 y lo compara con el décimo dígito del NPI enviado.
El algoritmo es determinista y local: sin llamada al registro NPPES, sin reloj y sin aleatoriedad. Esta herramienta no resuelve NPI a nombres, no demuestra taxonomía ni estado de inscripción y no contacta a CMS: solo prueba que la cadena de dígitos está bien formada según la regla oficial Luhn con 80840.
Frente a herramientas Luhn genéricas de tarjetas o de IMEI, la intención de búsqueda aquí es estrecha: quien necesita una calculadora de dígito de control NPI para bases de nueve dígitos o un comprobador de National Provider Identifier de diez, no una herramienta de pago o de dispositivo.
Dónde encajan los dígitos de control NPI en flujos sanitarios reales
Los proveedores de gestión de consultas y EHR reciben bases internas de nueve dígitos en sandboxes de onboarding y deben añadir el dígito de control Luhn oficial antes de que un NPI aparezca en reclamaciones, facturas o directorios de proveedores. Las clearinghouses y los pagadores validan NPI de diez dígitos en la admisión de reclamaciones para que una sola transposición no cree un proveedor fantasma ni una transacción 837 rechazada.
Los trabajos ETL que cargan ficheros maestros de proveedores recorren cada columna NPI de un CSV o de un feed HL7, llaman al modo validate y ponen en cuarentena las filas donde valid es false, capturando tanto ediciones humanas como errores de generadores en uno.
No trate un NPI que pasa la comprobación como prueba de que el proveedor esté activo en NPPES, autorizado en un estado o inscrito con un pagador; solo demuestra que el dígito Luhn es coherente con la base bajo los pesos CMS 80840 usados para National Provider Identifiers.
Qué puede hacer con ella
Auditar columnas NPI en datos maestros de proveedores
Valide por lotes cada NPI de diez dígitos en un CSV de EHR, credencialización o clearinghouse y ponga en cuarentena las filas cuyo dígito de control ya no coincida con el valor esperado recalculado.
Preguntas frecuentes
¿Qué es un dígito de control NPI?
Es el décimo dígito de un National Provider Identifier de EE. UU., calculado con el algoritmo de Luhn tras anteponer la constante 80840 a los nueve primeros dígitos, de modo que los errores de escritura y de escaneo suelen detectarse antes de almacenar o facturar el número.
¿Qué ocurre con longitud incorrecta, letras o guiones?
Las tareas de validación fallidas no se facturan.
¿Es gratuita la herramienta de dígito de control NPI?
La herramienta del navegador es gratuita y se ejecuta en local.
¿Cómo se calcula el dígito de control del NPI?
Se antepone 80840 a la base de nueve cifras y se aplica el método de Luhn a esos catorce dígitos: se duplica uno de cada dos desde la derecha, se resta nueve a lo que pase de nueve y se suma todo. El dígito de control lleva el total a un múltiplo de diez.
¿Un NPI válido significa que el proveedor está activo?
No. Un resultado válido solo indica que el último dígito coincide con el cálculo. La herramienta no consulta el registro NPPES y no dice si el proveedor está activo, inscrito o con licencia.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/enc/npi \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"123456789"}'const res = await fetch("https://api.kit.forhosting.com/enc/npi", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "123456789"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/npi",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "123456789"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/npi", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"123456789"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"123456789"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/npi", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"number": "123456789"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.npi",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
La entrada no numérica y las longitudes incorrectas fallan con invalid_input en lugar de un recorte silencioso, de modo que usted nunca persista un identificador a medias. La misma aritmética pura se ejecuta gratis en el navegador y al precio publicado de la API, sin consulta de red a registros NPPES y sin afirmar que un checksum válido signifique que el proveedor esté activo, inscrito o autorizado.
Contrato de entrada, modos y comportamiento de error
Envíe un campo number que contenga solo caracteres del cero al nueve. Una longitud incorrecta es un error explícito que nombra el modo y la longitud enviada —nueve para compute, diez para validate— de modo que los formularios cliente puedan mostrar «se necesitan nueve dígitos» sin adivinar. Las cadenas vacías, el number ausente y los valores de mode inválidos fallan antes de cualquier suma Luhn y no se facturan. Las tareas de validación que rechazan forma incorrecta no se cobran; una cadena bien formada de diez dígitos que simplemente tiene el dígito de control incorrecto devuelve valid false sin lanzar error. Espacios, guiones, letras y puntos decimales se rechazan como entrada no numérica con invalid_input para que un valor recortado en silencio no llegue al almacenamiento. El modo compute es el predeterminado: el motor exige exactamente nueve dígitos, devuelve check_digit como cadena de un carácter, devuelve with_check como el NPI de diez dígitos que usted puede imprimir o persistir, y también devuelve prefix (siempre 80840) y prefixed (80840 más la base de nueve) para auditorías y depuración de la regla CMS. El modo validate exige exactamente diez dígitos; la respuesta indica valid true cuando el dígito final coincide con el expected_check_digit recalculado, e incluye siempre payload (los nueve primeros dígitos), check_digit, expected_check_digit, prefix, prefixed y length diez. Se aceptan alias como digits, npi y code para el mismo campo de carga, de forma que las integraciones que ya hablan de «npi» no necesiten renombrar. Como la ruta es parse puro sin reloj, fuente aleatoria ni red, el mismo cuerpo JSON produce siempre el mismo resultado JSON en la herramienta gratuita del navegador y en la API a $0.002 por solicitud correcta.
Dónde encajan los dígitos de control NPI en flujos sanitarios reales
Los equipos de credencialización y de plantillas recalculan expected_check_digit cuando una clínica lee un número por teléfono o lo pega desde un PDF, capturando errores de escritura antes de enviar un contrato o un archivo de inscripción. En todo flujo el contrato es el mismo: solo dígitos, longitud fija por modo, JSON estructurado que usted puede probar con goldens, comportamiento idéntico en navegador gratuito y API prepago, e invalid_input honesto cuando la cadena no es una secuencia pura de dígitos de la longitud correcta.
Casos de integración
Completar una base NPI de 9 dígitos para fixtures de reclamaciones
Llame al modo compute con la base de nueve dígitos, almacene with_check y use el NPI de diez en reclamaciones de prueba, facturas o registros sandbox de proveedores.
Validar NPI tecleados o importados en la entrada
Cuando un formulario, archivo de plantilla o feed de socio envíe diez dígitos, llame al modo validate y bloquee la inscripción si valid es false, mostrando expected_check_digit para corregir un error de un solo dígito.
Preguntas técnicas
¿Cómo se calcula un dígito de control NPI con esta API?
Haga POST con number igual a exactamente nueve dígitos y mode compute (u omita mode). La respuesta incluye check_digit, with_check (el NPI completo de diez dígitos) y prefix 80840 para auditar la regla CMS.
¿Cómo se valida un NPI completo de diez dígitos?
Haga POST con la cadena de diez dígitos y mode validate. La respuesta incluye valid, check_digit, expected_check_digit y payload (dígitos sin el último).