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

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

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

2 0
0 457
文章
· 六月 11 阅读大约需 7 分钟
统一语义数据平台

数据平台一直在进化:从数据中心到数据中台,离散的数据资产得到进一步梳理和整合、按业务封装数据和操作数据的方法,并逐步提供了企业统一的访问、更新、检索、查询等数据服务。

然而市场上不乏听到数据平台的成功案例,却鲜见这些案例得到大规模推广。原因是什么呢?

一. 传统数据平台建设的挑战

传统数据平台的数据模型基于各自厂商的理解,缺乏统一行业数据模型和行业语义。可供参考的国内卫生信息数据元、数据集标准并非完整的行业语义,例如没有业务实体模型和数据元关系定义。传统的数据平台建设通常根据业务域,围绕数据应用需求组织数据。经常看到按业务域划分为CDR(临床数据中心)、ODR(运营数据中心)、RDR(科研数据中心)......

这造成了几个挑战:

1. 按业务域、而非业务实体来划分数据,虽然方便相应的业务域数据分析,但跨业务域重叠的业务实体数据,例如患者,需要跨数据中心同步。这些同步由于数据模型上的差异,往往非全息拷贝。随着同步次数越多,跨数据中心的数据越失真,造成数据资产多源不统一、数据资产一致性问题和时效性问题。

2. 数据平台产品语义表达上参差不齐,业务用户依赖数据工程师对数据理解和操作,无论是统计分析还是机器学习,海量的实施工作无法满足业务敏捷性要求;

3 0
3 339
文章
· 九月 21 阅读大约需 12 分钟
IRIS自动安装集群--manifest(安装清单)

前言

生产环境下我们部署和使用IRiS引擎,往往采用其主备镜像模式,虽然此架构简单但是往往我们需要持续在电脑前点击或者操作1到2小时,如果中间有个环节出现了问题有时我们可能需要部署一天.

接下来我分享的是IRIS自带的一个功能帮助我们部署---manifest-安装清单。他的主要使用方式是提前通过配置约定好我们期望的安装设置,在安装的过程中由IRIS程序直接执行脚本,简化IRIS集群的部署,减少运维人员的操作步骤,让我们有更多的精力放在实际项目和业务上。

20 5
0 184

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

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

1 0
0 245

IRISHealth以其完备且系统化的安全特性在医疗行业的数据库中独树一帜,这些特性包括安全认证、安全授权、安全审计、数据加密以及安全配置。其中数据传输无疑是其中最重要的一环。为此,IRISHealth采用了SSL/TLS技术来对传输的数据进行加密,有效保障了从IRIS数据平台的超级服务数据传输、Telnet服务数据传输、java/.net/Studio客户端的访问数据传输、MIRROR与DB的数据传输,到DBServer和ECPApp之间的数据传输的安全性。


本文是在两个IRISHealth2021实例之间进行ECP服务通信的示例,一个作为DBServer,一个作为ECPApp,两个实例之间通过使用SSL/TLS的ECP协议进行TCP的加密传输通信。

1.IRIS的DB和ECP环境:

DBServer

ECPApp

14 4
3 155
文章
· 十一月 23 阅读大约需 2 分钟
使用支持SSL的ODBC连接IRIS数据库
  • 前言

随着网络安全日益被重视,特别是等级保护制度的大环境下,SSL加密传输越来越被重视,本文介绍如何使用支持SSL的ODBC连接IRIS数据库。

数据库版本:IRISHealth-2023.1

  • 1. 服务器端配置

1)新建SSL服务器配置。

2)开启超级端口的SSL支持,这里我们选择启用即可,如所有超级端口的连接都支持SSL可选要求。

11 5
3 120

开发者您好!

这里向介绍@Lorenzo ScaleseOpenAPI-Suite (一个用于从OpenAPI 3.0生成 ObjectScript 代码的工具集)。这个工具集在 2023 年 InterSystems 开发工具大赛的21 个参赛作品中获得专家提名第三名

3 0
1 182
文章
· 二月 22 阅读大约需 12 分钟
InterSystems IRIS的面向对象数据库特性

面向对象编程的优势

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

1 0
0 168
文章
· 一月 6 阅读大约需 8 分钟
《数据二十条》的号角声

国务院于2022年12月19日发布了《中共中央 国务院关于构建数据基础制度更好发挥数据要素作用的意见》(后简称《数据二十条》),如何有效利用数据已经成为下一步的趋势。另一方面,无论是基于数据中台还是数据编织理念,两者也都对如何利用数据提出了构想。因此医疗行业数字化建设的目标已不能再局限于如何收集数据,建立医疗行业数据的流通机制将会是为越来越普遍的需求。

时钟拨回几年前,数据中台概念开始火爆。人们对数据中台的定义、诠释尽管有诸多差异,通过数据中台降低数据共享和利用的成本则是共同的期望。但经过这几年的探索之后,中台已死的观点也在涌现。究其原因,除去中台概念在技术上的不确定,数据流通过程中的责权益的不清晰也是严重的制约因素。毕竟,数据中台自身作为一套技术框架并不能代替法律法规与市场自动将数据转变为商品从而创造出流通价值。

