CN107004238A - 用于管理电子健康护理信息的系统和方法 - Google Patents

Abstract

本发明涉及用于在高度可缩放和可定制的软件和硬件架构上管理电子健康护理信息的系统和方法，所述架构强调便携式设备以及升级和缩放期间的最少停机时间。本发明还涉及高效地访问和定制用于以电子形式生成和管理患者信息的表单的系统和方法。在本发明的一个方面中，本发明的电子健康记录系统(EHR)也可以被称作电子医疗记录系统(EMR)，其可以被部署并且运行在多台服务器上，其中可以按照非集中方式在所述多台服务器上分配计算和/或存储负荷，从而使得总体系统即使在被缩放、升级和/或通过其他方式修改时仍然可以保持运转和操作。

Description

用于管理电子健康护理信息的系统和方法

技术领域

本发明涉及用于管理电子健康护理信息的系统和方法，特别涉及用于电子健康护理信息的高度可缩放和可定制的创建和管理的系统和方法。

背景技术

医疗专业人员保持关于患者的记录。这样的记录在患者拜访医疗专业人员时(例如在最初住院或登记时)、在住院期间以及在出院时生成。住院或登记过程通常包括由患者或纳入人员填写表单，并且所捕获的信息过去是通过手写或键入的。更近以来，医院已经包括了在计算机屏幕上显示的表单上输入这样的纳入信息。该表单通常预先填写有对应于一般信息的类目，比如患者的姓名、出生日期等等，其后是用于输入此类信息的空间。如果所述空间不够用于输入信息，通常推荐使用单独的页面并且把附加页面附加到记录。最后，一些医院仍然把这样的记录保持在纸质表单中。除了收集一般信息之外，许多医院还收集可能与该医院的专长领域有关或者与医院工作人员所开展的特定最佳业务有关的特定类型的信息。此类信息也是利用专门的表单从患者收集的。

当在计算机上生成记录时，其还可以通过电子方式被保存在服务器上，并且具有与纸质表单相同的存储格式。与纸质表单一样，所创建的信息越多，需要存储的记录也越多。当服务器超负荷时，必须安装更大并且能力更强的服务器来应对增加的负荷，这类似于把文件转移到更大的存储空间或建筑物，并且通常涉及用于升级和安装的停机时间(downtime)。停机时间也意味着信息是不可访问的。

发明内容

本发明涉及例如用于在高度可缩放和可定制的软件和硬件架构上管理具有按需信息收集的需求的各种行业中的电子信息(或者电子记录管理或ERM)的系统和方法，所述行业包括而不限于健康护理、顾客关系管理、人力资源、会计、项目管理、政治/慈善活动管理以及类似的行业，所述架构例如可操作在包括固定式或台式设备、移动设备、便携式设备或其组合的设备上，并且操作为在升级和缩放期间具有最少停机时间。本发明还涉及高效地访问和定制例如用于以电子形式记录和管理患者信息的表单的系统和方法。

在一个实施例中，本发明涉及用于在高度可缩放和可定制的软件和硬件架构上管理健康护理行业中的电子健康护理信息的系统和方法，所述架构例如可操作在包括固定式或台式设备、移动设备、便携式设备或其组合的设备上，并且操作为在升级和缩放期间具有最少停机时间。本发明还涉及高效地访问和定制例如用于以电子形式记录和管理患者信息的表单的系统和方法。

本发明例如利用了分层结构数据(HSD)文档(比如JSON文档)的灵活性，以及HSD文档(比如JSON文档)可以在前面提到的任何适当设备上被动态处理的独有方式。例如在健康护理领域中，本发明允许基于例如被编码在存储于至少一台计算机服务器上的分层结构数据(HSD)文档(其被称作“系统对象”)中的规范集合来创建完整的电子健康记录系统。健康护理领域中的用户可以包括医师、护士、放射科技术人员、药剂师、记账专业人员、医院管理人员以及甚至患者本身。其可以通过设备(例如便携式或移动设备)与电子健康记录系统进行交互，所述设备从至少一台计算机服务器取回情境相关的系统对象，并且遵循这里所定义的特定处理集合来实现用于查询、查看、与之交互以及编辑例如存储在至少一台计算机服务器上的包含健康护理相关数据的HSD文档(其被称作“健康记录文档”)的用户界面。这里所使用的“健康记录文档”被宽泛地定义成包括可以由健康护理专业人员使用来为患者提供处理的临床和非临床、患者特定和非患者特定数据。为患者提供护理的实例可以包括而不限于手术规程指示单(临床)、保险记账信息(非临床)、药剂目录(非患者特定)以及在医师与护士之间发送的消息(患者特定)。能够被即时创建的用户界面可以支持简单的操作，比如列出/查看健康记录文档(比如过敏症列表和药物列表)或者多份健康记录文档当中的统计量(比如每日急诊室住院率)，并且还可以支持更加复杂的多步骤操作，比如允许医师撰写处方指示单并且签名以便由药剂师配药以及由护士施药。基于在系统对象中规定的内容，所述设备(例如移动设备)还可以基于当前登录到系统中的用户的类别来限制对于特定用户界面单元的可见性，从而例如向放射科技术人员呈现将要实施的x射线指示单的列表而不会使其看到记账信息，或者使得药剂师不会看到由患者向其医师发送的消息。一般来说，由于定制仅仅影响系统对象定义而不影响运行在移动设备或计算机服务器上的软件代码，因此可以在任何时间以最少的系统停机时间转出(roll out)、更新和维护对于电子健康记录系统的定制，并且不需要移动设备软件或计算机服务器软件的新的版本。

在本发明的一个方面中，本发明的电子健康记录系统(EHR)也可以被称作电子医疗记录系统(EMR)，其可以被部署并且运行在多台服务器上，其中可以按照非集中方式在所述多台服务器上分配计算和/或存储负荷，从而使得总体系统即使在被缩放、升级和/或通过其他方式修改时仍然可以保持运转和操作。

在一些示例性实施例中，本发明的EHR系统可以是软件系统，其通常可以包括被部署并且运行在服务器共享集合(pool)中的多台服务器上的多个基本上相同地配置的工作节点(worker node)。在本发明中，EHR系统可以在服务器共享集合中的各台服务器上分配其工作负荷和/或存储负荷，例如在服务器共享集合中的可用服务器上基本上均匀地分配。由于EHR系统可以包括多个基本上相同地配置的工作节点，因此各个单独的工作节点可以被取下、故障和/或被修改，而不会影响其他工作节点和/或严重影响EHR系统的总体可操作性。这可能是符合期望的，因为EHR系统一般可以被用来运行任何健康护理设施的操作，并且在这样的医疗设置中，访问患者信息的需求例如常常是时间敏感的并且对于适当的患者治疗是至关重要的。因此，一旦部署之后，EHR系统经历最少停机时间或者没有停机时间可以确保平滑的操作而不会有不必要的中断。通过这种方式，例如服务器共享集合可以在几乎任何给定时间添加附加的服务器和/或取下服务器以用于替换、升级、修复或其他用途从而修改服务器共享集合的容量和/或功能，而不会使得EHR系统由于服务器修改而经历停机时间，从而最低程度地影响总体系统的可用性。

在一些实施例中，本发明的EHR系统可以被建立在高度自动化的安装平台上，其中系统的各个单独的组件可以被包装到分开的镜像中，所述镜像可以包括特定组件的配置。所述系统可以从镜像创建并且运行组件的实例，同时把应当是永久性的任何所生成的数据与镜像分开存储在永久性存储中。因此，所述系统可以任意创建和丢弃组件的实例，而既不会丢失存储在镜像中的配置信息，也不会丢失存储在永久性存储中的永久性数据。分开的EHR系统组件可以被取下以用于升级、修复和/或其他修改而不会影响其他组件。

在一个实施例中，本发明的EHR系统可以被建立在自动化安装平台上，例如“Docker”。“Docker”通常可以利用Linux Container(Linux容器)，一种嵌入到Linux中的比传统虚拟化方法更加轻量型的技术。本发明的EHR系统的组件随后可以被包装到“Docker”镜像中。随后可以在“Docker”内启动镜像，以便产生组件的运行实例。在传统的环境中，例如这些实例可以类似于运行在中间件以及在配置方面需要为之投入大量时间和能量的其他组件的堆栈上的已安装的软件。与此相对，该实施例中的EHR组件的实例通常可以易于创建，并且例如可以在希望或者必须对EHR系统进行修复、升级和/或修改时丢弃。“Docker”通常还可以允许把针对每一个组件的配置数据(其可以被存储在“Docker”镜像中)与永久性数据(其可以被存储在永久性存储中)分开。因此可以在任何时间丢弃每一个组件的实例，这是因为例如在任何时间都可以通过基于相同的原始镜像启动新的实例来重新创建所述实例的配置，同时由所述实例管理的永久性数据不被存储在实例本身中而是被存储在例如后端之类的永久性存储中，比如网络附属存储(NAS)。

在一些实施例中，永久性数据可以利用可缩放后端数据库系统来存储，所述数据库系统通常可以利用非关系数据库结构，但是也可以利用分立文档为中心的结构，所述结构还可以利用服务器或存储共享集合上的可缩放性、文档复制和/或负荷分配。作为另外的实例，所述数据库系统还可以利用文档锁定系统，其中文档对所有被允许的用户都保持可查看，但是每次只有一个用户可以通过将其检出数据库来修改文档。这对于例如防止可能引入相矛盾的信息的文档的同时修改可能是合乎期望的。这在健康护理领域中是特别合乎期望的，其中相矛盾的信息可能是生死攸关的。

在一个示例性实施例中，所述可缩放后端数据库系统可以采用NoSQL数据库，例如“MongoDB”。

在本发明的另一个方面中，EHR系统可以被设计成几乎完全从便携式或移动设备进行主要的访问、保持和利用，其中只有特定功能需要直接访问服务器和/或固定式计算机。这不同于一般大多数的EHR系统，后者被设计成用于固定式计算机，其中任何移动访问或功能都是后来的考虑。这总体反映了用以保持健康记录的更加传统或者过时的方式，其更加类似于没有大量利用允许用以保持信息的不同方式的任何技术进步的纸张和档案室系统。

一般来说，在医疗领域中可当责性(accountability)和可稽核性(auditability)是重要的概念。由于作出明智的临床决定非常依赖于准确的患者记录，因此本发明的EHR系统可以被设计成例如通过日期、时间、用户和/或任何其他适当的方式来跟踪对于患者记录所发生的所有改变。EHR系统通常还可以把过去文档版本的全部和/或所期望的选择部分存储在数据库中以便于稽核。EHR系统的用户还可以通过使用在EHR系统中可用的检入(解锁)和检出(锁定)动作来促进可稽核性，这是因为这些动作通常例如还可以防止多个用户对任何给定文档作出潜在地相矛盾的修改。

在一些实施例中，本发明的EHR系统的所有主要用户可以利用便携式或移动设备来进行其对EHR系统的访问和利用。在一个实施例中，通常可以利用平板设备和/或其他类似的平板计算设备。一般来说，可能希望从受欢迎的、普及的和/或熟悉的计算平台利用本发明的EHR系统，因为这样例如可以允许用户专注于其实际的任务而不是尝试搞清楚不熟悉的和/或过于复杂的软件界面。此外，受欢迎的和/或普及的计算平台通常可以受益于勤勉的技术支持、问题熟悉性、更新以及/或者替换的可用性。本发明的EHR系统通常可以被利用在任何适当的设备上，其中可以包括而不限于智能电话、平板计算机、个人计算机以及/或者任何其他适当的计算设备。一般来说，本发明的EHR系统可以采用图形用户界面(GUI)，并且取决于设备，所述图形用户界面可以通过任何可能是适当的触摸屏界面和/或键盘/鼠标界面来访问。本发明的EHR系统还可以采用其他形式的界面，比如针对存在视觉和/或听觉缺陷的用户的使用所设计的界面，以及/或者替换的界面，其中例如可以包括语音识别和/或重放、盲文(Braille)计算机界面、触觉界面以及/或者任何其他适当的界面。

在本发明的另一个方面中，本发明的EHR系统可以利用高度可定制的架构，其通常可以允许对EHR系统进行定制以适应(多个)用户的任何特定需求，而无需对EHR系统的底层功能和/或设计作出任何重大改变。在一些示例性实施例中，本发明的EHR系统架构可以是基于使得系统的大多数方面的配置以系统对象的形式暴露于管理员，其中例如包括而不限于向表单添加栏位以创建用于应对实验室指示单的新的工作流程之类的改变都可以在不改变本发明的底层EHR系统的情况下实现。系统对象通常可以利用YAML句法来定义并且例如可以作为分层结构数据(HSD)文档(其中的一个实例是JavaScript对象标记(JSON)文档)存在，其方式类似于由EHR系统管理的所有其他文档(比如患者记录)。

在本发明的另一个方面中，本发明的EHR系统可以被高效地并且容易地定制以便安装在工作地点处，例如医院、医生办公室和/或其他健康护理机构，而不需要对于EHR系统的大量“后端”定制以实现能够工作的实现方式。一般来说，针对一个医疗专业人员群组将EHR带上线的其中一项最大的开销就是在系统内实施机构的现有工作流程和处理所花费的时间。虽然大多数机构共享会面(encounter)、患者账户、指示单、实验室结果、协议和/或其他相同的基本概念，但是将这些概念缝合在一起以便从住院到出院驱动患者护理的确切方式对于不同的机构可以大为不同。在许多情况下，在典型的EHR实施期间使用逐步处理，以便识别和区分机构的不同工作流程和处理之间的相互联系。有效的EHR系统通常被设计成适应对于系统配置的小的、渐进的、潜在地频繁的改变，以便适当地实施EHR系统从而使其将与机构一起工作。系统的表单、工作流程以及其他方面的定义有时常常被硬编码到EHR本身中，由于所需的改变是在“后端”进行的，因此这常常需要分配具有高度技术水平的开发人员的时间来实施。此外一般来说，一旦机构定制开始涉及底层EHR产品中的改变，频繁渐进改变的想法可能就变得不切实际。

在本发明的一个示例性实施例中，本发明涉及一种在无需创建电子健康记录系统软件的多个版本的情况下定义电子健康记录系统中的定制表单的方法。通过本发明实现了针对前述挑战的一种解决方案，并且允许多个机构对于其电子健康记录系统具有不同的定制而无需创建移动设备和/或服务器软件的多个版本。这是通过利用以标准化句法或格式存储数据的文档(比如JSON文档之类的HSD文档)的灵活性以及此类文档(比如JSON文档)在前面提到的任何适当设备上被动态处理的独有方式而实现的，而不管所述设备是否是移动设备。举例来说，健康记录可以作为一系列HSD文档(比如JSON文档)被存储在至少一台计算机服务器上。这样可以允许不是具有高度技术水平的软件开发人员的软件安装或服务技术人员把表单布局(例如人口统计信息表单、过敏症表单等等)定义成存储在至少一台计算机服务器上的一系列HSD文档(比如JSON文档)，而不存在改变底层软件的复杂性或技术难度。(由前面提到的技术人员定义的)表单布局可以规定一系列表单层级小部件(widget)，其中包括“节段(sections)”、“列表”、“附注(notes)”以及“节段划分选项卡”或其他小部件。节段还可以规定一系列节段层级小部件，其中包括文本栏位、代码挑选器、日期/时间挑选器、签名栏位、单选/多选挑选器、是/否按钮、日历、复选框、定制HTML小部件、目录用户/群组挑选器、重量/长度/高度/血压栏位、条形码栏位、照片栏位、数字标度挑选器、房间挑选器、文档挑选器等等。

