下载掌阅APP，畅读海量书库
立即打开
电子病历系统的应用和电子病历数据的有效利用能够提高医疗服务质量、提升医疗服务工作效率、降低医疗费用、减少医疗差错，并且能够为医院的管理、科研、教学和公共卫生提供大量的信息资源。电子病历数据的有效利用与信息技术在医疗领域的应用密切相关，并且不断发生变化。早期电子病历数据的有效利用主要是一家医院内部电子病历数据的有效利用，包括医疗服务流程的优化和临床决策支持技术的应用。伴随着医疗信息技术的不断发展，目前电子病历数据的有效利用不再局限于一家医院或者几家医疗机构的数据利用，尤其是大数据时代的到来和人工智能技术的不断应用，使得电子病历数据有效利用打破了原有的医院或者区域限制，数据利用需要基于越来越多来自分散的异构电子病历数据的有效融合。
电子病历涉及患者在医院内所有相关的电子化记录，包括人口统计学信息、费用信息、诊断信息、药物信息、免疫信息、体检信息、实验室检验信息、就诊信息、实验室检验信息、影像检查信息、用血信息、护理信息、手术信息、麻醉信息、医嘱信息、病程录、病案首页、查房记录等，这些信息既相对独立又相互关联，共同组成了患者所有的医疗健康相关的信息。一方面这些信息的背后是大量的领域知识，另一方面这些复杂的信息具有极大的利用价值。电子病历涉及信息内容种类繁多、关联复杂，这对标准化和医疗信息建模是一个挑战。
此外，电子病历数据的标准化和信息建模也需要面对动态性问题。由于目前医院内部并不是所有数据都已经电子化，仍存在一些纸质的特殊检查、检验数据或者一些还没有实现电子化的专科相关数据，伴随着医院信息化的发展，这些数据应该都会电子化并成为电子病历覆盖的内容。同时，医学领域在不断地发展和进化，不断有新的技术或者疗法产生，进而也会导致新的电子病历数据产生，使得电子病历数据具有动态性特征。
本节将展示一个基于openEHR多层单源建模方法的医疗信息协同模式下的电子病历标准信息模型是如何构建起来的。
在需求分析阶段，首先组建一个跨区域多领域专家组成的电子病历标准信息模型团队。考虑到电子病历数据从产生到利用的过程以及原型构建所需的领域知识，确定电子病历标准建模团队的成员，包括：10个临床专家、4个电子病历系统实施人员、2个原型知识专家、5个医疗信息学专家和2个术语专家。
然后确定电子病历建模的需求来源。目前，电子病历已经被国内很多的医院所采用，尤其是三级甲等医院。电子病历系统用来收集、存储、管理和使用电子病历数据。目前我国的电子病历数据主要包括患者人口统计学信息、病程录、诊断、药物、体征、既往史、免疫、实验室检验、影像检查、就诊、离院、转科/转院等信息。现有的电子病历系统中的数据需求可以作为电子病历原型构建的参考，因为它们是在临床实际中产生和运转的电子病历需求。因此，在电子病历标准信息模型构建的需求分析阶段，选用2个具有代表性的电子病历系统的数据库文档作为数据需求收集的参考资料。其中一个是已经被超过1000家医院所采用的电子病历，可以代表我国近年来电子病历的需求；另一个则是在国家项目“高端电子病历研究与实现”中的研究成果之一，并在示范医院进行使用的电子病历系统，可以在一定程度上代表最近的电子病历水平。这两个电子病历系统都采用关系型数据库进行数据的存储和管理。此外，结合新增的电子病历体检需求构建原型以满足体检数据需求，其中的体检信息需求来源是一家医院的体检关系型数据库表结构。
为了收集数据需求，电子病历系统实施人员将两个关系型数据库的设计结构进行分析和处理。首先，依据两个数据库中的表结构进行分类作为概念发现的结果。然后，按照分类结果将数据库中所有的字段都收集起来作为起始的电子病历所需的数据元素。
通过分析现有的2个电子病历关系型数据库结构收集其中的数据元素，并将这些数据元素分成13种类别，如表4-2所示。
表4-2 概念发现结果
电子病历关系数据库中的表结构设计往往是用来支持特定的业务逻辑或者功能，而不是用来表达领域概念。一张关系型数据库表可能包含了一个领域概念的一部分属性，也可能包含多个领域概念，但是其很少直接对应一个领域概念。由于需求分类被定义作为一组具有相似功能的领域概念，如医嘱信息、入出转信息，因此几张表示类似功能的关系表可以被归类到一个需求分类。如此一来，非常方便利用种类来归类关系型数据库表和其所包含的数据元素，然后再将这些数据组织成为领域概念。
基于领域本体中定义的领域概念，结合上述步骤中获得的电子病历概念发现结果和对应的数据元素集进行电子病历信息概念设计。这一过程由临床专家、原型知识专家和医学信息学专家完成，可以采用3种模式来进行概念组织，分别是人口统计学模式、临床模式和非临床模式。每一种电子病历需求类型对应着三种模式之一。
对于患者人口统计学模式，可以基于电子病历系统的开发和实施经验来组织领域概念，概念包括患者信息、地址信息和组织信息。对于非临床模式，可以参考患者在医院中的实际就诊流程进行概念组织，概念包括就诊、离院和转院/科。对于临床模式，可以基于代表临床信息流动的问题解决逻辑来组织领域概念。问题解决逻辑将临床信息分为四类，包括指令（Instruction）、行为（Action）、评估（Evaluation）和观察（Observation）。指令类型用来表示检查或者干预信息，其在时间上用于表示未来将要发生的活动；行为类型表示关于指令已经发生了什么；观察类型用来表示或者记录客观观测的数据，如实验室检验结果、心电图报告或者影像检查报告；评估类型是关于意见和总结，其往往是由医疗服务人员基于领域知识做出的评价或者评估，如诊断信息、风险因素评估和社会史。临床模式中的对应的电子病历需求类型基于问题解决逻辑进行更为细粒度的概念划分。例如，电子病历需求中的影像检查类型被分为影像检查申请、影像检查行为、影像检查结果和影像序列。在这一步骤中，临床专家会被邀请对于概念的组织进行审核。为了方便临床专家对概念的可行性和合理性进行审阅，将思维导图这种领域专家更容易接受和理解的概念表达方式作为临床概念展现的媒介。领域专家们共组织了37个领域概念，如图4-9所示。
图4-9 领域概念设计结果
确定领域概念之后，由电子病历系统实施人员、医学信息学专家和术语专家共同对领域概念中所包含的数据原型进行正规化。为了获得完整且没有语义重叠的电子病历数据元素，三个我国电子病历相关标准作为参考被用来进行数据元素的正规化，分别是《电子病历基本数据集》《卫生信息数据元目录》和《卫生信息数据元值域代码》。《卫生信息数据元目录》定义了标准数据元及其对应属性，包括数据元名称、数据元定义、数据类型、表示格式和允许值；《卫生信息数据元值域代码》定义了编码的标准数据元素的取值范围及其包含的属性，包括编码值、含义和备注；《电子病历基本数据集》定义了电子病历中涉及的17个子集及其对应包含的数据元素，其可以促进不同系统之间特定的医疗信息互操作。《电子病历基本数据集》中的部分数据元素是引用《卫生信息数据元目录》中的数据元定义，而其中编码的数据元素的值域则是引用自《卫生信息数据元值域代码》。
由于以上3个标准是通过收集和分析国内一些代表性医院内的临床业务表格进行定义，以求促进数据互操作，所以它们的定义内容仅仅能够覆盖大部分的医疗数据互操作所涉及的内容，而不能够覆盖电子病历的全部数据内容。因此，相关标准和实际的电子病历需求之间存在着差异。虽然在标准和实际的电子病历数据需求之间存在差距，但是这些标准可以用来帮助数据需求中涉及的数据元素的正规化。
首先，将标准中的未出现在已经收集的信息需求的数据元素添加到数据需求收集阶段定义的数据元素集中。然后，利用标准来正规化数据元素集，具体的正规化规则如下。
（1）如果电子病历数据元素和标准中的数据元素具有同样的语义，那么采用标准中的数据元素定义来替代原有的数据元素定义，包括命名、值域、编码值和备注。
（2）如果多个电子病历数据元素对应一个标准数据元素，意味着电子病历中的数据元素粒度小于标准中对应数据元素的粒度，那么细粒度的多个电子病历数据元素和标准中的对应数据元素都将保留，如Apgar评分在标准中对应一个数据元素，而在实际的电子病历需求中对应着6个数据元素，最后Apgar评分包含7个数据元素。
（3）如果一个电子病历数据元素对应着标准中多个数据元素，并且电子病历数据元素的语义能够被这些标准数据元素所覆盖，那么电子病历数据元素将被标准数据元素替代，如在电子病历需求中地址对应着一个数据元素，而在标准中则对应着6个数据元素，包括省、市、县、街道、门牌号。
（4）如果一个电子病历数据元素对应多个标准中的数据元素，但是这个电子病历数据元素的语义并不能够被标准中的数据元素全部覆盖，那么电子病历数据元素和标准数据元素同时保留。
（5）如果多个电子病历数据元素对应着多个标准中的数据元素，且存在语义重叠现象，那么在保留标准数据元素的前提下需要进行一次讨论。
通过基于我国的3个电子病历相关标准进行数据元素的正规化，将91个标准中的数据元素补充到上述的13个类别中，最终得到一个完整的电子病历数据集，如下表4-3所示。经过数据元素正规化操作后，电子病历数据集共包含932个数据元素。
表4-3 数据元素正规化结果
为了尽可能重用现有的原型，检索领域概念所对应原型是一个必要的步骤。原型的重用对于利用openEHR方法促进语义互操作至关重要。除此之外，通过原型的检索可以促进领域概念定义的优化。
检索到的领域概念对应的或者原型与领域概念的关系可以分为三种类型。第一种，领域概念与检索到的原型语义相同，如概念“诊断”和现有原型“openEHR-EHR-EVALUATION.problem_diagnosis.v1”。第二种，领域概念的语义是对应检索到原型语义的一种特例，如领域概念“手术申请”是现有原型“openEHR-EHRINSTRUCTION.request.v0”。第三种，领域概念的语义比检索到原型的语义更为通用，换言之，现有原型是领域概念的一种特例，如概念“体征”和现有原型“openEHR-EHR-OBSERVATION.body_temperature.v2”的关系。对于第三种情况，领域概念可以考虑精细化，如概念“体征”可以划分成为粒度更细、语义更为清晰的概念，包括身高、体重、体温、体表面积、BMI指数、心率。
基于上述三种关系，HMC平台作为原型的检索平台和源头。由于HMC中的大部分原型都是重用国际上现有的原型，导致这些原型的内容都是非中文版本的。虽然HMC上已经提供本地化翻译模块，并且已经翻译了一些原型，但是还不足以支持全平台的基于中文的原型检索。因此，在检索过程中免不了需要将一些领域概念翻译成对应的英文内容再进行检索。考虑到HMC平台上目前的检索功能主要是基于字符串匹配进行执行的，所以领域概念的翻译准确度及原型内容中英文的表达准确程度都将影响原型的检索准确程度。
为了提高检索的查准率和查全率，领域概念及其翻译内容的同义词应该尽可能地被考虑。同时，考虑到检索功能存在问题，人工检索还是必需的。虽然通过人工的查询和比对可以提升检索的查全率和查全率，但是人工检索是一件费时费力的工作。
对于每一个领域概念，HMC支持基于概念名称、数据元素或者它们同义词的查询。在检索结果列表中，可以通过比对领域概念与查询到的原型的定义来确定检索结果是否存在与领域概念对应的原型。当存在多个原型与领域概念对应的情况时，选最高相似度的原型作为最终的查询结果，查询结果如下表4-4所示。
表4-4 领域概念对应原型查询结果
通过领域概念和检索所得的原型的内容比较，可以将其对比的结果分为六类。根据这六类情况，原型编辑的规则如下表4-5所示。
表4-5 原型映射规则
如果领域概念没有被检索到对应的现有原型，那么领域专家将依据领域概念的定义新建一个原型。如果存在现有原型与领域概念对应，那么以下五种操作可以实现对现有原型的重用。
（1）如果现有原型可以覆盖领域概念所有的数据元素并且不需要任何修改，那么现有原型将被直接重用。
（2）如果现有原型覆盖了领域概念中的所有数据元素，但是其中原型的元信息需要修改，那么将对现有原型进行Revision操作（修改），涉及翻译的添加、数据元素值域的扩充以及描述信息的修改。
（3）如果现有原型仅仅能够覆盖领域概念中的部分数据元素，那么需要对原型进行三种操作中的一种。三种操作分别为特例化（Specialization）、扩展（Extension）和更新（New version）。当领域概念是现在原型的一种特例时，可以通过Specialization操作实现对现有原型语义的紧密约束，可能涉及数据元素的语义的紧密约束、值域范围的约束、利用特例化数据元素替代原有语义更为通用的数据元素。Extension操作则是通过对现有原型进行一种兼容性修改，主要涉及数据元素的添加和更新，以达到重用现有原型来表达领域概念的目的。如果领域概念与现有原型存在一定的非兼容性差距，则需要对现有原型进行New version操作，其会导致一个新的原型被构建，但是其中也会复用一部分现有原型的数据元素，这些数据元素与领域概念中的数据元素是兼容的。
现有原型的修改涉及元数据的修改、数据元素的添加、数据元素值域和术语的调整。新建原型时首先需要确定原型的所属类型及原型名称，其中原型类型在参考模型中有定义，包括COMPOSITION、SECTION、ACTION、EVALUATION、OBSERVATION、INSTRUCTION、ADMIN_ENTRY等。然后需要对原型的元数据进行编辑，包括原型对应的领域概念的描述、关键字、适用情况、不适用情况、原型构建的目的。最后，编辑领域概念对应的原型中所应该包含的数据元素及相关术语。
目前，原型编辑工具或者包含原型编辑功能的平台包括Archetype Editor（AE）、Link EHR Editor和HMC平台。电子病历标准信息模型构建采用协同建模的方法，因此采用HMC平台支持协同建模方法的实现。首先，在HMC上的受控层设立了一个电子病历受控子空间，用来保证原型构建的标准化；然后，由建模专家组在受控空间内开发原型；最后，经过多次原型建模迭代开发了“草稿”状态的原型，等待进一步的原型审核和发布。
原型审核是在目标领域内获得一致的、高质量原型的一种实用方法，其中的审核行为由整个建模团队操作。原型的审核过程中涉及原型状态信息。只有状态为草稿状态的原型才能够被允许发起审核申请，进入审核过程时原型的状态为审核状态。若原型内容得到领域专家们的认可并通过审核，原型的状态变更为发布状态。若原型内容未得到领域专家们的一致认可，则原型状态由审核状态变更为草稿状态，并继续进行修改直至下次进入审核流程。
为了提高原型构建质量，促进原型的共享和重用，通过专家审核团队来执行原型审核操作。专家团主要审核原型内容的2个方面：领域概念和信息表达。对于领域概念审核，为了方便领域概念内容的审核，原型内容采用思维导图的方式呈现给参与领域概念审核的专家们。审核内容包括概念的元数据和组织结构，包括命名、概念描述、术语约束，以及数据元素之间的关系。对于信息表达方面的审核，其关注点在于数据元素的数据类型选择和数据元素的组织方式。
通过近一年的努力，为了覆盖电子病历信息需求，一共定义了64个原型（如下表4-6所示）。这些原型中，55%（35）是直接重用的原型，9%（6）是完全新建的原型，36%（23）是基于现有原型的修改。换言之，案例中构建的原型中91%是对现有原型的重用。通过分析原型状态数据，我们发现仅有19%的原型是发布状态，也就意味着大部分的重用原型还需要进一步地被认可。与此同时，在所有重用的原型中有17%被openEHR设置成为弃用或者拒绝状态，也就是说这些原型已经被建议不再重用。在对现有原型的修改，涉及2个Revision操作、2个New version操作、1个Specialization操作和18个Extension操作。另外，我们发现原型的修改大部分发生于ACTION、ADMISSION、EVALUATION、INSTRUCTION和OBSERVATION类型的原型，而直接采用的操作大部分发生于CLUSTER、EVALUATION、OBSERVATION和DEMOGRAPHIC类型，新建原型操作多发生于CLUSTER、ADMISSION和OBSERVATION类型的原型。
表4-6 电子病历标准原型
随着医疗信息技术的不断发展，越来越多的医疗信息系统在实际的医疗服务场景中发挥着重要作用的同时积累了大量的电子化医疗数据，为基于电子化医疗数据开展科学研究提供了基础。在实际的对医疗数据的有效利用中，研究团队往往都以某种特定疾病为中心开展相关研究，因此，专病医疗数据的收集是数据有效利用的前提。由于缺乏标准或者标准化的信息模型支持，专病医疗数据存在共享性差和利用率低的问题。在应对小样本专病医疗数据有效利用需求时，这些问题可能更多地表现为人力资源的浪费，但是不会影响其科研价值的获取。然而，随着大数据和人工智能相关技术不断被应用于医疗领域，专病医疗数据的共享已经成为迫切需求。通过人工智能和大数据相关技术在专病医疗数据上的应用，可以分析、挖掘出更多的科研价值。这些技术的应用需要以专病数据共享为前提。特定的临床注册中心或者临床人员收集的专病医疗数据已经不能满足有效利用的需求，需要将多个专病医疗数据相关的数据源中的数据进行共享才能够满足数据分析和挖掘的需求。考虑到大数据应用的特点，专病医疗数据共享涉及的电子病历和临床注册中心数据源会越来越多、内容越来越复杂、语义要求越来越高，需要一套标准化的信息模型来支持专病数据共享和语义互操作。
本节将以急性冠脉综合征（Acute Coronary Syndrome，ACS）为范例，展示如何以openEHR原型为表现形式进行标准信息模型的开发。
急性冠状动脉综合征是一组由冠状动脉内粥样硬化不稳定斑块破裂或者糜烂导致血栓形成而引起急性心肌缺血的临床综合征，其包括不稳定型心绞痛、非ST段抬高心肌梗死、急性ST段抬高心肌梗死，是心源性猝死的重要原因。ACS的相关研究需要以ACS患者的相关数据作为基础，本案例选取的患者数据由来自不同的医疗卫生机构的不同结构的ACS相关数据组成，与通用电子病历中的数据存在一定的差异。ACS数据粒度更细并且数据内容是以疾病为导向进行组织的，而不是侧重于服务临床业务，更侧重观察性结果的记录，具有专科或者专病数据的特征。除此之外，ACS数据中还会包含一些目前电子病历并未包含的数据项目，如是否患有某种疾病的标记，是否复用某种特定的药物标记。然而，电子病历中的数据记录往往服务于临床业务流程，并且其粒度更为粗糙以增强其通用性。虽然两者之间存在一定的差异，但是两种数据之间会存在一定的联系：ACS研究数据中有一部分可以从电子病历中进行提取或者转换，剩余部分可能需要人为的补充。因此，ACS标准信息模型的构建可以参考电子病历标准信息模型和上述医疗信息协同建模方法，具体构建过程描述如下。
（1）需求分析阶段
首先，根据ACS标准信息模型组建包括30名来自不同三级甲等医院的ACS治疗相关的临床专家、3名原型建模专家、5名医学信息学专家、5名临床数据中心开发人员和2名术语专家的ACS原型建模团队。然后，由ACS治疗相关的临床专家讨论并定义出ACS专病数据应该包括的数据元素，包括数据元素的名称、描述、值域和对应的表现形式。临床专家组将这些数据元素编辑成为一张CRF表单形式的文档，以便提供数据元素之间的上下文信息，辅助其他领域专家理解，促进领域概念的设计。CRF表单中的每一个小节及其包含的数据元素就是概念发现的结果和对应的数据元素定义。
（2）概念设计阶段
基于领域本体中定义的领域概念，结合上述步骤中获得的ACS概念发现结果和对应的数据元素集，由临床专家、医学信息学专家和原型建模专家共同进行ACS概念设计。确定ACS领域概念之后，由术语专家对数据元素的术语进行定义和添加。最终，定义了包含183个数据元素的20个领域概念。
（3）原型开发阶段
首先在HMC上申请了一个受控子空间用于ACS标准原型的开发。然后依据每个领域概念在HMC检索对应原型，以便尽可能地重用现有原型，保证原型定义的一致性。检索结果中，原型重用的规则如下。
如果检索结果中同时存在电子病历标准原型和非电子病历标准原型，那么选择电子病历标准原型进行重用。因为电子病历标准原型就是基于原型进行构建的，在遵从建模原则上进行了原型内容的扩展，并且已经获得了领域的认同。此外，ACS专病数据本身有一部分来自电子病历数据。
如果检索结果仅存在非电子病历标准原型，那么在重用的基础上参考现有的原型内容进行原型内容的扩展。虽然现有的非电子病历标准原型的定义在数据元素定义和组织方式上可能存在问题，但是其中的一些数据元素的定义可以作为一种参考。
然后，原型建模专家负责依据医疗信息协同建模方法中关于原型映射的规则进行原型的编辑工作。获得了原型初步的定义之后，医学信息学专家和临床数据中心开发人员会对原型内容的组织方式进行修改或者编辑，术语专家进行编码数据元素的术语绑定工作。
在建模团队成员对原型没有修改需求的时候，子空间管理员将原型状态设置为“草稿”状态，等待进入原型审核和发布阶段。
（4）原型审核和发布阶段
邀请国内临床专家、医学信息学专家、医疗软件开发人员、医疗信息管理专家在HMC平台上对原型的内容、组织方式和术语三个方面进行审核，并将审核意见收集汇总反馈给建模团队。如果专家们对于原型的定义没有异议，那么将原型设置为“发布”状态。如果专家们对于原型的定义提出修改意见，那么原型将由建模团队基于修改意见进行修改，然后进入下一个审核周期直到原型发布为止。
最终建模团队定义了26个ACS标准原型，其中重用电子病历标准原型18个，重用非电子病历标准原型5个，新建原型3个，如下表所示。
表4-7 ACS标准原型信息
（5）设计数据库
通过模板、原型、模板关系映射配置三部分信息，按照一定的映射规则，映射成相应的数据库表来存储具体的openEHR实例数据。原型定义了各种临床概念，如体征、医嘱、血常规检查等，模板对这些原型进行合理组合，并做进一步的语义约束，而模板关系映射配置包含了自动映射过程对关系数据库的一些必要的约束和配置，如索引列、字段类型长度的设置等。通过解析原型、模板和模板关系映射配置，得到一个经过约束和修正的模板对象模型，然后按照一定的映射规则生成一组关系数据库表，最后openEHR实例数据可以通过属性与数据库字段的映射信息存储到相应的数据库表和字段中。