【FHIR应用实例：台中荣总】瞄准精准医疗即时战情室，中荣先以FHIR结合生理量测练兵

“我们要打造一套精准医疗即时战情室！”台中荣总资讯室资讯工程师暨智慧医疗AI小组组长范承佑说道。去年开始，台中荣总瞄准精准医疗，要建立一套战情室来即时汇整病人各种生理量测数值，并以一套仪表板来呈现数值走势，帮助医护人员即时决策。而战情室的关键资讯，不只来自院内医疗资讯系统（HIS）资料，还包括了各种外部IoT医疗设备的连续性资料，譬如像是生理量测机、呼吸器、穿戴式装置等。

但是，“要整合这些资料且即时更新资讯，可不简单。”范承佑指出，不像院内医疗资料，可轻易从核心数据库捞取，这些来自外部厂商的IoT生理量测设备资料，会因为资料格式和量测数值内容的不同，而难以整合。

比如，一些厂商的IoT设备资料格式，可能采JSON、XML，或者是自订的资料格式；而同样是生理量测机，一些厂牌可能只显示心率、呼吸值，另一些可能显示呼吸次数、波型资讯等。

这对IT人员来说，就有两个挑战。首先，工程师必须想办法整合不同格式的生理量数值，因此得花时间理解每台量测机的所有资料字段，再将所需的资料转换为医院统一格式；同时，工程师也得理解不同厂牌生理量测机所产生的资讯，并从中捞取医院所需要的资讯，而非全盘接受。也因此，“医院每新增一款生理量测机，工程师就得挪出更多时间来处理资料介接问题。”

台中荣总资讯室资讯工程师范承佑指出，团队以MongoDB自建一套FHIR服务器，希望透过FHIR RESTful API将中央站生理量测数值转换为FHIR格式，存入FHIR服务器。图片来源／台中荣总

以FHIR打破资料隔阂，先从小规模病房试验

为解决资料标准不一的问题，台中荣总IT团队找寻不同解决方案，后来看上新一代国际医疗资料交换标准FHIR，决定以FHIR来串接不同设备的资料。FHIR问世九年，由专门制定医疗资料交换标准的国际HL 7协会设计，目的是要解决前几代标准（如CDA）的问题，比如将复杂资料字段规范简化、可支援临床和非临床类型资料，以及支援更多资料格式，像是XML、JSON和Turtle。

更重要的是，FHIR遵照HTTP网络通讯协定，以行动装置常见的RESTful API来介接资料，因此，只要是支援网络传输技术的IoT设备，就可以透过FHIR来交换资料，以弥补HL7 v2、HL7 v3、CDA的不足。透过FHIR，IT团队就不必再一对一自订API，来串接每款生理量测机。

正因为这些优点，台中荣总决定以FHIR来打造即时战情室，于是选定院内一间只有15台生理量测机的病房，来小规模测试FHIR整合资料的能力。范承佑指出，还没采用FHIR前，战情室的资料处理流程是由每台生理量测机收集心率、呼吸数值，再将这些数值统一汇整至一台厂商提供的中央站，再由中央站将这些资料传送至医院接收端数据库。这些资料经过医院数据库分析处理，就可透过UI仪表板来呈现数值变化，供第一线医护人员参考。

有了FHIR，原本的资料处理流程就能以两种理想情境来实现，一种是将中央站汇整的资料，以FHIR RESTful API来介接至医院接收端的FHIR服务器，最后在FHIR服务器中分析数据，以仪表板来呈现即时数值变化。其中的中央站资料介接工作，可由医院或厂商来进行。

另一个理想情境，则是直接在各IoT生理量测机端，以FHIR RESTful API将资料储存至医院接收端的FHIR服务器，最后再以仪表板即时呈现数值变化。也就是说，在这个情境中，资料介接的地方从中央站改为每台生理量测机，直接省略中央站。不过这种理想情境，还得在厂商设备支援FHIR的前提下才能实现。