不同于纸质文档，移动设备软件实施特定处理以便组合健康记录HSD文档(比如JSON文档)和表单布局HSD文档或JSON文档(二者都取回自至少其中一台计算机服务器)，从而得到允许用户读取和/或改变电子健康记录中的数据的最终呈现：移动设备软件在屏幕上垂直排布表单层级小部件，并且在小部件中填写来自健康记录HSD文档(比如JSON文档)的信息，从而使得用户可以很容易地使用触觉、键盘驱动或语音驱动的范例例如通过移动设备屏幕与数据进行交互。

表单布局可以规定属性“映射”，其例如告知移动设备软件哪些小部件可以被用来操纵健康记录HSD文档(比如JSON文档)的哪些部分。属性映射可以定义用于取回和/或记录将通过设备屏幕上的小部件显示和/或从用户收集的HSD文档(比如JSON文档)内部的数据的分级操作的序列(例如取回/修改特定索引处的阵列单元，基于特定关键字取回/修改关键字-值对表的值)。

表单布局还可以规定例如用JavaScript编写的自动标题/子标题生成器算法，以便允许基于健康记录HSD文档(比如JSON文档)的属性来计算标题和/或子标题。这样就可以在无需例如修改移动设备和/或服务器软件的情况下定制健康记录文档的命名方式。每当例如在移动设备软件中修改健康记录文档时，设备(比如移动设备软件)可以例如只需要执行JavaScript标题/子标题生成器。

此外，例如还可以由移动设备软件把列表小部件渲染成具有行和列的表。各行可以对应于健康记录HSD文档(比如JSON文档)的阵列中的条目，并且各列可以包括将要在对应于健康记录HSD文档(比如JSON文档)中的给定阵列条目的该行的各个单元格中显示节段层级小部件的规范。列表小部件定义还可以规定嵌入式表单布局，以便显示出针对当用户在给定行的末端渲染的“信息(info)”按钮上敲击时出现的该行的HSD对象的一部分或全部剩余数据；这在利用基于列的机制没有足够的空间来显示一行的所有信息的情况下是有用的。

对于代码挑选器小部件可以实施另一个处理步骤，比如：至少其中一台计算机服务器可以被用来存储表示标准化治疗概念的“代码”集合(例如，诸如乳房X射线照片的放射科规程，诸如左臂的解剖单元，诸如胆固醇测试的实验室规程，诸如亚裔或基督教之类的可能的人口统计信息属性等等)。代码挑选器小部件规范可以定义能够向用户显示并且作为来自用户的可能值而接受的可能代码的受限制子集(例如仅有宗教；仅有放射科规程；仅有非品牌药品；等等)。移动软件向至少其中一台计算机服务器查询可以与所规定的限制相匹配的代码，并且将其呈现在用户在移动设备上所看到的视觉表单上以便从中进行“挑选”。

移动设备软件可以允许用户利用来自具有相关目的或类似布局的健康记录文档的值自动填写健康记录文档。这在第二次就医时更新例如人口统计信息之类的信息的情形中可能是有用的，从而使得医生或其他用户不再需要重新输入从前一次就医以来可能未发生改变的数据。移动设备软件例如可以在移动设备屏幕上显示菜单，该菜单允许用户挑选另一个健康记录文档以从中进行“自动填写”。移动设备软件例如可以利用来自所述另一个文档的值自动填写小部件，并且用黄色高亮显示这些小部件。表单布局可以被配置成规定该自动填写处理每当在至少其中一台计算机服务器上已经存在适当的文档时自动发生，以便自动从中进行填写。

这方面的一种变型或替换方案可以是“调和(reconciliation)”，其主要在基于列表的表单上工作(表单布局规定将要调和的表单上的列表的性质以及调和处理可以针对其工作的文档的特性)。当用户正在特定表单上工作时，移动设备软件例如可以向用户呈现菜单以便选择相关的文档。移动设备软件从至少其中一台计算机服务器取回由用户选择的(多个)文档，并且把来自不同相关文档的“行”一起合并到表单上，其中用黄色显示来自其他文档的行。用户随后可以被允许接受或去除黄色的行。在调和结束时，移动设备软件把仍然存在的各行一起合并到单个文档中，并且把该文档保存在至少其中一台计算机服务器上。这方面的一个实例可以如下：外科医生正在准备对由患者的主要护理医师转交给他/她的该患者动手术。外科医生在表单上填写患者当前正在服用的药物。所述表单并不是技术上冗余的，这是因为外科医生想要在对患者动手术之前亲自双重确认他/她正在服用的药物。除了外科医生所填写的表单之外，还有来自患者的主要护理医师的表单，其中也列出了患者当前正在服用的药物，至少是由主要护理医师在填写表单时所记录的药物。在这种情形中，例如移动设备向外科医生呈现存储在至少其中一台计算机服务器上的其他药物列表的菜单以便与之进行调和，并且一个此类药物列表是来自主要护理医师的药物列表。在外科医生从菜单中选择了主要护理医师的药物列表之后，移动设备从外科医生所填写的列表和主要护理医师所提供的列表创建合并药物列表。所述列表被呈现使得包含从主要护理医师的列表并入的药物的行用黄色高亮显示，并且随后提示外科医生保留或者去除这些黄色高亮显示的行，以作为关于确认或拒绝主要护理医师所表明的在填写主要护理医师的表单时由患者服用的药物的指示。在外科医生对所有黄色高亮显示的行采取动作之后，移动设备随后把最终的文档保存到计算机服务器。

计算机服务器可以利用存储在永久性存储中的搜索引擎数据库存储所有可能的代码(可能有数十万的这些代码)。当用户基于特定标准(例如文本搜索项、比如放射科规程之类的代码类型等等)寻找特定代码时，计算机服务器遍历(iterate through)存储以便找到与所规定的标准相匹配的代码，其中可能使用索引或分布式搜索(其中代码被分布在用来分治搜索的多台计算机服务器上)来优化这一处理。

计算机服务器存储HSD文档(比如JSON文档)，其方式在两个方面不同于标准纸质表单。首先，创建不仅自动记录对于每一个HSD表单(比如JSON表单)的改变(什么以及由谁)而且还记录内容何时被查看、查询或打印(什么以及由谁)的稽核踪迹。其次，可以由单个用户“锁定”HSD文档(比如JSON文档)以便防止其他用户对于相同文档的同时改变。

稽核踪迹存在于至少其中一台计算机服务器上的不同存储部分中，并且每当实施改变、查看、打印或查询活动时被修改。

所述锁定也可以被存储在至少其中一台计算机服务器上的不同存储部分中。对于每个HSD文档(比如JSON文档)可以自动创建一个锁定，并且其具有以下属性：(a)底层JSON文档的ID；(b)锁定JSON文档的人的用户ID(如果该文档当前被锁定的话)；(c)用户在其中锁定文档的用户登录会话的安全性令牌；(d)锁定被建立时的时间戳。

当用户想要在设备(比如移动设备)上修改HSD文档(比如JSON文档)时，移动设备软件首先确认没有其他用户在至少其中一台计算机服务器上的所述文档上设置锁定。

一般来说，可以独立于健康记录JSON文档并且独立于例如移动设备和/或服务器软件的版本来更新表单布局，只要表单布局定义所依赖的能力(而不是具体定制本身)受到移动设备和/或服务器软件版本的支持即可。

健康记录表单HSD文档(比如JSON文档)的片段也可以被存储在至少一台计算机服务器上，以便支持其中用户具有被例行输入到健康记录表单中的信息的情形；前面的移动设备软件的自动填写菜单还可以显示适用的健康记录表单片段，并且当用户在对应于此类片段的菜单项目上敲击时，移动设备软件可以利用已被存储在该片段中的那些栏位自动填写表单。

为了促进一次创建多个健康记录表单文档的处理，移动设备软件例如可以允许特别标记的列表小部件利用“批处理模式”收集用于多个文档的信息。举例来说，为了允许用户一次输入多项用药指示单，可以规定特别标记的列表小部件，其中表中的每一行实际上是单独的用药指示单。在用户完成输入用于批处理文档创建的所有信息之后，移动设备软件例如创建刚刚所创建的健康记录文档的一份单独的拷贝，其不同之处在于，关联到所创建的每一份单独的健康记录文档拷贝中的特别标记的列表小部件的属性包含原始阵列的单行而不是整个阵列。

一些医疗表单可能需要图像、扫描文档或者其他图形单元。至少一台计算机服务器可以存储可以与每一个健康记录表单相关联的图形附件。表单布局可以规定用以显示图形附件的屏幕区域。

在本发明的另一个示例性实施例中，本发明包括一种在无需创建电子健康记录系统软件的多个版本的情况下定义电子健康记录系统中的定制工作流程的方法。这里的挑战在于如何定制电子健康记录系统，以便允许特定用户类别在对应于医院或其他健康护理机构中所存在的处理的步骤序列中创建、检视、许可或拒绝健康记录表单(例如登记新的患者，允许药剂师检视由护士代表医生撰写的处方，记录为患者给出的用药剂量等等)——而不需要移动设备/服务器软件的多个版本。本发明通过利用HSD文档(比如JSON文档)的灵活性以及HSD文档(比如JSON文档)在前面提到的任何适当设备上被动态处理的独有方式实现了这一点，从而例如提供了一种可以允许技术人员把“模式化处理”定义成存储在至少一台计算机服务器上的HSD文档(比如JSON文档)的解决方案。所述模式化处理是利用例如JavaScript代码之类的脚本代码定义的(当然这可以被推广到使用某种其他编程语言)。所述代码例如可以运行在移动设备上，并且可以与至少一台计算机服务器动态交互，从而实施诸如前面所定义的查询、文档创建、文档锁定/解锁以及文档删除之类的操作。为模式化处理代码给出对于操作“情境”的访问(例如如果代码在用户查看特定患者记录时被调用，则向模式化处理传递参数从而向其通知该患者的ID)。模式化处理代码还可以被允许利用“堆栈(stack)”隐喻在屏幕上显示表单。所述表单可以类似于由技术人员创建的前面所描述的健康记录表单，其不同之处在于，模式化处理中的表单可以基于情境、从其他健康记录文档收集的信息等等被即时动态地生成。这些表单可以显示/捕获特定于正被实施的人工处理的数据。堆栈隐喻与web浏览器的隐喻的类似之处在于，当显示新的表单时，其具有被“堆叠”在先前显示的表单之上的选项，从而使得用户可以在“返回”按钮上敲击并且回到先前的表单。

