CDS Hooks Archives

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: