JHNRD

Parte de Awesome HORIZON SHIELD — el índice verificable de cada conjunto de datos, servidor MCP y libro de contabilidad que ejecutamos.

Base de datos de reembolsos de enfermería de visita a domicilio en Japón

Un registro de las reglas de reembolso de enfermería de visita a domicilio en Japón — adiciones, reducciones y la caducidad de las instrucciones médicas — en el que cada requisito lleva consigo el documento en el que se basa.

Los números en sí son públicos. Lo que contiene este conjunto de datos es de dónde proviene cada número.

日本語版はこちら → README.ja.md

間違いを見つけた方へ。 この資料の誤りに気づけるのは、現場で算定している方です。 直し方は CONTRIBUTING.md に日本語で書いてあります。 出典を1つ添えて Issue を立ててください。 「この加算の要件が違う」の一行でも構いません。訂正は不具合として扱います。

No tome una decisión de facturación basándose solo en esto

Actualmente, 8 fuentes se basan en el propio texto del estatuto (statute — el aviso ministerial, ordenanza o circular). statute es 11 en total; 5 de ellas son revisiones superadas y no pueden usarse como autoridad vigente. Se conservan solo para que el historial de revisiones sea legible.

El resto son material ministerial que no es el texto del estatuto (agency, 8) y comentarios privados (secondary, 7).

54 requisitos no están confirmados. Cualquier cosa que no pudimos verificar contra el texto del estatuto lo dice explícitamente. No se deja en blanco.

Lo que este conjunto de datos puede decir es: "esta reducción tiene los requisitos A, B y C, y C aún no se ha confirmado contra el texto del estatuto." Nunca dice "puede facturar esto" ni "esto se aplica a usted."

La razón de esa línea es simple: cuando se devuelve una reclamación, alguien tiene que rendir cuentas, y un conjunto de datos no puede hacerlo.

Related MCP server: koko-call-mcp

Dónde se encuentra

33 elementos. Este no es un mapa completo de las reglas. El nombre va por delante del contenido, y el recuento de elementos se pone primero para que esto no quede oculto.

Los términos legales japoneses nunca se traducen

Los nombres que provienen de un estatuto — 看護体制強化加算 (Ⅰ), 特別管理加算, 告示第95号 — se mantienen textualmente en este repositorio, en los datos y en este README, con una glosa en inglés al lado cuando ayuda.

No se reemplazan por un nombre en inglés. No existe ningún nombre en inglés para ellos en ningún estatuto japonés, así que inventar uno crearía una precisión que la fuente no tiene. Esa es la misma razón por la que un requisito no confirmado se publica como no confirmado en lugar de ocultarse.

Las disciplinas

1. Ningún número sin fuente. Cada valor unitario y cada requisito lleva un source.

2. Cada fuente declara su propia posición, en tres niveles. statute / agency / secondary. El material publicado por el ministerio no se trata como igual al texto del estatuto.

3. Un elemento no confirmado nunca se deja en blanco. Lleva confirmed: false y un unconfirmed_reason. En blanco y no confirmado son cosas diferentes.

4. Cuando las fuentes no coinciden, no elegimos una y nos callamos. Ambas lecturas van a conflicts, y el conflicto permanece marcado como sin resolver. En el momento en que se elige una, la razón para elegirla desaparece.

5. Nada que se lea como "puede facturar esto" se permite en los datos. El validador lo rechaza.

6. Las revisiones crean una nueva versión; la anterior no se elimina. De lo contrario, las decisiones pasadas no pueden auditarse después.

7. Cada requisito está vinculado uno a uno a una pregunta de entrevista. Un requisito sin pregunta adjunta es un requisito que nadie ha preguntado realmente.

Estas no son aspiraciones. tools/validate.py las verifica mecánicamente, y CI falla ante cualquier incumplimiento.

Endpoint MCP público (sin clave, solo lectura)

https://jhnrd-mcp.oga-surf-project.workers.dev

El conjunto de datos se sirve a través de MCP (JSON-RPC 2.0 / HTTP transmisible en POST /mcp) y a través de HTTP simple (/status.json, /items, /items/<id>, /sources, /search?q=, /unconfirmed, /conflicts, /gaps, /disclosure, /cite). Sin clave. Sin ruta de escritura.

El contenido ya es CC BY 4.0 — pero un archivo JSON por sí solo significa que cada consumidor escribe un analizador, y cada analizador mezcla la interpretación de su autor. Servirlo significa que eso ocurre en un solo lugar.

La misma línea se traza en el lado del servidor:

• No decide si una reclamación puede facturarse. Que nunca devuelva tal declaración se verifica mecánicamente mediante el conjunto de pruebas.

• Cada respuesta lleva la versión, el aviso de "esto no decide la facturación" y la divulgación de conflicto de intereses. Las once herramientas se prueban para ello.

• No tiene clave y no está conectado a ningún almacenamiento. En el momento en que lo esté, empezará a contener algo de alguien.

• Las herramientas que exponen las debilidades van primero: jhnrd_unconfirmed, jhnrd_gaps (incluidas las búsquedas que no devolvieron resultados), jhnrd_conflicts (ambas lecturas conservadas).