本发明还可以允许技术人员把工作流程许可步骤定义成表单布局HSD文档(比如JSON文档)的一部分(作为前面的#1的一部分进行了描述)。工作流程可以被定义成需要从已定义的用户类别集合(工作流程的“步骤”)收集的一系列数字签名以便达到最终的“状态”(例如“被许可”状态)。在向用户显示健康记录表单时，移动设备软件可以在屏幕上显示出按钮，以允许用户进行“提交”、“许可”、“拒绝”或“确认”——这些动作(除了“拒绝”之外)可以得到数字签名(利用例如SHA-256之类的标准数字签名算法)，所述数字签名是基于当前用户的私有密钥对于显示在表单上的数据计算的，并且被添加到保存在至少一台计算机服务器上的健康记录文档。此外，随着文档经历工作流程中的各个步骤而收集到必要的数字签名并且变得需要另外的数字签名，至少其中一台计算机服务器可以被用来把例如指向医生的指针存储在服务器的专用于特定用户或者专用于特定用户类别的存储部分中，其被称作“队列(queue)”。移动设备软件例如可以呈现对应于已登入用户或者该用户所属的用户类别的队列，以便提醒用户有文档等待他/她签名。“拒绝”的工作方式略有不同——例如移动设备软件去除至此为止所收集到的数字签名，并且把文档返回到原始提交者(第一签名人)的队列。“确认”是被支持以允许对于特定步骤充当实际经过授权的用户或者实际经过授权的用户类别的代理的用户作为代理对文档签名的动作。随后可以把指向文档的指针存储在用于代理用户代表其进行签名的经过授权的用户或用户类别的队列中，从而为经过授权的用户提供“确认”所述代理确实作为其代表采取行动的机会。

在本发明的另一个示例性实施例中，包括一种在无需创建电子健康记录系统软件的多个版本的情况下定义电子健康记录系统中的定制视图的方法。通过利用HSD文档(比如JSON文档)的灵活性以及HSD文档(比如JSON文档)在前面提到的任何适当设备上被动态处理的独有方式，解决了关于如何定制电子健康记录系统的挑战，以便允许用户例如使用移动设备软件来查看可以从多个健康记录表单导出并且可以被核对/重新安排/对应/交叉参考的信息，从而使得更容易支持决策制定处理而无需改变健康记录表单被存储在至少一台计算机服务器上的方式(例如对于所有住院患者显示出即将配药的用药指示单的列表，作为曲线图显示出过去2小时的特定患者的血压和心率等等)。举例来说，健康记录可以作为一系列HSD文档(比如JSON文档)被存储在至少一台计算机服务器上。本发明的解决方案包括允许技术人员把“定制小部件”定义成存储在至少一台计算机服务器上的HSD文档(比如JSON文档)。所述定制小部件例如可以利用存储在HSD文档(比如JSON文档)内部的HTML与例如JavaScript之类的脚本的混合来定义(当然也可以选择其他语言)。代码可以运行在设备(例如移动设备)上，并且可以与至少其中一台计算机服务器动态交互，从而实施例如前面所提到的查询、文档创建、文档锁定/解锁以及同样如前面所提到的文档删除之类的操作。可以为定制小部件代码给出对于显示请求的“情境”的访问(例如，如果代码在用户查看特定患者记录时被用来显示信息，则向定制小部件传递参数从而向其通知该患者的ID)。由于标准web技术可以被用来把定制小部件托管在设备(例如移动设备)上，因此可以很容易地合并第三方库(例如用于显示图表、计算体质指数等等)。此外，本发明可以允许把多门户组件(multi-portlet)“报告”定义成存储在至少一台计算机服务器上的HSD文档(比如JSON文档)。所述报告规定将由移动设备软件同时显示的小部件集合(其中包括前面所描述的定制小部件，而且还包括模式化处理)，以便在单个屏幕上为特定用户类别提供到相关信息的可见性。定义报告的HSD文档(比如JSON文档)提供将要显示的小部件列表以及例如宽度/高度之类的几何约束，以便允许移动设备软件按照具有视觉吸引力的方式在屏幕上排布各个小部件。

在本发明的另一个示例性实施例中，一种方法在无需创建电子健康记录系统软件的多个版本的情况下定义电子健康记录系统中的定制导览菜单。通过利用HSD文档(比如JSON文档)的灵活性以及JSON文档在前面提到的任何适当设备上被动态处理的独有方式，解决了关于如何定制向一个或多个用户类别显示的用户界面菜单从而使得很容易访问相关信息的挑战，这是根据以下事实：(a)任何给定用户可以同时是不止一个而是多个类别的成员；(b)被认为对于某一用户类别是相关的信息可能由于新的治疗协议的发展而快速改变，其中一部分在极端情况下可能无法等待移动设备/服务器软件的新版本。举例来说，健康记录可以作为一系列HSD文档(比如JSON文档)被存储在至少一台计算机服务器上。本发明所给出的解决方案允许技术人员把“内容层级表”和“内容层级贡献表”定义成存储在至少一台计算机服务器上的HSD文档(比如JSON文档)。当患者记录由移动设备软件显示时，例如移动设备软件向至少其中一台计算机服务器查询对应于情境中的对象(其通常最初是包含患者的基本/人口统计信息的健康记录表单)的内容层级表和内容层级贡献表。内容层级表HSD文档(比如JSON文档)可以通过唯一标识符来标识(存储在至少一台计算机服务器上的所有HSD文档(比如JSON文档)都是如此)，并且可以包含例如关于如何计算将为对应于该层级的菜单显示出的标题以及如何向至少其中一台计算机服务器查询适合在该菜单层级显示的信息和/或健康记录文档的信息。内容层级贡献表HSD文档(比如JSON文档)可以列出所述贡献对其相关的用户类别，并且包含到用于为之作出“贡献”的内容层级表HSD文档(比如JSON文档)的唯一标识符的参考。当在设备(例如移动设备软件)中显示菜单时，对于已登入用户相关的内容层级贡献表(由于该用户在例如医师、护士、实验室技术人员等特定用户类别中的成员关系)被聚合并且显示成菜单。每一个内容层级贡献表可以包括一系列节段；每一个节段包括菜单项目规范序列。各个节段可以依次被垂直地顺序显示，并且在每一个节段内，各个菜单项目可以根据菜单项目规范依次被垂直地顺序显示。存在几种类型的菜单项目规范，其中包括：(a)到表单布局HSD文档(比如JSON文档)的参考——其表明作为如在内容层级表JSON文档中规定的针对至少其中一台计算机服务器的查询的结果集合的一部分并且是利用所参考的表单布局HSD文档(比如JSON文档)创建的健康记录文档应当具有显示在菜单的该部分处的相关联的按钮，所述按钮在被敲击时使得文档被打开以进行编辑；或者可以显示出按钮以允许用户利用所参考的表单布局创建健康记录文档；(b)到定制小部件、多门户组件报告或者模式化处理的参考，以便允许用户在所得到的菜单项目上敲击从而带出菜单的情境中的相应的用户界面单元；(c)到内建命令(比如“打印”或者“添加患者门户访客账户”)的参考，以便为用户提供对于内建到移动设备软件中的功能的访问；(d)健康记录表单片段，其提示移动设备软件显示允许用户基于来自所述片段的预先填写的值创建新的健康记录的菜单项目。还可以利用编号对内容层级贡献表的各个节段进行优先级排序(具有较低优先级编号的节段被排序成在菜单中更早显示)并且还为其指派超驰关键字(override key)——这样允许定义具有相同超驰关键字的节段的多项贡献仅显示具有最高(或最低)优先级的一个节段而不是所有此类节段。最后，当对应于特定文档类型或文档的菜单项目被敲击时，移动设备软件可以显示子菜单(也就是内容层级表-内容层级贡献表的从属集合)，而不是打开文档以进行编辑。

在本发明的另一个示例性实施例中，一种方法通过一系列测试环境向生产系统转出定制(表单、工作流程、定制视图、导览菜单)。通过利用JSON文档的灵活性以及HSD文档(比如JSON文档)在前面提到的任何适当设备上被动态处理的独有方式，解决了关于如何通过各种方式在模拟由机构职员使用的计算机服务器的替换计算机服务器上验证定制的挑战，并且最终以最低程度的中断把更新后的定制部署到至少其中一台生产计算机服务器。举例来说，健康记录可以作为一系列HSD文档(比如JSON文档)被存储在至少一台计算机服务器上。除了至少其中一台生产计算机服务器之外，所述解决方案假设具有被配置成用于测试使用的多台计算机服务器(例如一台具有被用于简单测试的测试患者记录，一台具有被用于兼容性测试的真实患者记录的拷贝，一台具有由职员创建的虚构患者记录以用于训练目的等等)的环境。移动设备软件支持通过“同步(sync)”处理来传播定制，也就是说，用户使用移动设备软件同时登录到两台计算机服务器，并且把两台服务器上的定制(即，不是患者记录)HSD文档(比如JSON文档)进行比较。所述比较处理可以在设备(例如移动设备)上实施并且工作如下：(a)利用唯一标识符(例如128比特UUID)来标记HSD文档(比如JSON文档)，其允许标识出两台服务器上的哪些HSD文档(比如JSON文档)被认为是相同文档的不同版本；(b)计算HSD文档(比如JSON文档)的正规化(canonicalize)版本并且进行比较；如果其相同，则认为文档没有发生改变；(c)如果存在差异，则比较两个文档上的最近一次更新或最近一次同步的时间戳，并且如果存在差异，则移动设备软件向用户表明二者当中的哪一项被认为是日期更近的；(d)对于仅存在于其中一台服务器或另一台服务器上的HSD文档(比如JSON文档)(也就是说在另一台服务器上不存在具有相同的唯一标识符的文档)，移动设备软件向用户表明该文档是新的；(e)移动设备软件允许用户选择哪些文档版本要保持以及哪些版本要在任一个方向上传播，并且可以通过自动建议可以安全地传播仅存在于一台服务器上而不存在于另一台服务器上的文档或者其中一台服务器具有根据存在于另一台服务器上的版本而被修改的文档(也就是说并非存在于任一台服务器上的一对文档被同时修改的情况)简化这一处理；(f)通过直接把文档添加到另一台服务器(如果文档是新的话)，或者首先锁定目标服务器上的文档，把新的版本写入到目标服务器，并且最后解锁文档(类似于较早前描述的锁定/解锁概念)，移动设备软件随后在每一个所选择的文档上实施传播。

不同于通常需要使得系统离线或关停一段时间以便替换软件二进制的软件改变，本发明中的定制被存储为配置数据而不是表现在二进制代码中，因此不需要对移动设备/服务器软件作出改变，从而减少了停机时间。此外，不同于特别因为HSD(比如JSON)非常信息密集并且难以通过视觉方式挑选出改变而易于出错的人工同步处理，由移动设备软件实施的自动化处理能够利用散列非常精确并且准确地比较大量的定制。此外，由于HSD文档(比如JSON文档)总是“可用于”由其他用户使用移动设备取回，即使当新的版本被写入到给定的计算机服务器(采用被称作原子性的数据库的基本属性)时也是如此，并且还因为通过仅允许兼容的小部件改变(例如用是/否选择替换复选框)、通过添加新的小部件(从而不会影响读取/编辑由已经存在的小部件显示的值的能力)或者通过添加全新的健康记录表单模板可以使得定制HSD文档(比如JSON文档)“后向和前向兼容”，因此不需要停机时间来对包括生产计算机服务器在内的任何计算机服务器实施这些更新；这与许多基于传统关系数据库(或者甚至基于二进制代码)的定制模型不同，在这些定制模型中，用以支持新的定制的模式改变可能需要计算机服务器并且从而还有总体电子健康记录系统的停机时间。

在本发明的另一个示例性实施例中，本发明包括一种按照多模式方式输入健康记录数据的方法。由于例如在移动设备上导览大量菜单和表单以找到特定信息已被/应被记录的位置可能较为困难，因此特别对于习惯了纸质记录的医生来说，即使在单个机构内，在无需移动设备/服务器软件的定制版本的情况下支持用户的各种使用样式/要求的需求仍然可能是很大的挑战，而本发明通过利用HSD文档(比如JSON文档)的灵活性以及HSD文档(比如JSON文档)在前面提到的任何适当设备上被动态处理的独有方式实现了这一点。

用户可以通过多种模态(例如语音、触摸、键入等等)的组合向给定动作(例如撰写出院证明、开药等等)提供参数，并且安装技术人员可以通过存储在至少一台计算机服务器上的HSD文档(比如JSON文档)的形式规定可能的命令。举例来说，技术人员可以定义命令集合，每一项命令定义可以包括以下部分：(a)被允许使用该命令的用户类别的集合；(b)调用该命令的话语，其中可以包括语言的变型(例如“给我看过敏症(show me allergies)”相对于“显示过敏症(display allergies)”)，并且可以使用自然语言处理技术来描述可能的变型(例如BNF语法)；(c)参数集合，其中每一个参数可以包括(i)名称、(ii)语义类型(例如日期、患者ID等等)、(iii)表明其是否可选的标志、(iv)表明该参数所表示的对象是否需要被“打开以进行编辑”的标志(例如为了执行命令“把这个记下来以作为患者的症状(takethis down as the patient’s symptoms)”，“症状(symptoms)”健康记录文档例如需要在移动设备上实际被打开而不仅仅是被识别)；(d)每当由于用户动作而例如由移动设备收集参数时所执行的代码，其在收集到所有所需要的参数时执行命令；(e)可选地可以向用户输出以进行确认和/或消除歧义的消息(例如对于操作“给我看在两次就医之间增加了多少体重(show how much weight was gained between visits)”，在规定了其中一次就医之后，可能需要提示用户“规定与哪一次就医进行比较(specify which visit to compareagainst)”，这是因为例如“规定就医#2(specify visit#2)”之类的一般语言可能不够用户友好)。在用户登入时或者在话音辨识会话启动时，设备(例如移动设备)软件可以从至少一台计算机服务器加载适用于该用户所属的用户类别的具有话音命令规范的所有HSD文档(比如JSON文档)。当例如由移动设备软件捕获自然语言命令时(使用话音辨识组件/技术，其可以由平台提供、由语音辨识库提供或者由某种其他自然语言输入机制提供，其中包括键盘)，将其与可能的命令话语进行比较以便找到匹配的命令。如果找到匹配，则启动“会话”以通过下面的重复处理收集参数：(a)查看可能由用户的当前情境所满足的参数(例如刚刚通过用户的触摸动作而在移动设备上打开的患者记录可以有资格作为针对正被执行的命令的患者参数)；(b)提示用户找到或识别满足给定参数的需求的对象(例如“你想要显示患者的过敏症。请识别患者。(you want to display a patient’s allergies.pleaseidentify a patien.)”)，这可能是通过口头消息或者通过显示在设备上的事物；(c)调用命令定义内部的代码以便考虑从用户处收集或者从情境识别的作为可能参数值的新的对象，并且如果所有参数都被满足，则执行命令——例如JavaScript(或其他语言)之类的脚本代码随后将与移动设备/服务器软件进行交互，以便添加/查询/去除健康记录文档、在屏幕上对其进行显示或者对于命令所适当的其他动作。

在命令的参数已被满足并且准备好执行命令之后可以发生的一项可能的动作(由命令定义内部的代码规定)是例如把移动设备的操作模式改变成听写(dictation)模式。在该模式下，除了在通过听写收集到的文本上进行操作(例如拷贝/粘贴、删除)的固定话语以及表明听写模式的结束的话语之外，所捕获的话音被收集作为用于由命令定义规定的某个栏位的值(例如“针对处方配药的特殊指令(special instructions for prescriptiondispensation)”)。这样可以在例如“开具一天两次扑热息痛的处方(prescribeacetaminophen twice a day)”之类的话语意图作为文本被捕获并且直接记录到健康记录文档中时防止其被混淆成针对系统的命令。

在参数捕获期间以及在参数捕获结束时可以发生(可能多次发生)的另一项可能的动作(由命令定义内部的代码规定)是语音提示。在对话中的特定点处对用户说出的口头消息可以帮助引导用户提供用于执行命令的必要参数。

举例来说，一条内建命令可以是“别管了(never mind)”或其变型，其在由例如移动设备软件听到时表明用户想要取消执行命令和捕获任何所需的参数。

可以通过多种方式“嵌套”多条命令，并且会话机制允许解析可能在参数捕获期间出现的歧义。举例来说，如果用户最初声明希望“记录出院证明(record a dischargenote)”，例如移动设备随后提示用户指定“哪一位患者？(which patient？)”，随后用户声明命令“给我看上星期的患者(show patients from last week)”，系统可以提示用户指定“上星期(last week)”所指的是什么——住院日期还是出院日期，并且针对该问题的回答可以被消除歧义以指代对于“给我看上星期的患者(show patients from last week)”开始的第二会话，这是因为所述回答匹配第二命令/会话所需的参数的语义类型，并且不匹配任何第一命令/会话所需的参数的语义类型(如果这样的歧义存在，则移动设备将提示用户消除歧义)，此外，一旦显示出上星期的患者列表并且选择了一位患者，由于患者是第一命令/会话最初所要求的信息类型，因此其可以被用作针对第一命令/会话的参数。换句话说，多个命令会话可以同时活跃，由移动设备通过提示或者情境捕获的对象可以被用来满足用于这些命令会话当中的任一个的参数，并且如果存在歧义，则移动设备可以提示用户消除歧义。

虽然可能已经设想到用于多模式交互的其他系统，但是例如通过移动设备软件和至少其中一台计算机服务器实施的该机制允许在无需改变底层移动设备/服务器软件的情况下对话音样式和命令定义进行定制。

在本发明的另一个示例性实施例中，本发明涉及随着时间演进从而改进处理、对规章改变作出响应以及/或者修正错误的健康护理表单，并且当需要把关于原始表单布局集合所记录的健康记录迁移到具有新的表单布局的较新表单的集合上时，没有不必要的停机时间也不需要移动设备/服务器软件的新的版本。

当今在大多数其他EHR中，通常不鼓励表单模板改变，这不仅是因为更新硬编码的模板以产生新版本所需的工作量，而且还因为需要把数据迁移到新的模板版本，正如前面所提到的那样。用于应对更新的通用方法非常少，因此在升级到主要的新版本已完成时，常常开发定制工具以进行迁移。由于可能的停机时间以及在升级期间出错的可能性，这样的升级不会频繁进行。

本发明通过允许技术人员定义驻留在至少一台计算机服务器上的转换映射HSD文档(比如JSON文档)而满足了前述挑战，转换映射HSD文档把存在于原始表单布局集合上的数据栏位映射到更新后的/新的表单布局集合上的栏位上。

由技术人员定义的转换映射可以包括直接映射(例如属性“dob”需要被映射到属性“dateOfBirth(出生日期)”)以及可以利用JavaScript代码之类的脚本代码定义的更加复杂的映射的组合。

设备(例如移动设备软件)随后可以利用登录到负责保持患者记录的系统的用户的身份通过以下方式实施所需的变换：

移动设备软件开始于识别和锁定至少一台计算机服务器上的所有相关的(也就是使用所表明的原始和/或新的表单布局的那些)健康记录HSD文档(比如JSON文档)；

移动设备软件遍历在转换映射的变换前侧中所参考的每一个数据栏位，并且对于具有该栏位的每一个健康记录文档：(a)移动设备软件识别与该栏位被映射到的变换后数据栏位相关联的表单布局；(b)如果对应于该相同患者的健康记录文档(并且可能还有相同的会面ID或者其他相关的分组机制)尚不存在，则将一个健康记录文档添加在计算机服务器上并且锁定；(c)把数据映射过去并且写入到目标健康记录文档(其或者已经存在并且是在(b)中创建，或者实际上是与源健康记录文档相同的文档)上的相应的变换后数据栏位中；(d)将改变保存到计算机服务器；

在所述处理结束时，移动设备软件释放至少一台计算机服务器上的所有触及的健康记录JSON文档；以及

移动设备软件随后向用户呈现发生了映射的报告。如果其中一些映射由于以下原因未能发生：(a)另外的某人锁定了所需的文档；(b)数据被不正确地格式化；(c)在转换中检测到不一致——则移动设备向用户报告这些问题。

前面刚刚描述的处理可以被重复所需要的次数，每一次运行都把健康记录系统朝向目标转换“状态”递进地移动。通过这种方式，所述系统与GPS导航设备具有相同的属性，也就是说不管在中途遇到什么问题，重复尝试运行所述处理都导致更加接近目标目的地状态。

另一个重要的好处在于，即使在转换期间仍然可以由系统中的其他用户参考并且看到锁定的文档，并且仅仅短暂地禁止对于例如正由移动设备软件的转换所处理的特定文档作出进一步改变。

在一些示例性实施例中，本发明的EHR系统可以基于使得系统的大多数方面的配置以系统对象的形式暴露于管理员，所述系统对象例如可以利用YAML句法来定义，并且例如作为HSD文档(比如JSON文档)存在于系统中，正如前面所讨论的那样。通过这种方式，可以在无需改动底层EHR系统“后端”的情况下实现对于EHR系统的所暴露出的“前端”的各种改变和/或修改。改变和/或修改可以包括而不限于修改表单、创建新的工作流程。

在一些实施例中，本发明的EHR系统可以采用例如表单布局之类的基本系统对象，其可以定义如何向用户呈现信息和/或信息的总集，比如在表单之类的视觉表示中呈现，以及/或者如何在EHR系统中结构化和/或记录所输入的信息。

在一些实施例中，模板可以被用来作为表单向用户显示和/或组织一系列单独的信息呈现和/或收集组件，所述表单在视觉上可以类似于在健康护理环境中通常所采用的电子和/或纸质表单。举例来说，各个单独的信息呈现和/或收集组件可以是表单小部件(例如HTML小部件)，其随后可以被用户利用作为设备上的界面以用于输入和/或取回信息。表单小部件本身可以被嵌入到正显示在本发明的EHR系统的用户界面上的表单和/或报告中。信息和信息结构随后可以被存储在例如至少一台计算机服务器上的本发明的EHR系统的永久性存储中的HSD文档(比如JSON文档)内。

多种小部件可以被利用来例如简化对于不同种类的信息的收集，其中可以包括而不限于文本输入、日期和时间、血压读数、基于标准词汇表的代码、从设备取得的图片和/或照片以及/或者任何其他适当的小部件。小部件还可以被划分成各个节段和表以便于导览。在从用户收集数据时，可以通过小部件记录用于信息的值，其可以进一步被记录在通过模板定义的关键字之下，并且被放置到HSD文档(比如JSON文档)中。通过这种方式，表单的用户界面可以被利用来按照所利用的模板呈现底层HSD文档(比如JSON文档)，以便由用户按照用户友好的管理员定义的方式进行检查和修改。

在一些实施例中，宏集合可以被用来规定当在用户界面中操纵信息时出现在本发明的EHR系统中的宏集合。举例来说，当按下宏按钮时，对应于该宏按钮的文本可以被插入到活跃文本栏位中。所述文本可以由定义在宏集合中的脚本动态地生成，所述宏集合在由移动设备运行时从至少一台计算机服务器获得潜在地情境相关数据，比如患者的过敏症或人口统计信息，以便包括在所插入的文本中。宏集合的目标可以被设定在表单上的特定栏位、特定用户和/或特定群组。通过这种方式，需要快速键入常用的文本片断和/或其他信息的用户可以具有被定制成适合其需求的界面，从而可以允许其更加高效地输入信息。

一般来说，当EHR系统中的任何给定记录(比如患者记录)随着时间增长时，特定信息项可能会不可避免地被反复收集，比如过敏症和当前用药。举例来说，可能存在临床和/或可稽核性要求，其可能要求多次收集信息，从而可能导致最新的信息潜在地被分散在多个文档中。举例来说，患者可能在一次会面期间声明特定过敏症，但是在下一次会面中则忘记提起。

在一些示例性实施例中，本发明的EHR系统可以提供调和能力，以便允许将收集自多个文档上的相同和/或相关的表单模板的信息一起呈现，并且允许用户选择保留哪些(如果有的话)重复的和/或相矛盾的条目以及丢弃哪些条目。不同于纸质记录，EHR系统中的信息可以由EHR系统结构化和/或可识别，比如通过前面所讨论的关键字处理，从而使得搜索可以允许很容易聚集相同和/或相关的信息，而不是像纸质记录那样，用户必须人工筛检所有适用的表单以取回信息。此外，在纸质记录中，可能无法像EHR系统那样很容易地把信息从分散的纸质文档中拉取到单个文档上，或者当匆忙检视或时间紧迫时，在检视纸质文档的过程中可能会错失信息。

此外，不同于纸质文档，其中用于组织和/或重新组织的仅有手段通常是对页面重新排序、插入封面/分隔页面以及/或者附着带状标志等等，电子记录通常可以被基本上瞬时地重新整理，以便满足当时正在进行的工作的需求。举例来说，实验室技术人员感兴趣的患者记录中的文档子集可能在某种程度上不同于例如办理患者住院的接待员所感兴趣的子集。在纸质表单中，除了按照不同顺序具有相同记录的多份拷贝之外，无法对于一个用户按照不同于另一个用户的方式重新组织页面，这在患者护理中可能会导致问题，本发明则允许一个用户群组(例如实验室技术人员)感兴趣的患者记录中的文档子集可以在某种程度上不同于例如办理患者住院的接待员所感兴趣的子集。多份拷贝的存在还可能在稽核过程中导致问题和过度的开销，对于本发明的EHR系统则不会产生这些问题和开销。

在本发明的一个示例性方面中，本发明的EHR系统可以利用内容表(TOC)系统对象来定义用于患者记录中的文档的动态组织。在一些实施例中，可以通过TOC把文档动态地组织到树结构中，所述树结构可以类似于大多数台式计算机用户所熟悉的标准“文件夹范例”。举例来说，不同于纸质书之类的内容表，本发明的EHR系统能够利用可以不是静态的TOC定义，从而可以例如基于情况需求和/或基于用户的(多个)角色(例如医生、实验室技术人员等等)在每个用户的基础上对其进行适配。因此可以针对特定用户和/或特定情况需求来定制TOC，以便提供用以导览经过文档中的信息的高效和/或直观的组织方案。此外，不同于常见的文件夹分级结构类型的文件系统，EHR系统TOC可以作为导览工具操作，而不是实际控制信息本身被存储在系统内的方式。

在一些实施例中，根部TOC层级可以定义呈现给用户的选择菜单。所述选择菜单还可以包含文档的混合，比如基本患者信息文档、报告(例如“随着时间的血压(BloodPressure Over Time)”)以及/或者到其他TOC层级的链接,其在外观和/或用途方面可以类似于典型桌面系统中的子菜单。所述菜单通常可以被定义成针对本发明的EHR系统的数据库的一系列查询，并且所述查询可以非常具体(例如“给我看患者唯一的基本患者信息文档(show the patient’s one and only Basic Patient Information document)”)、宽泛(例如“给我看该患者的所有放射图像(show all radiology images for thispatient)”)以及/或者具有任何介于中间的具体性。菜单通常还可以被划分成多个节段以易于导览，并且还可以包括可以允许添加新的文档和/或组织层级的按钮和/或其他控制特征件。举例来说，菜单可以包括列出针对特定患者的所有放射图像的节段，并且按钮和/或其他控制特征件可以被配置成出现在该节段中以便为用户给出添加信息(例如新的图像)的选项。

在一些实施例中，TOC层级可以包含到其他TOC层级的链接，从而用户可以根据具体任务和/或情况选择沿着不同的轴来查看文档。这种灵活性与纸质系统完全不同，在纸质系统中只能按照一种方式或另一种方式对物理纸张进行排序，并且对其重新排序是非常耗时的。举例来说，通过在本发明的EHR系统中定义例如用于患者会面的TOC子层级并且把到患者的不同会面的链接放置在根部TOC层级中，门诊医师可以通过会面来查看关于患者所收集的信息。与此同时，作为另外的实例还可以定义用于记账账户的不同TOC子层级，并且把到这些账户的链接放置在根部TOC层级中。这些链接随后例如可以为会计部门的记账专业人员提供到完全相同的患者记录文档中的不同视图，所述视图按照对于单个纸质记录所不可能的方式更加适合于记账专业人员的需求。

在本发明的另一个方面中，由本发明的EHR系统利用的系统对象通常可以由机构按照类似于其他机构知识的方式来对待，并且因此可以被备份、版本处理、根据已定义的改变处理更新以及/或者在其他方面按照与受到管理的其他机构知识类似的方式来对待。

在一些示例性实施例中，系统对象通常可以定义关于用户如何与其机构处的本发明的EHR系统进行交互的几乎每一个方面。因此，系统对象的整个总集可以被备份、版本处理、根据已定义的改变处理更新等等。举例来说，在EHR系统转出的开头，可以基于各种项目的通用定义的组合来产生初始版本，比如内容表、患者表单布局、针对患者住院的特定于机构的定制以及/或者实验室处理。随后可以按照多种方式引入系统对象总集的下一个版本和/或后续版本，以便最小化对于机构处的EHR系统的持续操作的干扰。可能希望在可以被专用于开发和测试的本发明的EHR系统的拷贝或实例上对这些系统对象实施更新，并且从而与正由机构使用的主要操作实例分开。因此，当设计工作和/或其他更新完成和/或被许可时，新的系统对象总集可以被拷贝到同样可以与主要操作实例分开的本发明的EHR系统的训练实例，以便在不影响机构处的本发明的EHR系统的主要操作实例的持续操作的情况下允许职员和/或其他用户熟悉新的改变。在充分的训练、调试和/或其他定型之后，所述系统对象总集随后可以被推送到生产服务器，从而使其可以在本发明的EHR系统的主要操作实例中成为机构中的主流使用的一部分。

在一些实施例中，本发明的EHR系统可以通过利用同步工具来提供对于系统对象总集的版本管理，所述同步工具可以促进本发明的EHR系统的实例之间的系统对象定义的传递，比如开发和测试实例、训练实例以及主要操作实例之间的传递。在一个实施例中，同步工具可以利用识别系统对象的各个版本的方法，从而可以把同步发生时的歧义降到最低程度。举例来说，同步工具可以识别不同的版本，并且为用户给出例如单独地、全体地或者分批地把系统对象的更新后的版本从一个实例拷贝到另一个实例的选项。

在其他实施例中，本发明的EHR系统可以通过利用标准软件开发源控制实践来提供对于系统对象总集的版本管理，所述实践通常可以把每一个系统对象作为可以从源控制储存库检出和更新的源文件来对待。举例来说，本发明的EHR系统例如对于系统对象的源文件可以利用git储存库。源控制通常例如可以允许更大的人员集合同时工作于更新，并且/或者以更加系统性的方式管理由每个人引入的改变。作为另外的实例，标准软件开发源控制实践还可以采用广为接受的用于备份和保持存储库的最佳实践，比如git，其可以被实施来保护由机构所利用的系统对象。

在一些示例性实施例中，本发明的EHR系统还可以包括能够从设备上的用户界面直接访问的用于修改和/或定制系统对象的特征件。这可能是符合期望的，因为本发明的EHR系统的表单、模板和/或其他系统对象组件可以被即时修改和/或定制，而不是完全依赖于存在延时的开发和/或定制。举例来说，定制因此可以在现场发生以及/或者在使用本发明的EHR系统的过程中发生，而不是等待很长的开发/更新周期才能发生。在一些实施例中，可以直接从本发明的EHR系统的用户界面内利用YAML句法的子集来创建和/或编辑系统对象。

在本发明的另一个方面中，本发明的EHR系统可以利用工作流程来促进和/或实施用户集合对于文档的检视和/或许可。

在一些实施例中，可以利用工作队列并且其可以包括已被张贴以供接收方使用、检视和/或许可的文档列表，其方式类似于电子邮件系统的收件箱。一般来说，本发明的EHR系统可以为每一个用户提供工作队列，并且/或者为每一个用户群组提供单个工作队列。EHR系统用户界面还可以包括仪表盘(dashboard)，其中用户可以查看已被张贴到其自身的工作队列以及/或者其所属的任何群组的工作队列的文档列表。

一般来说，把文档张贴到工作队列不会将其从本发明的EHR系统中的任何其他位置处移除(比如从患者记录和/或其他可访问的位置移除)，相反工作队列可以仅包含到已被张贴到其中的文档的链接。作为另外的实例，当文档被从工作队列中移除时，一般可以仅从队列中删除链接，底层文档则不受影响或者不被删除。通过这种方式，本发明的EHR系统可以利用电子系统，比如利用文档检入和检出特征，其可以允许本发明的EHR系统把底层文档保留在中央存储中，同时允许其被链接、可见和/或通过其他方式从本发明的EHR系统的各个部分访问而不会产生矛盾。

在一些实施例中，工作队列和/或工作流程中的文档例如在所述文档可以在工作流程中前进之前可能需要由特定用户检视和/或许可。在一个实施例中，工作流程中的文档可以由适当的用户签名以便继续工作流程。在一个实施例中，如果收集到来自所有必要用户和/或参与方的签名，则可以说文档已完成其工作流程。可以基于工作流程步骤来确定必要用户和/或参与方的列表。

一般来说，签名可以是数字签名或人工签名。例如可以通过使用公共/私有密钥对来创建数字签名，所述密钥对可以在每一个用户第一次对表单签名时为他/她生成并且还可以受到口令或其他加密密钥的保护，所述口令或其他加密密钥可以被用作该用户的签名口令。本发明的EHR系统中的数字签名例如可以使用在表单上对于用户可见的HSD(比如JSON)属性值的散列，这对于允许稽核员确认签名是真实的以及/或者签名对应于签名时显示在屏幕上的数据来说可能是符合期望的。

还可以利用人工签名，所述人工签名可以实质上是通常可以采取传统手写签名的形式的人类可读证据，还可以在本发明的EHR系统的用户界面中为其给出视觉表示。人工签名例如可以被存储在文档的属性中，所述属性被利用用于文档的模板的属性向工作流程系统声明。不同于数字签名，人工签名通常不可由EHR系统本身认证，因此EHR系统例如可以要求用户证明人工签名是代表经过授权的提交者正确地捕获的，以作为例如可稽核性的一部分。

工作流程中的文档提交者通常可以是发起特定工作流程处理的用户；但是所述提交者可以不一定是在工作流程中的某一步骤结束时提交文档的同一人。举例来说，许多机构允许电话指示单以及/或者通过传真或者其他基于纸张的手段接收到的指示单，因此提交文档的人可能是在代表文档的实际提交者采取行动，所述实际提交者例如是医师，其在指示单的情况下可能是被授权合法地提交指示单的唯一用户类型。

在一些实施例中，可以在本发明的EHR系统中限制工作流程中的提交，从而使得仅有经过授权的和/或正确的用户可以进行提交。举例来说，如果用户不属于在本发明的EHR系统中规定的其中一个用户类别，则EHR系统可以提示用户表明正在代表哪一个用户提交表单和/或其他工作流程项目。通过这种方式，例如用户可以输入电话、传真和/或其他远程指示单，其可以使得本发明的EHR系统如同经过授权的用户已经签名的情况那样开始工作流程，并且/或者还并行地(也就是说不妨碍正常工作流程)把文档放置到经过授权的用户的队列中以进行最终签核。在使用人工签名的实施例中，EHR系统可以例如基于实际输入提交的用户的公共/私有密钥对来创建数字签名，同时还合并实际代表其进行提交的用户的标识信息。

一般来说，工作流程的各个步骤可以规定签名和/或其他授权将被收集的顺序。步骤可以规定表明完成步骤可能所需要的签名种类的特定用户和/或用户群组。举例来说，如果步骤规定特定用户，那么如果文档已经收集了该用户的签名，则认为该步骤完成。作为另外的实例，对于规定用户群组的步骤，来自该群组中的任何用户的签名可能就是足够的。因此，在工作流程中进行提交时，本发明的EHR系统可以顺序地检查各个工作流程步骤，以便找到尚未完成的第一个步骤。该步骤的特定用户和/或用户群组还可以决定将把文档放置到其中的特定工作队列。从而当所有步骤都完成时，可以把文档放置在例如可以通过文档的模板定义的已完成队列中。还可以把附注合并到工作流程的各个步骤中，以便例如允许用户随着工作流程的进展作出注释和/或评注。可以通过模板把附注小部件包括在表单中，从而使得可以很容易地从EHR系统的用户界面添加附注。

此外，在本发明中，电子健康记录不仅是供单个机构使用而且还供多个机构使用，并且可能的用户不仅是健康护理专业人员而且还有患者或者例如监护人之类的患者代表人。前面描述的定制能力还可以被利用来提供对于健康记录表单的简化和/或只读访问。此外，可以基于通过患者自身的便携式设备捕获的健康数据自动填写或者自动创建健康记录表单，比如心率、锻炼样式、体重等等。因此患者受益于能够看到所有其健康数据，而不仅仅是可以被拷贝到现有技术的(可能是不可定制的)个人健康记录(PHR)系统的健康数据，并且如果需要患者同意来实施特定动作的话(比如通过因特网把信息传送到其他提供商)，患者还可以成为工作流程许可处理的一部分。从主记录暴露以及/或者从个人设备捕获的个人健康数据都可以通过驻留在至少一台计算机服务器上的系统对象来配置，因此不需要用于每一种定制配置的移动设备/服务器软件的不同版本。

正如前面所提到的那样，还可以把来自多个机构的健康护理专业人员包括在可能用户的列表中。举例来说，有可能在大得多的计划中使用EHR，其中涵盖医院/诊所的系统，或者甚至整个保险人口(这在例如“人口健康”或“当责护理组织”的名称下是已知的)。由于可以在粒度层级进行定制，因此不同诊所中的医生可能具有不同的需求，但是利用在每位医生、每个诊所/机构或者每项政策的层级定制的表单和处理，不同诊所中的医生可以共享相同的电子健康记录系统而都不需要移动设备/服务器软件的专门版本。后端计算机服务器的可缩放性质使得有可能支持数量极大的用户。这种方法的好处在于，患者能够从多家提供商获得护理，而在过去由于不兼容的系统，所述提供商将必须使用传真机或快递来交换健康记录表单的打印版本。利用本发明的方法，这些提供商正在使用考虑到相同环境内的表单布局中的差异的系统。

此外，本发明包括消息传送以作为用于健康护理表单的应用列表当中的一项。表单机制可以允许支持患者以及健康护理专业人员之间的双向或n向消息传送。

在其他行业中，本发明类似地涉及用于在高度可缩放和可定制的软件和硬件架构上管理其对应的相关信息的系统和方法，所述架构例如可操作在包括便携式设备的设备上，并且操作为在升级和缩放期间具有最少停机时间。本发明还涉及高效地访问和定制例如用于以电子形式生成和管理信息的表单的系统和方法。前面所提到的适用于健康护理的所有实施例和方面同样适用于这些其他行业。

例如在顾客关系管理中，取代患者的是顾客；并且取代健康记录表单的是顾客交互的记录。在人力资源中，取代患者的是雇员；并且取代健康记录表单的是例如表现评估、福利选择(benefit election)等等。在会计中，取代患者的是收款人/销售商/供应商；并且取代健康记录表单的是用于可以被记录的不同交易类型的表单。在项目管理中，取代患者的是项目；并且取代健康记录表单的是用于将要完成的任务、工作指派以及来自利益相关者(stakeholder)的反馈的表单。在现场志愿者的领域(例如政治运动)中，取代患者的是潜在的选民；并且取代健康记录表单的是用于将要记录的不同政治议题的表单。

通过后面对于如在附图中示出的本发明的实施例的详细描述，可以最佳地理解本发明以及前述和其他优点。

附图说明

图1和1a示出了本发明的EHR系统的用户界面的仪表盘视图；

图2示出了本发明的EHR系统的用户界面的工作队列视图；

图3示出了本发明的EHR系统的用户界面的视图中的预约和日程安排小部件的集合；

图4和4a示出了本发明的EHR系统的用户界面的视图中的患者信息小部件和TOC的集合；

图5和5a示出了表单中的小部件的特定输入栏位中的自动填写行为；

图6和6a示出了本发明的EHR系统的用户界面中的TOC子层级行为；

图7和7a示出了可以从本发明的EHR系统的用户界面访问的系统对象编辑器；

图8示出了本发明的EHR系统的视图中的具有多种小部件的表单的实例。

具体实施方式

下面阐述的详细描述意图作为关于根据本发明的各个方面提供的当前例示的系统、设备、方法和材料的描述，并且不意图表示可以在其中实践或利用本发明的仅有的形式。但是应当理解的是，通过同样意图被涵盖在本发明的精神和范围内的不同实施例可以实现相同的或等效的功能和组件。

除非另行定义，否则这里所使用的所有技术和科学术语都具有与本发明所属领域的普通技术人员通常所理解的相同含义。虽然在本发明的实践或测试中可以使用与这里所描述的类似或等效的任何系统、方法、设备和材料，但是现在将描述所例示的系统、方法、设备和材料。

这里出现在说明书或附图中的人名意图是完全虚构的，并且不表示任何在世或去世的真人。对于真人的姓名或特性的任何相似性都是完全非刻意的、巧合的、意图明显是虚构的并且/或者仅仅用于说明性目的。这里的内容都不应当构成或者被解释成专业意见或处理。

正如前面所提到的那样，针对医疗专业人员群组将任何EHR带上线的其中一项最大的开销就是在系统内实施机构的现有工作流程和处理所花费的时间。虽然大多数机构共享会面、患者账户、指示单、实验室结果以及协议的相同基本概念，但是将这些概念缝合在一起以便从住院到出院驱动患者护理的确切方式对于不同的医院可以显著不同。常常采取逐步处理来识别和区分机构的不同工作流程和处理之间的相互联系。为了持续这一过程，EHR系统需要适应对于系统配置的小的、渐进的、潜在地频繁的改变，以便“正确实施(getit right)”。与这一需求相矛盾的是，系统的表单、工作流程和其他方面的定义有时被硬编码到EHR本身中，从而需要分配具有高度技术水平的开发人员的时间来实施。一旦机构定制开始涉及底层EHR产品中的改变，频繁渐进改变的想法就可能变得不切实际。对于需要停机时间来实现任何改变或升级的EHR特别是如此。

先前的生成系统还常常被设计成在单个服务器上运行。当所述单个服务器变得超负荷时，解决方案常常是用更大、能力更强的服务器来替换该服务器。通过想尽一切办法使得该单个服务器不发生故障并且具有备用的相同的备份服务器实现了高可用性。最后，通过对于服务器安排停用日程、升级软件以及尽可能快地进行发烟测试(smoke test)来实施升级，以便最小化停机时间。

本发明涉及用于通过电子方式输入信息并且把此类信息存储在多台服务器(其中可以包括云端服务器)上的系统和方法，以便易于访问、管理、共享和组织此类信息并且在缩放和升级期间具有最少停机时间。不同于现有的系统，本发明被设计成在多台服务器上运行，并且在这些服务器上均匀地分配工作负荷。由于每一层应用包括基本上相同地配置的工作节点，因此各个单独的节点可以发生故障并且/或者被取下以进行维护和升级，同时最低程度地影响总体系统的可用性。为了支持数量更大的用户或记录，简单地把更多服务器添加到这些共享集合。

除了用以在升级和缩放期间最小化停机时间的高度可缩放和可定制的软件和硬件架构之外，本发明还强调了便携式设备。

在本发明的一个方面中，本发明的电子健康记录系统(EHR)(其也可以被称作电子医疗记录系统(EMR))可以被部署并且运行在多台服务器上，可以按照非集中方式在所述多台服务器上分配计算和/或存储负荷，从而使得总体系统即使在被缩放、升级和/或通过其他方式修改时仍然可以保持运转和操作。在一些示例性实施例中，本发明的EHR系统可以是软件应用，其通常可以包括被部署并且运行在服务器共享集合中的多台服务器上的多个基本上相同地配置的工作节点。在本发明中，EHR系统可以在服务器共享集合中的各台服务器上分配其工作负荷和/或存储负荷，例如在服务器共享集合中的可用服务器上基本上均匀地分配。由于EHR系统可以包括多个基本上相同地配置的工作节点，因此各个单独的工作节点可以被取下、故障和/或被修改，而不会影响其他工作节点和/或严重影响EHR系统的总体可操作性。这可能是符合期望的，因为EHR系统运行任何健康护理设施的操作，并且在这样的医疗环境中，访问患者信息的需求例如常常是时间敏感的并且对于适当的患者治疗是至关重要的，因此一旦部署之后经历最少停机时间或者没有停机时间可以确保平滑的操作而不会有不必要的中断。通过这种方式，例如服务器共享集合可以在几乎任何给定时间添加附加的服务器和/或取下服务器以用于替换、升级、修复或其他用途以便修改由于服务器修改而经历停机时间的系统，从而最低程度地影响总体系统的可用性。

在一些实施例中，本发明的EHR系统可以被建立在高度自动化的安装平台上，其中系统的各个单独的组件可以被包装到分开的镜像中，所述镜像可以包括特定组件的配置。所述系统可以从镜像创建并且运行组件的实例，同时把应当是永久性的任何所生成的数据与镜像分开存储在永久性存储中。因此，所述系统可以任意地创建和丢弃组件的实例，而既不会丢失存储在镜像中的配置信息，也不会丢失存储在永久性存储中的永久性数据。分开的EHR系统组件于是可以被取下以用于升级、修复和/或其他修改而不会影响其他组件。

在一个实施例中，本发明的EHR系统可以被建立在自动化安装平台上，例如“Docker”。“Docker”通常可以利用Linux Container(Linux容器)，一种建立到Linux中的比传统虚拟化方法更加轻量型的技术。本发明的EHR系统的组件随后可以被包装到“Docker”镜像中。随后可以在“Docker”内启动镜像，以便产生组件的运行实例。在传统的环境中，例如这些实例可以类似于运行在中间件以及在配置方面需要为之投入大量时间和能量的其他组件的堆栈上的已安装的软件。与此相对，该实施例中的EHR组件的实例通常可以易于创建，并且例如可以在希望或者必须对EHR系统进行修复、升级和/或修改时丢弃。“Docker”通常还可以允许把用于每一个组件的配置数据(其可以被存储在“Docker”镜像中)与永久性数据(其可以被存储在永久性存储中)分开。因此可以在任何时间处理每一个组件的实例，这是因为例如在任何时间都可以例如通过基于相同的原始镜像启动新的实例来重新创建所述实例的配置，同时由所述实例管理的永久性数据不被存储在实例本身中而是被存储在例如后端之类的永久性存储中，比如网络附属存储(NAS)。

在一些实施例中，永久性数据可以利用可缩放后端数据库系统来存储，所述数据库系统通常可以利用非关系数据库结构，但是也可以利用分立文档为中心的结构，所述结构还可以利用服务器或存储共享集合上的可缩放性、文档复制和/或负荷分配。作为另外的实例，所述数据库系统还可以利用文档检出系统，其中文档对所有被允许的用户都保持可查看，但是每次只有一个用户可以通过将其检出数据库来修改文档。这对于例如防止可能引入相矛盾的信息的文档的同时修改可能是合乎期望的。这在健康护理领域中是特别合乎期望的，其中相矛盾的信息可能是生死攸关的。

在一个示例性实施例中，所述可缩放后端数据库系统可以采用NoSQL数据库，例如“MongoDB”。一些数据库(比如“MongoDB”)可以特别被设计成按照可缩放的方式管理和存储数量极大的HSD文档(比如JSON文档)。

在本发明的另一个方面中，EHR系统可以被设计成几乎完全从便携式或移动设备进行主要的访问、保持和利用，其中只有特定功能需要直接访问服务器和/或固定式计算机。这不同于一般大多数的EHR系统，后者被设计成用于固定式计算机，其中任何移动访问或功能都是后来的考虑。这总体反映了用以保持健康记录的更加传统或者过时的方式，其更加类似于没有大量利用允许用以保持信息的不同方式的任何技术进步的纸张和档案室系统。在这方面，本发明的EHR系统通常可以在与患者接触时以及/或者在需要输入和/或取回信息的实际事件期间被立即利用，而不是在事后利用。这例如可以帮助提高效率和/或信息保真度，这是因为事后记录保存由于后来无法访问信息来源而可能会固有地引入错误和/或不完整性。

一般来说，在医疗领域中可当责性和可稽核性是重要的概念。由于作出明智的临床决定非常依赖于准确的患者记录，因此本发明的EHR系统可以被设计成例如通过日期、时间、用户和/或任何其他适当的方式来跟踪对于患者记录所发生的所有改变。EHR系统通常还可以把过去文档版本的全部和/或所期望的选择部分存储在数据库中以便于稽核。EHR系统的用户还可以通过使用在EHR系统中可用的检入和检出动作来促进可稽核性，这是因为这些动作通常例如还可以防止多个用户对任何给定文档作出潜在地相矛盾的修改。

在一些实施例中，本发明的EHR系统的所有主要用户可以利用便携式或移动设备来进行其对EHR系统的访问和利用。在一个实施例中，通常可以利用平板设备和/或其他类似的平板计算设备。一般来说，可能希望从受欢迎的、普及的和/或熟悉的计算平台利用本发明的EHR系统，因为这样例如可以允许用户专注于其实际的任务而不是尝试搞清楚不熟悉的和/或过于复杂的软件界面。此外，受欢迎的和/或普及的计算平台通常可以受益于勤勉的技术支持、问题熟悉性、更新以及/或者替换的可用性。本发明的EHR系统通常可以被利用在任何适当的设备上，其中可以包括而不限于智能电话、平板计算机、个人计算机以及/或者任何其他适当的计算设备。一般来说，本发明的EHR系统可以采用图形用户界面(GUI)，并且取决于设备，所述图形用户界面可以通过任何可能是适当的触摸屏界面和/或键盘/鼠标界面来访问。本发明的EHR系统还可以采用其他形式的界面，比如针对存在视觉和/或听觉缺陷的用户的使用所设计的界面，以及/或者替换的界面，其中例如可以包括语音辨识和/或重放、Braille计算机界面、触觉界面以及/或者任何其他适当的界面。

在本发明的另一个方面中，本发明的EHR系统可以利用高度可定制的架构，其通常可以允许对EHR系统进行定制以适应(多个)用户的任何特定需求，而无需对EHR系统的底层功能和/或设计作出任何重大改变。在一些示例性实施例中，本发明的EHR系统架构可以基于使得系统的大多数方面的配置以系统对象的形式暴露于管理员，其中例如包括而不限于向表单添加栏位以创建用于应对实验室指示单的新的工作流程之类的改变都可以在不改变本发明的底层EHR系统的情况下实现。系统对象通常可以利用YAML句法来定义并且例如可以作为HSD文档(比如JavaScript对象标记(JSON)文档)存在，其方式类似于由EHR系统管理的所有其他文档(比如患者记录)。

对于大多数现有的EHR存在一个共同的问题：表单和处理需要定制以满足各个单独的机构(例如医院)的需求。为了解决这一问题，这些EHR当中的大多数采用代码中的硬编码表单和处理定义，这需要附加的时间和技术水平更高的开发人员来创建产品的多个定制版本。这意味着或者需要创建电子健康记录系统软件的多个版本并且存储在至少一台服务器上；或者技术水平更高的开发人员可能要花时间来创建即席(ad hoc)定制版本，从而妨碍机构的操作。此外，当多个机构希望具有针对其电子健康记录系统的不同定制时，如果没有事先创建设备和/或服务器软件的多个版本，则针对技术水平更高的开发人员和时间的这些需求可能会倍增。

通过利用按照标准化句法或格式存储数据的文档(比如JSON文档之类的HSD文档)的灵活性以及比如JSON文档之类的HSD文档在前面提到的任何适当设备上被动态处理的独有方式，本发明解决了前面提到的缺陷并且在需要即席定制表单时消除了对于技术水平更高的开发人员的需求，而无需创建电子健康记录系统软件的多个版本。举例来说，可以把健康记录作为一系列HSD文档(比如JSON文档)存储在至少一台计算机服务器上。

本发明可以利用表单引擎，其例如可以从作为配置文件提供给产品的表单定义进行工作。通过这种方式，只需要较低的技术水平来定制用于特定医院的EHR，并且可以在配置文件中定义定制表单和处理，所述配置文件可以被更新而不需要基础产品的定制版本。

举例来说，所述表单引擎可以如下工作：当要在EHR中向用户显示文档时，表单引擎从数据库取回文档。文档可以在HSD(比如JSON)格式中被编码成一系列关键字-值对。其中一个关键字-值对可以表明文档所基于的表单模板。EHR随后可以从数据库取回表单模板，所述表单模板本身也可以在HSD(比如JSON)格式中被规定为一系列关键字-值对。表单模板规定可以在屏幕上显示哪些栏位(例如针对性别或年龄的栏位)，使用何种“小部件”捕获来自用户的输入(例如选择小部件或者用于查找代码的搜索小部件)，以及如何把用户输入的值存储在文档中(通常在HSD文档(比如JSON文档)中给出针对关键字-值对的“关键字”名称)。在最后的步骤中，EHR的表单引擎可以每次一个小部件地在用户设备(比如iPad)的屏幕上依次创建实际的表单呈现，从而反映出当时的最新定制，并且随后利用来自文档的数据填充所述小部件。

除了更加高效以及节省时间之外，本发明还不同于普通纸质表单或者其他应用中的表单。首先，表单没有被硬编码，因此可以只需要配置改变来更新/定制表单。对于实施改变的人员不需要开发方面的技术，并且不需要生产产品的新版本以及/或者打印和/或提交主表单。此外，由于表单没有被硬编码，因此在iPad上向用户显示出的确切呈现可以由表单引擎在运行时间优化。举例来说，对于硬编码的表单，例如字体以及在屏幕上的定位之类的布局特性是明确地设定的。对于本发明，利用表单引擎，可以根据屏幕上的可用空间使用一项抽象表单布局规范在风景模式、人像模式下以及甚至对于web浏览器中的使用为用户设备(比如iPad)产生表单用户界面。此外，表单输入屏幕总是反映出由系统管理员准备的最新版本。将不对iPad、服务器或者(在许多情况下)甚至已经利用表单的早前版本填写的数据进行升级。这与纸质表单明显不同，其中对于表单模板本身的更新将不会传播回已经被填写的表单的拷贝。此外，更容易在每个表单的基础上控制版本处理。举例来说，有可能使得多个机构共享表单模板并且知晓各个单独的表单模板被更新的日期。给定的医院可以选择转出新的人口统计信息表单，同时延迟转出被用来捕获重要器官(vital)的表单。这在具有硬编码表单的系统中可能是无法实现的并且明显与之不同，在具有硬编码表单的系统中，不同表单模板版本的每一种排列都需要产品本身的不同版本，其组合的激增可能导致EHR销售商无法跟踪以及保持最新的无法管理的版本数量。因此，除了不需要具有高度技术水平的开发人员之外，本发明不仅进一步简化了处理，而且还使得将要跟踪的版本数目最小化，从而最小化发生混淆的几率并且节省时间和工作量。

在本发明的另一个方面中，本发明的EHR系统可以被高效地并且容易地定制以便安装在工作地点处，例如医院、医生办公室和/或其他健康护理机构，而不需要对于EHR系统的大量“后端”定制以实现能够工作的实现方式。一般来说，针对医疗专业人员群组将EHR带上线的其中一项最大的开销就是在系统内实施机构的现有工作流程和处理所花费的时间。虽然大多数机构共享会面、患者账户、指示单、实验室结果、协议和/或其他相同的基本概念，但是将这些概念缝合在一起以便从住院到出院驱动患者护理的确切方式对于不同的机构可以大为不同。在许多情况下，在典型的EHR实施期间使用逐步处理，以便识别和区分机构的不同工作流程和处理之间的相互联系。有效的EHR系统通常被设计成适应对于系统配置的小的、渐进的、潜在地频繁的改变，以便适当地实施EHR系统从而使其将与机构一起工作。系统的表单、工作流程以及其他方面的定义有时常常被硬编码到EHR本身中，由于所需的改变是在“后端”进行的，因此这常常需要分配具有高度技术水平的开发人员的时间来实施。此外一般来说，一旦机构定制开始涉及底层EHR产品中的改变，频繁渐进改变的想法可能就变得不切实际。

在一些示例性实施例中，本发明的EHR系统可以基于使得系统的大多数方面的配置以系统对象的形式暴露于管理员，所述系统对象例如可以利用YAML句法来定义，并且例如作为HSD文档(比如JSON文档)存在于系统中，正如前面所讨论的那样。通过这种方式，可以在无需改动底层EHR系统“后端”的情况下实现对于EHR系统的所暴露出的“前端”的各种改变和/或修改。改变和/或修改可以包括而不限于修改表单、创建新的工作流程、定制报告、创建和/或修改信息输入和/或显示特征件以及/或者任何其他适当的改变或修改。

在一些实施例中，本发明的EHR系统可以采用例如模板之类的基本系统对象，其可以定义如何向用户呈现信息和/或信息的总集，比如在表单之类的视觉表示中呈现，以及/或者如何在EHR系统中结构化和/或记录所输入的信息。

在一些实施例中，模板可以被用来作为表单向用户显示和/或组织一系列单独的信息呈现和/或收集组件，所述表单在视觉上可以类似于在健康护理环境中通常所采用的电子和/或纸质表单。举例来说，各个单独的信息呈现和/或收集组件可以是表单小部件(例如HTML小部件)，其随后可以被用户利用作为设备上的界面以用于输入和/或取回信息。表单小部件本身可以被嵌入到正显示在本发明的EHR系统的用户界面上的表单和/或报告中。信息和信息结构随后可以被存储在本发明的EHR系统的永久性存储中的HSD文档(例如JSON文档)内。

图1和1a示出了本发明的一些实施例中的针对用户的EHR系统的仪表盘视图100的实例。EHR系统用户界面通常可以利用用户登录指示标102表明哪一个用户已登录(如果有的话)，并且通常还可以提供退出登录按钮103。在EHR系统用户界面中显示的信息通常可以安排在各列中，其可以针对用户的优选项以及/或者针对任务和/或情况的具体需求而被定制，比如通过图1中的列A、B和C所示出的那样。

多种小部件可以被利用来例如简化对于不同种类的信息的收集，其中可以包括而不限于文本输入、日期和时间、血压读数、基于标准词汇表的代码、从设备取得的图片和/或照片以及/或者任何其他适当的小部件。小部件还可以被划分成各个节段和表以便于导览。在从用户收集数据时，可以通过小部件记录用于信息的值，其可以进一步被记录在通过模板定义的关键字之下，并且被放置到HSD文档(例如JSON文档)中。通过这种方式，表单的用户界面可以被利用来按照所利用的模板呈现底层HSD文档(例如JSON文档)，以便由用户按照用户友好的管理员定义的方式进行检查和修改。

在一些实施例中，如图1中所示，仪表盘视图100例如可以包含多种小部件，其可以通过控制仪表盘视图100的模板来定义。如图所示，作为另外的实例，小部件可以包括用于示出EHR系统的不同视图的导览栏110，比如在仪表盘视图100中示出的总览视图，通过按钮112示出用户的工作队列视图，通过按钮114示出报告，通过按钮116示出检出文档并且通过按钮118示出预约，用户可访问和/或被指派的患者列表121(比如在患者列表120中)，预约日程安排130，以及/或者其他适当的小部件，作为另外的实例比如有条形码扫描器140和管理员控件150。如图所示，图1a示出了具有替换的安排以及不同的小部件和控件的实例的仪表盘视图100，正如通过导览栏110所示出的那样，其中具有用于特定专业人员(例如医师)、总览视图以及检出文档的按钮111、113、116，即将到来的规程列表130’，具有患者121’的活跃患者列表120’，以及许可队列160。

图3示出了可以从预约日程安排按钮118访问的EHR系统中的预约日程安排300的视图。预约日程安排300可以包括用于显示现有预约的小部件并且/或者允许将预约输入/修改到用户的日历中。

在一些实施例中，宏集合可以被用来规定当在用户界面中操纵信息时出现在本发明的EHR系统中的宏集合。举例来说，当按下宏按钮时，对应于该宏按钮的文本可以被插入到活跃文本栏位中。所述文本可以由定义在宏集合中的脚本动态地生成，所述宏集合在由移动设备运行时从至少一台计算机服务器获得潜在地情境相关数据，比如患者的过敏症或人口统计信息，以便包括在所插入的文本中。宏集合的目标可以被设定在表单上的特定栏位、特定用户和/或特定群组。通过这种方式，需要快速键入常用的文本片断和/或其他信息的用户可以具有被定制成适合其需求的界面，从而可以允许其更加高效地输入信息。文本栏位和/或其他输入项还可以包括标准词汇表集合和/或预设选项,其还可以是可搜索的。

图5示出了显示选项宏集合504的表单500中的文本栏位502的实例，其中在一些文本503的初始输入之后具有可插入项的选项505。图5a示出了表单500中的按钮502a的实例，其在按钮502a被按下时显示选项宏集合504a，而不是需要一些信息输入(比如图5中的文本503)。

一般来说，当EHR系统中的任何给定记录(比如患者记录)随着时间增长时，特定信息项可能会不可避免地被反复收集，比如过敏症和当前用药。举例来说，可能存在临床和/或可稽核性要求，其可能要求多次收集信息，从而可能导致最新的信息潜在地被分散在多个文档中。举例来说，患者可能在一次会面期间声明特定过敏症，但是在下一次会面中则忘记提起。

在一些示例性实施例中，本发明的EHR系统可以提供调和能力，以便允许将收集自多个文档上的相同和/或相关的表单模板的信息一起呈现，并且允许用户选择保留哪些(如果有的话)重复的和/或相矛盾的条目以及丢弃哪些条目。不同于纸质记录，EHR系统中的信息可以由EHR系统结构化和/或可识别，比如通过前面所讨论的关键字处理，从而使得搜索可以允许很容易聚集相同和/或相关的信息，而不是像纸质记录那样，用户必须人工筛检所有适用的表单以取回信息。此外，在纸质记录中，可能无法像EHR系统那样很容易地把信息从分散的纸质文档中拉取到单个文档上，或者当匆忙检视或时间紧迫时，在检视纸质文档的过程中可能会错失信息。

此外，不同于纸质文档，其中用于组织和/或重新组织的仅有手段通常是对页面重新排序、插入封面/分隔页面以及/或者附着带状标志等等，电子记录通常可以被基本上瞬时地重新整理，以便满足当时正在进行的工作的需求。举例来说，实验室技术人员感兴趣的患者记录中的文档子集可能在某种程度上不同于例如办理患者住院的接待员所感兴趣的子集。在纸质表单中，除了按照不同顺序具有相同记录的多份拷贝之外，无法对于一个用户按照不同于另一个用户的方式重新组织页面，这在患者护理中可能会导致问题，本发明则允许一个用户群组(例如实验室技术人员)感兴趣的患者记录中的文档子集可以在某种程度上不同于例如办理患者住院的接待员所感兴趣的子集。

在本发明的一个示例性方面中，本发明的EHR系统可以利用内容表(TOC)系统对象来定义用于患者记录中的文档的动态组织。在一些实施例中，可以通过TOC把文档动态地组织到树结构中，所述树结构可以类似于大多数台式计算机用户所熟悉的标准“文件夹范例”。举例来说，不同于纸质书之类的内容表，本发明的EHR系统能够利用可以不是静态的TOC定义，从而可以例如基于情况需求和/或基于用户的(多个)角色(例如医生、实验室技术人员等等)在每个用户的基础上对其进行适配。因此可以针对特定用户和/或特定情况需求来定制TOC，以便提供用以导览经过文档中的信息的高效和/或直观的组织方案。此外，不同于常见的文件夹分级结构类型的文件系统，EHR系统TOC可以作为导览工具操作，而不是实际控制信息本身被存储在系统内的方式。

在一些实施例中，根部TOC层级可以定义呈现给用户的选择菜单。所述选择菜单还可以包含文档的混合，比如基本患者信息文档、报告(例如“随着时间的血压(BloodPressure Over Time)”)以及/或者到其他TOC层级的链接，其在外观和/或用途方面可以类似于典型桌面应用中的子菜单。所述菜单通常可以被定义成针对本发明的EHR系统的数据库的一系列查询，并且所述查询可以非常具体(例如“给我看患者唯一的基本患者信息文档(show the patient’s one and only Basic Patient Information document)”)、宽泛(例如“给我看该患者的所有放射图像(show all radiology images for thispatient)”)以及/或者具有任何介于中间的具体性。菜单通常还可以被划分成多个节段以易于导览，并且还可以包括可以允许添加新的文档和/或组织层级的按钮和/或其他控制特征件。举例来说，菜单可以包括列出用于特定患者的所有放射图像的节段，并且按钮和/或其他控制特征件可以被配置成出现在该节段中以便为用户给出添加信息(例如新的图像)的选项。

图4和4a示出了EHR系统中的关于患者的报告400的视图，其中例如可以包括显示对于该患者可用的文档分级结构的TOC 410，以及用于显示来自文档420的特定信息的(多个)小部件，作为另外的实例比如有示出患者的图片的照片小部件422以及具有用于患者的QR代码的标签小部件424。还可以利用其他小部件，比如HTML小部件，例如图4a中所示的可以分别被利用来显示生命体征记录和心率/脉搏的小部件426、428。在TOC内还可以访问例如表单和报告之类的不同项目，如图4a中所示的表单链接413和报告链接414。TOC还可以包含命令项，如命令按钮411所示。图8还示出了具有多种小部件的表单800的实例，比如简单文本内容801，用于从所提供的选项列表中进行选择的词汇表搜索小部件802，用于从几个选项按钮当中进行选择的单项选择小部件804，日期输入小部件806，以及二元(例如是/否)小部件808。还可以显示关于正在查看哪位患者的指示标，比如患者指示标104。

在一些实例中，TOC层级可以包含到其他TOC层级的链接，从而用户可以根据具体任务和/或情况选择沿着不同的轴来查看文档。图4a示出了可以打开TOC子层级的嵌套TOC层级指示标412的实例。这种灵活性与纸质系统完全不同，在纸质系统中只能按照一种方式或另一种方式对物理纸张进行排序，并且对其重新排序是非常耗时的。举例来说，通过在本发明的EHR系统中定义例如用于患者会面的TOC子层级并且把到患者的不同会面的链接放置在根部TOC层级中，门诊医师可以通过会面来查看关于患者所收集的信息。与此同时，作为另外的实例还可以定义对应于记账账户的不同TOC子层级，并且把到这些账户的链接放置在根部TOC层级中。这些链接随后例如可以为会计部门的记账专业人员提供到相同的患者记录文档中的不同视图，所述视图按照对于单个纸质文档所不可能的方式更加适合于记账专业人员的需求。

图6示出了从图4中的TOC 410访问的TOC子层级600的实例。TOC子层级600可以基于TOC 410中的发源TOC项进一步显示针对可能是有用的附加文档/表单的链接，正如通过另外的TOC子层级项610和/或所选项620所示出的那样。还可以包括返回按钮612以便将用户返回到更高的TOC层级。图6a还可以显示可以从图6中的TOC子层级600访问的TOC子层级600’以便显示附加的文档/表单，比如通过附加的另外的TOC子层级项610’和/或所选项620’所示出的那样。类似地，还可以包括返回按钮612’以便将用户返回到更高的TOC层级。正如前面所讨论的那样，TOC层级和/或子层级通常可以显示到文档/表单的链接而不会影响文档的底层存储。

在本发明的另一个方面中，由本发明的EHR系统利用的系统对象通常可以由机构按照类似于其他机构知识的方式来对待，并且因此可以被备份、版本处理、根据已定义的改变处理更新以及/或者在其他方面按照与受到管理的其他机构知识类似的方式来对待。

在一些示例性实施例中，系统对象通常可以定义关于用户如何与其机构处的本发明的EHR系统进行交互的几乎每一个方面。因此，系统对象的整个总集可以被备份、版本处理、根据已定义的改变处理更新等等。举例来说，在EHR系统转出的开头，可以基于各种项目的通用定义的组合来产生初始版本，比如内容表、患者表单、针对患者住院的特定于机构的定制以及/或者实验室处理。随后可以按照多种方式引入系统对象总集的下一个版本和/或后续版本，以便最小化对于机构处的EHR系统的持续操作的干扰。可能希望在可以被专用于开发和测试的本发明的EHR系统的拷贝或实例上对这些系统对象实施更新，并且从而与正由机构使用的主要操作实例分开。因此，当设计工作和/或其他更新完成和/或被许可时，新的系统对象总集可以被拷贝到同样可以与主要操作实例分开的本发明的EHR系统的训练实例，以便在不影响机构处的本发明的EHR系统的主要操作实例的持续操作的情况下允许职员和/或其他用户熟悉新的改变。在充分的训练、调试和/或其他定型之后，所述系统对象总集随后可以被推送到生产服务器，从而使其可以在本发明的EHR系统的主要操作实例中成为机构中的主流使用的一部分。

在一些实施例中，本发明的EHR系统可以通过利用同步工具来提供对于系统对象总集的版本管理，所述同步工具可以促进本发明的EHR系统的实例之间的系统对象定义的传递，比如开发和测试实例、训练实例以及主要操作实例之间的传递。在一个实施例中，同步工具可以利用识别系统对象的各个版本的方法，从而可以把同步发生时的歧义降到最低程度。举例来说，同步工具可以识别不同的版本，并且为用户给出例如单独地、全体地或者分批地把系统对象的更新后的版本从一个实例拷贝到另一个实例的选项。

在其他实施例中，本发明的EHR系统可以通过利用标准软件开发源控制实践来提供对于系统对象总集的版本管理，所述实践通常可以把每一个系统对象作为可以从源控制储存库检出和更新的源文件来对待。举例来说，本发明的EHR系统例如对于系统对象的源文件可以利用git储存库。源控制通常例如可以允许更大的人员集合同时工作于更新，并且/或者以更加系统性的方式管理由每个人引入的改变。作为另外的实例，标准软件开发源控制实践还可以采用广为接受的用于备份和保持存储库的最佳实践，比如git，其可以被实施来保护由机构所利用的系统对象。

在一些示例性实施例中，本发明的EHR系统还可以包括能够从设备上的用户界面直接访问的用于修改和/或定制系统对象的特征件。这可能是符合期望的，因为本发明的EHR系统的表单、模板和/或其他系统对象组件可以被即时修改和/或定制，而不是完全依赖于存在延时的开发和/或定制。举例来说，定制因此可以在现场发生以及或者在使用本发明的EHR系统的过程中发生，而不是等待很长的开发/更新周期才能发生。在一些实施例中，可以直接从本发明的EHR系统的用户界面内利用YAML句法的子集来创建和/或编辑系统对象。

图7和7a示出了可以从本发明的EHR系统的用户界面访问的系统对象编辑器700的实例，其作为另外的实例可以包括可供选择以进行编辑的现有系统对象列表710，比如通过显示在编辑小部件720中的所选系统对象711所示出的那样。用户随后可以编辑定义，比如通过系统对象定义721所示出的YAML句法，其中例如示出了用于图7中的基本患者信息模板的定义以及用于图7a中的吸烟/酒精状态模板的定义。还可以提供附加的编辑工具，比如特定的句法按钮730。

在本发明的另一个方面中，本发明的EHR系统可以利用工作流程来促进和/或实施用户集合对于文档的检视和/或许可。

在一些实施例中，可以利用工作队列并且工作队列可以包括已被张贴以供接收方使用、检视和/或许可的文档列表，其方式类似于电子邮件应用的收件箱。一般来说，本发明的EHR系统可以为每一个用户提供工作队列，并且/或者为每一个用户群组提供单个工作队列，正如通过图1a中的许可队列160所示出的那样。EHR系统用户界面还可以包括仪表盘，其中用户可以查看已被张贴到其自身的工作队列以及/或者其所属的任何群组的工作队列的文档列表。

图2示出了可以从工作队列按钮112访问的工作队列视图200。工作队列视图200通常可以显示用于由用户检视和/或许可的项目的列表210，并且可以通过进行选择来查看每一个单独的项目，比如通过所选项目220所示出的那样。如图所示，所选项目220还可以包括附加的控件222，比如用以提交指示单、查看工作流程中的指示单的状态以及/或者显示出附加选项的按钮。

一般来说，把文档张贴到工作队列不会将其从本发明的EHR系统中的任何其他位置处移除(比如从患者记录和/或其他可访问的位置移除)，相反工作队列可以仅包含到已被张贴到其中的文档的链接。作为另外的实例，当文档被从工作队列中移除时，一般可以仅从队列中删除链接，底层文档则不受影响或者不被删除。通过这种方式，本发明的EHR系统可以利用电子系统，比如利用文档检入和检出特征，其可以允许本发明的EHR系统把底层文档保留在中央存储中，同时允许其被链接、可见和/或通过其他方式从本发明的EHR系统的各个部分访问而不会产生矛盾。

在一些实施例中，工作队列和/或工作流程中的文档例如在所述文档可以在工作流程中前进之前可能需要由特定用户检视和/或许可。在一个实施例中，工作流程中的文档可以由适当的用户签名以便继续工作流程。在一个实施例中，如果收集到来自所有必要用户和/或参与方的签名，则可以说文档已完成其工作流程。可以基于工作流程步骤来确定必要用户和/或参与方的列表。图2示出了针对工作流程项目220中的指示单的必要签名224的显示。

一般来说，签名可以是数字签名或人工签名。例如可以通过使用公共/私有密钥对来创建数字签名，所述密钥对可以在每一个用户第一次对表单签名时为他/她生成并且还可以受到口令或其他加密密钥的保护，所述口令或其他加密密钥可以被用作该用户的签名口令。本发明的EHR系统中的数字签名例如可以使用在表单上对于用户可见的HSD(比如JSON)属性值的散列，这对于允许稽核员确认签名是真实的以及/或者签名对应于签名时显示在屏幕上的数据来说可能是符合期望的。

还可以利用人工签名，所述人工签名可以实质上是通常可以采取传统手写签名的形式的人类可读证据，还可以在本发明的EHR系统的用户界面中为其给出视觉表示。人工签名例如可以被存储在文档的属性中，所述属性被利用用于文档的模板的属性向工作流程系统声明。不同于数字签名，人工签名通常不可由EHR系统本身认证，因此EHR系统例如可以要求用户证明人工签名是代表经过授权的提交者正确地捕获的，以作为例如可稽核性的一部分。

工作流程中的文档提交者通常可以是发起特定工作流程处理的用户；但是所述提交者可以不一定是在工作流程中的某一步骤结束时提交文档的同一人。举例来说，许多机构允许电话指示单以及/或者通过传真或者其他基于纸张的手段接收到的指示单，因此提交文档的人可能是在代表文档的实际提交者采取行动，所述实际提交者例如是医师，其在指示单的情况下可能是被授权合法地提交指示单的唯一用户类型。

在一些实施例中，可以在本发明的EHR系统中限制工作流程中的提交，从而使得仅有经过授权的和/或正确的用户可以进行提交。举例来说，如果用户不属于在本发明的EHR系统中规定的其中一个用户类别，则EHR系统可以提示用户表明正在代表哪一个用户提交表单和/或其他工作流程项目。通过这种方式，例如用户可以输入电话、传真和/或其他远程指示单，其可以使得本发明的EHR系统如同经过授权的用户已经签名的情况那样开始工作流程，并且/或者还并行地(也就是说不妨碍正常工作流程)把文档放置到经过授权的用户的队列中以进行最终签核。在使用人工签名的实施例中，EHR系统可以例如基于实际输入提交的用户的公共/私有密钥对来创建数字签名，同时还合并实际代表其进行提交的用户的标识信息。

一般来说，工作流程的各个步骤可以规定签名和/或其他授权将被收集的顺序。步骤可以规定表明完成步骤可能所需要的签名种类的特定用户和/或用户群组。举例来说，如果步骤规定特定用户，那么如果文档已经收集了该用户的签名，则认为该步骤完成。作为另外的实例，对于规定用户群组的步骤，来自该群组中的任何用户的签名可能就是足够的。因此，在工作流程中进行提交时，本发明的EHR系统可以顺序地检查各个工作流程步骤，以便找到尚未完成的第一个步骤。该步骤的特定用户和/或用户群组还可以决定将把文档放置到其中的特定工作队列。从而当所有步骤都完成时，可以把文档放置在例如可以通过文档的模板定义的已完成队列中。

还可以把附注合并到工作流程的各个步骤中，以便例如允许用户随着工作流程的进展作出注释和/或评注。可以通过模板把附注小部件包括在表单中，从而使得可以很容易地从EHR系统的用户界面添加附注。如图2中所示，可以对于工作流程项目220显示附注226。

TOC功能的实例

在一个实例中，当用户第一次打开患者记录时，在EHR系统的左侧呈现TOC层级。每一个TOC层级按照基本上相同的方式动作：TOC层级聚焦在单个文档上(在本例中是患者文档)，并且显示从通过tocLevel文档(queryExpression(查询表达法)属性)定义的数据库查询得到的文档列表。用于该列表的UI被分解成通过配置(config)文档定义的节段。可以有多个配置文档，并且这些配置文档的子集将适用于当前的情况，这是因为其包含对应于活跃TOC层级的tocLevelID属性以及可以与当前用户的群组成员关系相匹配的targetGroupIDs属性下的群组列表。当TOC层级被加载时，UI自动查询所有匹配的配置文档，并且把其中所定义的节段组成到单个列表中。配置文档中的节段(在sections(节段)属性下列出)用来过滤通过前面提到的数据库查询所返回的文档。

查询文档以便出现在TOC层级中的实例

tocLevel文档可以包含queryExpression属性，其字符串值预期是JavaScript表达法，其在被评估时应当产生将被传递到“MongoDB”的JSON对象以便实施数据库查询。在该JavaScript表达法内，一些常用的表达法包括：

1)context.document指的是该TOC层级所聚焦的文档

2)context.document._id指的是该TOC层级所聚焦的文档的ID

