FHIR

Epic in Singapore: What It Really Takes to Integrate with NGEMR

Simon · October 16, 2026 · Leave a Comment

Integrating with NGEMR: what it really takes to connect your system to Epic in Singapore, for vendors, startups and cluster teams planning their next interface

The Next Generation Electronic Medical Record went live across NHG Health and NUHS in July 2024, consolidating a long list of legacy systems into one shared record across 37 institutions. SingHealth, the largest of the three public healthcare clusters, starts its rollout from late 2026 through 2028. The SAF Medical Corps comes on board by 2028. MOH has put the whole-sector investment at around S$1.5 billion over ten years. And when the Health Information Act takes effect, expected from early 2027, every licensed healthcare provider, private clinics included, will have to contribute key health information to the NEHR.

Underneath the acronym, NGEMR runs on Epic. The Institute of Mental Health’s case study says so plainly, and so does Synapxe’s own developer playbook.

That means something very practical for anyone whose product or department sits next to a public hospital: every system that used to talk to the old EMR now has to talk to Epic. That includes the queue management system, the medical device feeds, the lab middleware, the specialist registry, the AI tool your clinicians piloted last year, and the startup product you hope to scale across clusters. Some of those connections exist. Many still need to be designed, prioritised, budgeted, built and tested.

This year we designed Epic integration solutions for cutting-edge startups like Triomics and Sapien Health, and implemented them at world-class health systems including Rady Children’s Health, Stanford Health Care and UCSF Health. Before that, we spent years designing Epic integrations of every shape: AI in clinical workflows, surgical device tracking in OpTime, bulk data retrieval for population health, and interoperability strategies for NIH grant proposals.

This post is for two kinds of reader, often sitting in the same meeting:

The people who own the outcome: user champions in the clusters, heads of IT and product at healthtech vendors, startup founders, and the APAC teams of overseas companies whose product already integrates with Epic back home and now needs to work here. For you, the question is scope, cost, timeline and risk.
The people who will design it: solution architects, integration leads and senior engineers who have found the Epic FHIR documentation and are wondering what else they don’t know yet.

Building a healthtech or AI startup? Start here

If you’re a founder or CTO with a product that works, a clinician at one of the clusters who wants to pilot it, and the word “NGEMR” has just appeared in your inbox, this section is for you.

Big systems integrators are built for big programmes. A startup usually needs something different: a senior architect who has done this before, a design that fits a seed or Series A budget, and answers in days rather than after a statement of work has been through three rounds of redlines.

Here is what we’ve seen work for startups taking AI into Epic:

Live inside the clinical workflow, not next to it. AI that sits in a separate tab gets forgotten. A SMART on FHIR launch from the right place, or a CDS Hooks card at the right moment, is what gets clinicians to actually use it.
Reading is easy; write-back is the real design problem. If your AI produces something a clinician should act on, such as a draft note, a risk score or a flagged result, decide early where it lands in the chart and who signs it off.
Prove it in the sandbox first. Epic’s public sandbox and Synapxe’s HealthX simulation of NGEMR let you show a working integration before you ask anyone for analyst time. It is also the most persuasive thing you can put in front of a user champion.
Your user champion is your sponsor. A startup can’t raise an NGEMR workplan item on its own. A champion inside a cluster carries it through review and prioritisation, and they need a clear scope and a realistic cost picture to do that. Make their job easy.
Don’t build what Epic already does. The first question at pre-assessment is whether Epic covers your use case out of the box. Know the answer, and the gap you fill, before you walk in.

If you want to skip ahead: The five ways into Epic explains the options, Speaking Epic covers the part nobody writes down, and The road to go-live in Singapore walks through the process from user champion to go-live.

“Health system” or “cluster”? Some of the vocabulary changes, but Epic stays Epic

If you’ve read American material on Epic integration, including our own, you’ll see the phrase health system everywhere. In the US, each health system (Stanford, UCSF, Rady Children’s) licenses and runs its own Epic instance, with its own build, version, local records and conventions. An integration that works at one site is not automatically portable to the next.

Singapore is set up differently, and in some ways that works in your favour:

Clusters, not health systems. The public sector is organised into three clusters (SingHealth, NHG Health and NUHS), each covering restructured hospitals, national specialty centres, polyclinics and community hospitals in its region.
One record, shared. NGEMR is a single, shared patient record across the clusters that have adopted it, so the “build it again for every customer” tax that US vendors pay is much smaller here.
A national integration team. Integration work goes through the NGEMR team at Synapxe, the national HealthTech agency, which works alongside Epic and the clusters. Much of the Epic build expertise that sits inside each hospital’s IT department in the US sits in Synapxe here.
A published process. Synapxe’s HealthX Innovation Sandbox publishes an EMR Integration Sandbox playbook, including a simulated NGEMR with synthetic data. American vendors would be quite envious.

The catch is the flip side of the same coin. A shared platform means a shared queue. Your integration is not just competing with other requests at one hospital. It is being prioritised against national and MOH strategic projects, operational support and cross-cluster initiatives, all needing time from the same NGEMR analysts.

What doesn’t change is Epic itself: the same APIs, the same modules, the same record types, the same way of thinking. That is where six years on the US side, where Epic was born, pays off.

Why Epic feels so elusive from the outside

Even with Synapxe’s playbook, Epic is a strangely closed world for anyone who isn’t working inside it:

Epic’s main documentation portal, UserWeb, is only open to Epic customers and their staff. Vendors and startups mostly can’t see it.
Screenshots are scarce. Most organisations running Epic restrict them, so you often can’t even see what the screen your app will launch from looks like.
You can’t run Epic locally. No Docker container, no VM. The public sandboxes (Epic’s own, and HealthX’s NGEMR simulation) are good for testing OAuth, token exchange and FHIR payload parsing against synthetic data, but they won’t behave like the real build.
There is no public HL7 v2 sandbox at all.
The real test happens late. You only find out how your integration behaves against real departments, real providers, real procedure records and real security rules once it is configured in a non-production environment, by which point mistakes are expensive.

“Can’t I just ask AI?”

Further than you might expect, but only if you already know what to ask. Today’s frontier models have clearly absorbed a lot about real-world Epic implementations, but they are guarded about what they volunteer.

Start from a blank page and you’ll get a reasonable-looking, generic Implementation Guide. It will be missing exactly the details an Epic team looks for first, and that gap tells them straight away that you haven’t done this before.

A SMART on FHIR launch is a good example. Every app embedded in Epic needs an integration record (an FDI record) that defines the launch URL and the context passed to your app: which patient, which encounter, which user. Leave it out of your design and AI is unlikely to bring it up, so you find out it was needed when the NGEMR team asks. Name it, and suddenly AI becomes a very good assistant.

AI is a powerful accelerator for experienced teams. It can’t tell you what you don’t know to ask.

The five ways into Epic (and why you’ll probably need more than one)

When teams first start researching, they usually find the Epic FHIR APIs and assume that’s the whole story. It’s one stall in the hawker centre. A good meal usually means ordering from a few.

Here is the plain-English version.

1. FHIR APIs: patient-specific, mostly read-only

Epic’s FHIR R4 APIs are the modern, standards-based way in, and Epic implements them well. They are also narrower than most people expect:

They are patient-centric. Most reads and searches need you to already know which patient you are asking about.
They are predominantly read-only. Write support covers a limited set of resources. The NGEMR APIs Synapxe lists are almost all .Search operations, with writes limited to creating a patient and filing vitals as an Observation.
They are request/response. FHIR has no native way to tell you that something happened. If you want to know when a patient is admitted, you would have to keep asking, which is slow and puts load on a production system that thousands of clinicians depend on.

FHIR APIs can be called by backend services (a server talking to a server, no user involved) or by a frontend app launched by a clinician, which brings us to the next one.

2. SMART on FHIR: your app, inside Epic, with single sign-on

A SMART on FHIR launch embeds your web app directly in the Epic screen. The clinician clicks a button, your app opens in a panel inside Epic, and through OAuth 2.0 it already knows who the user is and which patient is on screen. No second login, no searching for the patient again, and your app can then call the FHIR APIs above on that user’s behalf.

Where the button goes matters as much as whether it exists. Launch points can sit in an activity tab, the sidebar, a toolbar or menu, or a Storyboard component. A button buried three menus deep won’t get used, however good the app is. Designing the launch location around the real clinical workflow, and recommending it as part of your implementation package, is half the job.

3. CDS Hooks: the right prompt at the right moment

