3.1 InterSystems IRIS内码与多语言支持

3.1.1 InterSystems IRIS内码与字符集转换

InterSystems IRIS的内码是UTF-16,因此它支持Unicode多语言字符集。对于其它字符编码,例如UTF-8、GB18030、Big 5,它会自动进行转码。例如对于简体中文,它将GB18030输入数据转换为UTF-16,或者将UTF-16数据转换为GB18030输出。

2 0
0 337

%SYS.Journal.Record 类有一个查询(query), List, 可以列出Journal文件中记录的数据修改历史。例如,要查询谁对global节点^QP(1,2)做过修改,可以使用如下代码。它查询Journal文件(输入参数pFilePath)中的global节点(输入参数pSearchGlobal)的操作:

2 1
2 380
文章
· 三月 17, 2024 阅读大约需 12 分钟
生成式大语言模型和检索增强生成

近来生成式大语言模型掀起了革命性的AI浪潮。生成式大语言模型是什么原理?我们怎么在业务中利用它?

一. 大语言模型的工作原理

生成式大语言模型是生成式人工智能底层的机器学习模型,是一种用于自然语言处理的深度学习模型。

人工智能、机器学习与大语言模型的关系如下图:

1.1 为什么我们称之为大语言模型?

大语言模型的“大”体现在多个方面:

2 0
0 736

InterSystems 是一家已经深耕数据库平台领域达44年的公司,成立于1978年,现在已经在全球的80多个国家开展相关业务,每天有超过10亿患者的电子病历数据都跑在以我们的数据库平台构建的应用系统之上。

2 0
0 441
文章
· 十月 7, 2023 阅读大约需 19 分钟
国际卫生信息互操作标准发展简史

卫生信息和其它信息化一样,经历了数码化、数字化到当今的数字化转型,卫生信息互操作一直伴随左右。

数码化(digitization):国内90年代开始,HIS全面铺开,卫生信息进入数码化时代。数码化初期业务集中在HIS上,互操作需求不高,点对点接口可以满足绝大多数需求。

数字化(digitalization):在2000年之后,各种专科系统、尤其是电子病历的诞生,医保和新农合的实施,要求卫生信息共享交换,以提高流程自动化水平。互操作需求爆发,2007年集成平台开始进入市场,卫生信息化进入数字化时代。

数字化转型(digital transformation):2014年,国内正式进入移动互联网时代;次年《全国医疗卫生服务体系规划纲要(2015—2020年)》发布,卫生信息化的服务对象(服务于医护技到服务于患者)和业务形态(临床管理到患者服务)都发生了翻天覆地的变化,开始步入数字化转型的时代。它对互操作提出了更高的要求 - 利用互操作,增强全员参与,为卫生服务创造新价值、发展新业务,推动医疗机构持续数字化转型。

可以说,卫生信息互操作在整个的卫生信息产业中愈发重要。

国际卫生信息互操作发展了30年,国内也发展了20年,但卫生信息互操作依然是一个挑战。

知史而明鉴,识古而知今。我们看看国际卫生信息互操作发展的历程,对未来的卫生信息互操作有什么借鉴。

卫生信息互操作标准的要素

HIMSS把信息互操作/集成定为4个不同的级别:

基础级别,仅仅打通了系统间进行数据通讯的通道;

结构级别,在基础级别上,定义了数据交换的格式和语法;

语义级别,建立在行业通用的基础模型和数据编码上,使用标准化的行业语义来定义数据元素,使用标准的值集。因此语义级别的互操作是全行业可以理解并有确定行业意义的互操作级别。或者说语义级别的互操做才是基于标准的互操作。

组织级别,通常都是由国家、行业协和和行业标准开发组织开发的。它加入了政策、社区、法律等方面的考虑,分析了通用的业务流程和工作流,在此基础上设定了参与互操作各方的角色、权限,服务和知情同意策略等。我们的互联互通,就是组织级别的互操作。

目前的卫生信息互操作项目多数停留在结构级别。只有达到语义级别的信息互操作/集成,才是标准化的信息互操作/集成,才能降低实施成本和提高实施效率。

做到语义级别的互操作标准并不容易,首先是消除语义歧义、其次行业普遍认可、再次是要覆盖行业用例并具有适应行业不断变化需求的弹性。