通常还如下结构化queryExpression：

queryExpression:|

jsonExpression＝{…}

使得表达法开始于jsonExpression＝的原因是要利用内建到JavaScript中的JSON句法来构造查询对象，其仅对于赋值(＝)运算符右侧的表达法可用。

当用户选择了在TOC层级下的节段中列出的文档时，可以定义发生几项动作的其中之一。如果文档被设置成触发到更深TOC层级的导览，则UI把当前TOC层级“压栈(push)”到导览堆栈上，并且显示新的TOC层级。(“压栈”指的是“返回”按钮出现以允许“弹栈(pop)”回到早前的TOC层级。)该新的TOC层级的聚焦文档将由到TOC层级的导览触发如何被设置来决定。如果文档没有被设置成触发TOC层级导览，则其将在右侧窗格中被打开。

TOC层级还允许用户创建新的文档。与文档选择一样，文档创建也可以被设置成不在右侧窗格上创建用户可编辑的文档本身，而是创建其主要目的是充当用于其他文档的容器并且触发到更深TOC层级的导览的文档。“会面”和“记账账户”是此类容器文档的实例。

定义TOC中的节段的实例

正如前面所提到的那样，通过配置文档的节段属性来定义节段。节段阵列中的单独的节段具有项目属性，其规定在该节段下出现的菜单项目的顺序。假设项目阵列中的每一个项目是文档ID。相应文档的类型决定所显示的(多个)相应菜单项目的行为：

