Simon, Author at Keta

JP Core FHIR Sandbox

Get started with FHIR and the JP Core profile using our hosted sandbox at https://medplum-jp-core.keta.nyc

Why the thing that looks like too much work is the one that saves you the most of it: a practical introduction for anyone building healthcare software in Japan

The first time anyone opens the FHIR specification, the reaction is roughly the same, and in Japan it usually gets said out loud in three syllables: 「なんだこれ」.

Over 140 resource types. A Patient resource with dozens of elements, most of which you will never populate. Extensions on extensions. ValueSets, CodeSystems, profiles, implementation guides, conformance resources, and a meta.profile field whose entire job is to point at a document explaining the rules for the document you are currently holding. All of this to store what, exactly? A name and a date of birth?

I have watched a lot of very good engineers reach the same conclusion at this point: this is enterprise ceremony, we can do better, we’ll just build our own.

I want to make the case that this reaction is completely reasonable, completely understandable, and, after about six months, completely wrong. Not because FHIR is beautiful. Because you are going to build it anyway.

The 温泉旅館 Problem

There is a phrase Japanese engineers use for a certain kind of system: 温泉旅館建築, or onsen ryokan architecture. The system that started as a modest, elegant little building, then had a wing added, then a corridor to the annex, then a staircase that goes to a floor that no longer exists, until the only person who can navigate it is the one who has worked there for twenty years. The Japanese kitchen has the same idea in 秘伝のタレ, the secret sauce that has been topped up and never emptied since 1952. Delicious. Also, nobody knows what is in it.

Every healthtech product I have ever seen builds an onsen ryokan out of its patient record. It goes like this.

Week 1. patients table. id, family_name, given_name, dob, sex. Clean. Elegant. You feel good.

Week 3. Product wants フリガナ for sorting and for the reception desk. Now you need a second representation of the same name. You add family_kana, given_kana. Then someone asks whether you store 全角 or 半角, and whether the legacy system on the other end is going to send you 半角カナ regardless of what you asked for.

Week 6. A patient changes their name after marriage. The old name still appears on results issued last year. Names now need a validity period, and a flag for which one is current. Your two columns become a table.

Week 9. Insurance. It turns out a patient identifier is not one number: it is 保険者番号, plus 記号, plus 番号, plus 枝番, plus whichever public-payer scheme applies, plus the hospital’s own 患者ID, plus, increasingly, the マイナ保険証 lookup. And the same human being has different identifiers at different facilities, so now you are doing 名寄せ. Your id column has become an identifier system with namespaces.

Week 14. A doctor at the clinic becomes a patient at the clinic. Your users table and your patients table have been arguing about who owns this person’s name for two days.

Week 20. Allergies. Not just “penicillin”: who recorded it, when, how confident are they, was it an allergy or an intolerance, was it observed or reported by the patient’s family, and is it still active. One string field becomes eight.

Week 26. Lab results. A number is not a result. A result is a number, plus a unit, plus a reference range, plus a JLAC10 code, plus the specimen, plus the time it was collected (which is not the time it was reported), plus who ordered it, plus a status, because results get amended and corrected and occasionally retracted.

And here is the punchline. At week 26 you stop, look at the schema you have built, and realise you have independently invented Patient.identifier, HumanName.period, AllergyIntolerance.verificationStatus, and Observation, except yours has no documentation, no test data, no validator, no library support, no one else in the world who understands it, and a notes column that three different features are quietly using as a junk drawer.

Health data is genuinely, irreducibly complex. It is multi-dimensional by nature: every clinical fact carries who, when, by whom, how sure, in what context, superseding what, and expressed in which coding system. FHIR is not a description of an idealised system. FHIR is a description of what your schema is going to look like in three years, written down in advance by several hundred people who already made all of those mistakes. The elegance you are protecting in week 1 does not survive contact with week 26. The only question is whether the complexity you end up with is documented and shared, or 秘伝のタレ.

車輪の再発明 is bad enough. Reinventing the wheel slightly out of round is worse.

You Are Allowed To Use 5% Of It

Here is the part that nobody tells you, and it is the single most useful thing in this post.

You do not need to understand FHIR to benefit from FHIR.

The learning curve people are afraid of is the curve to full conformance: profiles, terminology servers, capability statements, validation pipelines, the whole 作法. That curve is real. But almost nobody needs to climb it on day one, and pretending otherwise is why teams bounce off the standard entirely.

