用于在卫生保健环境中接收、映射和构造来自全异系统的数据的方法和系统

摘要

本发明名称为“用于在卫生保健环境中接收、映射和构造来自全异系统的数据的方法和系统”。描述了用于在卫生保健环境中接收、映射和构造来自全异系统的数据的方法和系统。一种接收与卫生保健消息结构的不同版本关联的数据输入的示例计算机实现的方法，包括通过单个服务接口来接收按照第一格式的第一数据。卫生保健消息结构的不同版本的至少一个不支持第一数据的一个或多个字段。示例方法还包括通过该单个服务接口来接收按照第二格式的第二数据。卫生保健消息结构的不同版本的至少一个不支持第二数据的一个或多个字段。该单个服务接口实现第一数据和第二数据的接收，以便最小化接口端点的数量。

说明书

相关申请 

本专利要求2011年2月21日提交的美国临时申请No.60/444,940的优先权，通过引用将其完整地并入本文。 

技术领域

背景技术

诸如医院和诊所之类的卫生保健环境通常包括信息系统(例如，电子病历(EMR)系统、实验室信息系统、门诊患者和住院患者系统、医院信息系统(HIS)、放射科信息系统(RIS)、存储系统、图片存档和通信系统(PACS)等)，以管理临床信息(例如，患者病史、成像数据、测试结果、诊断信息、管理信息、财务信息和/或调度安排信息)。不同的卫生保健实体可按照不同方式来格式化和/或构造与其结合所生成、接收、传送和/或处理的卫生保健文档。 

发明内容

附图说明

图1是示例卫生保健环境的框图。 

图2是可用于实现本文所述示例的示例消息处理系统的框图。 

图3描绘了通过多个已知服务接口来路由的消息。 

图4描绘了通过示例通用图式(schema)来路由的消息。 

图5描绘了可与本文所述示例结合使用的示例树结构。 

图6描绘了可用于实现本文所述示例的示例架构。 

图7描绘了可与本文所述示例结合使用的示例树结构。 

图8-16是能够用于实现本文所述示例的示例方法的流程图。 

图17是可用于和/或编程为实现本文所述示例方法和系统的任一个或全部的示例处理器平台的示意图。 

当结合附图进行阅读时，将会更好地理解以上概述以及某些示例的以下详细描述。为了便于说明本文所述的示例，附图中示出某些示例。但是，应当理解，本公开并不局限于附图所示的布置和手段。 

具体实施方式

虽然下面公开包括在硬件上运行的固件和/或软件以及其它组件的示例方法、设备、系统和制造品，但是应当注意，这类方法、设备、系统和/或制造品只是说明性的，而不应当被认为是限制。例如，预期这些固件、硬件和/或软件组件的任一个或全部可排他地通过硬件、排他地通过软件、排他地通过固件或者通过硬件、软件和/或固件的任何组合来实施。相应地，虽然下面描述示例方法、设备、系统和/或制造品，但是提供的示例并不是实现这类方法、设备、系统和/或制造品的唯一方式。 

当所附权利要求的任一项被阅读为涵盖纯软件和/或固件实现时，至少一个示例中的至少一个元件在此明确定义成包括存储软件和/或固件的有形介质，例如存储器、DVD、CD、蓝光等等。 

本文所述的示例使来自卫生保健组织的全异临床系统的数据能够集中到例如临床医生可访问的一个中央位置中。因此，使用所述的示例，访问具体患者数据的临床医生可访问所有患者的相关数据，并且可使用终端用户组件来选择他们想要查看那个数据的哪一部分。本文所述的示例通过在存储于数据库(例如，临床数据资料库)之前把来自全异临床系统(例如，现有应用和产品)的关联数据聚合到标准化和/或结构化格式或模型，来实现这些系统的互通。另外，本文所述的示例 使数据在被接收时能够使用可定制仪表板用户接口来显示。数据可包括电子病历(EMR)、与IT解决方案关联的数据等等。 

在一些示例中，仪表板用户接口可包括告警和/或通知，以便在所接收数据与所定义临床标准有差异时通知临床医生。在从全异临床系统接收到数据时，可通过映射以使数据能够以其它临床系统和/或应用可用的结构化格式或模型被转换和存储，来对数据进行规格化。在从全异临床系统接收到数据时，数据中的词汇可经过标准化(例如，标准健康水平7(HL7)语言)，例如以便使数据能够由其它临床系统和/或应用用于临床决策支持。由于本文所述的示例平台的开放架构，使用所述示例的客户可利用这些平台以便构建其自己的应用，连同其它所提供应用一起来使用该平台，和/或基于客户的特定偏好和/或需要来定制仪表板用户接口。 

本文所述的示例适应单一通用图式中以不同方式格式化的消息，从而使不同装置能够被连接和/或使不同通信能够在信息系统之间路由。更具体来说，本文所述的示例系统和方法实现与消息结构的不同版本关联的字段的聚合，例如健康水平7(HL7)入院出院转院(ADT)、观察结果(ORU)、医疗文档管理(MDM)等、ADT、ORU、MDM等的多种2.x HL7版本以及触发(例如，A01、A02等)。在一些示例中，示例通用图式定义可通过不限制与格式的任一种结合生成的字段，来接收由第一程序所创建的按照第一HL7格式的消息，同时还接收由第二程序所创建的按照第二HL7格式的消息，即使可能不是跨所有版本或HL7结构都支持那些字段。在一些示例中，如果这些字段不是跨所有版本或HL7结构都被支持的，则示例通用图式定义可以不要求不是结合第一HL7格式或第二HL7格式的任一种所生成的字段。 

与已知方式相反，本文所述的示例可为不同HL7消息类型(例如，ADT、ORU、MDM)的每个的所有触发来提供单一通用图式定义，从而减少与现有系统的不同HL7消息类型的每个结合使用的接口端点的数量。因此，使用本文所述的示例，维护这类系统的时间和人力强度 可得到降低和简化。 

在具有不同格式的消息由通用图式接收之后，可使用相同或相似的商业逻辑基于所接收的消息类型来格式化、组织和/或存储消息。例如，基于所接收的消息和/或内容，示例系统可搜索消息中的不同类型的数据，并且建立包括一个或多个对象的一个或多个字段的配置文件。所创建的配置文件可与所接收消息的触发关联，并且对象可在创建时相关。识别的数据则可传送到字段和/或对象，以便以结构化格式来存储。通过搜索入局消息以识别填充字段和/或对象的数据，可有效地滤波入局消息以获得预期数据。在一些示例中，客户可定制如何处理所接收的消息和/或内容。例如，如果接收到具体消息类型，则客户可改变所采取的动作和/或所创建的对象。例如，存储数据结构可在运行时使用运行时所定义的图式来动态定义。例如，商业逻辑可在运行时动态定义。 

在具有不同格式的消息由通用图式接收之后，消息可基于所接收的消息类型以及配置用户接口的设定来映射到不同对象的不同字段，并且存储在数据结构中。在一些示例中，所接收的数据可使用相同或相似的商业逻辑来映射到一个以上对象中的不同字段，而与所接收消息的格式无关。 

使用本文所述示例的客户可使用配置用户接口来配置、暴露于和/或规定处理消息、特定对象起作用等时如何操纵或改变消息、对象状态等行为，以便使系统和方法适合客户的具体偏好。本文所述的示例可设计成使得对于第一客户，消息创建新用于保存数据的新对象。本文所述的示例可设计成使得对于接收同一消息的第二客户，从消息中的数据进行更新的特定对象是可用的。在一些示例中，客户可将系统配置成使得在接收具体消息时创建特定对象。作为补充或替代，客户可将系统配置成使得系统在接收具体消息时忽略创建特定对象。 

例如，基于所配置的存储数据结构，系统可将消息识别为来自医院的健康信息系统并且是A01消息类型。另外，系统可将消息中包含 的数据映射到对象字段，并且在消息被处理时改变关联对象状态(例如，新、活动、不活动)。在一些示例中，至少一些消息可具有对象处于特定状态中的待决条件。对于识别为入院患者(例如，A01)消息类型的患者对象的入局消息，示例系统和方法可具有作为‘新’和/或‘活动’的先决条件状态，因为患者先前在系统中已经登记。在处理入院患者消息时，患者对象状态改变成‘活动’，指示患者是卫生保健机构的活动患者。另外，在处理入院患者消息类型时，可采用入院患者类型中包含的诸如患者ID、实体、相关性、映射等的信息来更新患者对象。对于识别为登记患者(例如，A04)消息类型的入局消息，示例系统和方法可预计患者对象最初不存在，因为患者尚未在系统中登记为患者。在处理登记患者消息类型时，创建患者对象，并且状态设置为“活动”。 

本文所述的示例可使用在运行时所部署的一个或多个脚本来将以不同格式所接收的关联实验室和/或观察数据重构和/或聚合为一种结构化格式(例如，扩展标记语言)。例如，以第一格式所接收的第一数据可经过解析并且以结构化格式(例如，具有父和子关系的树结构)来格式化，并且以第二格式所接收并且与第一数据关联的第二数据可经过解析，以结构化格式来格式化并且与第一数据聚合。解析数据使相关数据能够被识别和/或提取并且保存供将来使用。在一些示例中，观察可包括不同对象中的数据，其中包括实际数据、注释、参考范围等等。使用本文所述的示例，与观察关联的数据可经过解析并且聚合到决策支持和/或收集患者数据中可使用的一个结构化对象中。在一些示例中，取决于所接收的临床数据，告警可被生成以帮助决策支持，并且添加到数据结构的父级和/或子级的报头。在一些示例中，对象中存储的数据可包括经过完全验证的代码和/或结构。 

在一些示例中，可在过程流程中显露挂钩函数(hook)，其动态引入拦截过程流程并且基于所接收数据将数据通过聚合、修改、解析、滤波等处理成结构化格式的脚本。脚本可以是在过程流程中的一个或多个阶段所运行的可定制插件。阶段之一可在数据变换为和/或映射到 内部数据结构之前(例如，预映射脚本)，和/或阶段之一可在数据已经变换为和/或映射到内部数据结构之后(后映射脚本)。可在数据已经变换为内部数据结构之后拦截过程流程的脚本可以是附加器插件脚本。在一些示例中，附加器插件脚本可把来自入局消息的与同一观察关联的所有观察值(例如，各具有相同键控代码和/或观察ID)附加到可作为由系统持续的一个对象来存储的一个字符串中。当观察值在其结尾包括回车时，这种方式会是有利的。使用附加器，可从观察值中滤波回车。然后聚合和/或附加没有回车的观察值供存储。在其它示例中，微生物标本观察数据可在不同格式化段来接收。使用示例脚本，段可被聚合、在适用时通过分出以文本形式所嵌入的数据来解析以提取相关信息、并且按照结构化格式来存储。在一些示例中，可聚合关联段的数据，同时可不聚合不关联段的数据。 

脚本可按照可由用户选择的树结构来显示。所选脚本可基于所接收消息类型来运行，而无需关闭系统。例如，可将脚本提供给客户，和/或脚本可由客户来编写和/或修改。 

在一些示例中，可使用无需关闭系统而可部署的示例可定制数据结构建模工具，基于所接收数据和/或内容，来对数据动态建模。示例工具可聚合从多种系统所接收的患者实验室和/或观察数据，并且将这个数据存储在可定制和/或动态可配置数据结构中。例如，本文所述的示例可捕获、解析与观察关联并且从不同源所接收的数据(例如，不同段)和/或将其聚合为供按照结构化方式来存储的包括可经过完全验证的代码和/或结构的观察单元。在一些示例中，可基于所接收数据来建立帮助决策支持的告警。数据一旦被存储则可被检索和/或用于帮助临床决策支持。由于来自不同源的数据可按照结构化格式来组织，所以本文所述的示例可帮助对特定患者的有意义使用阶段3测量，以便达到国家卫生部的全国卫生统计。 

在一些示例中，存储器中和/或持续数据存储可通过搜索用于创建特定数据结构的查找表、基于动态配置数据结构来创建并且持续。在 一些示例中，存储器中和/或持续数据存储可基于创建对象的事件中指定的数据以及所接收数据的内容来创建。事件数据图式与数据模型之间的映射可以是基于客户偏好和/或需要可定制的。 

在一些示例中，基于所接收的输入消息，示例系统识别与消息关联的服务标识符代码，并且确定是否存在对识别的代码指定的模型。如果存在指定的模型，则示例系统从消息内容中提取模型，并且将模型作为面板存储在存储器中。在一些示例中，基于所接收的输入消息，示例系统识别观察标识符代码，并且确定是否存在对识别的代码指定的模型。如果存在指定的模型，则示例系统从消息内容中提取模型，并且将模型作为观察存储在存储器中。 

图1是其中可实现接收、处理和/或构造卫生保健信息的本文所述示例方法、设备、系统和/或制造品的示例卫生保健环境100的框图。示例卫生保健环境100包括医院102，其中具有在医院102中进行操作和/或与医院102关联的多个实体。医院102包括图片存档和通信系统(PACS)104、实验室信息系统106、心脏科108、放射科信息系统(RIS)110以及肿瘤科112。但是，医院102可包括比所示的更多、更少和/或不同的实体，例如包括卫生保健信息系统(HIS)。 

心脏科108包括心脏相关联卫生保健专业人员、职员以及支持心脏实务和治疗的装置和/或系统。心脏科108可具有生成、接收、传送和/或处理卫生保健文档的特定格式和/或结构。肿瘤科112包括癌症关联卫生保健专业人员、职员以及支持肿瘤实务和治疗的装置和/或系统。肿瘤科112可具有生成、接收、传送和/或处理卫生保健文档的、与结合心脏科108所使用的格式和/或结构不同的特定格式和/或结构。在一些示例中，由心脏科108所生成的入院出院转院(ADT)消息可以是第一格式，而由肿瘤科112所生成的相似ADT消息可按照第二格式。在一些示例中，由心脏科108所生成的观察结果(ORU)消息可按照第一格式，而由肿瘤科112所生成的相似ORU消息可按照第二格式。这类差异还可存在于PACS 104、实验室信息系统106、RIS 110等等之 间。 

