下载掌阅APP，畅读海量书库
立即打开
openEHR信息建模方法由openEHR基金会提出并进行维护，通过两层信息模型的构建来促进医疗健康信息的生成、语义互操作和利用。openEHR分层建模方法是参考近20年的EHR相关研究和项目的成果所提出的，包括欧洲的Good European Health Record（GEHR）、GEHR澳大利亚项目（1997—2001）、欧洲Synapses（1996—1998）和SynEx（1998—2000）、欧洲EHCR support action、ISO 18308、HL7以及其他相关研究经验。
openEHR将信息模型的构建分为2个部分：参考模型（Reference Model，RM）和原型模型（Archetype Model，AM）。参考模型依据上述描述的医疗健康信息需求和研究经验，抽象出医疗信息记录和表达所需要的通用属性，并用面向对象的方法构建出相应的类和属性。参考模型是一个稳定的参考信息模型，其详细内容通过几个对应的openEHR规范对外公布。原型模型包括原型和模型。原型是对领域知识的表达，原型通过对参考模型进行约束而定义；模板则是依据具体的信息需求对原型的组装和约束。原型和模板都可以由领域专家进行定义。每一个原型对应一个领域概念的最大数据元素集，而模板对应特定医疗信息应用环境下的特定数据元素集合。换言之，原型面向领域知识表达，模板对应实际医疗信息应用需求。openEHR分层建模方法是术语中立的，术语的绑定可以发生在原型和模板定义的过程中。
openEHR参考模型用来表达医疗信息的信息语义，通过固定的对象类集合定义了医疗数据表达的通用属性，使得医疗信息系统或者服务可以基于参考模型进行构建。openEHR发布了多个规范用来支持和定义参考模型，包括数据类型、数据结构、逻辑信息结构、访问安全、隐私和其他技术实现所需的内容。其中EHR信息模型规范和人口统计学规范描述了参考模型的逻辑信息结构，分别对应着EHR信息和人口统计学信息。这些逻辑信息结构对应着原型的定义类型，如表4-1所示。EHR信息模型中的逻辑信息结构对应的类包括：COMPOSITION、SECTION、ENTRY、OBSERVATION、ADMIN_ENTRY、INSTRUCTION、EVALUATION和ACTION。人口统计学信息模型中的逻辑信息结构对应的类包括：PARTY、ROLE、PARTY_RELATIONSHIP、PARTY_IDENTITY、CONTACT、ADDRESS、CAPABILITY、ACTOR、PERSON、ORGANIZATION和AGENT。
表4-1 信息模型类名称及其描述
参考模型中EHR信息模型中的COMPOSITION和SECTION是用来组织医疗信息内容的容器类，为灵活地表达医疗信息内容提供基础。ENTRY及其子类负责用来表达所有的医疗信息内容单元。openEHR RM将医疗信息内容分为临床信息内容和管理信息内容，其中ADMIN_ENTRY用来表达管理信息内容，而剩余的临床信息内容则按照临床问题解决过程划分为OBSERVATION、INSTRUCTION、ACTION和EVALUATION。ENTRY类于临床问题解决过程中的医疗信息类型关系如图4-1所示。
图4-1 临床问题解决过程中的医疗信息类型
原型是领域实体的基于约束的模型，每一个原型都是针对一个领域概念对其在参考模型对应的类型的数据实例的配置。原型的类型对应着参考模型中可以原型化的类，如COMPOSITION、SECTION、OBSERVATION、ADMIN_EENTY、INSTRUCTION、EVALUATION、ACTION、ROLE、ORGANIZATION等类型原型。COMPOSITION和SECTION类型原型用来组织和约束ENTRY类型的原型内容，来表达特定的领域概念，如病案首页、健康档案、SOAP病历等。ENTRY的5个子类原型用来表达一个个完整离散的领域概念，不同类型表达不同类型的医疗信息内容：INSTRUCTION类型原型用来表达发生在未来的医疗干预或者指令相关概念，如影像检查申请、实验室检验申请、处方申请；OBSERVATION类型原型用来表达已经发生的客观记录对应的领域概念，如影像检查报告、实验室检查报告；Action类型原型用来表达INSTRUCTION类型所指定的医疗信息活动中已经发生的活动，如为筛查、诊断、治疗等目的而进行的临床活动；ADMIN_ENTRY类型原型用来表达管理相关的领域概念，如就诊、转诊和离院信息。openEHR定义了一种原型表达的形式化语言——原型定义语言（Archetype Definition Language，ADL）。ADL已经被国际标准化组织ISO采纳成为ISO 13606-2标准。ADL使用限制原型定义语言cADL（constraint ADL）、数据原型定义语言dADL（data ADL）和一阶谓词逻辑FOPL（First-order Predicate Logic）三种语法来表达原型，其中cADL负责定义原型定义语言的约束部分，dADL负责定义原型定义语言的数据部分，FOPL负责定义一阶逻辑相关部分。原型的内容可以分为原型标识、语言、定义和本体等几个部分，原型定义语言的三种语法在原型内容不同部分的应用如下图4-2所示。openEHR原型可以由领域专家基于专用的建模工具进行定义。
图4-2 三种语法在原型内容不同部分的应用
原型是领域概念的最大数据集定义，而模板是为了满足特定的目的或者实际医疗信息应用需求而对多个原型进行组装和约束。就使用范围来讲，原型是通用的、重用的、可共享的，也是医疗信息语义互操作中语义表达的基础。医疗信息的语义互操作的实现形式往往通过模板实现，因为模板对应着具体的应用需求，包括数据的输入和认证。模板的定义往往都通过在COMPOSITION和SECTION原型引用ENTRY子类型原型并添加具体的约束得以实现。
基于模型驱动的方法和分层建模方法，openEHR方法支持领域专家通过定义原型和模板来控制医疗信息系统的功能实现，包括数据存储、用户界面语义互操作涉及的内容等。此外，openEHR定义了一种基于原型进行医疗信息语义检索的原型查询语言（Archetype Query Language，AQL），该语法的实现独立于应用程序、编程语言、系统环境和存储模型。除了发布了一系列的openEHR规范文档和一些原型和模板编辑工具之外，openEHR还提供了一个原型和模板管理平台——临床知识管理器（Clinical Knowledge Manager，CKM）。目前CKM平台上已经共享了500多个原型，包含6500多个数据元素。
Health Level Seven Version 3（HL7 V3）是Health Level Seven（HL7）的新的一代消息标准，是一种用于生成XML表现形式的消息或者文档的、基于模型驱动方法的临床信息交换方法。HL7 V3标准文档提供了一个参考信息模型（Reference Information Model，RIM）、数据类型定义、术语集和一个形式化的标准开发方法来支持V3消息和CDA文档的构建和交换。HL7 V3采用分层建模方法促进医疗信息语义互操作，其目标是解决医疗信息系统之间的信息交换问题。
HL7 V3分层模型建模涉及RIM、HL7发展框架HDF（HL7 Development Framework）和HL7模板（HL7 Template）规范。RIM是一个低层的通用信息模型，所有的HL7 V3的模型都是源自RIM中类的继承或约束，包括域信息模型（Domain Message Information Model，D-MIM）、精细化消息模型（Refined Message Information Model，R-MIM）、层级消息描述（Hierarchical Message Description，HMD）等，并且这些模型也属于参考模型，如HL7临床档案结构（Clinical Document Architecture，CDA）R2对应的R-MIM也是参考模型。HL7模板是分层模型中的上层模型。HL7发展框架是定义针对消息或者文档所需的消息模型的框架描述，是承接底层模型RIM和上层模型HL7模板的约束规范。HL7 V3的建模方法如图4-3所示。
图4-3 HL7 V3分层模型构建方法
RIM提供了HL7 V3标准信息需求的静态视图。RIM使用高度抽象的方法将所有的医疗信息内容抽象成为“实体”扮演“角色”，“参与”到“行动”中，此外“行动”之间存在关系，“角色”之间也存在关系。RIM定义了6个核心类来支持这个抽象。
（1）Act类：对应着“行动”，记录正在做的、已经做的、想要做的或者申请去做的事情。领域信息和过程记录主要采用Act及其子类进行表达。例如，临床观察、健康状况评估、治疗服务等。
（2）Entity类：对应着“实体”，医疗保健活动中涉及的人或者物。例如，人、组织、材料等。
（3）Role类：对应着“角色”，用来表示医疗保健活动中涉及的各种角色。例如，捐献者、医生、患者等。
（4）Particition类：对应着“参与”，表示“行动”和“角色”之间的关联以及活动发生的上下文信息。例如“行动”的主体、位置。
（5）ActRelationship类：用来表示不同“活动”之间的关系。例如，为了观察“胆石症”可能会进行“胆囊切除术”，其中“胆囊切除术”和“胆石症”观察都是“行动”。
（6）RoleLink类：用来表示不同“角色”之间的关系。例如，角色“管理员”对于“检验员”存在“直接授权”的关系。
除了上述6个核心类之外，RIM中还包括它们的子类。RIM中类的信息和关系如图4-4所示。这些类是HL7 V3模型驱动方法的基础，所有的HL7 V3模型都是对RIM类的约束细化，都可以追溯到具体的RIM类。
图4-4 RIM的UML类图（来源：HL7 RIM规范）
HDF规范是由HL7的建模和方法学工作组主导的方法规范项目的产物。HDF项目的目的是分析、涉及和记录与HL7标准开发相关的过程、策略和人工产物。HDF是一个HL7用来制定实现医疗信息系统之间互操作的规范的建模、管理过程、策略和可交付成果（deliverables）的框架。HDF是HL7 V3标准制订过程的重要组成部分，其指导标准如何通过为RIM添加约束来获得标准所需的各种信息模型及其相关的知识产物。HL7 V3的信息模型包括RIM、D-MIM、R-MIM、HMD或HD（HL7 V3 CDA标准中的层级描述）。RIM是与具体的业务领域无关的顶层的概念模型，D-MIM和R-MIM是逻辑模型，D-MIM是一个特定业务领域的信息模型，一个业务领域中可能包含多个主题，R-MIM是业务领域内一个主题的信息模型。HMD是针对一个特定触发事件对应的R-MIM的扁平化描述，是HL7 V3消息定义的重要依据。HD是针对CDA R-MIM的扁平化描述，是CDA标准实际应用过程中所需的CDA XML schema的来源。HDF框架的信息约束流程如HL7 V3分层模型构建方法示意图中HDF对应部分所示，可以描述为：首先针对建模领域进行一系列的分析并描述为领域分析模型（Domain Analysis Model，DAM），其中包括故事板（Storyboard）、用例模型（Use Case Model）、词汇表（Glossary）、信息模型分析（Information Model Analysis）、业务触发时间分析（Business Trigger Analysis）、流程图（Process Flow）和业务规则描述（Business Rules Description）。然后，结合DAM基于RIM中对应的类约束定义D-MIM，其中描述了特定领域所涉及的类及其关系。每个D-MIM中具有多个入口（Entry），并且其中的类型的约束相当的通用，不能够直接进行实现。最后，针对每一个入口对D-MIM进行约束细化形成多个R-MIM。HMD和HD分别是V3消息的R-MIM和CDA R-MIM的扁平化表达。
HL7模板是针对HL7标准的一个模型添加约束的形式化定义，如HL7 V3 R-MIM或者HL7 CDA R-MIM模型。模板中定义的约束类型包括：数据类型约束、基数约束、强制性/一致性约束、数值范围、单位、分数、术语绑定、出现等内容。模板是一个为了满足特定的用例或者上下文的需求而针对现有模型的约束，可以看作针对特定用途数据实例创建的“指令”或者“指令集合”。
美国观察性医疗结果合作组织（Observational Medical Outcomes Partnership，OMOP）由FDA和NIH发起，于2010年成立。在OMOP建成后，观察性健康医疗数据科学与信息学（Observational Health Data Sciences and Informatics, OHDSI，发音为“奥德赛”）作为一个开放科学社区成立。OHDSI旨在通过各个组织间的合作来收集和分析数据，进而促进更好的决策和医疗。为解决使用多中心数据进行科学研究的挑战，OMOP团队设计了通用数据模型（Common Data Model，CDM）以应对各个来源的数据类型，和一套标准术语集以统一各个国家和各个机构对于医学术语的应用。
1）OMOP CDM优势
由于单独使用医疗大数据来源均难以满足统计分析的需求和避免单个数据的局限性，因此使用多中心数据共同分析研究问题显得尤为重要。
为实现多中心数据分析和对于各中心数据隐私的保护，CDM具有以下优势。
（1）通用性：各个不同来源、结构的医疗数据在脱敏后，均可使用OMOP提供的ETL工具和标准术语集，在本地转化存储为CDM结构。
（2）统一性：对于医疗术语部分，OMOP标准术语集囊括了医疗数据所需的相关概念，以统一各个数据源对于术语使用的不同。
（3）安全性：数据经由各个机构脱敏后，CDM转化和研究分析均在本地进行，无需联网。开展多中心研究也只需分享研究代码和研究结果。源数据仅该机构可见。
（4）可拓展性：CDM的设计赋予了各个机构根据自身需求，引入适当的新概念和术语的选择。
2）OMOP CDM结构介绍
OMOP CDM结构主要包括以下6方面。
（1）临床数据：病人信息，诊断，操作，用药，检验等临床记录。
（2）临床派生数据：临床数据基础上，对于诊断，用药的归纳总结。
（3）标准术语集：标准概念，概念关系，源概念信息等。
（4）医疗系统数据：就医地点，医疗提供方信息。
（5）健康经济数据：就医费用，投保信息。
（6）整体数据信息概况（Metadata）：机构数据的整体描述信息。
3）OMOP CDM标准术语集
OMOP CDM通用数据模型中，对各类术语进行了标准化映射。由于很多术语集已经在真实世界中被广泛地使用，并且术语集的创造和成熟需要大量的资源和时间的检验，OMOP标准术语集均选用了已有的术语系统。针对各个领域各个国家的术语集（共78个），OMOP标准术语集选用了其中适用于开展研究的术语集作为标准，并将未被选择或者各国本土化的术语系统映射到标准术语集。
以下为OMOP所收录和选用的主要术语集的介绍。
（1）疾病诊断类：标准术语集选用医学系统命名法SNOMED和国际疾病分类第10版ICD-1O, SNOMED中对于疾病的逻辑分层，以及ICD-1O中对于肿瘤特有属性的表述更有利于研究开展。
（2）手术操作类：各大术语集对于操作类的概括均有亮点和不足，因此根据不同操作，选用了不同术语集作为OMOP标准。
（3）药品类：标准术语选用临床药品标准命名术语表RxNorm，一个关于临床药物的标准命名法，包含了药物的活性成分、强度和剂型。RxNorm不仅标准化、全面、系统地记录了药品信息，并且其关系表实现了药品信息交互。
（4）检验类：标准术语选用检测指标标识符逻辑命名与编码系统LOINC，其临床部分的术语包括生命体征、血流动力学、液体的摄入与排出、心电图、产科超声、心脏回波、泌尿道成像、胃镜检查、呼吸机管理、精选调查问卷及其他领域的多类临床观测指标。
4）OMOP CDM中文术语标准化映射方案
以下将从疾病诊断、手术操作、药品、检验四方面阐述中文术语到OMOP标准术语集的映射方案。
（1）疾病诊断类
我国诊断类术语以ICD-10或者ICD-11的不同拓展版本为主，在ICD-10的4位代码的基础上进行拓展。编码拓展的繁多使得一步式的标准化映射尤为困难并需要更多资源。因此，疾病诊断类术语到OMOP标准术语集的映射可分为两个步骤。
①提取中文术语中与ICD-10相同的前4个字符；
②根据各个机构所使用的拓展版本，由医学专家做第二轮6字符中文术语到OMOP标准的细致映射。
（2）手术操作类
与疾病诊断类术语相似，我们的手术操作类术语以ICD-9 Procedure的不同版本为主，在ICD-9 Procedure的4位编码的基础上进行拓展。因此，手术操作类术语到OMOP标准术语集的映射也可分为两个步骤：
①提取中文术语中与ICD-9 Procedure相同的前4个字符；
②根据各个机构所使用的拓展版本，由医学专家做第二轮6字符中文术语到OMOP表尊的细致映射。
（3）药品类
由于药品类在我国术语使用情况较少，因此将其术语化需要首先建立我国药品的信息库，继而完成信息库到OMOP标准术语集RxNorm的映射。对于医院使用的药品数据，进行标准化映射具体步骤如下。
通过国家药品监督管理局的数据库，获得所有批准的化学药品的清单和其对应的各方面信息，如成分（中文和英文）、剂型、商品名、产品名、生产单位等。将信息结构化处理后，使用RxNorm信息模型，建立每个药品独特的概念，并将其相关信息与RxNorm中已有概念进行关联（如成分，剂型等），从而建立药监局获批的所有化学药品到RxNorm的映射。
根据各个医院的不同药品记录方式，利用ETL和NLP技术，提取有用信息，如成分、商品名信息，进而与第一步中的我国药品信息库做映射，最终获得RxNorm的映射关系。
（4）检验类
与药品类相似，检验类术语在我国的应用较少，各机构之间对于检验项目名称的记录和检验单位也存在较大不同。我国目前对于检验类的术语集包括LOINC中国，这份检验数据表也被LOINC国际收录。因此，我们可根据各个机构的不同检验数据记录，适用ETL和NLP的方法，通过LOINC中国将检验数据与OMOP标准检验术语集LOINC相映射。
临床元素模型（Clinical Element Model，CEM）是Intermountain Healthcare公司的第三代临床数据模型。Intermountain Healthcare的CEM信息建模方法，将模型分为抽象实例模型（Abstract Instance Model）和抽象约束模型（Abstract Constrain Model）。抽象实例模型通过递归结构表达实例数据，而抽象约束模型为实例数据添加约束，进而提供一种正式的详细临床模型（Detailed Clinical Model）的定义方法。临床元素模型语言（Clinical Element Model Language，CEML）是抽象实例模型的实现语言。
抽象实例模型的构建方法是构建一个以临床元素为核心的递归模型。抽象实例模型是由临床元素节点组成的树状结构。临床元素的最基本骨架包括type、key和value choice属性。属性type的取值是一个确定该临床元素实例所要遵从的临床元素约束类型的编码值，对应着抽象限制模型中的临床元素类型。属性key的取值对应着现实世界概念的一个编码值，用于说明临床元素要表达的内容。属性value choice则是一个数据结构选择，待选择结构为data和items。属性data代表一个叶子节点，其取值为一个符合HL7 V3数据类型的数值。如血清钠含量是140 mEq/L，如下图4-5所示。属性items是一个包含多个临床元素的序列结构，其体现模型的递归属性。以血压实例为例子，血压包含收缩压和舒张压，收缩压和舒张压就是items属性下的2个临床元素，而且这2个临床元素的value choice都是data属性，如下图4-6所示。
图4-5 血清钠CEM数据实例
图4-6 血压CEM数据实例
除了最基本的属性外，抽象实例模型的其他属性，包括quals、mods、atts、instanceId和alt。属性quals用于记录一些修饰信息，其不会修改临床元素的意思，如血压测量的位置信息，并且在处理实例数据时忽略修饰信息也不会有太大问题。属性mods用于记录一些修改临床元素的意思，包括主题（subject）和否定（negation）信息，在处理实例数据时必须与mods属性的信息一起解释，否则会引起致命的问题。属性atts用于记录一些上下文信息，如谁、什么时间、在哪、为什么等属性信息。属性instanceId用来记录临床元素的唯一表示，采用GUID进行记录。属性alt用于记录一些不符合临床元素限制类型但是实例数据语义等同的临床元素，如血压测量的临床元素限制类型BloodPressurePanel中要求收缩压为数值，但是实际的实例数据却为“高”，这时可以在属性alt中记录“高”，并将属性data中的取值设置为“Null”。
抽象约束模型用来约束抽象实例模型，其由临床元素限制类型（Clinical Element Constrain Type，CEType）组成。CEtype的定义包括name、base、kind属性和一系列约束（constrains）。
属性name是用来定义CEType的名称，也是其唯一标识符，保持整个约束模型都是唯一的。属性base用来定义应用其他的现有CEType所定义的约束，通常base引用的CEType应该是比定义的CEType更为通用的约束，如base定义了labObervation，而定义的CEType定义了其中血清钠约束。属性kind用于记录CEType的功能性分类，其类型包括statement、component、Noninstantiable、panel、attribution和modifier。
Noninstantiable用来定义不完整的约束，需要进一步定义为statement、panel和component。statement用来定义data属性所定义的约束。panel用来定义items对应实例数据所需的约束。component用来定义可存储实例的部分约束的CEType，如修改属性quals。attribution用来定义约束atts属性的CEType。modifier用来定义约束mods属性的CEType。
约束由属性path和value两个部分组成。path用于记录约束应用在临床元素实例模型中的位置，路径能够定位到实例模型中的任意节点。属性value对应着实例模型中约束节点的取值。在路径表达过程中能够定义到其所对应的数据类型的所有属性，如key.code、key.domain、data.type、data.cwe、data.cwe.code、data.pq.unit.code、data.pq.unit.domain、data.pq.unit.normal等。