The minimum viable use of FHIR is this: treat it as the answer to “what fields should go in a patient record?”

Open the JP Core Patient profile. Read it as a checklist. It will tell you that you need a kana name representation, that identifiers come in flavours with defined namespaces, that gender and 性別 are not the same conversation, that addresses in Japan have their own shape. Then go and implement that in Postgres, in DynamoDB, in a Rails model, in a spreadsheet if you like. Nobody is checking. There is no FHIR police (残念ながら, no 標準化警察 is going to raid your office).

What you have gained is a data model designed by people who have seen every edge case in twenty countries, for the price of an afternoon’s reading. If you later decide to expose a real FHIR API, you are 80% of the way there because your fields already line up. If you never do, you still shipped a better schema than you would have written yourself.

とりあえずビール, as they say. In this case: とりあえず Patient. Order one resource, see how it goes, order more later.

Cutting Through the Jargon

FHIR has an unusually high jargon-to-substance ratio, and I think this scares away more good engineers than the actual difficulty does. So let me deflate the vocabulary.

A FHIR server is a JSON document store with a REST API on top. That is not a simplification for beginners; that is genuinely what it is. GET /Patient/123 returns a JSON document. POST /Observation creates one. GET /Observation?patient=123&code=http://loinc.org|718-7 is a query string. The clever part is not the technology, it is that somebody already decided what the JSON looks like and what the query parameters are called, so that your client works against Epic, against a Japanese vendor’s EHR, and against your own server without a rewrite.

A Resource is a JSON document with a resourceType field.
A Reference is a foreign key that happens to be a string: {"reference": "Patient/123"}.
A Bundle is an array with a wrapper, so you can send several at once.
A Profile is a validation rule set: spiritually, JSON Schema with a healthcare vocabulary.
An Implementation Guide (IG) is a documentation site generated from a pile of profiles. JP Core is an IG.
A CapabilityStatement is /.well-known for your API, machine-readable.

And SMART on FHIR is OAuth 2.0. That is it. That is the whole thing. It is OAuth 2.0 with an agreed vocabulary for scopes (patient/Observation.read instead of everyone inventing their own scope names), plus a launch context so that when a clinician opens your app from inside the EHR, the token arrives already knowing which patient is on screen. If you have ever integrated “Sign in with Google”, you have already done the hard part of SMART on FHIR. The hardest thing about SMART on FHIR is honestly the name. It stands for Substitutable Medical Applications, Reusable Technologies, which is a backronym so strained it deserves its own 大喜利 segment.

Strip the vocabulary away and the stack is: JSON, HTTP, OAuth. You know all three already. What FHIR adds is agreement, and agreement, not technology, is the expensive part of healthcare integration.

The Real Reason To Do This Now: AI Cannot Read Your 秘伝のタレ

If you have spent any serious time with modern AI, you already believe the next part, and if you haven’t, no blog post is going to convince you. Medicine is going to be transformed by these models, not eventually, but within the working lifetime of everyone reading this. Trial matching for oncology patients who would never otherwise have been screened. Rare disease diagnosis, where families currently spend years and a dozen specialists to get a name for what is wrong. The 指定難病 problem in Japan is a needle-in-haystack problem, which is precisely what these models are good at. Drug discovery and protein structure. Imaging. Early sepsis warning. Ambient documentation that gives doctors their evenings back, a benefit that lands especially hard in a country where 医師の働き方改革 has made physician hours a national policy issue.

But models are only as good as the data you can put in front of them, and this is where the standards argument stops being philosophical and becomes an engineering constraint.

An AI system reasoning over a patient’s history needs to know that KENSA_KEKKA_3 is an HbA1c, that the value is in NGSP percent and not IU, that the reference range differs by lab, and that a result from 2019 was later corrected. If that knowledge lives in a 20-year-old vendor’s column-naming convention and in the head of one 情シス veteran who retires next year, then every AI project at your organisation begins with six months of archaeology, and it starts again from zero at the next hospital. If it lives in coded FHIR Observation resources, the model gets structure, provenance, and units for free, and the work you did at hospital A transfers to hospital B.

There is a second, more immediate effect that I think is under-appreciated, and it is the one that shows up in your sprint velocity next month.

Modern LLMs already know FHIR. The spec, hundreds of implementation guides, HAPI, Medplum, thousands of open source repos, years of Zulip discussion: all of it is in the training data. Ask Claude to generate a valid MedicationRequest, or to write a client that pages through a search Bundle, or to map an HL7 v2 OBX segment to an Observation, and it will do it well, immediately, because it has seen a million examples.