图片来源:EuroVulcan Conference 2023

先说消除语义歧义。要在信息交换时消除语义歧义,需要在语言、语法、词义、句法等多方面努力,而且涉及到数据的颗粒度。尤其在医疗行业,完整、消除歧义才能保障卫生信息准确和医疗行为安全!

HIMSS认为要消除语义歧义、达到语义级互操作性,需要基于五位一体的语义标准,包含:

  • 词汇/术语标准:依靠结构化的词汇、术语、代码集和分类系统来表示健康概念。例如ICD-10SNOMED-CTLOINC RxNorm行业里典型的词汇和术语标准。
  • 内容标准:描述信息交换中,数据内容的结构和组织。而HL7 CDAHL7 V2C-CDA都是行业内容标准。
  • 传输标准:定义了计算机系统、文档架构、临床模板、用户界面和患者数据链接之间交换的消息格式和传输方式。传输方式确定了卫生信息交换的“推”和“拉”方式。DICOMIHE等都是传输标准。
  • 隐私和安全标准:是确定谁、何时、出于何种目的、使用哪种个人健康信息的权利,以及如何护健康信息的机密性、可用性和完整性的标准。美国的HIPAA和欧洲的GDPR都是关于隐私和安全的标准。
  • 标识符标准: 是用来唯一标识患者、机构、医护技、设备等实体的方法。例如咱们互联互通里用到的OID和美国的护士标识NCSBN ID …

并非消除了语义歧义的标准就能被广泛接受和认可,需要行业标准化组织的推动,实现厂商中立,毕竟互相竞争的厂商很难接受对方的企业标准。回顾一下行业里流行的标准,无论是术语标准、还是消息和文档标准,都是行业里标准化组织发布的,其中最有名的就是HL7。

从这个行业标准发展史可以看到,毫无例外的,标准先从术语标准开始,例如ICD、SNOMED,历史都非常久远。而我们常用的HL7 V2有30多年历史了,CDA和V3也20年左右了。从2014年,HL7推出了FHIR。这些标准是为何以及如何演进的?

互操作标准发展要满足不断变化的行业需求和用例

先看看90年代初的互操作的业务环境,就像下图那么简单:医疗机构还处在数码化向数字化转换的时代 - HIS等业务系统开始大规模部署以实现流程和数据的数码化,同时产生了非常有限的跨业务系统的流程自动化 – 信息集成需求。实时卫生信息交换的需求基本都在医疗机构内部(局域网,那时候WWW刚诞生),而院内的业务系统数量非常有限、且系统边界清晰,使用的用户基本就是医护技和管理人员,需要的互操作流量规模可以准确预测。而且系统互操作的技术手段非常有限,基本就是文件传输、串并口、socket,而SOAP(2000年)、RESTful(2000年)、甚至HTTP(1996年)等协议都还没有产生。

HL7 V2

这就是HL7 V2消息交换标准产生的时代,和所面临的互操作业务需求:它将业务事件和业务事件的上下文封装在消息结构中,在系统边界中传递这些消息。

业务系统边界清晰,一般用消息引擎来路由和转发这些消息,从而不打破系统边界。各个业务系统只要能接收/发送并处理这些标准化的消息即可。

近距离看一个HL7 V2消息示例,它是一个由多种分隔符分割的字符串,由区段和字段构成:区段是一组分类的数据,例如PID是患者信息区段;而字段是每个数据项,例如患者标识(在PID区段里)是“1182594^^^系联医院&1^^系联医院&1”,它本身也是一个结构,用于放标识符(1182594)和标识分配机构(系联医院)等信息。

而事件就是消息头区段里的ORM^O01,其中ORM代表业务域”通用医嘱消息”,O01代表事件“医嘱请求”。

消息头区段 MSH|^~\&|HIS|系联医院|系联实验室|系联医院|202302160002||ORM^O01|demo22903||2.5|382|||||UTF8

患者区段 PID||1182594^^^系联医院&1^^系联医院&1|||李小明||19570320|M|||北京市朝阳区建国门外大街乙12号2702