PACS 104将诸如数字图像之类的医疗图像(例如，x射线、扫描、三维呈现等)存储在数据库或档案室中。图像由卫生保健专业人员(例如，成像技术人员、内科医生、放射科医生)在对患者的医疗成像之后存储在PACS 104中。作为补充或替代，图像可自动地从医疗成像装置传送到PACS 104供存储。 

RIS 110存储与放射科实务相关联的数据，例如放射报告、消息警告、告警、患者调度安排信息、患者人口统计数据、患者跟踪信息和/或内科医生和患者状态监测。另外，RIC 110实现检查预订输入(例如，预订患者的x射线)以及图像和胶片跟踪(例如，跟踪已经核对胶片的一人或多人的识别码)。 

实验室信息系统106存储临床信息，例如实验室结果、测试调度安排信息、对应专业人员和/或与对应卫生保健机构处的一个或多个实验室的操作相关联的其它信息。虽然以上将信息的示例类型描述为存储在医院102的某些元件中，但是不同类型的卫生保健数据可存储在实体104-112的一个或多个中。此外，实体104-112中存储的信息可以是重叠的和/或组合到实体104-112的一个或多个中。在一些示例中，图1的实体104-112可与电子病历(EMR)系统114进行交互。EMR 114存储与例如医院102及其实体104-112关联的卫生保健记录的电子副本。 

示例卫生保健环境100还包括门诊患者诊所116。虽然在图1的卫生保健环境中描绘了两个卫生保健企业(例如，医院102、门诊患者诊所116)，但是卫生保健环境100可包括任何数量(1、2、3等)的相似或不同卫生保健企业。示例门诊患者诊所116包括与示例医院102的对应实体相似地进行操作的实验室信息系统118和PACS 120。示例门诊患者诊所116的实验室信息系统118和PACS 120可生成、接收、传送和/或处理与医院102不同的卫生保健文档。因此，卫生保健信息的格式化和/或构造中的差别一般可存在于卫生保健企业的实体之间 和/或卫生保健企业之间。 

医院102和门诊患者诊所116经由网络124与企业临床信息系统(ECIS)(例如，Qualibria)122进行通信。网络124例如通过诸如专用网络或因特网、内联网、虚拟专用网络之类的无线或有线广域网(WAN)、有线或无线局域网等等来实现。更一般来说，本文所述的耦合的任一个可经由网络进行。作为补充或替代，医院102和/或门诊患者诊所116可经由直接或专用传输介质126和128与ECIS 122进行通信。 

ECIS 122可支持由卫生保健企业(例如，医院102、门诊患者诊所116等)的系统、装置、应用等等所实现的卫生保健信息处理。ECIS 122能够处理结合不同卫生保健企业实体(例如，实体104-114、118、120)所生成的消息、内容、段等，即使消息、内容、段等包括不同格式、结构、术语、协议、策略等。 

在一些示例中，ECIS 122的处理通过将数据聚合到然后能够由所有卫生保健企业实体用于帮助临床决策支持的标准化和/或结构化格式和/或模型中，来实现卫生保健企业实体的互通。在一些示例中，ECIS122以及更具体来说是ECIS 122的示例消息处理系统130可通过适应所有消息变体(例如，不同的HL7消息)，经由通用图式来接收包括不同消息类型(例如，ADT：01、ADT：02等)的数据。作为补充或替代，消息处理系统130可使用在运行时部署的一个或多个脚本来拦截入局数据的过程流程。脚本可将不同格式化数据重构、解析、修改和/或聚合成ECIS 122和/或卫生保健企业实体更合用的一种结构化格式(例如，树结构)。作为补充或替代，消息处理系统130可使用相同或相似商业逻辑来将入局消息的部分映射到不同对象的不同字段，而与所接收消息的格式无关。作为补充或替代，消息处理系统130可将所接收数据动态建模为可定制和/或动态可配置的数据结构。使用消息处理系统130所构造的数据可存储在数据库或存储132中。在一些示例中，数据库132可以是临床数据资料库(repository)。 

图2是可用于实现图1的示例消息处理系统130和/或数据库132 的示例消息处理系统200的框图。在这个示例中，消息处理系统130包括接口202、标识符204、通用图式206、预映射器208、处理器210、后映射器212和数据存储214。虽然图1示出了实现图1的消息处理系统130和数据库132的示例方式，但是图2所示的元件、过程和/或装置的一个或多个可按照任何其它方式来组合、划分、重新设置、省略、消除和/或实现。此外，接口202、标识符204、通用图式206、预映射器208、处理器210、后映射器212和数据存储214和/或更一般来说是图2的示例消息处理系统可通过硬件、软件、固件和/或硬件、软件和/或固件的任何组合来实现。因此，例如，接口202、标识符204、通用图式206、预映射器208、处理器210、后映射器212和数据存储214的任一个和/或更一般来说是图2的示例消息处理系统能够通过一个或多个电路、可编程处理器、专用集成电路(ASIC)、可编程逻辑装置(PLD)和/或现场可编程逻辑装置(FPLD)等等来实现。当所附权利要求的任一项被阅读为涵盖纯软件和/或固件实现时，接口202、标识符204、通用图式206、预映射器208、处理器210、后映射器212和数据存储214中的至少一个和/或更一般来说是图2的示例消息处理系统200由此明确定义成包括存储软件和/或固件的有形介质，例如存储器、DVD、CD等。此外，图2的示例消息处理系统200可包括作为对图2所示的补充或替代的一个或多个元件、过程和/或装置，和/或可包括所示元件、过程和装置的任一些或全部的一个以上。 

一般来说，示例消息处理系统200使来自卫生保健组织的全异临床系统的数据能够在一个位置按照临床医生、其它应用、程序等可使用的标准格式来集中和/或格式化。在一些示例中，消息处理系统200可将从这些全异临床系统所接收的消息的格式和/或内容解析、滤波、变换、聚合、附加、配置和/或修改成标准化的和/或结构化的格式和/或模型。例如，结构化数据可临床医生使用接口202来显示和/或使用。 

在一些示例中，当消息处理系统200通过例如通用图式206来接收消息时，标识符204可识别消息类型、消息的格式化和/或消息中包 含的内容。标识符204可将消息识别为按照第一格式化、第二格式化等的ADT消息类型。标识符204可将ADT消息中包含的内容识别为包括第一类型的内容、第二类型的内容等。标识符204可将消息识别为按照第一格式化、第二格式化等的ORU消息类型。标识符204可将ORU消息中包含的内容识别为标识第一类型的内容、第二类型的内容等。 