1)模板文档的ID指示UI显示从该模板创建的文档。

2)tocLevel文档的ID指示UI显示到该TOC层级的参考，其在被按下时触发到该TOC层级的导览，但是与当前TOC层级具有相同的聚焦文档。如果子TOC层级是要显示来自当前TOC层级的文档的子集，则这一选项是有用的。

3)报告文档的ID指示UI显示到该报告的参考，其在被按下时在右侧窗格上显示具有与当前TOC层级相同的聚焦文档的报告。

工作流程的实例：

在一个方面中，仅具有健康护理领域内的工作流程步骤的示例性工作流程的实例可以是如下的针对X射线指示单的工作流程：

1、医生填写X射线指示单表单

2、医生对X射线指示单表单签名(在内建到X射线指示单表单布局中的工作流程步骤中定义了对医生签名的需求)

3、X射线指示单被传送到放射科技术人员队列，以通知技术人员准备实施对于患者所需的指示单(在内建到X射线指示单表单布局中的工作流程步骤中定义了针对表单的最终目的地——放射科)。

在另一个方面中，仅具有健康护理领域内的模式化处理的工作流程的实例可以是如下的用于为患者登记实验室访问的工作流程：

1、登记台值班人员询问患者的ID

2、值班人员基于姓氏和出生日期在EHR中找到患者的记录