就诊区段 PV1|22903|O|心内科||||35030099^唐^南|||MED|||||||35019964^郑^顾樽||22903|||||||||||||||||||||||||202302160002^M

保险区段 IN1|1|65110116^城镇职工医保|

医嘱区段 ORC|NW|MS:1182594:1|||SC||||202302160002^M||||||||||||||||||||LAB

医嘱明细区段 OBR|1|MS:1182594:1||4548-4^糖化血红蛋白^loinc

为什么HL7 V2会是这种难读的格式?因为它是窄带时代的产物,当时通讯带宽有限,数据格式需要紧凑,通常仅用分隔符分割,以减少传输的数据量(相较与XML,通常能减少80%以上的数据),如今在一些检验检查设备的通讯协议中还能看到类似的设计。同时,从早期直到现在,多数HL7 V2消息是通过socket交换的。这些特征都是90年代互操作的历史印记。

HL7 V2是按模式复用的角度设计的颗粒度,也就是说它的颗粒度是信息区段。但并不是所有的信息区段都有独立的含义和复用的价值,例如区段TQ1、TQ2定义服药时间和用药途径,没有单独存在的可能和直接复用的价值。

另外,V2消息的字段随意性很大,相同内容可以放在不同的字段甚至区段里面;用户还被鼓励创建自定义的Z区段进行消息体扩展。也就是说它标准化程度不高,需要实施的双方事先约定好数据具体怎么放才能实现信息交换。同时V2术语约束机制很弱。

HL7 V3 和 CDA

世纪之交,卫生信息化发展提速,电子病历和各种专科系统崛起,更极大推动了卫生信息的交换和流程自动化的需求,同时对交换的语义标准化程度有了更高的要求。这需要更严谨的互操作业务抽象和术语约束。卫生信息正式进入数字化时代,也正是在这一时期,诞生了包括IHE、CDA、HL7 V3在内的众多互操作标准。

从模型抽象的角度看,应该全面包含用例模型、信息模型和交互模型,但V2的关注点基本在交互层面,对其它层面的抽象很弱。

由此,携着其著名的参考信息模型(RIM)方法论,V3在2005年横空出世,对业务场景进行分析,抽象交互逻辑,从参考信息模型到领域信息模型,再到精细化消息信息模型,最终产生需要的消息模型。模型以XML进行序列化,相较于V2,进步了许多。

这套方法论产生的V3消息标准化程度很高。但为了覆盖所有业务需求,RIM是高度抽象的(难于理解的);同时V3方法论是“按约束设计”(design by constraint),试图涵盖所有应用场景,避免自定义扩展,这使其越来越复杂、越来越庞大,而且用户没有RIM基础很难自己对其扩展,从一个极端走向另一个极端。

V3的高复杂性和高使用门槛,造成了它事实上的失败,没有成为V2的替代者,就像一些专家评论的 – “RIM创建了语义互操作性,但没有创建临床互操作性“。

注意,国内有一些实践中,甚至没有严格遵循V3发布的XML schema,直接用代码拼出XML字符串,也不做消息校验,这不算标准的V3。

同样在世纪之交,很多业务需要即时性不那么强、但数据更完整的交换 - 小结性质的临床文档交换。在这个领域,最主流的是CDA临床文档架构标准。CDA源于 1996 年就开始的临床文档中结构化标记工作,并在1997年并入HL7,随后使用V3参考信息模型来完善和发展。大家可能注意到前面的图上CDA早于V3发布,就是这个原因。

CDA临床文档架构,用于描述结构化文档,同时允许插入供人类解读的非结构化部分。它产生的文档具有上下文完整、可持久保存、可管理、可认证等特性。CDA文档和衍生的CCD文档广泛用于医疗机构边界间和医疗系统边界间的文档交换,或作为具有法律效力的临床文档依据保存在文档仓库。

CDA是成功的,可能是V3基础上唯一成功的部分,但它不能解决细数据颗粒度访问的需求。

IHE

虽然RIM基于业务场景、角色、触发事件等分析,但它的交付物 – 消息模型并无法执行流程与角色的约束。