La copia que sirve se genera a partir del conjunto de datos y nunca se obtiene en tiempo de ejecución — un borde de CDN una vez mantuvo viva una revisión obsoleta y un servidor interno entregó números antiguos. CI falla si la copia se desvía de la fuente.

Una vez al día, tanto la versión que el endpoint en vivo está sirviendo realmente como el manifiesto listado en el registro oficial de MCP se comparan con el repositorio (la insignia live de arriba) — porque empujar y olvidarse de desplegar, y publicar un manifiesto cuya metadatos el registro descartó silenciosamente, ya han ocurrido ambos aquí.

Esa verificación no falla cuando no se puede establecer la conexión — ser inalcanzable no es evidencia de estar obsoleto — pero sí falla cuando un estado HTTP regresa y no es 200, porque un estado es una respuesta. La primera versión de esta puerta confundió las dos cosas y pasó su vida reportando verde mientras recibía 403. Su lógica se ejercita contra diecisiete endpoints simulados en cada push, ya que una puerta que se ejecuta una vez al día puede permanecer rota durante un día sin que nadie lo sepa.

{ "mcpServers": { "jhnrd": { "type": "http", "url": "https://jhnrd-mcp.oga-surf-project.workers.dev/mcp" } } }

Vea mcp/README.md; el manifiesto del registro es server.json.

Conflicto de intereses

The HORIZONs Inc., que mantiene este conjunto de datos, vende un servicio de pago a proveedores de enfermería de visita a domicilio que se respalda en él. El pago se realiza como una tarifa inicial de construcción y una tarifa mensual.

Por lo tanto: las personas que construyen este conjunto de datos reciben un pago cuando se cree que es útil. Eso debe declararse primero, o los números anteriores no pueden usarse. Un conjunto de datos cuya disciplina central es que cada fuente declara su propia posición no puede eximirse de declarar la suya.

Cuatro cosas podrían doblarse, y cada una está atada de antemano:

Cada número en este README se genera a partir de status.json, y CI falla si se edita a mano. Inflar una cifra no es algo que se pueda hacer en silencio.

• Los ingresos provienen solo de esos clientes. Sin financiación gubernamental, de asociaciones comerciales o de proveedores. Sin tarifas de listado. Sin publicidad.

• No existe un conjunto de datos separado o ampliado para clientes que pagan. Lo que hay aquí es todo.

• Las notas de práctica recopiladas de los proveedores nunca se agregan sin su consentimiento (actualmente 0), y nunca son una fuente de reglas incluso cuando están presentes.

Texto completo, y lo que el mantenedor puede y no puede decidir: GOVERNANCE.md (japonés).

Cómo citar

Cite siempre la versión (el número de semilla). Diferentes versiones contienen contenido diferente. Debido a que las correcciones se apilan en lugar de sobrescribirse, una cita sin versión no puede reconciliarse después.

The HORIZONs Inc. (2026). JHNRD — Japan Home-visit Nursing Reimbursement Database,
version 2024-kaitei.seed.19. Zenodo. https://doi.org/10.5281/zenodo.22083722 (CC BY 4.0)

DOI: 10.5281/zenodo.22083722 — este es el DOI de concepto que cubre todas las versiones; siempre resuelve a la más reciente. Para citar una versión específica, use el DOI por versión en su registro de Zenodo. Diferentes versiones contienen contenido diferente.

Descripciones legibles por máquina — todas generadas a partir de status.json, ninguna escrita a mano: CITATION.cff ・ datapackage.json ・ .zenodo.json ・ CHANGELOG.md

Cada versión lleva una etiqueta anotada: git tag -l 'seed.*', y luego git show seed.19.

Las correcciones se tratan como defectos

Si alguna afirmación aquí es incorrecta o contradice el texto de la norma, abre un issue. No necesitas ejecutar un proveedor para hacerlo.

• Una corrección nunca elimina la redacción original. Eliminarla haría imposible comprobar después si la propia corrección era correcta.

• Una corrección basada en statute prevalece sobre agency, que prevalece sobre secondary.

• Cuando decimos «no confirmado» en lugar de guardar silencio, ese es exactamente el lugar donde hay que cuestionar.

Cómo presentar un issue: CONTRIBUTING.md. Contacto: contact@the-horizons-innovation.com

Lo que aún falta

Los vacíos sin cubrir se registran en known_gaps dentro de data/rules_2024.json — actualmente 7 (los resueltos se conservan, marcados como resueltos).

Mantenedor

The HORIZONs Inc. (número corporativo de Japón 7021001075279) Toshikatsu Oga (ORCID 0009-0000-9180-903X)

Mantenido por una única empresa. No es un organismo de revisión por pares, ni una autoridad pública, ni una asociación comercial. Sin relación con el Ministerio de Salud, Trabajo y Bienestar ni con ningún otro organismo gubernamental, y nada de lo aquí expuesto ha sido confirmado por ninguno de ellos.

Existe una base de datos de costes de construcción construida con las mismas disciplinas en JCCDB. JHNRD aspira a ocupar el mismo lugar para la enfermería de visita a domicilio. Hasta ahora son 33 elementos.