那么,如何能够使数据的流通合规合法,使数据能够如货币和商品一般自由流动,则是我们需要思考和探索的主题,这次《数据二十条》的出现,无疑为医疗信息技术工作者提供了一个明确的思考方向。

4 0
0 166
文章
· 十月 7 阅读大约需 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 154
文章
· 五月 4 阅读大约需 11 分钟
在 Docker 中配置镜像

我们客户的一个共同需求是配置 HealthShare HealthConnect 和 IRIS的高可用性模式。

市场上的其他集成引擎通常被宣传为具有“高可用性”配置,但事实并非如此。通常,这些解决方案与外部数据库一起使用,因此,如果这些数据库未配置为高可用性,当发生数据库崩溃或与它的连接丢失时,整个集成工具将变得不可用。

对于 InterSystems 解决方案,这个问题不存在,因为数据库是工具本身的一部分和核心。 InterSystems 如何解决高可用性问题?深奥的配置会把我们拖入异化和疯狂的漩涡?不!在 InterSystems,我们倾听并处理了您的投诉(正如我们一直努力做的那样 ;)),并且我们已将镜像功能提供给所有用户和开发人员。

镜像

镜像如何工作?这个概念本身非常简单。如您所知,IRIS 和 HealthShare 都使用一个日志系统,该系统记录每个实例的数据库上的所有更新操作。这个日志系统是后来帮助我们在崩溃后恢复实例而不会丢失数据的系统。好吧,这些日志文件在镜像中配置的实例之间发送,允许并保持镜像中配置的实例永久更新。

架构

让我们简要解释一下在 Mirror 中配置的系统架构是什么样的:

1 0
0 152

本文根据InterSystems中国技术总监乔鹏( @Qiao Peng )的演讲“互联互通套件赋能数据利用与应用创新”整理而成。

IRIS医疗版互联互通套件的缘起与发展演进

来源HL7:正在到来的挑战

http://hl7.org/fhir/change.html

这是来自HL7官网上的一张图,描述了我们在医疗卫生行业面临的一些挑战,以及信息化建设在应对挑战中发挥的作用。当今,医疗卫生、生物学、信息技术有很强的融合趋势,加之社会变革带来的经济方面的需求,同时构成颠覆传统医疗卫生行业的因素。

这张图显示了从“被动医疗”转向“主动医疗”过程中信息的爆炸式增长,信息共享交换推动了我们对信息的利用,在这一进程中,医疗卫生信息化起着核心作用——而让信息更具价值,赋予信息标准化和互操作能力的过程,这也是InterSystems一直努力的方向,我们在国内支持大量医院实现了互联互通建设。在建设过程中,我们注意到项目的定量部分的建设成本占比是比较高的,很多的工作都花在了合规性和相关管理工具的开发上——应用标准的实施是有成本的,而对于标准的理解在各个项目上水平不尽相同,这就进一步影响了互联互通项目的建设成果。

1 0
0 149

今天从官网下载了IRISHealth-2023.1.0.229.0-lnxrh9x64版本的数据库安装包,在RHEL9.0上进行安装配置测试,遇到一个问题,趁热记录下来。

测试环境及软件版本:

操作系统——Red Hat Enterprise Linux release 9.0 (Plow)

数据库——IRISHealth-2023.1.0.229.0-lnxrh9x64

测试创建镜像时,配置好虚拟IP,点击保存。

保存后发现数据库没有变成主成员状态,一直是等待的状态,如下图所示:

5 0
1 123

2023年4月14日-16日,2023 CHITEC将在安徽省合肥市合肥滨湖国际会展中心(安徽省合肥市锦绣大道3899号)盛大召开。点击查看CHITEC 2023完整日程。InterSystems将亮相CHITEC,通过展位展示、主题研讨会、分论坛演讲等方式,全方位多角度展示InterSystems加速评测,助力公立医院高效建设互联互通平台和数据中心的能力。

1 0
0 117
文章
· 三月 28 阅读大约需 1 分钟
安装本地 FHIR 服务器的最快最简单的方法!

嗨大家好!

最近我需要使用 IRIS For Health 设置本地 FHIR 服务器,我认为我找到了有史以来最简单的方法!

只需在终端中运行以下两行:

 docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-community

docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'

您将在 http://localhost:9092/fhir/r4 本地运行 FHIR 服务器。

就是这么简单!

FHIR 服务器将使用最新版本的 InterSystems IRIS for Health Community Edition,并将通过 FHIRSERVER 命名空间中的 IPM 包从该应用程序部署 FHIR 服务器

这是针对 Mac OS的,所以请在评论中添加它在 Windows 中的工作方式。

这是一篇非常短的文章,因为使用 InterSystems IRIS for Health 和IPM Package Manager 设置本地 FHIR 服务器真的很容易。

1 0
0 115
文章
· 五月 9 阅读大约需 5 分钟
接收从 PACS 到 IRIS for Health 的 DICOM 消息

在上一篇文章中,我们看到了如何捕获位于我们服务器上一个文件夹中的DICOM类型的文件,以及如何将它们发送到PACS软件(在我们的案例中是ORTHANC开源解决方案)进行存储和咨询。那么,在这篇文章中,我们要处理的是相反的动作。

在我们的例子中,我们将配置我们的IRIS for Health Prodcution,以接收从我们的PACS通过TCP/IP发送的图像。要做到这一点,我们必须包括一个标准EnsLib.DICOM.Service.TCP类的业务服务,它将允许我们配置接收端。让我们来看看这个配置:

如您所见,我们已经声明了将监听的端口,通过该端口将接收从 PACS 发送的图像。我们还配置了本地 AET (Application Entity Title,应用实体名称)(IRIS) 和将向我们发送 DICOM (ORTHANC) 的 PACS,请记住这些字段是强制性的,并且将用于检查发送和接收 DICOM 消息的有效性。不要忘记必须从 DICOM 设置菜单配置和关联两个 AET:

1 1
0 93
文章
· 七月 31 阅读大约需 2 分钟
ChatGPT 与 InterSystems FHIR SQL 数据库构建器

FHIR® SQL Builder或 Builder 是 InterSystems IRIS 医疗版数据平台 的一个组件。它是一种复杂的投射工具,用于将 InterSystems IRIS 医疗版数据平台FHIR 存储库中的数据创建为自定义的 SQL 模式,而无需将数据移动到单独的 SQL 存储库中。 Builder 专门设计用于与 InterSystems IRIS 医疗版数据平台中的 FHIR 存储库和多模型数据库配合使用。

1 0
0 112
文章
· 七月 13 阅读大约需 1 分钟
国际主流医疗数据标准一览

前不久,北京市人民政府印发了《关于更好发挥数据要素作用进一步加快发展数字经济的实施意见》的通知。其中提到要“率先探索数据跨境流通”。今年1月,北京市互联网信息办公室也发文公示,首都医科大学附属北京友谊医院与荷兰阿姆斯特丹大学医学中心合作研究项目成为全国首个被北京网信办批准的数据出境安全评估案例(编号20220001)。可以预见,为更好发挥数据要素作用将来可能出现越来越多的跨境数据流通。那么我们今天仅仅看下,在医疗领域国际主要流行的数据标准都有哪些。

以下是国际数字医疗合作组织的主要统计(该组织协同了世界卫生组织WHO,OECD和33个不同的国家和地区)

从上表可以看出,数据共享领域 DICOM,HL7 v2, CDA, FHIR,v3 是主要的标准,在临床术语方面 ICD9/10/11, SNOMED 和Lionc是目前国际上各个国家和地区最主流的医疗数据标准。供大家参考。

相关阅读

0 0
0 108
文章
· 一月 17 阅读大约需 3 分钟
ZPM 简单实现实战宝典

ZPM 设计用于与 InterSystems IRIS 数据平台的应用程序和模块一起使用。 它由两个组件组成:ZPN 客户端(用于管理模块的 CLI)和注册表(模块和元信息的数据库)。 我们可以使用 ZPM 来搜索、安装、升级、移除和发布模块。 使用 ZPM,可以安装 ObjectScript 类、前端应用程序、互操作性生产环境、IRIS BI 解决方案、IRIS 数据集或任何文件,例如嵌入式 Python wheel。

今天的这份实战宝典将分为 3 个部分:

  1. 安装 ZPM
  2. 生成模块
  3. 在注册表中查找、安装、发布模块
1 0
0 108
文章
· 十一月 16 阅读大约需 17 分钟
浅谈一下个人基于IRIS后端业务开发框架的理解

浅谈一下个人基于IRIS后端业务开发框架的理解

现状

由于国内使用基于M语言IRIS平台几乎都在医疗行业。医疗系统又非常的庞大和复杂。前期由于快速占领市场,系统数量越来越多,到了临界点后就产生了质变,所以前期基于功能的线性开发注重效率,所以导致大量的产品业务代码有如下集中情况:
- 系统交互乱如麻,各系统的交互关系变成了网状。
- 系统规模庞大,内部耦合严重,牵一发而动全身,后续修改和扩展困难,开发效率低。
- 关键功能逻辑复杂,容易出现问题,出现问题后很难排查和修复,开发成本高。
- 功能越来越多,导致系统复杂度指数级上升。

- 重复造轮子,相似的功能不断重复开发。

image

如上图所示,这仅仅是展示了五个模块之前的交互,在此基础上继续增加模块则复杂度成指数级上升,并且如果每个模块之间如果没有做好接口管理,维护起来也是地狱级别。

8 1
0 82
文章
· 十月 9 阅读大约需 4 分钟
FHIR与微服务架构

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

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

2 0
0 100