服务用于业务场景里流程、角色的表达,功能内聚,可以通过企业服务总线(ESB)来协同,比消息路由规则更直观、更灵活,更适合实现业务流程的自动化。通常服务是比较大尺度的业务表达,服务标准广泛采纳的难度在于它实际上是规范业务流程和业务方法,而实际上多数机构的业务并不那么一致。

IHE(Integrating the Healthcare Enterprise)是国际上比较流行而成功的卫生信息交换服务规范。它是1998年,由HIMSS 和RSNA(北美放射学协会)发起,由一帮放射学和IT技术专家创建的。它最初为放射影像信息共享提供技术框架,以解决即便有了DICOM后在不同厂商系统间放射影像信息交换的标准和流程上的困难,后面逐步涵盖了越来越多的业务场景。IHE使用已经发布的卫生信息内容标准和术语标准,例如DICOM、HL7、LOINC等,来构建自己的服务框架,利用企业服务总线来协同这些服务,可以实现比消息交互更功能内聚的互操作架构:

• 服务本身封装了事件、上下文

• 服务针对于场景定义了流程和角色

• 适合跨清晰的业务系统边界间信息交换

• 服务有多种互操作模式:

• Web 服务本身是可互操作的,这意味着任何客户端都可以直接调用 Web 服务

• 服务可以通过企业服务总线(ESB)来协同,比消息路由规则更直观、更灵活

IHE分析每个业务场景(Profile),将业务场景中参与方定义为角色(Actors),场景中角色的交互定义为事务(Transactions)。例如跨机构的文档共享业务场景中,有4个不同的角色:文档源、文档注册器、文档使用者和文档仓库。而交互事务有注册、查询、获取等

IHE能在服务标准上取得成功,在于它先在参与的用户基础上规范业务,然后再基于规范的业务发布相应的服务,也就是说,使用IHE需要先认同它的规范出的业务。

IHE一直随着业务、技术和互操作标准的发展而不断演进,从最初使用DICOM + HL7 V2,到最新基于FHIR;从最初的影像信息交换到最近的患者穿戴设备的数据交换。例如在2007年,IHE创建了基于HL7 V3的跨机构档案共享的Profile – XDS.b,之后又推出了基于FHIR的诸多移动端服务。

2 0
0 484
文章
· 九月 14, 2022 阅读大约需 5 分钟
集成平台消息相关的常见存储问题
  1. 从消息查看器看到清除周期以外的消息没有被正常清除

这种情况先抽查这些消息所处的会话中是否有未完成操作周期的消息(状态为除“Completed”“Error”“Discarded”之外的状态)。如有,且定期清除任务配置了“KeepIntegrity”,且该环境并不需要保留这些消息,可通过关闭清除任务中的“KeepIntegrity”配置清除这些会话和包含的消息。如果有这类消息,但是定期清除任务未配置“KeepIntegrity”,可能是定期清除任务的逻辑或消息数据问题导致清楚任务查找的时候没有覆盖这些消息,请联系WRC帮助排查具体原因。

有关定期清除任务的更多信息请参见文档

Purging Production Data | Managing Productions | InterSystems IRIS for Health 2022.1

2 0
0 164
文章
· 九月 28, 2022 阅读大约需 3 分钟
第四十六章 功能跟踪器收集使用统计信息

[toc]

第四十六章 功能跟踪器收集使用统计信息

作为 不断努力改进其产品以满足客户需求的一部分, 在 IRIS® 数据平台中包含一个名为 Feature Tracker 的软件实用程序,该软件实用程序收集软件模块使用情况的统计数据。本主题介绍特征跟踪器。

为什么 InterSystems 收集统计数据

Feature Tracker 收集的统计数据记录软件模块是否存在并在给定的 IRIS 实例中使用。 Feature Tracker 每周通过 https 将此信息发送给 InterSystems。这些统计数据有助于 InterSystems 规划开发和支持。
收集的信息不包括任何应用程序数据。

2 0
0 84
文章
· 三月 23, 2023 阅读大约需 24 分钟
中高级开发者教程:通用查询解决方案

简介

什么是Query

Query是一种查询方法,用于查找满足条件的数据,将结果以数据集的形式展现出来。

Query类别

  • SQL Query,使用类 %SQLQuerySQL SELECT 语句。
  • 自定义Query,使用类 %Query 和自定义逻辑生成查询数据。

