InterSystems IRIS/Caché的CDC

InterSystems IRIS/Caché未提供开箱即用的变更数据捕获(CDC)工具,而且由于其多模型建模能力和底层的多维存储模型,相对于关系型数据库的单一模型,针对于SQL的CDC在InterSystems IRIS/Caché上会更复杂一些。例如通过Journal日志记录的是底层持久化多维数组的数据变更,而不是SQL table的变更。

通常,在应用层面实现变更数据捕获是更灵活和简单的方式,例如通过设置触发器、类的DSTIME参数。但如果无法在应用层做CDC,可以考虑使用InterSystems IRIS/Caché的Journal和强大的开发能力获取数据变更。

这里介绍使用InterSystems IRIS/Caché的Reporting类型的异步镜像成员获取数据变更。

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

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

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

2 0
0 1K
文章
· 四月 24, 2021 阅读大约需 6 分钟
置顶--InterSystems 中文开发者社区精华文章集锦

欢迎大家将相关的经验在这个讨论区分享。

板块 文章列表
征文大赛作品集锦

2022年首届InterSystems 技术征文大赛集锦

2023年第二届InterSystems 技术征文大赛集锦

官方文档

我司即将推出中文官方文档门户,欢迎大家把需要的官方文档发在评论区,我们会优先发布。谢谢!

1 1
3 893

一些熟悉SQL的用户希望用SQL表的方式获取InterSystems IRIS/Caché的变更数据。知道了Global和SQL表的对应关系,就可以知道是哪一张SQL表数据变化了,甚至通过SQL查询获取变更的数据。
下面介绍如何实现这种方式,和注意事项。

获取Global和SQL表的对应关系

通常InterSystems IRIS/Caché的持久化的对象模型(类)和SQL表之间有一一对应的关系;而持久化的对象模型和Global之间也有一一对应关系。建立Global和SQL表的对应关系,通常可以使用以下的SQL查询特定SQL schema下所有表对应的Global:

0 0
1 859

在使用xDBC连接到字符集为US7ASCII的Oracle数据库时,大家可能遇到过中文的乱码问题,尤其是使用Oracle自己的xDBC驱动的时候。

字符集为US7ASCII的Oracle数据库虽然可以保存中文数据,但给客户端带来了很多麻烦,需要对获取和提交的数据进行转码。

在Ensemble/Health Connect/InterSystems IRIS 中使用SQL适配器连接到这样的Oracle数据库时,可以使用$ZCVT函数进行转码。

1. $ZCVT函数

$ZCVT函数是广泛使用的字符串转换函数,可以做大小写转换、编码转换、URL 和 URI 转换等。我们用其编码转换能力来解决字符集转码问题。

2. 获取的SQL结果集数据有中文时

6 2
0 841
文章
· 九月 30, 2022 阅读大约需 11 分钟
使用Prometheus监控Cache集群

使用Prometheus监控Cache集群

Executive Summary

生产级别的Cache集群往往由多个Cache实例组成,而Cache自带的管理界面不能满足对整个集群的监控,因此在实际使用中,往往需要投入人力对实例进行性能巡检。即便如此,这种巡检模式实时性低、告警的漏报错报率高、对既往数据追溯能力差。针对Cache/IRIS集群管理的这一缺憾,本文提出以Prometheus监控Cache集群的方案,最终实现了对集群全实例监控指标的自动化采集,以及准实时监控数据展示和告警提示。

监控大屏3.主机实例监控

24 8
0 816
文章
· 十一月 30, 2022 阅读大约需 5 分钟
HL7v2到底是什么?!

HL7(Health Level 7)是一套技术规范,用于医院信息系统(HIS)之间临床、财务和管理数据的计算机互交换。这些规范被不同程度地被纳入美国(ANSI)和国际(ISO)正式标准的语料库中。

HL7的L7表示它是在OSI模型的第7层,换句话说,在应用层运行的标准。这意味着HL7不需要考虑交换的安全性,也不需要考虑信息传输的安全性(这一点由较低层次的层来保证,例如用于安全的SSL/TLS或用于数据传输的TCP)。更准确地说,第7层支持终端用户进程和应用的通信,以及面向用户的软件应用的数据展示。作为OSI模型的最高层,也是最接近最终用户的层,第7层提供特定的应用功能,如识别通信伙伴和它们之间的服务质量,确定资源可用性,考虑隐私和用户认证,以及同步通信,并将应用与OSI模型的较低层连接起来。

回到HL7标准,HL7第二版标准(也称为Pipehat)最初创建于1989年,但目前仍在使用并定期更新,形成了2.1、2.2、2.3、2.3.1、2.4、2.5、2.5.1、2.6、2.7、2.7.1、2.8、2.8.1、2.8.2和2.9版本。v2.x标准是向后兼容的(例如,基于2.3版本的信息将被支持2.6版本的应用程序所理解),在更高的版本中,你会看到一些字段是专门为它而留的。

3 0
1 758
文章
· 十月 12, 2022 阅读大约需 10 分钟
前端操作自动生成BS、BP、BO

概述

现有Ensemble平台BS(服务)、BP(流程)、BO(操作)需对平台及开发语言有一定的了解才能实现,为简化用户操作,现对现有平台进行二次封装,通过API接口的形式进行前后端分离,通过前端界面操作实现BS(对外提供的服务)、BP、BO(逻辑处理或调用外部的服务)自动生成(通过%Dictionary实现),具体实现如下。

一、开发技术和工具

版本:Ensemble 2017.2.1

二、涉及公用类

2.1 %Dictionary.ClassDefinition(自定义类)

• property Super as %CacheString;
Specifies one or more superclasses for the class.
定义一个或多个父类,继承父类

29 10
6 693
文章
· 一月 19, 2023 阅读大约需 10 分钟
请求和接收测试结果(HL7v2的消息OML、ORL和ORU)

在上一篇文章中,我们看到了最常用的HL7消息类型之一--ADT(入院、出院、转院)的结构,以及ADT^A04的例子和它所有字段的描述。现在让我们来看看另一个数据流,它与测试订单的订购和履行有关。我说的是ORM(从2.5版本开始,你应该使用特定的消息来订购测试,如OMG、OML、OMD、OMS、OMN、OMI和OMP),ORL和ORU消息。在一个非常简化的情况下,数据的交换可能看起来像这样。

让我们更详细地看一下这些消息。

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

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

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

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

1 0
2 562
问题
· 九月 13, 2021
怎么获取Caché的CDC数据?

1.Caché数据库有没有办法配置然后用sql读取数据库实时变化的数据,类似于mssql那样?我看了可以写类去读取global获取journal的值,但是怎么用sql读呢?

2.不行的话,那用什么方式可以读取到journal日志文件,并输出日志文件的内容?

先谢谢大家了!!!

0 8
0 507

Caché Shadow

上次介绍了使用InterSystems IRIS/Caché的Reporting类型的异步镜像成员获取数据变更。但早期的Caché并不支持镜像,例如Caché 2008,它只支持Shadow。

在这些早期版本上是否也可以实利用Journal实现类似CDC的功能呢?答案是肯定的,就是利用Shadow服务器的Dejournaling filter routine (Dejournaling过滤器routine)。

Dejournaling filter routine

InterSystems Caché的 Dejournaling过滤器routine是一个用户自定义的routine,用于在Shadow服务器上过滤Journal记录。当配置了Dejournaling 过滤器后,Shadow服务器在redo journal前会自动调用Dejournaling过滤器routine。该routine传入参数以下:

0 0
0 494
文章
· 四月 25, 2022 阅读大约需 39 分钟
Angular 中 Ensemble 工作流的 UI

大家应该都已经很熟悉 InterSystems Ensemble(一个集成和应用程序开发平台),每个人都知道 Ensemble Workflow 子系统是什么以及它对于自动化人类交互的作用。 对于那些不了解 Ensemble Workflow 的人,我将简要介绍它的功能(已经熟悉的朋友可以直接跳过这一部分并学习如何使用 Angular.js 中的 Workflow 接口)。

InterSystems Ensemble

InterSystems Ensemble 是一个集成和应用程序开发平台,旨在集成异构系统、自动化业务流程和创建新的复杂应用程序,这些应用程序通过新的业务逻辑或新的用户界面增强集成应用程序的功能:EAI、SOA、BPM、BAM 甚至 BI (感谢 InterSystems DeepSee:一种用于开发分析应用程序的内置技术)。