与此同时，范承佑也研究了FHIR资料格式规范，像是生理量测常用的资料字段定义Patient和Observation。同时，他也尝试了不同的FHIR工具，包括免费开源的HAPI FHIR服务器，以及付费的Azure API for FHIR、Google Cloud Healthcare API和AWS FHIR云端平台等，都试过了一遍。

不过，几经考量，“我们决定自己来建立一套适合执行FHIR的环境，”范承佑说。

以Node.js和MongoDB自建FHIR环境，从尝试中不断修正

他解释，这是因为，团队想先熟悉FHIR整体运作流程。“我们想了解，资料从IoT设备端转换为FHIR格式、进入数据库，最后再以UI仪表板呈现数值变化的过程。”于是，台中荣总以MongoDB自建FHIR数据库服务器，再以Node.js来打造呈现生理数值变化的UI仪表板。

由于院内IoT生理量测设备已有原本介接的数据库，因此不得更动资料介接模式。台中荣总想出一套解法，从原本数据库中捞出所需资料并转换为FHIR格式，储存至MongoDB。图片来源／台中荣总

然而，正当团队想要串接起FHIR资料传输流程时，却发现3个问题。首先，台中荣总现有的IoT生理量测机并未支援FHIR格式，因此无法直接以FHIR格式来传输资料；再来是通讯端点Socket问题，因为，这些IoT生理量测机原本已有一套介接方式，已由Socket指定特定IP位置，将资料传送至院内数据库，因此要将IoT设备资料介接到FHIR服务器，就得重新设定Socket的介接IP位置。

范承佑指出，如果将资料接收端改为FHIR服务器，会衍生出资料是否能正确传送和显示的问题。此外，如果要改变接收端环境，还得重新写程式，较耗费时间。

而重新写程式则会引发第3个问题，也就是程式改写时，院内接收端会无法接收IoT生理量测资料，因此造成仪表板无法显示资料，影响第一线医护人员的工作流程。

于是，台中荣总想出一套解法，在不更动现有工作流程的情况下，来进行FHIR资料格式转换。也就是说，他们维持原本IoT生理量测机和中央站的资料处理流程，但在原本接收端的数据库中，“将资料捞出来，转换为FHIR格式，”并存入FHIR服务器，最后再以Node.js来呈现生理量测数值变化。

进一步来说，团队将FHIR资料转换分为三步骤：首先是从原本数据库抓取生理量测资料，并转换为FHIR格式规范的Patient和Observation型式，再来将这些FHIR格式资料，以POST指令传送至FHIR服务器；这两个步骤，都以程式语言Python来执行。完成这两个步骤后，最后一步就是将FHIR服务器中的生理量测资料，以GET指令捞出，再以Node.js来呈现数值变化。

台中荣总资讯室资讯工程师范承佑指出，在资料转换过程中，以Python从数据库的大量生理量测数值中，抓取出病历号、姓名、性别等资讯，并将这些资讯转换为FHIR Patient资料型式。图片来源／台中荣总

除了Patient型式资料，台中荣总也以Python从数据库中捞取病历号、量测时间、心率等生理量测值，并将这些值转换为FHIR Observation型式，再将这些资料存入FHIR服务器。图片来源／台中荣总

范承佑也以资料转换实例，来说明从数据库中，找出所需资料并转换为FHIR格式资料的过程。比如以Python从数据库中的大量生理量测数值，抓取出病历号、姓名、性别等资讯，并将这些资讯转换为FHIR Patient资料型式；另一个例子则是透过Python，从数据库中捞取病历号、量测时间、心率等生理量测值，并将这些值转换为FHIR Observation型式，再将这些资料存入FHIR服务器。

这些资料整合至FHIR服务器后，便可清楚呈现捞取资料的类别和细节，包括一位病患的基本资料、生理量测资讯如心率和量测时间等。