3、值班人员敲击移动设备上的按钮，以带出动态地生成用以确认患者的实验室预约细节(时间、实验室的具体种类等等)的表单并且生成将要打印的条形码标签腕带的模式化处理。

在另一个方面中，包括健康护理领域内的模式化处理和工作流程步骤两者的工作流程的实例可以是如下的针对处方指示单的工作流程：

1、医生填写用药指示单表单

2、医生对用药指示单表单签名(在内建到用药指示单表单布局中的工作流程步骤中定义了对医生签名的需求)

3、用药指示单被传送到药剂师的队列(在内建到用药指示单表单布局中的工作流程步骤中定义了第二许可人——药房)

4、药剂师使用模式化处理，其特别被设计成在由所述模式化处理动态地生成的表单上在患者的当前用药和过敏症旁边向他/她显示出用药指示单

5、随后，药剂师使用特别被设计成动态地生成显示出即将需要被配药的剂量的表单(其被称作“配药列表”)的模式化处理，并且他/她配制所需的用药剂量

6、护士随后取得该用药剂量并且使用另一模式化处理，该另一模式化处理特别被设计成显示出提示护士确认日期、时间、数量、路线和药品的表单，并且随后在所述剂量已被施药时要求护士的签名。

本领域普通技术人员将认识到，在不背离其精神或实质特征的情况下可以通过其他具体形式具体实现本发明。因此，本发明的描述在所有方面被认为是说明性而非限制性的。本发明的范围由所附权利要求书表明，并且落在其等效表述的含义和范围内的所有改变都意图被涵盖在其中。

