Talk Notes: SMART on FHIR Meets LINE Bot, a Privacy-First Medical AI Architecture

The English write-up of my talk. Chinese original at 演講側記：SMART on FHIR 遇上 LINE Bot.

I gave this talk at the 2026 AI Enterprise Summit. The premise is very Taiwanese and very simple: people already live inside LINE, so if we want patients to actually read their own medical records, the records have to come to them inside LINE. Everything interesting is hiding behind that simple wish.

• Event: 2026 AI Enterprise Summit / Cloud Summit, hosted by iThome
• Time and place: 2026-07-02, 11:15 to 11:45, room 701F
• Title: SMART on FHIR Meets LINE Bot, Building a Privacy-First Medical AI Architecture
• Speaker: Nickle Cheng, Director of Information Systems, Kaohsiung Armed Forces General Hospital

My whole argument is that this is a modular architecture problem, not a coding problem. LINE Bot is one module, the FHIR server is another, and the value comes from how cleanly they connect. If the seams are built on open standards, patients get their records and the system stays honest about who is allowed to see what.

Why I put LINE Bot and SMART on FHIR together

"Let patients read their own lab results and medication history inside LINE" is one of the most common patient services Taiwanese hospitals want to build. From the patient's side it looks like "log in, then see data". I have learned to distrust that framing. That flow is really three independent problems strung into one identity chain, and getting any single segment wrong is a security incident or a patient-safety incident (I break the whole chain down in line-liff-fhir-patient-record-access).

I reach for these two pieces on purpose:

• LINE Bot and LIFF give patients a zero-install entry point. They just open LINE. The catch is that LIFF runs inside a WebView as a public client, so it cannot keep any client secret. I treat that as a design constraint, not a nuisance: it forces the authorization step to use Authorization Code with PKCE, which is where I wanted to end up anyway.
• SMART on FHIR gives me a standardized, cross-system model for authorizing and accessing clinical data. "Which app may read which of which patient's records" becomes an explicit, auditable rule instead of a promise. This is the open-standards half of the system, and it is the half that keeps the data from being locked inside one vendor.

The part everyone underestimates: identify, confirm, authorize

The one line I want people to take home: "which LINE account" is not "which patient" is not "which records they may read".
Those are three independent facts. Each one has to be established on its own. You cannot infer one from another, and every time I see a breach in this space, it is because someone tried to.

sequenceDiagram
    autonumber
    participant U as Patient (LINE)
    participant L as LIFF / LINE Bot
    participant LL as LINE Login
    participant B as In-hospital Binding
    participant AS as FHIR Auth Server
    participant API as FHIR API

    U->>L: Open LIFF / LINE Bot
    L->>LL: LINE Login (OAuth2)
    LL-->>L: line_user_id
    Note over U,B: First binding: in-person KYC<br/>(ID check + consent form + phone OTP)
    U->>B: Verify ID at counter, sign consent, verify phone number
    B->>B: Create line_user_id to patient_id (high assurance)
    B-->>L: Binding done (patient now known)
    L->>AS: Authorization Code + PKCE (patient consents to scope)
    AS-->>L: Access Token (carrying scope)
    L->>API: Read Patient/Observation/MedicationRequest with token
    API-->>L: Return records per scope

The four rules I design by

1. The weakest link is the binding, not the encryption. OAuth2, PKCE, and TLS are mature and I trust them. The step that actually breaks is the "in-hospital binding". Records are highly sensitive PHI, so I hold the binding to an identity-assurance bar no lower than opening a bank account. First-time binding is counter KYC: ID verification, a signed consent form, and a phone OTP. Every later change, a new number, a re-bind, a new device, an unbind then rebind, stays at the same level. I never let "already bound" become an excuse to downgrade.

2. A public client dictates PKCE. LIFF lives in a WebView and cannot hide a secret, so Authorization Code with PKCE is the only honest answer. PKCE protects the authorization code from being intercepted and reused. Encrypting the data on the wire is TLS's job. I keep those two ideas separate on purpose, because conflating them is how people talk themselves into weak designs (details in fhir-oauth2-pkce-data-exchange).

3. Minimize scope. An access token grants only the smallest data range the feature needs. A medication-lookup feature has no business being able to read every imaging study. Scope is where I make the system human-centered, because it is the patient's data and the patient decides how much of it moves.

4. Consent is revocable, binding is releasable. When a patient revokes consent or unbinds, the matching tokens and binding expire immediately and leave a complete, provable audit trail (aligned with fhir-box-phi-security-guide). A system that can grant access but cannot cleanly take it back is not finished.

What I want you to remember

With LINE Bot as the entry point and SMART on FHIR as the authorization backbone, a patient can open LINE and read their own records. But privacy-first is not decided by the encryption algorithm. It is decided by how strict that middle "in-hospital binding" step is, because that step is the one guarding PHI. It deserves bank-grade counter KYC, not convenience-first online self-service. Build the seams on open standards, keep the modules replaceable, and never let convenience quietly lower the bar on the one door that matters.

Further reading

• The three-segment identity chain for reading records from LINE
• How FHIR exchanges data with OAuth2 plus PKCE
• TW Core IG and Taiwan's layered FHIR interoperability architecture
• FHIR Box PHI security implementation guide
• Talk notes: One Person's DevOps
• Chinese original of these notes