CDS Hooks lets Epic call your service automatically when something happens in the clinician’s workflow: opening a patient’s chart, or signing an order.

For example: a polyclinic doctor signs an order for an imaging study. Epic fires an order-sign hook to your service, which checks the patient’s recent results and history. If there is something the doctor should know, a card appears before they finish (a warning, a suggestion, or a button that launches your SMART on FHIR app for the full picture).

It is the difference between hoping a clinician remembers to open your tool and having your tool show up exactly when it’s relevant. Whether a given hook is available on NGEMR is a conversation to have early with the NGEMR team.

4. HL7 v2: old school, and still doing the heavy lifting

HL7 v2 is the messaging standard Epic has spoken for decades, through its Bridges interface module. Synapxe’s own playbook calls it the most common way to connect Epic with third parties, and for good reason. It does two things FHIR can’t:

It pushes events to you as they happen, for every patient. Every admission, discharge and transfer (ADT), every appointment change (SIU), every order and result (ORM/ORU), every transcribed document (MDM). If you need to know about every patient who registers at a clinic today, regardless of who they are, this is how.
It still carries the most write capability. Orders, results and documents can flow back into Epic through inbound interfaces in ways the FHIR APIs don’t yet cover.

It isn’t glamorous. It is often the most reliable piece of the whole design.

5. Epic private APIs: the capabilities standards don’t cover

Some things simply aren’t in any standard. Sending a message to a doctor’s In Basket (Epic’s clinical inbox) is the classic example: you might want a result your system produced to land in front of a clinician for review and sign-off, rather than going silently into the chart. Capabilities like this go through Epic’s proprietary APIs (NGEMR lists them as an integration option alongside HL7 and FHIR), which require activation through Epic’s Vendor Services programme and usually carry their own licensing.

And around the edges

Real designs often add analytics extracts from Clarity or Caboodle (Epic’s reporting database and data warehouse) for population-level work, scheduled flat-file drops for high-volume operational batches, and DICOM for imaging. Some logic can’t be integrated at all. Cadence scheduling decision trees, for instance, are evaluated inside the Epic client at runtime and can’t be exported; they have to be documented with the scheduling team.

Choosing the right mix for each data flow is the single biggest driver of scope, cost and timeline. Get it wrong and the project runs over budget. Get it right and the budget paper practically writes itself.

Writing back into the chart: narrower than you think

Reading data out of Epic is the easy part. Writing it back in is narrower, more tightly governed, and where most late-stage surprises happen.

The mechanism depends on the data. A signed clinical note may go in as a FHIR DocumentReference or through an HL7 v2 MDM interface. A discrete score may land in a flowsheet row or a SmartData Element. Each has different build work behind it.
A human usually has to look at it first. Many organisations won’t let a third-party system file finalised data straight into the active chart. Results are routed to a staging area, an In Basket message, or a pended state that a clinician verifies and signs.
Patient-facing messages go through the provider’s own channels, and must respect the patient’s preferences and consent.

Agree the write-back design and the clinical review steps early. It is much cheaper to have that conversation at pre-assessment than at user acceptance testing.

Speaking Epic: the part nobody writes down

Here is the part that you won’t find in any documentation, and that no AI model will tell you: how Epic teams are actually organised, who does what, and what language they speak.

Every Epic organisation is divided into application teams, each owning one part of the system. There are application analysts for Ambulatory (outpatient), Inpatient, ASAP (A&E), OpTime (operating theatres), Willow (pharmacy), Beaker (lab), Radiant (radiology) and Cadence (scheduling). There is a Bridges team for interfaces, a client systems and security team for app registration and access, report writers for Clarity, Physician Builders, and trainers. In Singapore, many of these roles sit in the NGEMR team at Synapxe. Look at Synapxe’s job listings and you’ll see titles like Systems Analyst – Integration (NGEMR). That is the Bridges role.

The boundaries between those teams are where integrations quietly fail.

Take a simple outbound order feed: you want your system to receive every order for a particular procedure. The Ambulatory analyst builds the procedure record and makes sure it appears in the right order sets for the right clinics. The Bridges analyst builds the interface that decides which orders leave Epic, and how the codes are mapped on the way out. If the new procedure isn’t added to the interface filter, the clinician orders it, everything looks fine on screen, and your system never hears about it. Each team reasonably assumes the other has it covered.