说明:在讲通用Query解决方案之前,我们先了解一下Query的基础和基础使用,有助于理解实现原理。如果读者了解Query基本使用,可跳过此章节,直接阅读“现状”。

2 0
0 175
文章
· 十一月 29, 2022 阅读大约需 3 分钟
配置 DSN

在Windows配置DSN

  1. 确认InterSystems ODBC客户端驱动已安装
    • InterSystems IRIS ODBC驱动会随着InterSystems IRIS安装包默认安装。
    • 如果没有随着InterSystems IRIS安装,请由此下载驱动,下载后执行.exe文件进行安装。
  2. 定义DSN(Data Source Names)
2 3
0 508
文章
· 十月 10, 2022 阅读大约需 4 分钟
IRIS镜像状态监控

在生产环境中IRIS通常以故障转移集群的形态被部署,而集群中各故障转移成员的镜像状态将决定该集群在故障发生时是否能够顺利切换保障业务不中断。因此,成员状态通常也是运维团队需要巡检或监控的目标。

尽管IRIS内部API提供了丰富的集群配置、成员状态监控等一系列接口,但除Portal上的镜像监视器外,并没有特定的接口便于从外部系统访问(如进行企业级监控集成时),也没有整合好的监控接口可用与获取镜像的健康状态。但在IRIS上开发一个REST接口暴露镜像状态数据并不困难,如下所示:

2 0
0 225

InterSystems流程自动化与工作流引擎

InterSystems工作流程引擎的主要功能 2

使用InterSystems工作流程引擎 3

场景描述 3

环境配置与测试 5

任务管理 15

任务API和自定义任务用户界面 16

展望 17

15

集成平台除了集成业务系统,打通数据与业务流程外,另一个核心的功能就是流程自动化(BPA)。

流程自动化涉及几个重要的特性:

  1. 流程建模
  2. 流程协同
  3. 决策自动化
  4. 低代码工作流程自动化
  5. 任务协同与任务管理

其中第4和5点都是和工作流程相关的。

什么是工作流程(Workflow)?它和业务流程(Business Process)有何区别?为何集成平台要涉及对工作流程的管理?

2 0
2 398
文章
· 三月 6, 2021 阅读大约需 16 分钟
第五章 SQL定义表(一)

第五章 SQL定义表

表名称和架构名称

可以通过定义表(使用CREATE TABLE)或通过定义投影到表的持久类来创建表:

  • DDL:InterSystemsIRIS®数据平台使用CREATE TABLE中指定的表名来生成相应的持久类名,并使用指定的架构名来生成相应的包名。
  • 类定义:InterSystemsIRIS®数据平台使用持久类名称来生成对应的表名,并使用包名称来生成对应的模式名。

由于以下原因,这两个名字之间的对应关系可能不相同:

2 2
0 254
文章
· 十二月 31, 2022 阅读大约需 10 分钟
HL7 ADT消息的类型和ADT^A04的例子

在上一篇文章中,我们讨论了标准 HL7v2 的起源、结构和消息类型。现在让我们看一下最常用的消息类型之一及其结构示例。我说的是 ADT。

HL7 ADT 消息(入院、出院、转院)用于在医疗机构传达基本患者信息、就诊信息和患者状态。 ADT 消息是使用最广泛且容量最大的 HL7 消息类型之一,因为它为许多触发事件提供信息,包括患者入院、注册、取消、更新、出院、患者数据合并等。

2 0
0 1.1K
文章
· 四月 2, 2021 阅读大约需 7 分钟
数据应用方案分享之一:新生儿先天性心脏病筛查

着手书写数据应用方案分享系列文章的初衷是,希望从终端用户的视角阐述我们所期待的数据应用方式及其可能为医疗领域带来的获益,为医学信息工作者提供参考。在这个系列中,笔者会以临床常见疾病和流程为例,用真实的数据录入、获取、展现和使用场景说明需求;尤其是如何细致、精准的构建数据源头,以确保现代医学信息技术“有数可用”、“数用必达”。其中肯定有思虑不周全或逻辑不严谨之处,望各位读者按需审阅,取其精华、弃其糟粕。此外,本系列更多在于探讨数据应用的可能性,而非可行性。文中部分图片尚处于设想模拟阶段,并非真实系统图片,请知悉。