在一些示例中，在使用处理器210对消息进行处理、映射和/或动态建模之前，预映射器208可对入局过程流程应用一个或多个脚本。脚本可将不按照同格式所接收的数据通过滤波、解析、修改、聚合等处理成处理器210更合用的一种结构化格式。例如，消息处理系统200可接收由多个段所组成的按照不同格式并且与同一观察相关的消息。使用预映射器208，可将多个段聚合到在消息处理系统200中持续的单个对象中。单个对象可按照具有父和子关系的树结构来格式化，其中父可包括更一般内容和/或数据，而子可包括更详细内容和/或数据。例如，可接收与微生物检查结果相关联的多个段。微生物检查结果可包括微生物标本和载玻片检查，其中嵌入了定性数据、定量数据和/或注释。使用预映射器208，微生物检查结构的数据可按照树结构来格式化，使得标本数据存储在与标本数据关联的节点处，显微镜载玻片检查数据存储在与显微镜检查数据关联的节点处，以及定性数据、定量数据和/或注释存储在其中相应的节点处。例如，结构化数据可保存在数据存储214处供以后使用。 

消息在预映射器208处格式化之后，和/或如果这种格式化不适用和/或不需要，则可使用处理器210来处理消息。处理器210可对数据动态建模和/或配置，而无需关闭系统。处理器210可通过映射、解析、滤波、修改和/或聚合等处理从多种系统所接收的患者数据(例如，ADT数据、实验室数据、观察数据等)和/或内容，并且将这个数据存储在数据存储214处的可定制和/或动态可配置数据结构中。例如，数据结构可由客户和/或提供商使用接口202来定制。 

在一些示例中，处理器210可通过映射来对消息的数据和/或内容进行规格化。例如，映射可以是基于客户偏好和/或需要、使用接口202可定制的。然后，这个规格化数据可经过转换并且存储在临床决策支持中可使用的结构化格式、模型、面板等等中。例如，基于将消息识别为来自医院的卫生保健信息系统(HIS)并且是A01消息类型的标识符204，处理器210可将来自消息的数据映射和/或提取到与A01消息类型关联的一个或多个对象的字段，其中数据然后可按照结构化格式保存在数据存储214处供以后使用。 

例如，基于将消息识别为来自医院的心脏科并且是观察消息的标识符204，处理器210可将来自消息的数据映射和/或提取到与观察消息关联的面板和/或子面板中的一个或多个观察项，其中数据然后可按照结构化格式保存在数据存储214处供以后使用。但是，例如，如果不存在与观察消息关联的面板，则数据可作为观察项按照结构化格式存储在数据存储214处供以后使用。 

例如，基于将消息识别为来自肿瘤科并且是实验室消息的标识符204，处理器210可从消息中映射和/或提取数据以生成与实验室消息关联的模型，其中数据然后可按照结构化格式保存在数据存储214处供以后使用。在一些示例中，可把来自不同源和/或按照不同格式的映射数据解析和/或聚合到供按照结构化方式存储的、包括可完全验证的代码和/或结构的单个单元中。 

在使用处理器210来处理了消息之后，后映射器212可对过程流程应用一个或多个脚本。脚本可滤波、解析、修改、聚合所接收的数据。例如，在其结尾包括回车的观察值可使用后映射器212来滤波，以便去除回车。然后，例如可附加经滤波的观察值供存储在数据存储214。 

消息处理系统200可包括一个或多个内部存储器和/或其中包括数据存储214的数据存储。数据存储能够包括多种多样的内部和/或外部存储器、磁盘、与消息处理系统进行通信的远程存储装置。在一些示 例中，接口202可配置为图形用户接口(GUI)。 

图3描绘了通过多个已知服务接口、子图式和/或图式304路由到卫生保健信息系统306的多个ADT消息结构302。使用多个服务接口304，因为入局ADT消息(例如，A01、A02等)可按照不同方式来格式化，和/或具有与其关联的更少、更多和/或不同的字段。包括许多服务接口304创建许多接口端点308，其维护是时间和人力密集的。 

图4描绘了通过示例“通用”或统一图式(例如，通用XML图式)404路由到卫生保健信息系统406的多个ADT消息结构402。在一些示例中，通用图式404可用于处理HL7消息(例如，ADT消息、ORU消息、MDM消息等)的所有版本和/或触发。在一些示例中，通用图式404包括适合与HL7的多种版本关联的HL7消息结构和/或字段的任何变体的扩大消息传递框架。例如，通过不限制和/或要求可能不是跨所有HL7版本和/或HL7结构都支持的字段，通用图式404可聚合与2.x HL7ADT消息的多种版本关联的HL7 ADT消息结构和/或字段的每个的所有字段。通过使用通用图式404来代替图3的多个服务接口304，在卫生保健信息系统406处的接口端点408的数量显著减少，这又降低维护这类系统的时间和人力强度。 

图5描绘了具有父和子关系的示例树结构500，其中可映射、路由、配置、格式化、构造和/或存储消息。在这个示例中，树结构500包括父节点502-510和子节点512-524。但是，在其它示例中，树结构500可包括更少、更多和/或不同的节点。节点502与A01消息类型相关联，节点504与A01消息的患者对象类型相关联，以及节点512-516与其状态在通过对象状态来操纵消息时可发生变化的患者对象类型的字段相关联。节点506与冲突对象类型相关联，并且节点518和520与其状态在通过对象状态来操纵消息时可发生变化的冲突对象类型的字段相关联。节点508与A04消息类型相关联，节点510与A04消息的患者对象类型相关联，以及节点522和524与其状态在通过对象状态来操纵消息时可发生变化的患者对象类型的字段相关联。 

在一些示例中，从客户(例如，Mayo )526所接收的消息可识别为A01消息类型，并且可相应地映射到节点502、504和/或506。在一些示例中，对于A01消息类型，患者对象类型可在节点514具有作为‘新’和/或‘活动’的先决条件状态，因为系统预计患者先前在系统中已经登记。在处理A01消息类型时，患者对象状态在节点516可改变成‘活动’，指示患者是卫生保健机构的活动患者。另外，例如，在处理A01消息时，可将与其关联的数据和/或内容例如通过聚合、格式化等处理成树结构500的结构化格式。 

在一些示例中，从客户(例如，Intermountain Healthcare)526所接收的消息可识别为A04消息类型，并且相应地映射到节点508和/或510。在一些示例中，对于A04消息，患者对象类型可以不预计患者对象最初存在，因为患者尚未在系统中登记为卫生保健机构的患者。在处理登记患者类型消息时，在节点522创建患者对象，并且状态在节点524则改变成‘活动’。 

在一些示例中，与树结构500关联的示例系统的数据结构可由客户和/或提供商使用配置用户接口来操纵和/或定制。在一些示例中，与树结构500关联的示例系统可动态定义存储数据结构(例如，树结构500)。在一些示例中，与树结构500关联的示例系统可通过在运行时定义图式和/或格式化来接收任何类型的输入数据。 