Now ask it to write code against T_KANJA_MST with columns KJ_CD1 through KJ_CD9. It cannot. There are exactly zero examples of your schema in the training data, and there never will be. Every prompt has to carry your entire data dictionary as context, and the model still guesses.

This is a genuinely new argument for standards, and I don’t think it existed three years ago. Standards are pre-defined building blocks (ガンプラのランナー, snapped off and assembled), and the AI multiplier applies to shared building blocks far more than to bespoke ones. Teams building on standard resources are currently getting a large productivity gain that teams on proprietary schemas simply do not get. That gap compounds.

A 130-Year-Old Lesson About Not Standardising

Japan does not need to be lectured about the value of standards. This is the country of JIS, of kanban and poka-yoke, of the 7分間の奇跡, the Shinkansen cleaning crews who reset a 16-car train in seven minutes because every interface in that process is defined down to the second. Standardisation as a competitive advantage is not a foreign import here; it is arguably a national specialty.

Which is what makes the counter-example so instructive. In the 1890s, Tokyo Electric Light bought German AEG generators running at 50Hz. Osaka bought American GE generators running at 60Hz. Two sensible local decisions, made independently, by people optimising for their own situation.

Japan has had a split power grid ever since. In 2011, when the eastern grid desperately needed power, only a few gigawatts could be moved across the seam, because converting between the two halves requires purpose-built frequency conversion stations. A hundred and thirty years later, engineers are still paying for a decision that looked completely reasonable at the time.

Bespoke healthcare data models are frequency conversion stations. Every one you build is a permanent tax on every future integration, and the bill arrives at the worst possible moment: during an emergency, or during a national rollout, or when the AI capability everyone else has just arrived and you cannot connect to it.

So What Is JP Core?

JP Core is Japan’s national base profile for FHIR, the equivalent of US Core in America or AU Core in Australia. It sits on top of FHIR R4 (4.0.1) and adjusts the international resources so that they can actually describe a Japanese patient.

Who built it. JP Core comes from the FHIR日本実装検討WG (the FHIR Japan Implementation Working Group) inside the NeXEHRS課題研究会 at JAMI, the Japan Association of Medical Informatics, chaired by Professor 大江和彦 of the University of Tokyo, with government funding behind parts of the work. It is published at jpfhir.jp, and the related specifications are indexed at std.jpfhir.jp. Version 1.2.0 is the current published line, with 1.3.0 in development as of mid-2026.

It is worth being honest about the status: the guide itself carries a note that it is not formally approved by the Japan HL7 Association and is used at your own risk. Read that as a signal of how early it is rather than as a warning. Early is where influence lives.

Why it needs to exist. Baseline international FHIR does not know about Japan. It has no opinion on:

Kana names. JP Core defines how to carry フリガナ alongside the kanji name, using the ISO 21090 representation extension with SYL, plus a dedicated search parameter so you can sort by kana the way every reception desk in the country expects.
Insurance identifiers. JP Core defines identifier systems for 保険者番号 (eight digits, zero-padded) combined with 記号, 番号 and 枝番, and separate systems for public payer schemes. This is exactly the week-9 problem from earlier, already solved.
Japanese code systems. JLAC10 for labs, YJ codes and HOT numbers for medications, MEDIS disease codes, MERIT-9, STEM7 for procedures, plus dental and endoscopy vocabularies. The international spec assumes LOINC, RxNorm and SNOMED; JP Core binds the resources to what Japanese systems actually emit.
Japanese addresses, dates and text. Including the perennial 和暦/西暦 question. FHIR simply mandates ISO 8601, which means 令和 conversion happens once at the boundary instead of in nineteen different places, which is where it currently lives in most systems I have seen.

The profiles cover the areas you would expect: administration (JP_Patient, JP_Practitioner, JP_Organization, JP_Encounter), medication, diagnostics (JP_Observation, DiagnosticReport, ImagingStudy, Specimen), and clinical (Condition, AllergyIntolerance, Procedure, Immunization).

You may have heard that JP Core is mostly an academic exercise. Until recently that was a fair characterisation. It is not any more, and the reason is the next section.

And Its Industrial Sibling: JP-CLINS

The 電子カルテ情報共有サービス (the Electronic Health Record Information Sharing Service) is the part of Japan’s 医療DX programme that turns all of this from a research topic into a delivery deadline. It is operated by the 社会保険診療報酬支払基金 as part of the 全国医療情報プラットフォーム, it began phased operation in 2025, and full-scale operation is targeted for around the winter of FY2026.

The scope is the 三文書六情報:

Three documents: 診療情報提供書 (referral letter), 退院時サマリー (discharge summary), 健診結果報告書 (health checkup results).
Six information items: 傷病名, 薬剤アレルギー等, その他アレルギー等, 感染症, 検査 (救急・生活習慣病), 処方情報.

The FHIR specification for this is JP-CLINS (CLinical Information Sharing), published at jpfhir.jp/fhir/clins and currently around v1.11. Architecturally, the important thing to notice is that JP-CLINS is a derived IG: it is built on top of JP Core v1.1.x, adding profiles like JP_Patient_eCS, JP_Observation_LabResult_eCS, and JP_Bundle_CLINS for submitting the five information items as a single Bundle. It covers 2文書5情報 plus a patient summary; the checkup report travels a separate path.

This is the layering that makes national standards work, and it is worth internalising: international FHIR → JP Core → JP-CLINS → your application. Each layer constrains the one above it. Learn Patient, and you have already learned most of JP_Patient, which is most of JP_Patient_eCS. The investment compounds rather than resetting.

電子処方箋, the national electronic prescription service, is built on the same foundations.

And the incentives have arrived, which is usually the moment the architecture debate ends: as of 2026 there are 診療報酬 add-ons attached to connecting to the sharing service. When the 加算 shows up in the fee schedule, “we’ll standardise later” stops being an engineering opinion and becomes a budget line.

One more piece of context, because it matters for how you plan. Japan is not starting from zero. SS-MIX2, the standardised storage specification built on HL7 v2.5 messages and maintained under JAMI, has been deployed across a large number of Japanese hospitals for well over a decade, and underpins secondary-use work like MID-NET. That installed base is real, it is not going away this decade, and the practical architecture for most Japanese hospitals over the next several years is HL7 v2.5 and SS-MIX2 underneath, FHIR at the edges, with an adapter in between. Anyone who tells you to rip out SS-MIX2 and go pure FHIR has not been inside a Japanese hospital’s 電算室.

How To Actually Start This Week

Skip the six-month evaluation. Here is a genuinely small first step: an afternoon, not a quarter.

Take a quick squiz at one profile. Open the JP Core Patient profile and just look at how the fields are structured: how the kana name hangs off name, how identifier carries 保険者番号 with its own system URL, what is required and what is optional. You are not studying for an exam. You are looking at somebody else’s answer to a problem you already have.
Start a JP Core sandbox. We run one at https://medplum-jp-core.keta.nyc. Click Anonymous Login and you get your own disposable Medplum open source FHIR server, already loaded with the JP Core profiles and terminology, and seeded with Japanese example patients. Nothing to install, no signup, no Docker, no credit card. The link is bookmarkable, so you can come back to the same sandbox tomorrow.
Round-trip one real record. Take a single patient out of your existing system, map it into a JP_Patient, POST it to your sandbox, let the server validate it against the profile, and read it back. Then do the same with one lab result as an Observation. The gaps you hit on that one record are the honest scope estimate for the whole project, worth more than any spreadsheet, and you will have them by the end of the day.
Then, and only then, argue about architecture. With a working, validated resource in hand, the 稟議 writes itself.

Where We Come In

At Keta we design and build applications on healthcare standards: FHIR, and its very-much-still-alive predecessor HL7 v2. We have spent years doing EHR and EMR integration, SMART on FHIR apps, HL7 v2 interface engines, HIPAA-grade architecture, and AI-driven clinical workflow automation for clients in the United States, which is currently a few years ahead of Japan on this particular road and made most of the expensive mistakes already.

We are now bringing that experience to Japan, and we are especially interested in the hybrid reality described above: SS-MIX2 and HL7 v2 on the inside, JP Core and JP-CLINS at the boundary, AI on top of the result.

If you are staring at the 電子カルテ情報共有サービス deadline, wondering how to get an AI product to talk to a Japanese EHR, or simply arguing internally about whether FHIR is worth the learning curve, we would genuinely enjoy that conversation.

https://keta.nyc

お気軽にご相談ください。

And if you take only one thing from this post: your schema is going to end up as complicated as FHIR either way. You just get to choose whether the rest of the world can read it.