Claims (44)

1.一种用于在健康护理机构处实施和定制电子健康记录(EHR)系统的方法，包括：

在至少一台服务器上向机构提供EHR系统的服务器组件，所述EHR系统包括用于配置所述至少一台服务器与托管所述EHR系统的客户端组件的多个用户访问设备进行接口的软件，并且包括用于应对信息的底层数据应对特征件，其能够创建存储在存储设备中的与所述软件分开的文件集合中的分层结构数据(HSD)文档、向所述分层结构数据文档添加信息以及从中取回信息；

创建定义多个系统对象的一系列系统对象HSD文档，所述系统对象定义在所述EHR系统的所述客户端组件上向用户显示信息以及从用户收集信息的方式，并且还定义将被插入到HSD文档中以供保存和存储的所述信息的数据结构；以及

通过修改至少其中一个所述系统对象HSD文档来定制所述系统对象的输入和输出配置以便创建符合所述机构的机构实践的定制系统对象，在所述至少一台服务器上定制所述EHR系统，其中所述定制不改动所述软件或其他HSD文档；

其中所述定制创建所述EHR系统的生产版本以供活跃使用。

2.根据权利要求1所述的方法，其中，所述至少一台服务器包括测试服务器和生产服务器，所述测试服务器在所述定制期间存储并且运行所述EHR系统，并且被适配成把所述EHR系统的所述生产版本推送到所述生产服务器以供活跃使用。