在一些示例中，树结构500可与商业逻辑关联，其中商业逻辑映射、格式化和/或构造按照不同格式从不同客户、应用和/或程序所接收的消息。商业逻辑可在运行时动态定义。本文所述示例的这个商业逻辑对于所有客户可以是相同和/或相似的，即使那些客户使用不同的消息格式、应用和/或系统。因此，可使新的和/或现有的顾客或客户同步，使得以映射、格式化、配置等方式处理其入局消息，而无需例如改变系统的基础商业逻辑。 

图6描绘了包括基于客户的脚本的示例架构600。在一些示例中，架构600可包括可将脚本引入入局消息的预映射插件602。脚本可滤 波、附加、解析和/或聚合入局消息的数据和/或内容，以便将数据和/或内容格式化和/或构造成更合用的形式。在一些示例中，多个插件脚本(例如，观察组604、注释打包器606)可在库中是可用的，供客户(例如，管理员)和/或提供商使用。在其它示例中，插件脚本可由客户和/或提供商来编写和/或修改，并且添加到库中。 

在这个示例中，预映射插件602包括观察预订或组604和注释打包器606。例如，观察预订或组604可表示脚本的一个或多个将作用于其上的观察的入局数据结构。例如，注释打包器606可识别、聚合和/或组合来自关联观察(例如，同一观察)的多种数据结构的注释，并且将组合数据附加到存储数据结构的字段中。 

在一些示例中，入局消息608可包括与微生物观察相关联的按照第一数据结构的第一段以及包括附加标本数据的按照第二结构的第二段。使用预映射插件602，入局消息608可在适用时聚合和解析成标准数据结构。在一些示例中，解析可包括分出以文本形式嵌入段中的数据。在一些示例中，通过添加对入局消息类型、格式和/或从其中接收到消息的客户特定的一个或多个脚本，数据可聚合和格式化成标准数据结构。 

架构600可包括示例映射/建模工具610，工具610映射和/或聚合从多种系统所接收的数据，并且按照可定制和/或动态可配置数据结构来将数据存储在保存医疗信息的资料库中。例如，使用OSGI(例如，开放服务网关创始)，映射/建模工具610可在运行时对数据的映射和/或构造进行变更，而无需对代码应用任何补丁(例如，由制造商应客户请求所生成的定制补丁)。在一些示例中，可在应用预映射插件602的脚本之后，使用映射/建模工具610来处理数据。 

在一些示例中，映射/建模工具610实现事件数据图式与数据模型之间的定制映射。在一些示例中，映射/建模工具610可捕获与观察相关联的段中包含的并且从不同源所接收的数据和/或将其聚合为供按照结构化格式来存储的、可解析的观察单元。按照结构化和/或一致格 式的数据可包括完全验证的代码和/或结构。数据一旦被存储则可有利地用于决策支持中。在一些示例中，可建立在所接收数据与标准有差异时警告客户和/或提供商的告警。 

架构600可包括后映射插件612，插件612可在使用映射/建模工具610处理之后将脚本引入数据。例如，脚本可在数据和/或内容的存储之前对其进行滤波、附加、解析和/或聚合。在一些示例中，多个插件脚本(例如，观察组614、附加器616)可在库中是可用的，供客户和/或提供商使用。在一些示例中，插件脚本可由客户和/或提供商来编写和/或修改，并且添加到库中。 

在一些示例中，后映射插件612包括观察预订或组614和附加器616。例如，观察预订或组604可表示脚本的一个或多个将作用于其上的观察的数据结构。附加器616可将与同一观察关联的入局观察消息的观察值附加到在系统中变得持续的对象中。例如，在其结尾包括回车的观察值可使用附加器616来滤波，以便去除回车。然后，例如可附加经滤波的观察值供存储。 

图7描绘了具有父和子关系的示例树结构700，其中可使用示例预映射插件来聚合、滤波、解析、格式化、构造和/或存储消息。在这个示例中，树结构700包括父节点702、704和706以及子节点708-716。但是，在其它示例中，树结构700可包括更少、更多和/或不同的节点。节点702与微面板相关联，并且节点704与包括节点708处的定性数据、节点710处的定量数据和节点712处的注释的标本数据相关。节点706与包括节点714处的定性数据和节点716处的定量数据的显微镜载玻片检查数据相关联。 

在一些示例中，入局消息可包括全部与微生物标本相关联的多个段。一部分段可包括定性数据，一部分段可包括定量数据，以及一部分段可包括注释。通过应用预映射脚本，定性数据可经过滤波、聚合、组合和/或解析并且存储在节点708处，定量数据可经过滤波、聚合、组合和/或解析并且存储在节点710处，以及注释数据可经过滤波、聚 合、组合和/或解析并且存储在节点712处。 

在一些示例中，入局消息可包括全部与显微镜载玻片检查相关联的多个段。一部分段可包括定量数据，并且一部分段可包括定性数据。通过应用预映射脚本，定性数据可经过滤波、聚合、组合和/或解析并且存储在节点714处，以及定量数据可经过滤波、聚合、组合和/或解析并且存储在节点716处。在其它示例中，可接收包括微生物标本数据和显微镜载玻片检查数据的多个段。 

图8-16描绘了表示可使用例如可用于对卫生保健系统中的数据进行映射和/或建模的计算机可读指令来实现的过程的示例流程图。图8-16的示例过程可使用处理器、控制器和/或任何其它适当的处理装置来执行。例如，图8-16的示例过程可使用诸如闪速存储器、只读存储器(ROM)和/或随机存取存储器(RAM)之类的有形计算机可读介质上存储的编码指令(例如，计算机可读指令)来实现。本文所使用的术语“有形计算机可读介质”明确定义为包括任何类型的计算机可读存储装置，但不包括传播信号。作为补充或替代，图8-16的示例过程可使用其中将信息存储任何时长(例如，延长时间段、永久地、短暂、临时缓冲和/或信息饿高速缓存)的诸如闪速存储器、只读存储器(ROM)、随机存取存储器(RAM)、高速缓存或者任何其它存储介质之类的非暂时计算机可读介质上存储的编码指令(例如，计算机可读指令)来实现。本文所使用的术语“非暂时计算机可读介质”明确定义为包括任何类型的计算机可读介质，但不包括传播信号。 

备选地，图8-16的示例过程的部分或全部可使用专用集成电路(ASIC)、可编程逻辑装置(PLD)、现场可编程逻辑装置(FPLD)、分立逻辑、硬件、固件等的任何组合来实现。另外，图8-16的示例过程的部分或全部可人工或者作为上述技术的任何组合、例如固件、软件、分立逻辑和/或硬件的任何组合来实现。此外，虽然图8-16的示例过程参照图8-16的流程图来描述，但是可采用实现图8-16的过程的其它方法。例如，框的执行顺序可以改变，和/或所述框的一部分可以改变、消除、 细分或组合。另外，图8-16的示例过程的任一个或全部可由例如独立处理线程、处理器、装置、分立逻辑、电路等依次和/或并行执行。 

