北京中科医院是假的吗 http://hy.stock.cnfol.com/bankuaijujiao/20200315/28015292.shtml
台中荣总采用FHIR进行即时战情室先导专案，选定院内一间拥有15台生理量测机的病房，来测试FHIR整合不同生理量测值的能力。（iThome文件照）「我们要打造一套精准医疗即时战情室！」台中荣总信息室信息工程师暨智慧医疗AI小组组长范承佑说道。去年开始，台中荣总瞄准精准医疗，要建立一套战情室来即时汇整病人各种生理量测数值，并以一套仪表板来呈现数值走势，帮助医护人员即时决策。而战情室的关键信息，不只来自院内医疗信息系统（HIS）数据，还包括了各种外部IoT医疗设备的连续性数据，譬如像是生理量测机、呼吸器、穿戴式设备等。但是，「要整合这些数据且即时更新信息，可不简单。」范承佑指出，不像院内医疗数据，可轻易从核心数据库捞取，这些来自外部厂商的IoT生理量测设备数据，会因为数据格式和量测数值内容的不同，而难以整合。比如，一些厂商的IoT设备数据格式，可能采JSON、XML，或者是自订的数据格式；而同样是生理量测机，一些厂牌可能只显示心率、呼吸值，另一些可能显示呼吸次数、波型信息等。这对IT人员来说，就有两个挑战。首先，工程师必须想办法整合不同格式的生理量数值，因此得花时间理解每台量测机的所有数据字段，再将医院统一格式；同时，工程师也得理解不同厂牌生理量测机所产生的信息，医院所需要的信息，而非全盘接受。也因此，「医院每新增一款生理量测机，工程师就得挪出更多时间来处理数据介接问题。」台中荣总信息室信息工程师范承佑指出，团队以MongoDB自建一套FHIR服务器，希望透过FHIRRESTfulAPI将中央站生理量测数值转换为FHIR格式，存入FHIR服务器。图片来源／台中荣总以FHIR打破数据隔阂，先从小规模病房试验为解决数据标准不一的问题，台中荣总IT团队找寻不同解决方案，後来看上新一代国际医疗数据交换标准FHIR，决定以FHIR来串接不同设备的数据。FHIR问世九年，由专门制定医疗数据交换标准的国际HL7协会设计，目的是要解决前几代标准（如CDA）的问题，比如将复杂数据字段规范简化、可支持临床和非临床类型数据，以及支持更多数据格式，像是XML、JSON和Turtle。更重要的是，FHIR遵照HTTP网络通讯协定，以行动设备常见的RESTfulAPI来介接数据，因此，只要是支持网络传输技术的IoT设备，就可以透过FHIR来交换数据，以弥补HL7v2、HL7v3、CDA的不足。透过FHIR，IT团队就不必再一对一自订API，来串接每款生理量测机。正因为这些优点，台中荣总决定以FHIR来打造即时战情室，於是选定院内一间只有15台生理量测机的病房，来小规模测试FHIR整合数据的能力。范承佑指出，还没采用FHIR前，战情室的数据处理流程是由每台生理量测机收集心率、呼吸数值，再将这些数值统一汇整至一台厂商提供的中央站，再由中央站医院接收端数据库。医院数据库分析处理，就可透过UI仪表板来呈现数值变化，供第一线医护人员参考。有了FHIR，原本的数据处理流程就能以两种理想情境来实现，一种是将中央站汇整的数据，以FHIRRESTfulAPI医院接收端的FHIR服务器，最後在FHIR服务器中分析数据，以仪表板来呈现即时数值变化。其中的中央站数据介接工作，医院或厂商来进行。另一个理想情境，则是直接在各IoT生理量测机端，以FHIRRESTfulAPI医院接收端的FHIR服务器，最後再以仪表板即时呈现数值变化。也就是说，在这个情境中，数据介接的地方从中央站改为每台生理量测机，直接省略中央站。不过这种理想情境，还得在厂商设备支持FHIR的前提下才能实现。与此同时，范承佑也研究了FHIR数据格式规范，像是生理量测常用的数据字段定义Patient和Observation。同时，他也尝试了不同的FHIR工具，包括免费开源的HAPIFHIR服务器，以及付费的AzureAPIforFHIR、GoogleCloudHealthcareAPI和AWSFHIR云端平台等，都试过了一遍。不过，几经考量，「我们决定自己来建立一套适合执行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从数据库的大量生理量测数值中，抓取出病历号、姓名、性别等信息，并将这些信息转换为FHIRPatient数据型式。图片来源／台中荣总除了Patient型式数据，台中荣总也以Python从数据库中捞取病历号、量测时间、心率等生理量测值，并将这些值转换为FHIRObservation型式，再将这些数据存入FHIR服务器。图片来源／台中荣总范承佑也以数据转换实例，来说明从数据库中，找出所需数据并转换为FHIR格式数据的过程。比如以Python从数据库中的大量生理量测数值，抓取出病历号、姓名、性别等信息，并将这些信息转换为FHIRPatient数据型式；另一个例子则是透过Python，从数据库中捞取病历号、量测时间、心率等生理量测值，并将这些值转换为FHIRObservation型式，再将这些数据存入FHIR服务器。这些数据整合至FHIR服务器後，便可清楚呈现捞取数据的类别和细节，包括一位病患的基本数据、生理量测信息如心率和量测时间等。最後，为了将这些数据呈现给第一线医护人员，范承佑团队也写了支网页程序，来呈现患者即时量测数据。在网页首页，用户可以文字形式来阅览病患姓名、病历号、性别和量测记录等信息。如需要更详细的信息，用户只需点击病历号，就可查看视觉化的患者连续生理量测数值变化，一旁还会以JSON文件内容来对照，来确认数值。台中荣总将FHIR数据库分析後的数值，以网页接口呈现，除了显示生理量测数值变化外，还会附上JSON档数据内容，给第一线医护人员参考。图片来源／台中荣总FHIR实例化反思：即时性数据量大是最大问题在这场一年多的试验中，台中荣总IT团队虽然成功以FHIR来整合院内数据和IoT设备量测数值，但也意识到不少实例化问题。首先，「IoT生理量测机的即时性数据过於庞大，」如果只依靠FHIRServer作为储存端，在转换和传送数据时，就可能发生传送性能不佳或延迟的状况。这是因为，IoT中央站每分钟会派送一次数据，而且每份数据都会先转换为FHIR格式数据（比如心率存一套、呼吸值存一套），如此就大幅增加储存容量。范承佑指出，就FHIR测试病房来说，每分钟会派送15台IoT生理量测机数据，而在转换为FHIR的情形下，每天产生约为30MB的数据量；与之相比，原本同一病房在未采用FHIR的情况下，每周也才产生20MB的数据量。也因此，为解决数据量大造成的传送性能问题，范承佑团队想出一个方法，也就是当IoT生理量测机以FHIR格式将数据传送至指定地点时，只需存取所需数据即可，或於数据再次转传时，将数据转为FHIR格式传送即可。至於储存量大的问题，团队思考，要是能将同一病患同一时间的生理量测数据整合为一，比如将心率和呼吸值合并为一笔数据来储存，或是以DataHub文字档方式储存（如JSON），也许能克服储存空间不足的问题。另外，由於前述每产生一笔生理量测数据，就会存为一份FHIRObservation格式数据，因此当数据过多时，容易发生前端解析Observation数据过久的状况。对此，团队打算将前端解析FHIR格式数据的工作，改为在後端接收IoT生理量测数据时，先将所需数据提出，再送到前端仪表板显示。不只如此，面对数据爆量问题，团队也思考FHIR服务器的布建。范承佑指出，要是病房加入更多IoT生理量测机，他们计划部建更多FHIR服务器，来缓解设备过多造成的数据爆量问题；或是从机制上调整，先在FHIR服务器接收IoT设备信息时，捞出必要信息，并直接送至仪表板接口来显示。FHIR公用样板来检测数据正确性，医院与厂商更得有套合作模式话锋一转，范承佑也思考到，未来IoT设备厂商开始支持FHIR数据格式後，医院还会面临一个问题，也就是「如何知道IoT设备传出的FHIR格式和内容，是否正确？」在他看来，台湾今年首次举办的FHIR联测，若透过联测产生了公用FHIR样板，台中荣总就能用来打造自动检测程序，医院的IoT设备厂商数据格式是否正确。除此之外，要使用FHIR互通数据，医院与IoT量测设备厂商还得有套配合模式才行。对此，范承佑提出两种合作模式，一是厂商在中央站集中IoT量测信息後，以FHIRRESTfulAPI将数据以POST医院接收端，「如此一来，医院在FHIR服务器介接的工作量。」另一种模式，则是IoT厂商不必设置中央站，直接在每台生理机端产生FHIR格式数据，透过POST指令将数据送到FHIR服务器，由医院直接解析数据、将数值变化呈现在仪表板上。有了这次FHIR战情室先导专案经验，台中荣总IT团队表示，还要持续改善即时战情室的建置工作，期望在不久的将来落实於院内，来强化第一线即时医疗照护服务。

转载请注明:http://www.aideyishus.com/lktp/6571.html