Japan has a standard format for some inpatient data called DPC. Many people in the OHDSI world use the OMOP Common Data Model. I could not find public code that connects the two, so I started writing it. The project is called jpomop, and the code is on GitHub: https://github.com/kojikojikojikoji/jpomop
I am a Japanese data scientist, and I live in London.
Why DPC data matters
DPC is used to classify acute inpatient stays and help set hospital payments in Japan. Hospitals in the system send standard files about each stay to the Ministry of Health, Labour and Welfare (MHLW). The ministry publishes the file layout every year in a long manual. The FY2026 edition has 244 pages (MHLW, PDF).
The scale is large. The MHLW summary of the FY2024 discharged patient survey lists 1,767 DPC hospitals in the analysed data (MHLW, PDF). Other hospitals also take part in the survey. Every hospital in the survey makes its files from the same manual for that year.
jpomop reads two of those files. Form 1 (様式1) holds details about the patient and stay, with diagnoses coded in ICD-10. The EF file (入院EF統合ファイル) records billed services by day, including drugs and procedures, and ward information.
Why OMOP
The OMOP CDM is an open community standard for observational health data. The OHDSI CDM Working Group manages it (OHDSI).
In Europe, EHDEN says it has a network of over 100 data partners mapped to the OMOP CDM (EHDEN). In England, the NHS Research Secure Data Environment Network agreed in 2023 to adopt the OMOP CDM (HDR UK).
OMOP is used in many places where I would like Japanese data to be usable. Putting DPC data into OMOP tables is a first step toward using OHDSI tools and study code. Whether a study works also depends on the mappings and on what DPC records.
What was missing
I looked for open code that turns DPC files into OMOP tables. I did not find any. There is an open ETL for Japanese EHR tables from the Rinchu-net standard data tables (GitHub). Its source list does not include DPC files.
I wanted something anyone could run without real patient data. I wrote the converter from the public specification and tested it with synthetic data and the worked examples in the manual.
What jpomop does
This is the quick start from the README:
pip install -e .
jpomop synth --n 100 --out synth/
jpomop validate --yoshiki1 synth/yoshiki1.txt --ef synth/ef.txt
jpomop convert --yoshiki1 synth/yoshiki1.txt --ef synth/ef.txt --out cdm.duckdb
jpomop report --cdm cdm.duckdb
synth makes fake data for 100 patients. validate checks the files against the parts of the FY2026 specification that jpomop supports and lists the problems it finds. convert writes the CDM tables to DuckDB. report summarises the result.
The validation step can be useful on its own. It does not need OMOP or a vocabulary. A hospital that does not use OMOP could still use it to check the supported fields in its DPC files. I have not tried this on real files yet.
This table shows which OMOP tables jpomop writes from each input:
| DPC | CDM table |
|---|---|
| Form 1, whole-stay form | person, visit_occurrence, observation_period |
| EF, ward code for each day | visit_detail |
| Form 1, non-suspected diagnoses (ICD-10) | condition_occurrence |
| EF, codes that start with 6 | drug_exposure |
| EF, codes that start with 1 | procedure_occurrence |
| Form 1, discharge outcome 6 or 7 | death |
That makes eight CDM tables. Patient IDs are hashed.
The manual tells hospitals to set the ward code for each service date, not the ward at discharge (page 193). jpomop makes one visit_detail row for each run of days on the same ward. The ward code is each hospital's own code.
The specification lives in YAML files. Each field has a name, a length, a type and the page number in the manual. I did not copy the manual's text.
The tricky parts
Suspected diagnoses. Japanese claims data often carry diagnoses marked as "suspected". In Form 1, this is the modifier code 8002. jpomop leaves these out of condition_occurrence and counts them. I made this choice to avoid treating them as confirmed diagnoses.
Dates. Form 1 has no date for each diagnosis, so jpomop uses the admission date as the condition start date. This matters for studies of when a condition began: admission may not be the start date. The EF file has a date for each service, so jpomop uses the recorded service dates for drugs and procedures.
Form types. Form 1 has several form types for one stay. jpomop uses the form for the whole stay. It uses the day-90 interim form only when a stay has no whole-stay form yet. Ward-group forms and readmission forms are counted but not converted. In the manual, a ward-group form covers part of a stay (page 42). A readmission form joins two stays, and each of those stays also has its own form (page 125). So their days are already in the forms that jpomop uses. I have not checked this on real files.
Diagnosis codes. DPC writes ICD-10 without a dot, and sometimes with a fifth character. jpomop tries the most specific Athena code first and then shorter ones. For example, S7200 becomes S72.00, then S72.0, then S72.
Drug mapping. The EF file uses receipt codes for drugs. jpomop looks up each code in the public drug master to get the NHI drug price code. Then it looks up that code in the table by Kimura et al. (2025), which maps Japanese drugs to RxNorm concepts (dataset, CC BY 4.0; paper). The table has 12,178 rows for oral and injectable drugs. It does not cover every drug. In the October 2026 drug master, 11,956 of 19,222 items have a concept ID in the table. That is 62% of the items, not of real drug use. I have not checked these concept IDs against Athena yet. Drugs that patients bring from home are left out.
Masters are not included. The code masters come from the Japanese body that reviews and pays health insurance claims. Its website terms prohibit using or reproducing its documents without permission. So the repository does not include them. Users download the masters, the Athena vocabularies and the Kimura table themselves. Then jpomop vocab build joins them on the user's own machine. Without a vocabulary, diagnosis and drug concept IDs are 0, and the original codes stay in the source value columns.
The repository has a PROVENANCE.md file. It lists every document used, with its version, URL, retrieval date and SHA-256 hash.
Status and honest limits
jpomop is early. The current version number is 0.0.1. Here is what is true today:
- It reads and checks both files and writes eight CDM tables.
- 44 tests pass. Some of them rebuild the worked examples in the FY2026 manual.
- I have tested it only with synthetic data and those manual examples.
- I have not run it on real hospital data.
- I have not measured mapping rates with a full Athena vocabulary.
- Procedures keep their DPC code as the source value. Their concept ID is 0 for now.
- It targets CDM v5.4. The OHDSI site now lists v5.5 as the current version.
Synthetic data shows that the code works on the cases I made. It does not show that it works on real hospital files. Errors such as double counting or wrong joins between Form 1 and EF may not show up until the code is tested on real data.
I plan to release v0.1 at the end of November 2026.
How you can help
I am looking for two kinds of people.
If you work with DPC data in Japan, I would like you to run jpomop inside your own environment. You do not need to share any data. Counts and error messages are enough. If my reading of the manual is wrong, I want to know.
If you work with OHDSI tools, I would like your view on the mapping choices. How should suspected diagnoses be handled? Is the admission date a fair start date for conditions? What would make Japanese inpatient data useful in your network studies?
Issues and pull requests are open on GitHub: https://github.com/kojikojikojikoji/jpomop
The code is under Apache-2.0. Mapping tables made by the project are under CC BY 4.0. This does not cover the masters, the Athena vocabularies or the Kimura table. They keep their own terms.
Top comments (0)