图8描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图800。在框802，方法800确定是否接收到输入消息。入局消息可以是包括观察数据、实验室数据等的ORU消息。如果接收到入局消息，则在框804，方法800识别与该消息关联的服务标识符代码(例如，OBR-4.1)的术语。在框806，方法800确定是否存在对识别的服务标识符代码指定的和/或与其关联的模型(例如，是否存在对OBR-4.1指定的模型)。如果不存在与识别的服务标识符代码关联的模型，则控制转到框808，其中可生成错误消息。 

但是，如果方法800识别到与识别的服务标识符代码关联的模型，则控制转到框810，并且方法800从消息的内容中提取关联模型。在框812，方法800可将所提取模型存储在用于面板的存储器中。 

在框814，方法800可识别与消息关联的观察标识符代码(例如，OBX 3.2)的术语。在框816，方法800确定是否存在对识别的观察标识符代码指定的模型(例如，是否存在对OBX 3.2指定的模型)。如果方法800确定不存在对识别的观察标识符代码指定的模型，则控制转到框818，方法800创建用于观察的一般模型，并且在框820，将模型存储在存储器中用于观察。 

但是，如果方法800确定对识别的观察标识符代码关联指定了模型，则控制转到框822，并且方法800从消息的内容中提取关联模型。在框824，方法800可将所提取模型存储在存储器中用于观察。在框826，方法800确定是否返回到框802。否则，示例方法800结束。 

图9描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图900。在一些示例中，方法900可用于处理具有面板的观察。在框902，方法900确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到904，并且方法900识别与消息关联的OBX-3观察ID。在框906，方法900确定是否存在对识别 的OBX-3观察ID的映射概念代码。如果方法900没有识别映射概念代码，则控制转到框908，并且方法900生成错误消息。 

但是，如果方法900识别了映射概念代码，则控制转到框910，并且方法900得到识别的OBX-3观察ID的映射概念代码。在框912，方法900确定是否已经创建与映射概念代码关联和/或映射概念代码所指向的面板。在一些示例中，面板可以是包括诸如收缩血压测量、舒张血压测量、平均动脉压测量等的项的血压面板。在一些示例中，面板可以是包括诸如排量测量、流体描述评估等的项的尿输出面板。如果方法900确定没有创建面板，则控制转到框914，并且方法900得到面板映射，并且在框916，方法900创建面板。 

在框918，方法900得到观察项映射，并且在框920，方法900使用例如消息中包含的数据来创建观察项。在框922，方法900传送观察项到关联面板中和/或将其放入关联面板中，并且在框924，方法900将面板存储在存储器中。在框926，方法900确定是否返回到框902。否则，示例方法900结束。 

图10描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1000。在一些示例中，方法1000可用于将包括多个段的观察处理成没有面板的一个模型。在框1002，方法1000确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到1004，并且方法1000识别与消息关联的OBX-3观察ID。在框1006，方法1000确定是否存在对识别的OBX-3观察ID的映射概念代码。如果方法1000没有识别映射概念代码，则控制转到框1008，并且方法1000生成错误消息。 

但是，如果方法1000识别了映射概念代码，则控制转到框1010，并且方法1000得到识别的OBX-3观察ID的映射概念代码。在框1012，方法1000确定是否已经创建与映射概念代码关联和/或映射概念代码所指向的观察项。在一些示例中，观察项可以是温度测量、呼吸器血管活性剂或血压。如果方法1000确定没有创建观察项，则控制转到框 1014，方法1000得到观察项映射，并且在框1016，方法1000使用例如消息中包含的数据来创建观察项。 

在框1018，方法1000获得观察项映射，和/或应用插件限定器处理。在框1020，方法1000使用例如消息中包含的数据来创建观察项。在框1022，方法1000将观察项存储在存储器中。在框1024，方法1000确定是否返回到框1002。否则，示例方法1000结束。 

图11描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1100。在一些示例中，方法1100可用于处理没有面板的观察。在框1102，方法1100确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到1104，并且方法1100识别与消息关联的OBX-3观察ID。在框1106，方法1100确定是否存在对识别的OBX-3观察ID的映射概念代码。如果方法1100没有识别映射概念代码，则控制转到框1108，并且方法1100生成错误消息。 

但是，如果方法1100识别了映射概念代码，则控制转到框1110，并且方法1100得到识别的OBX-3观察ID的映射概念代码和/或映射。在框1112，方法1100确定观察基本类型是否为一般过程。在一些示例中，一般过程可与呼吸器模式评估、呼吸设定速率测量、呼吸速率测量、呼气末正压设定测量、呼出校正机器一次呼吸量测量、吸入氧浓度测量、压力支持设定测量、心率测量、中心静脉压测量等等关联。如果方法1100确定观察基本类型不是一般过程，则控制转到框1114，并且方法1100得到与消息关联的特定观察的映射。在框1116，方法1100构建特定观察。 

但是，如果方法1100确定观察基本类型是一般过程，则控制转到框1118，并且方法1100得到一般过程的映射。在框1120，方法1100创建和/或构建与消息关联的一般过程。在一些示例中，过程可与单个瓣膜过程(例如，AVR、MVR、TVR等)、冠状动脉搭桥手术(例如，CABG)、心肌切除、没有循环停止的近端上行主动脉瘤修复等等关联。 在框1122，方法1100采用与OBX-3观察ID关联的映射概念代码来替换键控代码(例如，CEType键控代码)。在框1124，方法1100将过程和/或关联信息存储在存储器中。在框1126，方法1100确定是否返回到框1102。否则，示例方法1100结束。 

图12描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1200。在一些示例中，方法1200可用于处理实验室数据。在框1202，方法1200确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到1204，并且方法1200识别与消息关联的OBR-4服务码(例如，通用OBR-4服务码)。在框1206，方法1200识别与消息关联的OBX-3观察ID。在框1208，方法1200确定是否存在OBX-3观察ID的映射，和/或是否在ECIS术语名称空间中存在映射。如果方法1200没有识别到OBX-3观察ID的映射，则控制转到框1210，并且方法1200生成错误消息。 

但是，如果方法1200识别了OBX-3观察ID的映射，则控制转到框1212，其中得到这种映射。在框1214，方法1200确定消息是否在标准实验室域和/或实验室观察域中。如果消息不在标准实验室域和/或实验室观察域中，则控制转到框1216，并且方法1200生成错误消息。在框1218，方法1200确定哪一个一般实验室模型与消息关联。在一些示例中，方法1200可识别与消息关联的OBX-2值类型，并且使用OBX-2值类型来确定结果的数据类型，例如数据是在标准实验室观察定量模型、标准实验室观察编码模型、标准实验室观察叙述模型等等中。 

但是，如果方法1200确定消息是在标准实验室域和/或实验室观察域中，则控制转到框1220，并且方法1200例如基于与消息关联的键控代码、关系上下文等等来确定特定实验室模型。在框1222，方法1200从消息内容来生成模型，并且在框1224，方法1200将模型存储在存储器中。 

