Taiwan's HIS Proprietary Lock-in, and Why SMART on FHIR Is the Only Way Out

I work in a hospital IT office, and I wrestle with one thing every day: almost every hospital in Taiwan runs its own Hospital Information System (HIS), and none of them talk to each other. I call this phenomenon proprietary lock-in, which most people would recognize as data silos, except I want to stress the root cause behind the silos, that each hospital runs a spec only it and its original vendor can read. This piece is my attempt to lay that out clearly, and to explain why I think there is only one way out, which is SMART on FHIR.

What proprietary lock-in is, and how it grew

Taiwan's medical IT foundation is actually deep. Years ago the big hospitals built or outsourced their own HIS so their own workflows would run. Medical centers often kept a whole team developing in-house, while regional and district hospitals bought commercial packages and then customized them heavily. By the end of it, how each hospital stores its data, defines its fields, and transitions its states became a spec entirely its own.

When systems need to exchange data, they mostly rely on point-to-point interfaces like HL7 v2, stitched one by one by hand. Hospital A needs to connect to Vendor B's lab system, so someone customizes one link; swap the system out, and you customize another. Over the years the whole thing inside a hospital becomes a web held together with tape, it works, but nobody dares touch it. As for crossing between hospitals, the main path has long been electronic medical record exchange, and that trades in documents like CDA, essentially sending a copy of a record over. It is not letting the other end query a specific patient's specific piece of data in real time and with precision.

None of this was stupid. It is the accumulation of history. Every step made sense at the time, and put together they became today's world where nothing connects.

The cost of lock-in is bigger than it looks

The real problem with lock-in is not that it cannot run today, it is that it makes every new thing you want to do more expensive and slower.

First, you cannot pull records across hospitals. A test a patient already had done at Hospital A often gets redone at Hospital B, because the two systems speak different languages. The patient bears the harm, and the whole national health insurance system eats the waste.

Second, any innovation has to clear the original vendor first. If I want to add a small feature to an outpatient workflow, or plug in an AI decision-support tool, my first step is not writing code, it is going back to whoever built the HIS to negotiate. Because the data is locked inside their spec, with no open interface, I cannot reach it. Negotiation, quotes, scheduling, and one round of that can drag a small feature out for half a year.

Third, this is a very deep form of vendor lock-in. You cannot swap the system out, because every customization and every interface grew for this one vendor, and switching means rebuilding the whole hospital. Your bargaining power stays permanently on their side.

Fourth, AI cannot get in, or if it gets in it cannot grow. Everyone has been talking about medical AI for the past couple of years, but for AI to scale, the precondition is that data is reachable and standardized. If every hospital's data model is different, then every hospital you connect to means redoing the data cleaning and mapping from scratch. I did the math on that in Automatically Converting Structured Clinical Data to HL7 FHIR with an LLM, where mapping non-standard data onto a standard model is the single biggest cost. Lock-in turns every hospital into an island, and AI has to land on each one all over again.

Why standardization is the only fix, and why FHIR

To solve lock-in, the direction is actually clear: take those two things, what the data looks like and how you access it, away from each hospital deciding for itself, and converge them onto one shared open standard.

Internationally, that standard already has an answer, HL7 FHIR. FHIR breaks clinical data into individual standard resources, patient, encounter, lab, medication, diagnosis, each with a clearly defined structure, and the access method is the RESTful API everyone knows, not a private interface only the vendor understands. It is like setting a common language for the whole medical data world. Here in Taiwan, the TW Core IG that the MOHW is pushing localizes FHIR, defining Taiwan's own core resources and rules, and that step is the right direction.

But I want to stress that FHIR alone is not enough. FHIR solves how data is described and queried, and it does not solve something equally critical: how an external app gets authorized, safely, to attach into a hospital's system.

Why SMART on FHIR, and not just FHIR