Fixing that, or better, preventing it, means talking to each team in its own language. Epic runs on records, and its people refer to them by three-letter master file names:

EAP: procedures (what gets ordered)
LRR: result components (the individual values a result is made of)
LLB: the labs results come from
SER and DEP: providers and departments
FDI: the integration record behind a SMART on FHIR launch

An Implementation Guide that says “please configure the orders” gets put to the back of the queue. One that says “please add these EAP records to the outbound ORM filter, and map these LRRs to the following codes for results from this LLB” tells the NGEMR team you have done this before, and gets scheduled.

This is also why we work alongside an Epic Physician Builder: a practising doctor and Epic-certified power user who knows the system from the clinician’s side of the screen. When the question is “where would a doctor actually click?” or “will nurses really use this?”, documentation won’t answer it and a Physician Builder will.

The road to go-live in Singapore

Synapxe’s playbook sets out four stages for integrating an external system with NGEMR in production. In plain terms:

Pre-assessment. A user champion from a cluster (or MOH, MOHH or MOHT) drives the request. The NGEMR team and Epic first check whether something Epic already offers out of the box meets the need, because that always comes first. If not, the NGEMR team, Epic and the vendor agree on an integration option (HL7, FHIR and so on), and the champion lines up Capex and Opex budget, including any Epic API or interface licensing.
Budgeting and approval. The request goes through the cluster’s Internal Review and Prioritisation process. A Synapxe project manager raises a workplan item, which is prioritised against national and MOH strategic projects, operational support, cross-cluster initiatives and general enhancements.
Contracting. Budget approval, the contract with the vendor, and any additional Epic contracting.
Implementation. A kickoff with the vendor, the NGEMR team and Epic; Solution Review Board approval and a TISO security risk assessment where required; build, testing with the external system, and go-live.

A few things this process tells you, if you read between the lines:

“Epic can already do this” is the first question, not the last. Before your product gets a slot, someone will ask whether native Epic covers it. The best answer separates what Epic can do from what is actually licensed, built and used, and points at the gaps where Epic genuinely doesn’t reach: handoffs between organisations, specialised device data, processes still held together by phone calls and spreadsheets. Products that complement native workflows get approved far more easily than ones that compete with them.
The user champion is your most important stakeholder. They need a clear, credible scope and a realistic cost picture to take into an internal prioritisation meeting. Help them look good.
The queue rewards preparation. In a shared queue, you can’t just chope a slot by leaving a tissue packet on the table. The requests that move are the ones that arrive fully specified: the roles involved, every build and security step, the records to be configured, and test scripts.
Configuration hours are not calendar time. In our experience, an integration needing only around 20 hours of actual configuration commonly takes 8 to 12 weeks from kickoff to production, and often longer. It has to fit around analyst workplans, testing sign-offs and change control windows.
Costs are spread around. Epic licensing for APIs and interfaces, infrastructure load, and above all analyst and security team time, often the largest hidden cost and the hardest to schedule. Map it early, so the champion isn’t blindsided at the budget stage.

Kiasu is a virtue here: seven questions to answer before you raise the workplan item

In integration projects, being a little kiasu pays. Before you take a proposal into cluster review, or accept one from a vendor, try answering these. The ones that are hard to answer are where the project risk is.

Has someone checked what Epic can already do, out of the box, and what is actually switched on for NGEMR? Can you explain the gap in one sentence?
For each data flow, which mechanism are you using, and why? FHIR, SMART on FHIR, CDS Hooks, HL7 v2, private API, extract or file drop. If the answer is “FHIR for everything”, look again.
Do you need to know about events as they happen, across all patients? If so, where are those events coming from?
What, exactly, gets written back into the chart, and who reviews it before it’s final?
Where will the clinician launch your app from, and have you checked that with someone who actually uses Epic every day?
Which Epic teams need to do build work, and does your Implementation Guide name the records they’ll touch?
What does it cost, beyond your own fee? Epic licensing, interface capacity, analyst time and security review, and who is paying for each.

If you can answer all seven with confidence, you’re ahead of most. If you can’t, that’s normal, and very fixable.

Why a team in Tokyo and New York?

We are not based in Singapore, and we won’t pretend otherwise. But two things make us an unusually good fit for Epic work here.

We share your working day. Singapore Standard Time is just one hour behind Tokyo. A 9am call in Singapore is a 10am call for us: no midnight calls, no waiting a day for a reply. And with the rest of our team in New York, work on a tricky interface problem carries on overnight and lands back with you in the morning.

The US is Epic’s home ground, and we’ve spent years in it. For more than six years we’ve designed and delivered Epic integrations across a wide range of American health systems, from academic medical centres to children’s hospitals, and for a wide range of products, from clinical AI and oncology platforms to surgical device tracking, population health analytics and research data pipelines. Singapore’s NGEMR is newer, but the Epic underneath is the same Epic. The requirements, edge cases and “we didn’t know we needed that” moments you’re likely to meet, we have very probably met before.

That matters most for the overseas companies using Singapore as their regional base. If your product is already integrated with Epic in the US, a surprising amount of that work can carry over, as long as someone who knows both sides maps what changes and what doesn’t.

How Keta can help

We design Epic integrations, and we help get them through the process and into use. Depending on where you are, that could look like:

A startup sprint: for early-stage teams, a short, fixed-scope engagement to choose the right integration pattern, prove it in the sandbox, and produce the scope and Implementation Guide your user champion needs to take into review.
An integration design review: a short engagement to look at your use case and recommend the right mix of FHIR, SMART on FHIR, CDS Hooks, HL7 v2 and private APIs, with an honest view of scope, cost and timeline. Useful before the budget paper goes in.
Solution architecture: end-to-end technical design for your integration, including write-back, security, identity and infrastructure.
Implementation Guides: written in the language the NGEMR team speaks: records, roles, build steps, security steps and test scripts.
Build and testing: SMART on FHIR apps, backend services and interfaces, tested in the sandboxes first so that the non-production environment holds no surprises.
Implementation support: working alongside the user champion, Synapxe, Epic and your own team through review, build, testing, training and go-live.
Advisory: an independent second opinion on a vendor’s integration proposal, or on whether a product should integrate with Epic at all.

If you’re planning something that needs to talk to NGEMR, or you’re part of the SingHealth transition and wondering what happens to the systems around it, we’d be glad to talk. Send us a few lines about what you’re working on and we’ll revert in your time zone. Consider it a virtual kopi session: no hard sell, just a frank conversation about what it would take.

Keta is a healthcare technology company based in New York and Tokyo, please don’t hesitate to get in touch.

Tokyo

Aoyama Ezaki Bldg 3F, 1‑1‑16 Shibuya, Shibuya-ku, Tokyo 150‑0002

New York City

Work Heights, 506 Warren St, Brooklyn, NY 11217

Simon Johnson

Simon is the lead architect for JupyterHealth and has spent more than six years designing Epic integrations, helping startups like Sapien Health go from zero to one and deploying clinical applications at major health systems across the US.

Maxime Guilbot

Maxime is the founder of Ekohe and has been based in Tokyo for more than a decade, helping companies across Asia adopt AI and build software.

To learn more about FHIR and healthcare interoperability, visit our Resources page.

And if you take only one thing from this post: the APIs are the easy part. Integrating with Epic is mostly about knowing which door to use, who holds the key, and how to ask them in their own language. Get those right, and NGEMR becomes a very good platform to build on.

Sources:

Healthcare DX in Japan: Adopting Electronic Medical Records and Interoperability Doesn’t Have to Be an All-or-Nothing Leap

Simon · October 12, 2026 · Leave a Comment

No all-or-nothing leap required: incremental options for moving to electronic medical records and interoperability, for anyone leading healthcare DX in Japan ahead of the 2030 100% target

Over many years we have built systems and led AI adoption for all kinds of organizations, and one lesson has been learned the hard way.

AI does not transform an organization on its own.

Transformation happens only when three things come together: systems built for the way you actually work, an internal team that runs them and keeps improving them day to day, and the organizational change that lets both take root. Miss any one of them and you get what Japanese calls 「仏作って魂入れず」: carving the Buddha statue but never breathing the spirit into it. An expensive system that, a few years later, sits gathering dust with nobody using it. We have seen that scene many times, in Japan and in the United States.

Healthcare DX is no different. You can buy the “D” (digital). You cannot buy the “X” (transformation). Installing a new system is not DX; DX happens when people and the organization make that system stick.