2 0
0 331
文章
· 二月 22, 2023 阅读大约需 12 分钟
InterSystems IRIS的面向对象数据库特性

面向对象编程的优势

在应用程序开发时,我们使用的大多数开发语言都是面向对象编程 object-oriented programming (OOP)语言,例如大家熟悉的Java、.NET。而TIOBE的2023年2月的最新开发语言流行排行榜上,前5大语言都是面向对象编程语言,连排名第六的Visual Basic都有了越来越多的OO特性:

2 0
0 509
文章
· 六月 12, 2023 阅读大约需 2 分钟
使用 Synthea 生成 FHIR 测试数据

文章相关视频参见Synthea生成FHIR测试数据,以及FHIR服务器加载FHIR资源文件

1. 什么是Synthea

Synthea是一个开源软件包,可以模拟生成患者就诊数据。他的github地址在这里

生成的就诊模版从最初的模拟美国前十种常见病、前十种慢性病到现今超过90种不同的模型。详细模型参见这里

基于当前版本,Synthea的特性包括:

2 0
1 286
文章
· 一月 31, 2024 阅读大约需 21 分钟
用Java开发互操作产品 - PEX

InterSystems IRIS、Health Connect和上一代的Ensemble提供了优秀的互操作架构,但即便有低代码开发能力,很多开发者还是希望能用自己的技术栈语言在InterSystems的产品上开发互操作产品。

考虑到互操作产品本身的开放性要求和各个技术栈背后庞大的生态价值,InterSystems IRIS和Health Connect提供了Production EXtension (PEX)架构,让开发者使用自己的技术栈语言来开发互操作解决方案。目前PEX支持Java、.net、Python。

这里我们介绍使用Java利用PEX进行互操作产品的开发。

一 InterSystems IRIS上使用Java开发的基础

在进入PEX主题前,需要简单介绍一下Java在InterSystems IRIS上开发的各种技术选项,因为PEX也是以这些技术选项为基础的。

2 0
1 236
文章
· 十月 8, 2024 阅读大约需 5 分钟
FHIR Object Model 简介

挑战

在使用FHIR进行开发的过程中,我们会面对海量的FHIR规范中定义的数据结构,具体来说在FHIR规范中定义了超过150个资源、700多个资源内元素。每个定义里都包括了对自身结构的描述以及数据约束、数据绑定值集等。对于一个开发人员要记住这些内容非常困难。

同时FHIR数据,特别是Json格式的FHIR数据是典型的“有向图”结构,它的资源中嵌套元素定义、集合以及复杂的资源间“关系”,在这些复杂结构的数据间导航并操作,非常困难。

解决方案

在InterSystems IRIS for Health 2024.1之前,我们会将FHIR数据以Json文档的方式载入 %DynamicAbstractObject,例如下面的代码

2 0
0 137
文章
· 十月 9, 2023 阅读大约需 4 分钟
FHIR与微服务架构

市场上有太多的技术体系和应用开发架构,C/S、三层架构、面向服务架构… 以三层架构为例,展现层可能是网页或Java/.net客户端、应用层可能是java、.net、Python,数据层可能是SQL、NoSQL、NewSQL。但大多建立的是单体架构应用 – 为特定业务目标从底层数据模型到业务逻辑再到用户界面的一体化设计,也就是孤岛型应用。

单体架构应用最大问题是没有哪一部分是以复用为主要目的设计和建设的,而且和其开发技术体系绑定:

2 0
0 241
文章
· 四月 11, 2022 阅读大约需 8 分钟
InterSystems 数据平台与三级等保 - 第一篇

数据平台不仅要安全,还要合规,三级等保是我们要符合的主要安全规范。InterSystems的数据平台和集成平台产品都和三级等保有关。如果没有正确配置它们的安全选项,就会影响到整个系统的安全,影响到合规性。

在生产环境上,如何配置安全的InterSystems的数据平台,并达到三级等保的要求?

这个系列文章,针对InterSystems 数据平台的安全架构,围绕对三级等保的合规性展开,介绍如何配置出一个安全、合规的数据平台。

1 0
2 632

