Why SMART on FHIR
The story of FHIRLineBot starts with a policy change. Taiwan's Ministry of Health and Welfare picked HL7 FHIR and SMART on FHIR as the direction for electronic medical records. The goal was to fix an old problem. Hospital information systems (HIS) in Taiwan grew separately for decades, and they do not talk to each other. The ministry even invited the founder of SMART on FHIR to visit Taiwan. I had been watching this for a while. When that happened, I could tell it was serious this time.
What really convinced me was the technology itself. FHIR does not tie you to one programming language. Java, C#, JavaScript, and Ruby all have ready-made libraries. Most servers and tools in the FHIR ecosystem start with a single Docker command. The more I looked, the more familiar it felt: containers, open standards, modular design. These are the same building blocks I use every day. My own technical path and the direction of international healthcare standards turned out to be the same road.
Then came the first Taiwan 50, a national contest that picks fifty representative FHIR implementations. People call it "the 0050 of healthcare". 0050 is a well-known Taiwanese index fund that holds the fifty largest companies on the local stock market, so the nickname fits. I decided to stop thinking and start building. I wanted to know if my idea matched the world standard, and whether it met what the medical field expected.
That is how FHIRLineBot was born. I was pleased with the name for a long time. FHIR is pronounced like "fire", so the Chinese name uses the character for fire. The app runs on LINE, the messaging app that almost everyone in Taiwan uses, so the name also takes the character for line. Put together, the Chinese name reads as "Fire Line Superman": a FHIR app that lives inside LINE. Patients open a chat window and check their visit records, queue status, and health reports. It later won a merit award in that first Taiwan 50.
Winning felt good. But looking back, what I gained along the way is far more useful than the trophy. How to connect OAuth authorization. How to manage servers from many hospitals. How to bind a patient identity. The answers now sit scattered across the specs and code of that project. This series walks the same road again, organized into 30 articles. The goal is simple. The next person who builds a SMART app should take fewer wrong turns.
The wall around medical data
Let me explain why this is worth doing.
Anyone who has worked in a hospital for a while will agree: patient data usually cannot leave the hospital. Change hospital, and your lab tests are done again. Want to organize your own health records? You become a human courier, moving between the apps and websites of every hospital. This is not because hospitals want to make life hard. Each HIS grew on its own for years. Data formats and interfaces are all different, so the systems share no common language.
This wall blocks developers too. You may be able to write an excellent health app. But once you face a different interface spec at every hospital, the integration cost alone can kill the project before it leaves the slide deck.
What FHIR and SMART each solve
These are the two main characters of this series.
FHIR (Fast Healthcare Interoperability Resources) solves "what the data looks like and how to get it". It defines medical data as standard Resources, such as Patient, Observation, and Condition. You read them through a RESTful API. For a web developer, calling a FHIR API feels the same as calling any other JSON API. You can even treat a FHIR server as a database built for healthcare. The tables (the Resource structures) and the query interface are both standardized. Only the query language changes, from SQL to HTTP.
SMART on FHIR solves "how an app plugs in safely". It sits on top of OAuth 2.0 and OpenID Connect. It defines how an app asks for permission, and how it knows which patient is on screen. It also defines how the app reads data with the least privilege it needs.
I like the power socket comparison. If FHIR is the electricity standard, SMART is the shape of the socket. Once both are standard, writing an app is like designing an appliance. You do not build a custom plug for every building. In the United States, standard FHIR APIs and SMART App Launch are now part of EHR certification and compliance rules. Write an app once, and in theory it runs on different medical systems.
In Taiwan, the National Health Insurance Administration and many hospitals have been rolling out FHIR over the past two years. Contests like Taiwan 50 are how a local ecosystem starts. The timing looks about right.
What this series covers
A few things to make clear before we start. SMART on FHIR means the authorization and launch framework. But a working app also needs data display, multi-server management, deployment, and a long list of other things. So this series covers SMART on FHIR application development in the broad sense. The SMART standard is the core, and along the way we look at what building a real medical app involves.
I split the 30 days into five parts:
| Part | Range | Content |
|---|---|---|
| 1. Origins | day01 to day04 | Background and development environment |
| 2. The SMART core | day05 to day14 | The authorization framework in full |
| 3. A useful app | day15 to day22 | Reading and writing clinical data |
| 4. Real-world traps | day23 to day27 | What the standard leaves out, record aggregation, ecosystem, security |
| 5. Launch and beyond | day28 to day30 | Deployment, review, next steps |
Two notes. First, FHIRLineBot is written in Ruby on Rails, but the examples in this series use JS/TS with public sandboxes. You do not need to know Rails, and you do not need a LINE account. A browser and an editor are enough. FHIRLineBot appears as experience notes, a reference point from the real world. Second, every article has a "follow along" section. In my experience, SMART concepts stay abstract when you only read about them. Run the authorization flow once with your own hands, and much of it clicks.
Follow along: a first look at the SMART world
No code on day one. Just a look around. Open your browser and do these two things:
- Browse the SMART App Gallery (apps.smarthealthit.org). It lists SMART apps from around the world. Pick two or three and look at what they have in common: they all claim to run on different electronic medical record systems. That is what standardization buys you.
- Open the SMART Health IT Launcher (launch.smarthealthit.org). This is our most important practice ground for the next month, a public sandbox that simulates an EHR environment. No need to operate it today. A glance at the home page is enough.
After that you get the general idea. Many people are already building houses in this ecosystem. What we will learn is how to build one.
Wrapping up
Today covered three things: the wall around medical data, the FHIR and SMART pair, and the map of this whole series. The story starts with Taiwan 50 and FHIRLineBot, but what this series really wants is to help more people build the next one.
Tomorrow we open a new map and sort out who is responsible for what among FHIR, SMART, OAuth 2.0, and OpenID Connect. An old map will not get you to a new place. More on that tomorrow.