This post is written for the hospital and clinic leaders tasked with healthcare DX or with adopting or replacing an EMR: administrative directors (事務長), IT departments (情シス), DX leads, and corporate planning. It is not about technical detail. It is about the management decision: what to do, in what order, and with how much risk.

First, what is actually happening

Many readers will know this already, but it is worth laying out. Healthcare DX is no longer something to get around to someday. It is a national project with deadlines.

Winter 2026: nationwide launch of the 電子カルテ情報共有サービス (Electronic Medical Record Information Sharing Service)
October 2026: the Social Insurance Medical Fee Payment Fund is reorganized into the “DX審査支払機構” (Healthcare Information Infrastructure and Medical Fee Review and Payment Organization), with promoting healthcare DX formally added to its mandate
FY2027: rollout begins of certified, cloud-native EMRs that support the information sharing service (for clinics and small-to-mid-sized hospitals, availability is planned from April 2027)
By FY2028: target of 100% EMR adoption for hospitals with 200+ beds (excluding hospitals centered on long-term care beds, among others)
By end of 2030: target of 100% EMR adoption

Meanwhile, according to the 2023 Survey of Medical Institutions, only 58.1% of hospitals and 43.3% of general clinics had fully adopted electronic records. The distance to the finish line is not short.

The Minister of Health, Labour and Welfare has described the goal as taking digital infrastructure that each institution built as an isolated “point” and reconnecting it, under common rules and a shared platform, “from points into lines, and from lines into a surface.” The direction is clear. The FY2026 revision to medical fee schedules also introduced an additional reimbursement for putting electronic clinical-information sharing in place.

Listen to people on the ground, though, and even those who agree with the direction are clearly asking, “So what are we supposed to do?”

“Show us the funding, not just the targets.” Margins are tight, and adopting or upgrading an EMR is expensive. Hospital associations have repeatedly asked for support for upgrades and modifications, not just new installations.
“Our replacement cycle comes before 2030.” For many hospitals, the current EMR’s lease or maintenance contract ends before the national target date.
“There is no standard yet for cloud-native EMRs at large-hospital scale.” Some are calling for a two-stage migration, upgrading on-premises first and moving to the cloud once a standard exists, with subsidies for both stages.
“If we go to the cloud, what happens in a disaster?” Concern about power outages and severed network lines runs deep, and many say a hybrid of cloud and on-premises is the realistic end state.
“We were told it was cloud-based, but they just moved our in-house server into a data center.” The so-called “cloud lift.” Cloud is supposed to mean paying for what you use, yet quotes that reserve multiple terabytes of dedicated server capacity from day one are not unusual.
“If you start small, you never get big.” One camp says go carefully; the other says nothing moves without a bold step. Both have a point.

We think every one of these concerns is legitimate. We also think most of them already have answers, both technical and in how the work is approached.

Living with the EMR you have been married to for years

The relationship between a hospital and its EMR is often compared to a long marriage. It is not that there are no complaints. It is just that leaving is far too much trouble.

The reasons are rational.

Stay with the same vendor and past clinical data carries over smoothly and day-to-day operations barely change. Unless the system is truly painful to use, the frontline voice says, “Keep what we have.” But when switching is off the table, renewal costs stay stubbornly high. An upgrade that should be cheaper than a new install often ends up costing about the same. We hear this from administrative directors again and again.

And when you do try to switch, migrating historical data becomes the wall. Even hospitals under 100 beds can be quoted tens of millions of yen just to export their data into a new EMR’s format. So the old system is kept around for read-only reference, and two sets of maintenance fees get paid indefinitely. That is the real nature of this 「腐れ縁」, the relationship you cannot get out of.

What we most want to say is this: adopting or upgrading an EMR is not a choice between replacing everything and doing nothing.

There is no need for an all-or-nothing investment, what Japanese calls 清水の舞台から飛び降りる (“leaping off the Kiyomizu stage”), the idiom for staking everything on one bold decision. There are many ways to move forward in stages, with a clear view of what comes next, matched to your budget, your replacement cycle, and the realities of your clinical teams.

Five options for moving forward in stages

Option 1: Keep your current EMR exactly as it is, and add an interoperability layer

The smallest step, and the fastest to start.