Ensemble 具有以下关键功能:

1 1
0 433

前面介绍了通过mirroring或shadow,使用journal日志过滤器的方式,在不改动数据模型的情况下实现InterSystems IRIS/Caché上的CDC能力。
但如果你可以修改InterSystems IRIS/Caché上的数据模型,也可以考虑使用DSTIME特性实现变更数据捕获。

DSTIME特性

DSTIME特性是InterSystems IRIS/Caché的嵌入式实时BI工具DeepSee用于跟踪数据变更的。
InterSystems IRIS和2011版之后的Caché,都支持DSTIME特性。它会自动记录数据库中SQL表记录或持久化对象的变更,并将变更记录写入持久化的多维数组^OBJ.DSTIME中。

0 0
0 425
文章
· 十月 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的诸多移动端服务。

1 0
0 415

在软件开发和业务集成中,规则无处不在:会员折扣的计算规则、根据消息类型和内容将其路由到不同目标系统的路由规则。还有一个规则发挥重要作用的地方- 辅助决策规则,例如临床知识库和医疗质量指标规则。

规则经常需要随业务调整和知识积累进行调整,而规则的调整是业务和行业专家定的。如果规则是以代码硬编码的,这些调整需要程序员改动,一来不直观、需要业务专家与程序员大量的沟通成本,二来硬编码改动会对应用伤筋动骨,甚至带来风险,三来没法控制新规则生效的时间 – 总不能让程序员在新规则生效的那一刻去编译和部署吧。

2 0
0 398
文章
· 八月 10, 2022 阅读大约需 4 分钟
关于如何管理和减少Ensemble系占用空间的一些策略

我们中的许多人在几年前安装了Ensemble,估计空间是足够的,但现在却遇到了意外--硬盘已经满了!我们可以看看我们可以采取哪些措施来调查发生了什么,然后如何减少所占用的空间。 让我们来看看我们可以采取哪些措施来调查发生了什么,然后如何减少占用的空间。

是什么占用了Ensemble的空间?
让我们来看看在Ensemble中占用空间的东西的清单。

  1. Ensemble安装。
  2. 备份文件
  3. 日志文件
  4. Ensemble数据库。
  5. 流文件。
  6. 自定义应用程序文件

让我们逐一来看看这些文件。

Ensemble安装占用的空间

这是一个相对较小的空间,取决于版本,大约为1GB。如果你想减少它,你有可能删除一些开发包或第三方连接驱动ODBC/JDBC。你可以通过改变安装选项来做到这一点,见Ensemble安装手册。

0 0
0 391

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 380

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

2 0
0 380

医疗行业的互操作性在改善病人护理、降低医疗服务提供者的成本以及为提供者提供更准确的情况方面发挥着重要作用。然而,由于有这么多不同的系统,数据的格式也有很多不同的方式。有许多标准被创造出来以试图解决这个问题,包括HL7v2、HL7v3和CDA,但每一种都有其缺点。

FHIR,即快速医疗互操作性资源,是一种新的医疗数据格式,旨在解决这些问题。它是由国际卫生级七组织(HL7)开发的,该组织还开发了HL7v2、HL7v3和CDA。

今天我们将探讨如何在VS代码中借助IntelliSense和自动完成功能,通过使用FHIR Schema 创建和验证FHIR资源。

第 1 步 :从FHIR 官方网站 https://www.hl7.org/fhir/下载 JSON schema file 文件用来做资源校验

0 0
0 380
文章
· 五月 31, 2021 阅读大约需 6 分钟
精华文章---HealthConnect中创建HTTP服务

HealthConnect中创建HTTP服务端

这里我说说怎么在HealthConnect上开发HTTP服务。

作为消息引擎,HealthConnect会需要从一个接口接收HTTP请求发送到另一个接口,中间做消息转换,路由等等,目的的接口可能是HTTP,或者SOAP,REST等等。这里只介绍HTTP服务的内容,也就是最简单的两种实现:

第一种:实现客户定制的HTTP服务业务服务组件(Business Servie)

创建Business Service类,继承EnsLib.HTTP.Service, 如下面的示例:

0 0
1 345