最后，为了将这些资料呈现给第一线医护人员，范承佑团队也写了支网页程式，来呈现患者即时量测数据。在网页首页，使用者可以文字形式来阅览病患姓名、病历号、性别和量测记录等资讯。如需要更详细的资讯，使用者只需点击病历号，就可查看视觉化的患者连续生理量测数值变化，一旁还会以JSON档案内容来对照，来确认数值。

台中荣总将FHIR数据库分析后的数值，以网页界面呈现，除了显示生理量测数值变化外，还会附上JSON档资料内容，给第一线医护人员参考。图片来源／台中荣总

FHIR实作反思：即时性资料量大是最大问题

在这场一年多的试验中，台中荣总IT团队虽然成功以FHIR来整合院内资料和IoT设备量测数值，但也意识到不少实作问题。首先，“IoT生理量测机的即时性资料过于庞大，”如果只依靠FHIR Server作为储存端，在转换和传送资料时，就可能发生传送效能不佳或延迟的状况。

这是因为，IoT中央站每分钟会派送一次资料，而且每份资料都会先转换为FHIR格式资料（比如心率存一套、呼吸值存一套），如此就大幅增加储存容量。范承佑指出，就FHIR测试病房来说，每分钟会派送15台IoT生理量测机资料，而在转换为FHIR的情形下，每天产生约为30MB的资料量；与之相比，原本同一病房在未采用FHIR的情况下，每周也才产生20MB的资料量。

也因此，为解决资料量大造成的传送效能问题，范承佑团队想出一个方法，也就是当IoT生理量测机以FHIR格式将资料传送至指定地点时，只需存取所需资料即可，或于资料再次转传时，将资料转为FHIR格式传送即可。

至于储存量大的问题，团队思考，要是能将同一病患同一时间的生理量测资料整合为一，比如将心率和呼吸值合并为一笔资料来储存，或是以Data Hub文字档方式储存（如JSON），也许能克服储存空间不足的问题。

另外，由于前述每产生一笔生理量测资料，就会存为一份FHIR Observation格式资料，因此当资料过多时，容易发生前端解析Observation资料过久的状况。对此，团队打算将前端解析FHIR格式资料的工作，改为在后端接收IoT生理量测资料时，先将所需资料提出，再送到前端仪表板显示。

不只如此，面对资料爆量问题，团队也思考FHIR服务器的布建。范承佑指出，要是病房加入更多IoT生理量测机，他们计划部建更多FHIR服务器，来缓解设备过多造成的资料爆量问题；或是从机制上调整，先在FHIR服务器接收IoT设备资讯时，捞出必要资讯，并直接送至仪表板界面来显示。

FHIR公用样板来检测资料正确性，医院与厂商更得有套合作模式

话锋一转，范承佑也思考到，未来IoT设备厂商开始支援FHIR资料格式后，医院还会面临一个问题，也就是“如何知道IoT设备传出的FHIR格式和内容，是否正确？”

在他看来，台湾今年首次举办的FHIR联测，若透过联测产生了公用FHIR样板，台中荣总就能用来打造自动检测程式，来验证医院的IoT设备厂商资料格式是否正确。

除此之外，要使用FHIR互通资料，医院与IoT量测设备厂商还得有套配合模式才行。对此，范承佑提出两种合作模式，一是厂商在中央站集中IoT量测资讯后，以FHIR RESTful API将资料以POST指令传送至医院接收端，“如此一来，也能减轻医院在FHIR 服务器介接的工作量。”

另一种模式，则是IoT厂商不必设置中央站，直接在每台生理机端产生FHIR格式资料，透过POST指令将资料送到FHIR服务器，由医院直接解析资料、将数值变化呈现在仪表板上。

有了这次FHIR战情室先导专案经验，台中荣总IT团队表示，还要持续改善即时战情室的建置工作，期望在不久的将来落实于院内，来强化第一线即时医疗照护服务。