第五十七章 镜像中断程序 - 在手动故障转移之前确定备份是否处于活动状态

在手动故障转移之前确定备份是否处于活动状态

假设有两个名为 IRIS AIRIS B 的故障转移成员。如果 ^MIRROR 例程确认备份 (IRIS B) 在与主 (IRIS A) 丢失联系时处于活动状态,因此具有最新的来自 IRIS A 的日志数据,可以使用单个过程手动进行故障转移。当连接因主要故障而丢失时,不会造成数据丢失的风险。但是,当发生多个故障时,活动备份可能没有来自主服务器的所有最新日志数据,因为主服务器在连接丢失后继续运行了一段时间。

使用以下过程确定备份是否处于活动状态:

1 0
1 99
文章
· 一月 20, 2021 阅读大约需 6 分钟
InterSystems IRIS医疗版2020.1 HL7基准测试

简介

最近完成了针对IRIS医疗版2020.1版本的性能及可扩展性基准测试,重点关注HL7v2的互操作性。本文介绍了在各种工作负载下观察到的吞吐量,并提供了IRIS医疗版用作HL7v2消息传输互操作性引擎时的系统常规配置和调整准则。

基准测试模拟了与实际环境接近的工作负载(详细信息请参见“工作负载说明和方法”部分)。本次测试的工作负载包括HL7v2患者管理(ADT)和生命体征结果(ORU)数据,并包含数据内容转换和路由。

IRIS医疗版2020.1版本可以表明,采用第二代Intel®Xeon®可扩展处理器和Intel®Optane™SSD DC P4800X系列SSD存储的商用服务器,每天的持续消息吞吐量超过23亿条(入站和出站总量),与此前的Ensemble 2017.1 HL7v2吞吐量基准测试相比,扩展性提高了一倍多。

1 2
0 332

第五十八章 镜像中断程序 - 主要故障转移成员的计划外隔离

主要故障转移成员的计划外隔离

如自动故障转移机制中所述,当主节点同时与备份节点和仲裁节点失去联系时,它会进入无限期的故障状态并且不能再作为主节点运行。通常,发生这种情况时,备份会接管并成为主要的。当主服务器与备份服务器的连接恢复时,备份服务器强制关闭主服务器;或者,可以在恢复连接之前自行强制关闭主服务器。

但是,如果一个网络事件(或一系列网络事件)导致故障转移成员和仲裁器同时(或几乎同时)彼此失去联系,则可能没有主节点,因为备份无法接管并且主节点不再存在作为主要操作。这种情况显示为自动故障转移机制详细部分中仲裁模式下对丢失连接的镜像响应表中的最终方案。当主数据库变得孤立并且备份由于错误而无法接管时,可能会发生类似的情况。

当这些情况发生时,有以下选择:

1 0
1 96
文章
· 七月 12, 2023 阅读大约需 4 分钟
当 GPT 与 FHIR 碰撞出火花:利用Open API 的规范力量

FHIR 通过提供标准化数据模型来构建医疗保健应用程序并促进不同医疗保健系统之间的数据交换,彻底改变了医疗保健行业。由于 FHIR 标准基于现代 API 驱动的方法,因此移动和 Web 开发人员更容易使用它。然而,与 FHIR API 交互仍然具有挑战性,尤其是在使用自然语言查询数据时。

1 0
0 323
文章
· 七月 26, 2023 阅读大约需 3 分钟
第三章 HL7 架构和可用工具 - 使用 HL7 架构结构页面

第三章 HL7 架构和可用工具 - 使用 HL7 架构结构页面

使用 HL7 架构结构页面

通过 HL7 架构页面,可以导入和查看 HL7 版本 2 架构规范。要显示此页面,请从主页中选择互操作性 > 互操作 > HL7 v2.x > HL7 v2.x 架构结构。有关使用此页面的一般信息,请参阅在产品中使用虚拟文档中的“使用架构结构页面”。

HL7 模式页面提供了一个附加选项卡:消息类型。此选项卡将两个消息结构标识为请求/响应对。

查看文档类型列表

要列出某个类别中的所有文档类型结构,请首先选择该类别,然后单击“DocType 结构”选项卡。

1 0
0 86