原型开发:上下文驱动的动态XML眼科数据捕获应用程序

介绍

背景

以机器可解释的格式捕获临床信息具有挑战性，但对患者护理、生物医学研究、医疗保健质量和工作流程效率倡议至关重要[1-7］．然而，如果没有结构化的数据捕获，计算机就不能用于执行或增强与患者接触有关的许多任务(例如，预约、诊断测试订单、返回测试结果并解释和计费)或向临床工作人员提供治疗方案[8，9］．此外，由于手工信息审查，一些研究、质量评估和过程改进活动可能成本过高。

电子健康记录(EHRs)使用各种机制来捕获结构化(或编码)医疗信息，以满足大量的监管和计费需求，但它们通常缺乏用于小批量辅助或特定于实践的医疗计划或研究的选项。因此，医疗保健机构经常使用供应商软件解决方案、表单开发工具或标准办公工具(例如，电子表格和文档编辑器)来补充电子病历数据捕获功能，以创建此类功能[10-12］．这些解决方案通常具有EHR集成限制，依赖于平台或设备，难以维护，缺乏安全性，并且在捕获和使用广泛的临床数据捕获方法方面受到限制。并非所有这些解决方案都公开了可用于与EHR交互的应用程序编程接口(api)，并且在表单系统或EHR升级的同时，还存在维护功能的挑战。此外，还有基于Web的订阅或付费服务，它们提供了各种Web表单的实现，但这些服务的功能集有限，导致无法创建自定义问题，无法支持系统集成和说明功能需求，并且缺乏处理医疗数据所需的监管保证(例如，健康保险可携带性和责任法案[HIPAA]安全;［13-15])。

处理文档中找到的信息可以使用灵活的机器和人类可解释的标记语言(称为可扩展标记语言(XML))来完成。XML可用于创建基于web的数据捕获表单，支持各种常见的数据格式，包括文本、数字、编码结果(例如，多项选择)、语音片段和图像。文献中报告了许多基于web的数据捕获应用程序，这些应用程序已用于研究[16-19]及临床护理[20.，21］．值得注意的创新，例如使用存储在数据库中的元数据动态生成结构化数据输入表单[20.]或XML模式、XML模式设计工具[18，22]，或将电子病历数据集成为XML格式[17]都有报道，可以使用。

验光和眼科学是医疗保健中的专业领域，涉及眼睛及其周围结构的解剖、功能和疾病。这些专科在采用电子病历或电子数据采集技术方面进展缓慢，因为它们的工作量大，工作流程复杂(例如，从办公室到手术室的转换)，而且需要大量的图像文件[23-26］．例如，光学相干断层扫描(OCT)专业测试图像可以由外部摄像机捕获并以PDF格式扫描到电子病历中，从而捕获图像中的数字数据，而不是离散可计算字段。许多临床相关信息都是通过手绘的眼睛图来获取的，因此，除非人工解释，否则无法用于后续的临床或研究使用[27］．在一些国家，非摄影视网膜图像的程序报销依赖于审查员生成的插图[28]，而且由于许多电子绘图工具还不够复杂，无法绘制视网膜图，因此它们在临床实践中加强了纸张的使用。

客观的

寻找或开发能够轻松集成并补充复杂工作流程的基本EHR数据捕获功能的软件解决方案对于患者护理、研究和质量管理工作是必要的[29］．使用眼科领域作为原型开发的用例，我们描述了识别临床和研究相关数据元素的过程，以及创建一个开源的、上下文驱动的眼科数据捕获应用程序，该应用程序可以很容易地适应各种临床工作流程和EHR环境。这项工作利用了以前的研究成果[20.使用封装在数据库或XML模式中的元数据来驱动表单生成和上下文驱动控件来填充数据捕获应用程序。我们通过将这些技术以集成的方式应用于眼科领域来扩展这些方法，并添加墨水over Web控件来捕获非结构化的临床相关图纸和笔记。ink -over，通常被称为数字墨水，是指以数字方式表示手写笔记和图纸的技术。在本研究中，我们描述了用于开发眼科数据捕获原型应用程序及其启发式评估的过程。

方法

目标

本研究的总体目标是开发一个上下文驱动的动态XML眼科原型，该原型能够有效地捕获眼科和验光数据，并增加离散(结构化)数据的收集，同时保留在需要时捕获手写笔记和绘图的能力。

具体目标包括:(1)确定与临床和研究相关的眼科数据元素(包括结构化和基于图像的);(2)记录辅助数据采集应用的系统需求;(3)设计、开发和评估具有上下文感知、可修改并可集成到电子病历中的数据捕获原型。

环境

Marshfield Clinic Health System的catailsmd EHR自20世纪80年代末以来一直用于临床护理，为威斯康星州中部和北部的临床医生提供服务。它使用各种数据收集技术来捕获和编码患者遇到的信息，包括诊断、实验室结果、程序、药物和生命体征测量，如身高、体重和血压。临床叙述和插图以文本和/或基于图像的非结构化格式存储，并可通过电子病历查看。医务人员使用平板个人计算机(pc)与经过优化以在这些设备上运行的EHR应用程序进行交互。眼科和验光部门使用这些电子病历应用程序，但他们也通过使用扫描到电子病历的纸质表格来补充临床数据采集。

过程

我们采用参与式流程来开发眼科数据采集原型。一个由利益相关者(3名医生、2名管理人员、3名医疗助理、2名研究人员、2名信息学家和2名程序员)组成的设计团队进行了一系列面对面会议，以(1)收集和了解眼科和验光中的用户和技术需求和工作流程;(2)定义和分析现有的和拟议的数据元素以供捕获。后者提示对现有形式进行内容分析和调查。这两个活动将在下一节中描述。从设计团队讨论中确定的需求被开发成原型开发的用例。例如，医生确定需要在原型中捕获眼睛的图纸。原型开发过程的概述见图1。一个反复的临床审查过程被用来完善原型。然后对开发的原型进行审查，并考虑通过优先排序过程将其集成到电子病历中。

‎ 查看此图

临床及研究要求

我们对30种不同的手写非结构化纸质表格进行了内容分析，这些表格用于记录验光和眼科患者的就诊情况。提名用于原型包含的数据元素按以下顺序排列优先级:(1)在多种形式中发现或被多种实践和/或专家使用的数据元素;(2)有意义使用所需的数据元素[30.];(3)美国眼科学会(AAO)制定的《成人医学眼科综合评估》中的数据要素[25］．然后，设计团队对该列表进行审查，并对其进行优先级排序。此外，对每个数据元素进行定义，然后将其分组为逻辑数据类(即访问信息、病史、家族史、检查、缝灯检查、专业测试和其他)。

与此同时，我们向参与电子病历和基因组学(eMERGE)网络的机构分发了一份EHR眼科数据可用性调查[31]以了解其他机构收集的数据元素，并评估跨机构收集的眼科数据元素的普遍性和常见类型，以及用于捕获这些数据的机制。调查可以在多媒体附录1。

技术与架构

眼科数据采集应用程序的原型是使用微软的ASP在一个可扩展的开放架构上开发的。. NET MVC 3.0, JavaScript和jQuery。为原型开发选择的开发环境和数据库是基于编程团队的熟悉程度和经验。该体系结构的概述见图2中可以找到支持数据捕获应用程序的数据库模式多媒体附录2。该体系结构支持表单规范数据库(FSD)，其中包括表单设计规范、操作和Web控件定义。如果数据库不可用或用于轻量级实现，表单规范也可以存储在XML配置文件中。每个数据收集表单都是使用Web控件(以下简称控件)构造的控制)，它允许用户与Web表单交互。消防处在数据库中有许多控制记录，用于定义表单的外观和操作。FSD模式可以存储多个表单，并且是可扩展的，可以容纳以后可能添加的其他控制类型。

呈现Web表单的整个过程概述在图2，描述如下:

• Web服务器根据存储在FSD中的规范生成Web表单，并代理数据请求电子健康档案或灵活的后端数据库(FBD)和Web浏览器设备(步骤1、2和4)。
• 然后，Web服务器从EHR或FBD请求患者可识别信息(PII)来填写Web表单(步骤3)。
• Web服务器生成Web表单，包括PII，并将其呈现给用户(步骤4和5)。
• 捕获用户数据和带墨水注释的图纸，并将其传回EHR或FBD进行存储(步骤6-8)。

一组控制类用于解析XML输入(从FSD或XML配置文件检索)，然后通过Web浏览器将表单内容交付给用户。控件可以是交互式的(用户可以操作的表单元素——checkbox, TextBox等)或被动的(例如，以可视方式对控件进行分组的容器)。存储在FSD中的每个控件包含许多属性和方法，如表1。这些属性和方法定义了表单在呈现给用户时的显示方式和行为。通过修改FSD或XML配置文件中定义的控件和/或控件属性和方法，可以动态更改Web表单。

‎ 查看此图

‎ 查看此图

眼科数据采集的原型是基于Web的，可以在包括iPad在内的各种设备上运行。表单分为七个逻辑部分，用于数据输入。所有部分最初都是折叠的，以便于表单导航，然后随着数据收集的进行展开。图3显示隐藏部分详细信息的Web表单，但狭缝灯检查部分除外。

上下文驱动的控制

包含上下文驱动控件被认为是应用程序的一个重要组件，原因如下。首先，它减少了用户查看和回答不必要问题的需要。这有助于指导和支持数据输入的流线型工作流程。图4显示支持隐藏控件的眼科原型的一部分。当临床医生选择一个专业测试时，将显示一个控件，并准备手写评论。用于生成表单的相应XML如图所示图4。其次，它有助于保持数据输入表单尽可能紧凑，根据先前问题的答案从表单中删除不必要的问题。例如，在图5我们有一个描述黄斑或中央视网膜的对照。如果患者的黄斑正常，图5(1)只显示，无须额外输入资料。的下拉值的选择黄斑(2)引起另一种形式的出现，提示用户定义黄斑病变的类型，在这个例子中，黄斑病变被显示为年龄相关性黄斑变性(AMD)。AMD的选择基于所选择的属性提示额外的控制(3)AMD类型，从而产生额外的相关数据捕获。目前，该应用程序允许非常基本的上下文驱动行为(基于选定值显示/隐藏子控件)。这是通过使用与控件关联的依赖属性和使用表单规范数据库(图2)。图5还展示了演示此概念的相应XML代码。若要在选择下拉列表中的值时显示控件，该控件的名称需要与其所依赖的项的值匹配。XML代码是根据表格规格数据库(图2)。用户可以通过添加或删除记录或更改数据库中数据元素的属性来定制和/或添加新的表单特性。

‎ 查看此图

‎ 查看此图

墨水的能力

眼科医生需要工具来说明眼部异常[28］．这个应用程序的一个关键特性是能够在Web表单或画布上绘图。画布区域覆盖了一个透明图像，用户可以在透明图像上进行他们认为合适的注释，如下所示图6。这些图像可以特定于表单的上下文，例如用于注释眼睛的墨水over Web控件，或者只是用于编写文本注释的一系列水平线(图6)。结合马什菲尔德诊所健康系统的信息技术环境(平板电脑和Windows 7/Internet Explorer [IE] 8)，我们着重于嵌入微软。将墨水库添加到Web表单中，为用户提供本机墨水功能。对于在使用IE 9+、Chrome、Firefox、Safari等浏览器的设备上访问表单的用户，这些浏览器没有安装Microsoft。安装墨水库，使用HTML5 Canvas。生成的图像与编码数据一起保存到电子病历或FBD (图2)。

‎ 查看此图

原型的评估

在原型开发之后，我们对软件进行了启发式评估。启发式评价是一种用于发现用户界面问题的可用性检查方法。Marshfield Clinic Research Institute的可用性分析师多次审查眼科数据捕获原型，将其与已建立的启发式列表进行比较，记录并报告与启发式的所有冲突[32］．

结果

在访谈和调查过程中，临床、研究和技术利益相关者优先考虑的最重要的设计标准呈现在表2。眼科医生认为界面最重要的要求包括:(1)易于导航，(2)集成到临床工作流程中，(3)组织成一个统一的视图和有意义的组(意味着所有眼科信息都位于一个地方，以便临床医生可以轻松查看，分组代表访问原因，医疗和家族史，检查和专业测试)。(4)集成了EHR，可以预先填写相关的患者信息;(5)墨水书写表格，可以支持眼部插图。重要的技术需求集中在集成和维护功能上。研究需求强调编码数据捕获和与其他合作者共享原型技术。所有涉众都提到需要一个安全的数据共享和身份验证体系结构。我们的解决方案满足了所有这些需求。

内容分析

独特的数据元素，从30多个不同的临床眼科学形式确定，由临床医生和专业领导审查。举行了几次合作讨论，将数据元素组织成七个一般数据类，以支持常见的眼科工作流程，见表3。在这些数据类别中确定了10个对研究重要的数据元素(用上标字母表示)一个在表3)。医疗和家族史相关的数据元素可能需要EHR访问来显示以前收集的信息。EHR的API可用于收集现有数据以预先填充表单。

涌现数据可用性调查

在9个eMERGE站点中，6个站点(66%;盖辛格卫生系统、马什菲尔德诊所、梅奥诊所、西奈山、西北大学和范德比尔特大学)完成了这项研究电子健康记录中的眼科/验光数据可用性调查发现于多媒体附录1。在这6个eMERGE站点中，4个站点(66%)使用商业开发的电子病历(Epic和通用电气的Centricity)， 2个站点使用内部开发的电子病历(Vanderbilt和Marshfield的cathailsmd)。调查结果摘要可于表4。受访者电子病历中的眼科信息以多种数据格式捕获，包括编码、XML、文本和图像。马什菲尔德发现的许多数据元素也正在其他机构收集。正如预期的那样，在新兴机构受访者中，电子病历中只有有限数量的编码眼科数据。

原型的评估

对原型的启发式评估显示，表单最常显示控件的使用不一致。当给定相同数量和类型的选项时，表单同时包含单选按钮和下拉控件。为了一致性和使用效率，可用性分析师建议在所有情况下实现单选按钮，这样就可以用触控笔直接选择。分析师还建议所有文本框都有一个擦除开关，而不是现有的擦除按钮，以便用户可以在写入和擦除之间来回切换。该表单最初阻止用户在单击擦除按钮后继续在文本框中写入。它要求在接受输入之前清除文本框。次要的建议包括突出显示选定的功能，增加按钮和控件(单选按钮、下拉框、文本框等)周围的填充，以及缩进依赖的子控件以显示与其父控件的关系。

讨论

主要研究结果

本研究描述了为眼科护理和研究创建一个上下文驱动的动态XML数据捕获原型。它的开放体系结构允许使用面向服务的体系结构(SOA)， SOA可以促进与各种EHR的集成，以检索特定于患者的信息，并将新收集的信息传输回EHR，从而使数据可用于其他用途。该体系结构还支持基于web的表单(可以从数据库或XML模式动态创建)、基于上下文的控件(用于高效的数据输入)和用于说明眼睛异常的墨迹式表单。源代码以及眼科原型的演示版本可以在Marshfield诊所研究所的网站上找到[33］．

与前期工作比较

我们研究了几种众所周知的用于眼科原型开发的数据捕获解决方案[10-15，19］．许多解决方案在入站和/或出站EHR数据流方面存在限制，支持条件逻辑、墨迹绘制功能和操作使用许可[19］．鉴于眼科所面临的独特挑战，我们选择基于web的技术进行原型开发，因为它在多种类型的设备上运行应用程序时最大限度地减少了问题。选择这种技术还提供了通过利用SOA进行EHR集成与其他机构共享原型的能力。

我们遇到了一些挑战。首先，眼科工作流程很复杂，目前使用的30多种不同的纸质表格表明了这一点。创建一个单一的、易于导航的、基于web的用户界面需要分析超过140个独特的数据元素，并采用前面描述的几种方法来减少项目的数量，并确定数据类的逻辑分组，以实现高效的工作流。表单设计存在问题，因为数据捕获需要大量的数据元素。我们开发了一系列基于上下文的控件来隐藏数据捕获的复杂性。

其次，用于支持上下文驱动控件的XML体系结构必须能够适应不断变化的数据收集需求和新控件。为了解决这个问题，我们为数据库中的每个控件添加了属性，指示一个控件是否依赖于另一个控件以及调用该控件所需的操作。使用这种方法可以通过更改数据库控件配置轻松地修改表单操作。

第三，为眼睛异常提供网络绘图功能带来了一些额外的挑战。我们的设计需要在各种支持web的设备上提供本机墨水绘制功能，支持各种客户端配置。我们使用微软。用于Marshfield Clinic Health System计算环境中的设备的Ink库，但必须研究具有其他操作系统或浏览器要求的非Marshfield设备的其他选项。只要管理用户定义了一个具有适当的涂墨控件的表单，我们将涂墨功能设计为与设备无关的(在平板电脑、笔记本电脑、台式机和移动电话上都可以使用)。在支持浏览器版本检测和微软方面付出了巨大的努力。油墨兼容性。

眼科数据捕获原型目前被打包为一个独立的应用程序，用于演示目的。我们设想，原型将被包装为电子病历附加设备，用于眼科和验光部门。原型构建在SOA之上，该体系结构促进了上下文感知，并以安全的方式支持应用程序和EHR之间的数据转换。这个原型目前使用一个灵活的后端数据库- mysql (图2)。通过开发包装Web服务来代理与此原型系统的服务之间的EHR数据交换，可以轻松地将这个独立数据库转换为EHR数据存储库。这种级别的集成将允许在应用程序的表单中预先填写来自EHR的患者信息，并最大限度地减少用户的数据输入。

限制

在整个开发过程中，几位眼科医生对数据捕获应用程序进行了审查，并对数据元素和表单流的术语和逻辑分组提供了建议。在原型开发期间，我们没有进行正式的可用性评估，但是我们进行了启发式评估。启发式评估通常受到这样一个事实的阻碍，即执行启发式评估的评审人员并非用户界面所涵盖领域的专家。在这种情况下，在整个数据收集和开发的设计阶段都有一个主题专家参与，因此由于这个先前贡献的专业知识，这个评估可能比其他评估更少受到限制。应用程序体系结构的模块化特性允许我们快速处理启发式评估的结果。我们能够修改用于提供一致控件的控件类型，并且对文本输入控件的增强立即应用于使用它的所有表单。

使用此应用程序收集的数据元素可以使用AAO、临床数据交换标准联盟(CDISC)或医疗保健数据标准联盟制定的标准来定义和注释。未来的应用程序增强可能包括与通用术语数据库或管理系统接口的api。

最后，我们没有在这个原型中实现审计跟踪或识别管理，也没有探索数据输入错误检查算法的使用，因为它是一个概念验证项目，旨在探索动态表单生成和数据收集上下文感知的可能性。未来的开发将包括此功能。

结论

本研究描述了一个开源、上下文驱动、结构化数据捕获动态XML眼科数据捕获应用程序的创建，该应用程序可以集成到各种电子病历中。相关的眼科和验光数据元素被确定用于临床护理和研究。使用上下文驱动的控件和用于说明眼睛异常的墨水功能简化了数据输入。