在框1226，方法1200确定是否存在OBR-4服务码的标准实验室 面板域(例如，代码是否存在于标准实验室面板域中)。如果不存在OBR-4服务码的标准实验室面板，则控制转到框1210，并且方法1200生成错误消息。但是，如果存在OBR-4服务码的标准实验室面板，则控制转到框1228，并且方法1200从消息内容来生成实验室面板。在框1230，方法1200将面板存储在存储器中，并且在框1232，方法1200确定是否返回到框1202。否则，示例方法1200结束。 

图13描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1300。在一些示例中，方法1300可用于处理观察数据。在框1302，方法1300确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到1304，并且方法1300识别与消息关联的OBR-4服务码(例如，通用OBR-4服务码)。在框1306，方法1300识别与消息关联的OBX-3观察ID。在框1308，方法1300确定是否存在对OBX-3观察ID的映射，和/或是否在ECIS术语名称空间中存在映射。如果方法1300没有识别OBX-3观察ID的映射，则控制转到框1310，并且方法1300生成错误消息。 

但是，如果方法1300识别OBX-3观察ID的映射，则控制转到框1312，其中得到这种映射。在框1314，方法1300确定消息是否在观察域中。如果消息不在观察域中，则控制转到框1316，并且方法1300生成错误消息。在框1318，方法1300确定哪一个一般观察模型与消息关联。 

但是，如果方法1300确定消息是在观察域中，则控制转到框1320，并且方法1300基于与消息、OBX-3代码关联的键控代码、关系上下文等等来确定特定观察模型(例如，特定观察临床元素类型(CEType))。在框1322，方法1300从消息内容来生成模型，并且在框1324，方法1300将模型存储在存储器中。 

在框1326，方法1300确定是否存在OBR-4服务码的标准观察面板域(例如，代码是否存在于标准观察面板域中)。如果不存在OBR-4服务码的标准观察面板，则控制转到框1310，并且方法1300生成错 误消息。但是，如果存在OBR-4服务码的标准观察面板，则控制转到框1328，并且方法1300从消息内容来生成特定观察面板(例如，特定实验室CEType)。在框1330，方法1300将面板存储在存储器中，并且在框1332，方法1300确定是否返回到框1302。否则，示例方法1300结束。 

图14描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1400。在一些示例中，方法1400可用于处理备选数据。在框1402，方法1400确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到1404，并且方法1400识别与消息关联的OBX-3观察ID。在框1406，方法1400确定是否存在对识别的OBX-3观察ID的实验室基本类型。如果不存在对识别的OBX-3观察ID的实验室基本类型，则控制转到框1408，并且方法1400生成错误消息。 

但是，如果方法1400确定存在对识别的OBR-3观察ID的实验室基本类型，则控制转到框1410，并且方法1400从消息内容来生成标准实验室观察。标准实验室观察可与标准实验室观察定量、标准实验室观察编码、标准实验室观察原始、标准实验室观察读取、标准实验室观察叙述等等关联。 

在框1412，方法1400识别OBX-2值类型，并且在框1414，方法1400确定OBX-2值类型是否与基本实验室数据类型兼容。如果OBX-2值类型与基本实验室数据类型不兼容，则控制转到框1416，并且方法1400识别与消息关联的OBX-5观察值。在框1418，方法1400发起备选处理，并且可生成告警消息。在框1420，方法1400将实验室观察和OBX-5(对于PQ)单元作为备选数据来存储。 

但是，如果方法1400确定OBX-2值类型与基本实验室数据类型兼容，则控制转到框1422，并且继续进行正常处理。在框1424，方法1400将实验室观察存储在存储器中，并且在框1426，方法1400确定是否返回到框1402。否则，示例方法1400结束。 

图15描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1500。在一些示例中，方法1500可用于处理序数定量(OrdQn)数据。在框1502，方法1500确定是否接收到ORU-R01消息。如果接收到这种消息，则控制转到1504，并且方法1500识别与消息关联的OBX-3观察ID。在框1506，方法1500确定与OBX-3观察ID关联的特定实验室基本类型是否为定量的。如果特定实验室基本类型不是定量的，则控制转到框1508，并且方法1500继续进行正常处理。在框1510，方法1500将与消息关联的单元和/或其它数据存储在存储器中。 

但是，如特定实验室基本类型是定量的，则控制转到框1512，并且方法1500从消息内容来生成标准实验室观察定量。在框1514，方法1500将标准实验室观察定量存储在存储器中。在框1516，方法1500识别与消息关联的OBX-2值类型，并且在框1518，方法1500确定OBX-2值类型是否与PQ数据类型兼容。如果OBX-2值类型与PQ数据类型兼容，则控制转到框1508。 

如果OBX-2值类型与PQ数据类型不兼容，则控制转到框1520，并且方法1500确定OBX-2与编码异常(CE)、编码有异常(CWE)或者编码序数(CO)是否有关联。如果OBX-2值类型没有与CE、CWE或CO关联，则控制转到框1522，并且方法1500执行备选数据处理。在框1524，方法1500存储附加在备选数据中的单元。 

如果OBX-2值类型与CE、CWE或CO关联，则控制转到框1526，且方法1500识别与消息关联的OBX-5观察值，以及在框1528，方法1500解析与消息关联的脱字符号界定数据。在框1530，方法1500得到与消息关联的第一字段和/或字段1的映射概念代码。如果对于字段1不存在映射概念代码，则控制转到框1532，方法1500生成错误消息，以及在框1534，方法1500将OBX-5和单元作为备选数据存储在存储器中。 

如果方法1500得到字段1的映射概念代码，则控制转到框1536， 并且方法1500确定映射概念代码是否在序数解释值集合中。如果不是的话，则控制转到框1532，并且可生成错误消息。如果是的话，则控制转到框1538，并且方法1500把来自序数解释限定器的代码和原始文本以及单元作为备选数据来存储。在框1540，方法1500确定是否返回到框1502。否则，示例方法1500结束。 

图16描绘了使入局消息的数据能够被映射、动态建模和/或按照结构化格式来存储的示例流程图1600。框1602表示实验室接口队列，并且框1604表示实验室HL7v2消息。在框1606，方法1600可识别OBR-4通用服务码，并且在框1608，方法1600可确定OBR-4代码是否具有到ECIS名称空间的映射。如果映射不存在，则控制转到框1610，并且方法1600可捕捉例外，并且发送告警。对如本文所述所生成的这个和/或任何其它告警和/或错误消息进行响应，这类消息可经由接口来传送给用户，从而实现用户人工审查。然后，控制可转到框1612，其中在ECIS名称空间中创建概念，并且在代码(例如，OBR-4代码)与ECIS概念之间创建映射。在框1614，方法1600可向队列重新提交消息。备选地，消息可在1616被映射、存储在适当面板中。这个备选可应用于连接到框1614的框的任一个。在一些示例中，在框1616的数据存储可以是临床数据1616可以是临床数据资料库(CDR)。 