This is exactly where SMART on FHIR sits. It stands on top of FHIR and fills in three things FHIR itself does not handle. One, it uses OAuth2 and OpenID Connect for authorization, so what an app gets is a scoped, time-limited, revocable permission, not the key to the whole database, a mechanism I took apart in Exchanging FHIR Data with OAuth2 + PKCE. Two, it defines the app-launch context, so an app can be invoked from inside the HIS and know which patient and which clinician it is dealing with right now. Three, it standardizes permission scopes, so a control like "this app can only read this patient's medications" becomes a standard way of writing it.

Put those three together, and SMART on FHIR achieves something crucial: it makes apps replaceable and portable. A SMART-compliant app, written once, can in theory attach to any hospital system that supports the standard, write once and run anywhere. That is exactly what unties the knot of lock-in from earlier. Apps are no longer married to a single HIS vendor, hospitals no longer have to go begging the original vendor every time they want a new feature, and innovators can just build an app to the standard, attach it, and use it. My own project, Firefighter Superman, was built along exactly this line of thinking, using SMART on FHIR to attach a LINE bot safely onto record data, with the details in SMART on FHIR Meets LINE Bot.

flowchart TB
  subgraph OLD[Today: proprietary lock-in, point-to-point custom links]
    A1[Hospital A HIS<br/>own spec] ---|custom interface| X1[Lab system]
    A1 ---|custom interface| X2[Imaging system]
    A1 ---|custom interface| X3[New feature / AI]
    B1[Hospital B HIS<br/>another spec] ---|yet another custom link| X4[Same feature, rebuilt]
  end
  subgraph NEW[Way out: SMART on FHIR, standard API + auth layer]
    H[Any hospital<br/>FHIR resources + REST API]
    S[SMART auth layer<br/>OAuth2 / scopes / launch context]
    H --- S
    S -->|write once, run anywhere| APP1[Patient-facing app]
    S --> APP2[AI decision support]
    S --> APP3[Cross-hospital retrieval]
  end
  OLD -.converge onto open standards.-> NEW

The world has already proven this path works

This is not wishful thinking on my part. In the 21st Century Cures Act, the US directly used regulation to require that certified EHRs must open a standardized FHIR API and SMART app launch, turning openness into a legal obligation, and it explicitly bans information blocking. The biggest players in the market, Epic and Oracle Cerner, both support SMART on FHIR, and a third-party app ecosystem has already grown up around it. In other words, the biggest medical IT market in the world has already bet that SMART on FHIR is the answer, and it used the law to push it.

Taiwan's foundation is actually not bad. TW Core IG has already laid down the data-standard piece, and the architecture discussion for cross-hospital FHIR interoperability is under way. What is missing is not the technology, it is the resolve to move it from a demonstration project into the everyday reality of hospitals.

The real obstacles to landing this in Taiwan, which I will not dodge

I do not want this to read like a sales pitch, so I have to be honest about the hard parts.

The biggest obstacle is not technical, it is sunk investment and vendor incentives. Every hospital has put many years and a lot of money into its existing lock-in system, and touching it means touching bone. And for the vendors who build HIS, an open standard means less lock-in, so in the short term they have little incentive to do this on their own. On top of that, what hospitals care about most is no downtime and no errors, and that safety-first constitution is naturally very conservative about swapping out the foundation. These are all real, and I face them every day.

But I believe the direction will not change, because the cost of lock-in grows over time: data keeps piling up, the AI and innovation you want to plug in keeps increasing, and cross-hospital needs keep getting more rigid. The price of the islands only gets more expensive. Rather than taping one more link onto an old interface every time a new need shows up, it is better to accept that this road has to be walked eventually. The pragmatic move is not to flip the whole hospital tomorrow, it is to make everything new grow to the SMART on FHIR standard, let the open part slowly get bigger, and let the old lock-in parts get wrapped up and replaced by the standard step by step.

The one thing I keep saying in Omakase Smart Hospital is exactly this: one person plus open standards can build many of the things that used to require a big vendor and a big budget. The precondition is that the data has to stand on an open standard first. SMART on FHIR is not just the trendier of many options, for the long-term health of Taiwan's medical IT, it is the one way out I can actually see.