因为工作关系，忙到没空写文，拖稿拖了好久......

FHIR 是什麽，能吃吗？

为什麽会有 FHIR？

基本上 FHIR 主要就是要解决跨系统／跨装置的资料交换问题。

以台湾来说，现行各家医院／医疗照护机构的系统通常是由不同厂商提供，由於是不同厂商开发的软件，底层资料结构、格式可能不一样。这就导致了当这些系统间有资料交换的需求时，会因为这像限制导致各系统间无法有效进行介接，而必须另外写程序进行转换才能完成资料交换这件事情。当中资料的结构、介接时使用的介面（Interface）、栏位的规则与限制都是需要在转换过程中反覆被提出来讨论的东西，也因此会花上很多人力与时间成本。事实上，现在一家系统／产品要进到医院内与院内其他系统整合，平均需要花大约两个月的时间。

上述的问题可说是现行医疗行业的困境，且并不仅限於台湾。为了解决这样的问题，医疗行业势必需要一套医疗资料交换标准来支撑互联互通的需求。这样的需求从早期仅支援医院工作流程，发展到现在已经不仅针对医院，而是需要扩大至所有健康照护领域，并且要具备处理临床与非临床资料的能力。FHIR 就是在这个时空背景下的产物。

换句话说，FHIR 就是医疗界的 USB，让我们可以用一个通用的医资标准 + 通用的互操作性存取机制来交换所有跟医疗有关的资料。

FHIR 相较於现行电子病历标准的优势

• 通用性：FHIR 标准目前在国外被广泛应用，而目前健保是参考 CDA R2 魔改成 108 个单张（实际上医院真正会交换到的东西不到 20 张），拿出去国际基本上没人会鸟你。
• 精简性：FHIR 采用的栏位格式更精简、可读性更高。（Schema 规划更简单易用）
• 可靠性：FHIR 使用现代主流的资料交换技术（HTTPS + REST API），并使用主流的 Oauth 2.0 作为建议的标准化授权认证机制，安全性更有保障。
• 可扩展性：FHIR 拥有相当高度的可扩展性，没有被 FHIR 规范在内的资料可以透过 Extenstion 栏位自行扩充。
• 一致性：你可以在 FHIR 里面，为特定应用情境／场域撰写 Profile 及 Integration Guide（IG，实作指引），来让所有使用这个情境的系统都能有最高度的标准化及一致性。
• 跨装置：FHIR 能广泛应用在各类装置上，就连苹果也早在 iOS 10 就开始支援 FHIR（低头看看你 iPhone 上的健康 APP 吧！） （可惜我没有 iPhone）

基本概念

FHIR 架构与资料结构

• FHIR 把你在进行医疗工作流程中，所有会接触到的资料都标准化为单一个资料结构（Data Structure）。
• FHIR 依照不同资料的性质进行归档，并把相关的资料整理成一个 Resource。
  • 例如病人的姓名、生日、地址等资料都归类在 Patient Resource 里面）
• 依照各 Resource 的分类，FHIR 将几个 Resource 组成一支 Module 方便检视。
  • 例如 Patient、Organization、Encounter 这几个 Resource 是其他更高层 Resource 会需要依赖的底层 Resource，因此一起归类为 Administration Module。
• 各 Module 依照抽象化程度，组成 Level 1 ~ Level 5 等层级，层级越高抽象化程度越高，也越贴近应用面。
  

以工程的角度重新认识 FHIR

• 我们认知的 FHIR，基本上就是一串 Data Model。
• 每个 FHIR Resource (Data Model) 都有固定的 Data Structure（schema）。
• 这些 Data Structure 可以被支援以不同的 Data Format 呈现。
• FHIR 使用主流的 REST API 作为 Interface 与其他系统介接。
  • 实际上不只有 REST API，不过在应用初期这会是最常碰到的交换方式
    

80-20 原则

• FHIR Resource 帮你规划好 80% 绝大多数系统会常用到的栏位（例如病人的姓名、生日、地址这类常用栏位），剩下 20% 客制化／本地化的资料提供一个 Extension 栏位让你自己定义跟扩充。
• 换言之，你可以用 20% 的时间去完成那些通用栏位的交换需求，拿剩下 80% 的时间专注在你自己的业务逻辑上。
• 好处就是可读性高，并且省下非常多规划 Schema 跟 Interface 的时间跟人力。
  

下一篇文章将会讲导读，带各位看懂 FHIR 官方的文件。