如果OBR-4代码具有ECIS名称空间中的映射，则控制转到框1618，并且方法1600确定OBR-4代码是否在术语的“OrderableLabTest”域中。如果OBR-4不在这种域中，则控制转到框1620，并且方法1600可捕捉例外，并且发送告警。在框1622，可将代码添加到术语中的适当域。 

如果OBR-4是在术语的“OderableLabTest”域中，则控制转到框1624，并且方法1600使用CEType标准实验室面板，以及然后在框1616可存储面板。 

在框1626，方法1600可识别OBX-3观察ID，并且在框1628，方法1600可确定OBX-3代码是否具有到ECIS名称空间中的概念的映 射。如果映射不存在，则控制转到框1630，并且方法1600可捕捉例外，并且发送告警。然后，控制可转到框1612，其中在ECIS名称空间中创建概念，并且在代码(例如，OBX-3代码)与ECIS概念之间创建映射。 

如果映射存在，则控制转到框1632，并且方法1600确定OBX-3代码是否在术语的“StandardLabObs”域中。如果OBX-3不在这种域中，则控制转到框1634，并且方法1600可捕捉例外，并且发送告警。在框1636，方法1600可将代码添加到适当实验室Obs域，并且可创建特定模型。 

如果OBX-3代码是在术语的“StandardLabObs”域中，则控制转到框1638，并且方法1600确定是否存在使用识别的OBX-3代码作为键(key)的特定实验室模型。如果没有特定实验室模型正使用识别的OBX-3代码作为键，则控制转到框1640，并且方法1600确定OBX-3代码是否为没有被认为是实验室观察的概念。在框1642，方法1600可捕捉例外，并且发送告警。在框1644，方法1600可创建特定实验室模型。 

如果方法1600确定OBX-3代码不是没有被认为是实验室观察的概念代码，则控制转到框1646，并且方法1600确定应当使用哪一个一般StandardLabObs CEType。在框1648，方法1600查找识别的CEType的特定映射配置文件。 

如果方法1600确定OBX-3代码是没有被认为是实验室观察的概念代码，则控制转到框1650和1652。在框1650，方法1600确定OBX-3代码是否为LabComment域中的概念，并且将OBX-3代码和/或任何关联数据作为注释限定器来存储。在框1652，方法1600确定OBX-3代码是否与性别、年龄或种族关联，并且根据术语中的键控代码和关系来查找CEType。在框1654，方法1600查找CEType的特定映射配置文件。 

如果方法1600确定存在使用识别的OBX-3代码作为键的特定实 验室模型，则控制转到框1656，其中方法1600查找术语中的CEType键控代码和关系。在框1658，方法1600根据CEType对象中的“基本”属性来查找CEType，并且在框1660，方法1600查找CEType的特定映射配置文件。 

图17是可用于实现本文所述的系统和方法的示例处理器系统1700的框图。如图17所示，处理器系统1700包括耦合到互连总线1704的处理器1702。处理器1702可以是任何适当的处理器、处理单元或者微处理器。虽然图17未示出，但是处理器系统1700可以是多处理器系统，并且因而可包括与处理器1702相同或相似并且在通信上耦合到互连总线1704的一个或多个附加处理器。 

图17的处理器1702耦合到芯片组1706，芯片组1706包括存储控制器1708和输入/输出(I/O)控制器1710。众所周知，芯片组通常提供I/O和存储器管理功能以及由耦合到芯片组1706的一个或多个处理器可访问或使用的多个通用和/或专用寄存器、计时器等。存储控制器1708执行使处理器1702(或者当存在多个处理器时的多个处理器)能够访问系统存储器1712和大容量存储存储器1714的功能。 

系统存储器1712可包括任何预期类型的易失性和/或非易失性存储器，例如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、闪速存储器、只读存储器(ROM)等等。大容量存储存储器1714可包括任何预期类型的大容量存储装置，包括硬盘驱动器、光驱动器、磁带存储装置等等。 

I/O控制器1710执行使处理器1702能够经由I/O总线1722与外围输入/输出(I/O)装置1716和1718以及网络接口1720进行通信的功能。I/O装置1716和1718可以是任何预期类型的I/O装置，例如键盘、视频显示器或监视器、鼠标等等。网络接口1720可以是例如以太网装置、异步传输模式(ATM)装置、802.11装置、DSL调制解调器、电缆调制解调器、蜂窝调制解调器等，它使处理器系统1700能够与另一个处理器系统进行通信。 

虽然存储控制器1708和I/O控制器1710在图17中示为芯片组1706中的独立块，但是，这些块所执行的功能可集成在单个半导体电路中，或者可使用两个或两个以上独立的集成电路来实现。 

某些实施例考虑实现实现上述功能性的方法、系统和任何机器可读介质上的计算机程序产品。例如，某些实施例可使用现有计算机处理器、或者通过为这个或另一个目的结合的专用计算机处理器、或者通过硬连线和/或固件系统来实现。 

某些实施例包括用于携带或者其上存储计算机可执行指令或数据结构的计算机可读介质。这种计算机可读介质可以是可由通用或专用计算机或者具有处理器的其它机器可访问的任何可用介质。作为举例，这种计算机可读介质可包括RAM、ROM、PROM、EPROM、EEPROM、闪存、CD-ROM或其它光盘存储、磁盘存储或者其它磁存储、或者可用来携带或存储采取计算机可执行指令或数据结构形式的预期程序代码并可由通用或专用计算机或者具有处理器的其它机器来访问的任何其它介质。以上装置的组合也包含在计算机可读介质的范围之内。计算机可执行指令包括例如使通用计算机、专用计算机或者专用处理机执行某个功能或某组功能的指令和数据。 

一般来说，计算机可执行指令包括执行具体任务或者实现具体抽象数据类型的例程、程序、对象、组件、数据结构等。计算机可执行指令、关联数据结构和程序模块表示用于执行本文公开的某些方法的步骤和系统的程序代码的示例。这类可执行指令或关联数据结构的具体序列表示用于实现在这类步骤中所述的功能的相应动作的示例。 

本发明的实施例可在采用到具有处理器的一个或多个远程计算机的逻辑连接的组网环境中实施。逻辑连接可包括在此作为举例而不是限制来呈现的局域网(LAN)和广域网(WAN)。这类组网环境是办公范围和企业范围的计算机网络、内联网和因特网中常见的，并且可采用大量不同的通信协议。本领域的技术人员将会意识到，这类网络计算环境通常包含许多类型的计算机系统配置，其中包括个人计算机、手 持装置、多处理器系统、基于微处理器的或者可编程的消费电子产品、网络PC、小型计算机、大型计算机等等。本发明的实施例还可在分布式计算环境中实施，在这些环境中，任务由通过通信网络链接(通过硬连线链路、无线链路或者通过硬连线或无线链路的组合)的本地和远程处理装置来执行。在分布式计算环境中，程序模块可位于本地和远程存储器存储装置中。 

虽然本文已经描述了某些方法、设备和制造品，但是本专利的覆盖范围并不局限于此。相反，本专利涵盖在字面上或者在等效体原则下完全落入所附权利要求的范围内的所有方法、设备和制造品。