3.根据权利要求1或2所述的方法，还包括：通过利用与所述至少一台服务器接口的所述EHR系统的所述客户端组件，在所述EHR系统的所述定制之后训练所述用户操作所述系统对象。

4.根据权利要求1、2或3所述的方法，其中，所述EHR系统通过创建、访问或修改所述HSD文档存储和取回健康护理信息，并且不修改所述系统对象HSD文档或所述软件。

5.根据权利要求1、2或3所述的方法，还包括：通过定义所述系统对象HSD文档的集合创建定制用户界面，所述系统对象HSD文档由所述多个用户访问设备利用来生成用于显示和收集健康护理信息的图形用户界面。

6.一种无需在至少一台计算机服务器上创建电子健康记录系统(EHR)软件的多个版本的情况下定义电子健康记录系统中的定制表单的方法，包括：

将健康记录作为一系列分层结构数据(HSD)文档存储在所述至少一台计算机服务器上；

把表单布局作为一系列HSD文档存储在所述至少一台计算机服务器上，所述表单布局规定一系列表单层级小部件；

利用来自健康记录HSD文档的信息填写所述表单层级小部件，并且使用触觉、键盘驱动或语音驱动的范例以使得用户能够通过至少一个设备上的显示表面与数据进行交互,其中所述表单布局规定将使用哪一个小部件来操纵将使用健康记录HSD文档的哪些部分，而无需修改驻留在所述至少一个设备和/或服务器上的软件；以及

取回所述健康记录HSD文档和表单布局(HSD)文档并且将其组合以在所述至少一个设备上产生针对用户的呈现，以便读取和/或改变电子健康记录中的数据。

7.根据权利要求6所述的方法，其中，所述HSD文档包括JSON文档。

8.根据权利要求6或7所述的方法，其中，所述表单层级小部件包括节段、列表、附注或者节段分割选项卡。

9.根据权利要求6或7所述的方法，还包括：

把表示标准化治疗概念的代码集合存储在所述至少一台服务器上；以及

利用至少其中一种所述表单布局定义至少一个代码挑选器小部件，每一个所述代码挑选器小部件定义所述代码集合的受限制子集；

其中，所述设备向所述至少一台计算机服务器查询与由所述代码挑选器小部件规定的限制相匹配的所述代码子集，并且将其呈现在视觉表单中以供用户选择。

10.根据权利要求6、7、8或9所述的方法，其中，所述表单布局利用属性映射来规定将使用哪一个小部件来操纵所述健康记录HSD文档的哪些部分。

11.根据权利要求6、7、8、9或10所述的方法，其中，所述设备允许用户利用来自具有相关目的或类似布局的至少一个健康记录文档的值自动填写新的或现有的健康记录文档表单。

12.根据权利要求6、7、8、9或10所述的方法，其中，基于用户的个人移动、可穿戴或健康监测设备上所存在的健康信息自动填写所述健康信息HSD文档。

13.根据权利要求6-12中的任一项所述的方法，其中，所述设备：

显示具有相关文档的菜单以供用户从中选择；

从所述至少一台计算机服务器取回用户选择的文档和用户选择的相关文档；

把来自所有用户选择的文档的所有行合并在一起；

在用户选择的文档中用黄色显示来自用户选择的相关文档的所述所有行，以便允许用户接受或去除任何黄色的行从而把剩下的各行一起合并到单个文档中；以及

把单个文档保存在所述至少一台计算机服务器上。

14.根据权利要求13所述的方法，还包括：把健康记录表单的片段作为HSD文档存储在所述至少一台计算机服务器上，所述健康记录表单的片段包括被例行地输入到健康记录表单中的信息。

15.根据权利要求6-14中的任一项所述的方法，还包括：

规定特别标记的列表小部件的集合以用于收集用于阵列表单中的多个文档的信息，每一个所述特别标记的小部件利用批处理模式输入用于所述多个文档中的每一个文档的所有信息；以及

利用所述特别标记的列表小部件一次创建多个健康记录表单文档；

其中，所述设备创建所述健康记录文档的单独拷贝，每一份所述单独拷贝包括来自原始阵列的单个行的属性。

16.根据权利要求7-13中的任一项所述的方法，其中，所述HSD文档能够利用脚本化句法进行编辑，以用于创建文档片段和所述表单布局而无需改动所述软件。

17.一种无需在至少一台计算机服务器上创建电子健康记录(EHR)系统软件的多个版本的情况下定义EHR系统中的定制工作流程的方法，包括：

把工作流程定义成一系列渐进的许可步骤，所述许可步骤包括需要按照规定顺序从已定义的用户类别集合收集的签名，并且把所述工作流程存储在所述至少一台计算机服务器上的表单布局分层结构数据(HSD)文档内部；

其中，所述EHR系统在用户设备上至少显示从所述表单布局HSD文档生成的表单，所述表单向适当的用户类别显示所述许可步骤，以便按照所述规定顺序从来自每一个所述适当用户类别的至少一个用户收集所述需要的签名。

18.根据权利要求17所述的方法，还包括：基于在所述表单中存在所述用户类别有权为之提供数字签名的所述许可步骤，利用所述表单填充用于所述其中一个所述用户类别的至少一个用户的用户队列。

19.根据权利要求17或18所述的方法，还包括：在获得先前的数字签名之后，基于所述表单中的后续许可步骤把所述表单移动到后续的用户队列。

20.根据权利要求17、18或19所述的方法，还包括：

在至少一台服务器的专用于特定用户或用户类别的存储部分中把指针存储在队列中；

允许对于实际经过授权的用户或者实际经过授权的用户类别充当代理的用户对于特定步骤作为代理对文档签名；以及

把指向文档的不同指针存储在用于代理用户代表其进行签名的经过授权的用户或用户类别的队列中，从而为经过授权的用户提供确认所述代理确实作为其代表采取行动的机会。

21.根据权利要求17、18、19或20所述的方法，其中，所述设备包括台式设备、移动设备、便携式设备或者其组合。

22.一种在电子健康记录系统(EHR)中创建定制的基于参数的数据输入界面的方法，包括：

利用一系列分层结构数据(HSD)文档提供EHR，以便定义存储在存储设备上并且能被至少一台服务器和至少一个用户界面设备访问的多种数据输入情况，所述EHR包括用于应对所述HSD文档以及来自所述至少一个用户界面设备的用户输入的软件；

提供接受来自所述用户界面设备的用户输入并且访问所述HSD文档的辨识引擎；

通过为所述辨识引擎提供能够存在于所述用户输入中的与所期望的数据输入任务相关的激活信息，在所述HSD文档中定义对应于所期望的数据输入任务集合的命令触发的集合，每一项所述命令触发包括被用于在所述EHR中执行命令的将要收集的参数集合；

当在所述用户输入中检测到用于一项所述命令触发的所述激活信息时，基于一项所述命令触发而触发第一命令输入会话，所述第一命令输入会话加载用于一项所述命令触发的所述参数集合；

定义至少一项嵌套查询以用于在所述第一命令输入会话内提示来自所述用户界面设备的用户输入，以便选择用于所加载的所述参数集合的值或选项；

其中，当对于所述参数集合选择了所有所述值或选项时，所述EHR执行或提示所述命令的执行。

23.根据权利要求22所述的方法，其中，所述辨识引擎包括自然语言解释器，其在考虑到自然语言输入中的变型和情境的情况下将所述用户输入与所述激活信息进行比较，以便在所述用户输入与所述激活信息之间生成可能的匹配。

24.根据权利要求22或23所述的方法，其中，所述命令输入会话包括一系列迭代的所述嵌套查询，其引导所述用户输入以便为所述EHR提供用于所述参数集合的完整并且无歧义的值以执行所述命令。

25.根据权利要求22、23或24所述的方法，其中，所述EHR还包括情境辨识以便提供用于所述参数集合的所述值或选项。

26.根据权利要求22、23、24或25所述的方法，其中，所述命令触发包括为所述辨识引擎提供所述第一命令输入会话内的所述参数、所述第一命令输入会话的所述嵌套查询以及第二命令输入会话的触发之间的区分的语义类型。

27.根据权利要求22-26中的任一项所述的方法，其中，所述辨识引擎驻留在从包括服务器、用户界面设备及其组合的组当中选择的设备上。

28.根据权利要求26所述的方法，其中，所述辨识引擎被配置成从所述用户输入接受用于单独命令触发的单独激活信息，以便在所述第一命令输入会话活跃的同时生成所述第二命令输入会话以作为并行的命令输入会话。

29.根据权利要求25所述的方法，其中，在所述第一命令输入会话活跃的同时，所述情境辨识从在所述用户界面设备上查看到的信息辨识出用于所述命令触发的可能的参数值或选项。

30.根据权利要求22-29中的任一项所述的方法，其中，所述HSD文档能够利用脚本化句法进行编辑，以用于通过所述用户界面设备创建所述命令触发而无需改动所述软件。

31.一种无需在至少一台计算机服务器上创建电子健康记录(EHR)系统软件的多个版本的情况下定义电子健康记录系统中的定制工作流程的方法，包括：

将模式化处理作为包括分层结构数据(HSD)文档的模式化处理定义文档存储在所述至少一台计算机服务器上以用于实施操作，所述模式化处理是利用与至少一台计算机服务器动态地交互的脚本代码来定义的，而无需改动所述EHR系统软件；

利用所述模式化处理定义文档，基于从存储在所述至少一台计算机服务器上的其他健康记录文档以及从来自所述设备的用户输入收集的情境和信息在设备上即时动态地生成渐进的表单集合；

其中，随着所述用户与其中一项所述模式化处理进行交互，所述设备以动态序列或组合向用户显示所述渐进表单集合。

32.一种无需在至少一台服务器上创建电子健康记录系统软件的多个版本的情况下定义电子健康记录系统中的定制视图的方法，包括：

把定制视图作为包括分层结构数据(HSD)文档的小部件定义文档存储在所述至少一台计算机服务器上以用于实施操作，所述定制视图是利用与至少一台计算机服务器动态地交互的呈现语言和脚本代码来定义的，而无需改动所述EHR系统软件。

33.根据权利要求32所述的方法，其中，所述呈现语言是HTML。

34.根据权利要求32或33所述的方法，其中，所述脚本代码语言是JavaScript。

35.一种把健康护理数据从电子健康记录(EHR)系统中的早前表单布局版本迁移到新版本的方法，包括：

采集存储在分层结构数据(HSD)文档中的健康护理数据集的集合，所述健康护理数据集关于存储在第一表单布局HSD文档中的第一表单布局版本被结构化；

定义映射HSD文档，其把关于所述第一表单布局版本结构化的所述健康护理数据集的单元映射到第二表单布局版本的单元；以及

通过利用所述映射HSD文档对关于第一表单布局版本结构化的所述健康护理数据集进行变换，生成关于所述第二表单布局版本结构化的变换后的健康护理数据集；

其中，所述变换后的健康护理数据集的所述映射和生成不改动应对所述HSD文档的所述EHR系统的软件。

36.根据权利要求35所述的方法，还包括：生成关于所述变换后的健康护理数据集的所述生成的报告，其包括映射关于所述第一表单布局版本在何处发生。

37.根据权利要求35或36所述的方法，其中，所述EHR系统识别并且锁定与生成所述变换后的健康护理数据集相关的所有HSD文档从而使其无法被编辑，同时允许由所述EHR系统的用户在所述生成期间查看所述HSD文档。

38.一种用于把具有关于原始表单布局集合记录的健康记录的健康护理表单迁移到具有新表单布局的较新表单集合上而无需不必要的停机时间或者对移动设备/服务器软件的新版本的需求的方法，包括：

定义驻留在至少一台计算机服务器上的转换映射HSD文档，其把存在于原始表单布局集合上的数据栏位映射到更新后的/新的表单布局集合上的栏位上；

使用设备识别并且锁定至少一台计算机服务器上的所有相关的健康记录HSD文档，以便遍历在转换映射的变换前侧所参考的每一个数据栏位，并且对于具有该栏位的每一个健康记录文档，识别出与变换后数据栏位相关联的表单布局，使得转换映射该数据栏位，并且把改变保存到至少一台计算机服务器；

释放至少一台计算机服务器上的所有触及的健康记录HSD文档上的锁定；以及

为用户呈现关于所发生的转换映射的报告。

39.根据权利要求38所述的方法，其中，所述转换映射包括直接映射与利用脚本代码定义的更加复杂的映射的组合。

40.根据权利要求38或39所述的方法，其中，通过暂时禁止对正由转换处理的特定文档作出进一步改变，在转换期间能够由系统中的其他用户参考并且看到所述被锁定的文档。

41.根据权利要求38、39或40所述的方法，其中，所述HSD文档能够利用脚本化句法进行编辑，以用于通过所述用户界面设备创建所述命令触发而无需改动所述软件。

42.一种用于在机构处实施和定制电子记录管理(ERM)系统的方法，包括：

在至少一台服务器上向机构提供ERM系统的服务器版本，所述ERM系统包括用于配置所述至少一台服务器与托管所述ERM系统的客户端版本的多个用户访问设备进行接口的软件，并且包括用于应对信息的底层数据应对特征件，其能够创建作为与所述软件分开的文件被存储在存储设备上的分层结构数据(HSD)文档、向所述分层结构数据文档添加信息以及从中取回信息；

创建定义多个系统对象的一系列系统对象HSD文档，所述系统对象定义在所述ERM系统的所述客户端版本上向用户显示机构信息以及从用户收集机构信息的方式，并且还定义将被插入到HSD文档中以供保存和存储的所述机构信息的数据结构；以及

通过修改至少其中一个所述系统对象HSD文档来定制所述系统对象的输入和输出配置以便创建符合所述机构的机构实践的定制系统对象，在所述至少一台服务器上定制所述ERM系统，其中所述定制不改动所述软件或其他HSD文档；

其中所述定制创建所述ERM系统的生产版本以供活跃使用。

43.一种无需在至少一台计算机服务器上创建电子记录管理(ERM)系统软件的多个版本的情况下定义ERM系统中的定制表单的方法，包括：

将机构信息作为一系列机构记录分层结构数据(HSD)文档存储在所述至少一台计算机服务器上；

把表单布局作为一系列表单布局HSD文档存储在至少一台计算机服务器上，所述表单布局规定一系列表单层级小部件；

利用来自机构记录HSD文档的信息填写所述表单层级小部件，并且使用触觉、键盘驱动或语音驱动的范例以使得用户能够通过至少一个设备上的显示表面与数据进行交互，其中所述表单布局规定将使用哪一个小部件来操纵将使用机构记录HSD文档的哪些部分，而无需修改驻留在至少一个设备和/或服务器上的软件；以及

取回所述机构记录HSD文档和表单布局HSD文档并且将其组合以便在所述设备上产生针对用户的呈现，以便读取和/或改变所述机构记录中的数据。

44.根据权利要求42或43所述的方法，其中，所述机构信息是从包括以下各项的组当中选择的：电子健康护理信息、人力资源管理信息、会计信息、项目管理信息、顾客关系信息以及活动管理信息。