Without touching your existing EMR at all, we build an interoperability layer on top of it, known as a FHIR facade server. It works as an interpreter: it translates the data in your existing system into Japan’s national standard, HL7 FHIR (JP Core and JP-CLINS), so it can be exchanged with the outside world.

Best for: organizations whose EMR replacement is still some way off, but who need to connect to the information sharing service or to AI tools now
Why it matters: nothing changes on screen or in clinical workflows. And because your data can now be exported in a standard format, the cost and effort of migrating data to any future vendor drops dramatically. Think of it as insurance: turning a relationship you cannot leave into one you could end amicably at any time.

Option 2: Keep the screens and workflows, and replace only the foundation underneath

Tokyo Station’s Marunouchi building was retrofitted with seismic isolation installed beneath it while its original façade was preserved, and while it kept operating as a station.

The same can be done with an EMR. The screens and workflows your staff use every day stay exactly as they are, while the foundation behind them, the database and servers, is replaced with a modern, cloud-native architecture built for security and interoperability.

Best for: organizations where staff are comfortable with the current system and do not want it to change, but aging infrastructure, security, or maintenance costs are a real problem
Why it matters: there is almost no staff retraining. The most overlooked cost of an EMR migration is usually not the system itself but the burden on clinical staff and the loss of productivity during the transition. This option keeps that to a minimum.

Option 3: Build a specialty-specific EMR from proven, existing modules

Psychiatry, ophthalmology, dialysis, home care, rehabilitation: plenty of specialties find that general-purpose EMRs never really fit how they work, and end up running paper and Excel alongside them.

In those cases, there is the option of building a specialty EMR. That does not mean hand-crafting everything from scratch. We assemble existing modules that already run in production EMRs across the United States and have been hardened in real clinical use, and custom-build only the parts unique to your specialty.

Best for: organizations whose specialty is poorly served by off-the-shelf packages, or who have no EMR yet and want to choose the right one from the start
Why it matters: because it is built on a FHIR foundation from day one, support for the information sharing service and for AI integration is built in rather than bolted on later.

Option 4: On-site development, fully managed cloud, or both

Cloud or on-premises? There is no single right answer. It depends on business continuity planning (BCP) for disasters, your existing network environment, and your in-house IT capacity.

We work either way.

On-site: our engineers embed with your team, working shoulder to shoulder with clinical staff and IT (in the US this is called the “forward deployed engineer” model). Well suited to on-premises builds and to detailed integration with existing in-house systems.
Fully managed: we handle everything in the cloud, from build through operations and maintenance. Well suited to organizations with few dedicated IT staff.
Hybrid: a cloud setup for normal operations, with the ability to keep treating patients on-site during a disaster or network outage. The real architectural question is not “cloud or on-prem” but “what lives where.”

Option 5: Support for people and the organization, to make the system take root

As we said at the start, installing a system does not change an organization.

Beyond creating training materials such as user manuals and training videos, we work directly with your clinical teams, physicians, nurses, and medical office staff, to build a migration plan grounded in how things really work on the floor. Which department moves first, when, and starting with which workflows. How to bring key people on board. How to protect day-to-day operations during the transition.

Implementing a system is like the wedding. What really matters is how you build the marriage that follows.

A migration that ignores standards just kicks the can down the road

Whichever of the five options you choose, there is one condition we will not compromise on.

Support for international standards such as HL7 FHIR.

However modern the cloud EMR you move to, if it still stores data in a vendor-proprietary format, you have only postponed the problem (問題の先送り). At the next replacement, five or ten years from now, you will hit the same data migration wall and the same quote for tens of millions of yen. An investment that leaves a problem for the future (将来に禍根を残す) is never cheap, however low the upfront cost.

In our previous post, “FHIR in Japan: The Over-Engineered Standard That Turns Out To Be the Shortcut”, we explained the value of FHIR for a technical audience. From a management perspective, the key points are these:

Lower vendor switching costs: if data can move in and out in a standard format, the cost of switching EMRs falls sharply. But data merely being stored in FHIR format is not enough; the system must be able to export it, and other systems must be able to import it. Make sure you check this whenever you receive a proposal.
Plug straight into national programs: both the information sharing service (三文書六情報, “3 documents and 6 types of information”) and electronic prescriptions are built on JP Core and JP-CLINS, Japan’s national FHIR standards. If you support the standard, you stop paying for one-off modifications every time a national program changes.
A prerequisite for AI: AI is only as good as the data it is given. With standardized data, AI can correctly understand what the data means, and something built for one hospital can be rolled out to another as-is. With proprietary formats, every AI project starts with months of data cleanup.
Escape the 「秘伝のタレ」 (secret family sauce): after years of patches, the system’s real specification often lives only in the head of one veteran staff member. Getting out from under that is a major risk reduction in itself.

If you or the engineers on your team want the technical background, we encourage you to read the previous post.

Seven questions to ask about any vendor proposal before you write the 稟議

When you receive a proposal to adopt or replace an EMR, put these questions to the vendor. The more of them they struggle to answer, the more future risk the proposal is hiding.

Getting data out: Can all of our clinical data be exported in HL7 FHIR (JP Core) format? Is there an extra charge for that?
Getting data in: Can you import data exported in FHIR format from another vendor’s EMR?
National programs: Is support for the information sharing service a standard feature, or does it require custom modification or extra fees?
What “cloud” really means: Is your “cloud” product actually cloud-native, or is it our in-house server moved to the cloud (a cloud lift)? Is pricing based on usage?
Continuity in a disaster: If there is a power outage or the network goes down, how do we keep treating patients?
Incremental migration: Can we switch over in stages, by department or by function? Can the old system run in parallel during the transition?
External connections: If we later want to connect AI tools or other systems, can we do so through standard APIs? Is there a fee for each connection?

Simply comparing vendors’ answers to these seven questions will reveal a good deal about each proposal’s true total cost. If you are not sure how to read the answers, or want help working out which option fits your organization, we are happy to talk.

What we have been working on for more than six years

On May 1, 2020, final rules implementing the 21st Century Cures Act were published in the US Federal Register, requiring EMR vendors, healthcare providers, and health insurers to exchange data through standard HL7 FHIR APIs.

For more than six years since then, we have worked with hospitals and clinics in the United States on exactly this problem: EMR integration, FHIR-based interoperability infrastructure, migration off legacy systems, and AI-driven automation of clinical workflows. We have seen what works, and we have seen the expensive mistakes.

The United States is a few years ahead of Japan on this road. That experience is something Japanese healthcare organizations can learn from, what Japanese calls 「他山の石」, a stone from another mountain that can polish your own jewel. There is no need to repeat the same mistakes.

Keta is a healthcare technology company based in New York and Tokyo, please don’t hesitate to get in touch.

Tokyo

Aoyama Ezaki Bldg 3F, 1‑1‑16 Shibuya, Shibuya-ku, Tokyo 150‑0002

New York City

Work Heights, 506 Warren St, Brooklyn, NY 11217

Simon Johnson

Simon is the lead architect for JupyterHealth and has helped startups like Sapien Health go from zero to one, building clinical applications and integrating with major health systems across the US.

Maxime Guilbot

Maxime is the founder of Ekohe and has been based in Tokyo for more than a decade, helping Japanese companies adopt AI and build software.

To learn more about FHIR and healthcare interoperability, visit our Resources page.

And if you take only one thing from this post: moving to a new EMR does not have to be a single leap off the Kiyomizu stage. Tapping the stone bridge before you cross it (石橋を叩いて渡る) is the right instinct. Just don’t tap it so long that 2030 arrives before you cross. And whichever bridge you choose, make sure it leads to a standard on the other side.

FHIR in Japan: The Over-Engineered Standard That Turns Out To Be the Shortcut

Simon · September 12, 2026 · Leave a Comment

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.

Keta is a healthcare technology company based in New York and Tokyo, please don’t hesitate to get in touch.

Tokyo

Aoyama Ezaki Bldg 3F, 1‑1‑16 Shibuya, Shibuya-ku, Tokyo 150‑0002

New York City

Work Heights, 506 Warren St, Brooklyn, NY 11217

Simon Johnson

Simon is the lead architect for JupyterHealth and has helped startups like Sapien Health go from zero to one, building clinical applications and integrating with major health systems across the US.

Maxime Guilbot

Maxime is the founder of Ekohe and has been based in Tokyo for more than a decade, helping Japanese companies adopt AI and build software.

To learn more about FHIR and healthcare interoperability, visit our Resources page.

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.