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

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

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

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

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

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

• 首先，模型尺寸巨大，尤其是它的参数数量。例如GPT3有1750亿的参数；
• 其次，大语言模型是在巨大的算力基础上，基于海量语料进行训练的。例如Meta的Llama 2 的训练数据达到了两万亿个词(token);
• 再次，大语言模型是为解决通用问题，而非特定问题构建的。

1.2 大语言模型是怎么训练的？

大语言模型是事先训练好的模型。

训练时，大语言模型基于各种语料 - 人类知识库（例如Wikipedia）、公共数据集、网络爬虫数据，让模型进行“填空”练习，并经过人工编辑和“校对” 训练出来的，需要成千上万的GPU建立集群进行训练。根据Meta的信息，其Llama 2 的训练数据达到了两万亿个token，上下文长度为4096，对话上也是使用100万人类标记的数据微调。

运行时，训练产生的大语言模型可以在小的多的硬件上运行。

1.3 大语言模型的机器学习算法

冰冻三尺,非一日之寒;滴水穿石,非一日之功。生成式大语言模型能够落地经历了相当漫长的技术积累与进步。

IRIS 2024.1已经发布，它引入了诸多新特性，其中之一是JSON_TABLE。

数据表达和交换中，JSON已经是日益主流的存在。在之前的IRIS版本中，可以轻易将JSON数据以对象解析并保存到IRIS，也可以将IRIS数据使用SQL、对象等多种方式输出为JSON。对于得到的JSON序列化的数据，如果我们想通过SQL去解析，甚至进行检索和查询，就可以利用JSON_TABLE这个新特性。

对于一些大规模的JSON序列化数据，例如从FHIR服务器查询获得的FHIR资源Bundle，里面包含了大量数据。例如下面的FHIR查询结果，后面的示例以这个的复杂的JSON作为用例：

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也是以这些技术选项为基础的。

TCP作为OSI 7层的传输层的通信协议，其使用上不像更上层的通信协议那么方便，因为TCP操作的不是数据包，它操作的是数据流。因此有多种将TCP数据流“解释”为数据包（消息）的方法。

InterSystems IRIS提供了多种TCP适配器，用于不同的“解释”，例如EnsLib.TCP.FramedInboundAdapter使用特定的首尾字符做为分隔、EnsLib.TCP.CountedInboundAdapter使用固定的长度进行分隔...

同时，InterSystems IRIS提供了多种开箱即用的TCP业务服务和业务操作，方便接入和发送TCP数据。这里我们介绍常见的使用特定的首尾字符做为分隔的TCP业务服务和业务操作。

1. 通用TCP业务服务和业务操作

EnsLib.TCP.Framed.PassthroughService和EnsLib.TCP.Framed.PassthroughOperation是一组使用特定的首尾字符做为分隔TCP数据流的通用业务服务和业务操作。EnsLib.TCP.Framed.PassthroughService业务服务会将TCP数据封装在Ens.StreamContainer发送给业务流程或业务操作；而EnsLib.TCP.Framed.PassthroughOperation业务操作发送并接收Ens.StreamContainer类型的数据。

1. 通用RESTful业务服务和业务操作

InterSystems IRIS 提供了一组通用的RESTful 业务服务和业务操作类，用户无需开发自定义的业务服务和业务操作类，就可以直接向外提供RESTful服务和调用外部的RESTful API。

2. 通用RESTful 消息

通用的RESTful 业务服务和业务操作类使用一个通用的RESTful消息类 - EnsLib.REST.GenericMessage，它是EnsLib.HTTP.GenericMessage的子类，二者数据结构都是

CDS Hooks是FHIR生态下一个决策支持架构，是SMART(Substitutable Medical Applications and Reusable Technologies, 可替代的医学应用和可复用技术)下的一个项目。

FHIR标准下也有一个决策支持相关的模块 - FHIR的Clinical Reasoning模块。它和CDS Hooks是有区别的：

FHIR的Clinical Reasoning模块提供一系列资源模型和工件，用于构建决策支持相关的规则、医嘱集、临床协议和质量指标，并基于此对特定患者和人群进行评估，进而产生决策行为。它构建的是本地决策支持体系。

而CDS Hooks提供一个决策支持架构，打通外部决策支持系统和本地的决策数据源、业务流程。

CDS Hooks是开源的，基于知识共享 CC BY 4.0，因此也获得了广泛采纳。

CDS Hooks的架构

CDS Hooks是打通外部决策支持系统和客户端应用的决策支持架构，完整的架构包括：

CDS客户端：通常是用户的业务系统，如HIS或电子病历

CDS服务：这是CDS Hooks提供的核心组件，向客户端发布的决策支持服务

FHIR服务器：这是用户侧的FHIR服务器，保存的是用户侧的FHIR资源数据。CDS服务通过访问FHIR服务器获得用户侧的决策依据的完整数据

FHIR标准提供灵活的扩展与再约束机制 - Profile。到底Profile机制如何工作？什么样的扩展需要用到Profile？怎么建立Profile？

FHIR核心资源模型  - FHIR Core

FHIR发布的资源模型是按80/20原则设计的 - 最常用那80%的用例中需要的数据会被涵盖在FHIR核心资源模型中，这些数据需求可能只是所有用例需要数据的20%；通过对核心资源的扩展和再约束，可以让它们适用于不常见的20%用例和未被涵盖的80%的数据需求。

FHIR发布的资源模型是FHIR核心资源模型(FHIR Core)，它们有如下特点：

1. 对象模型 - 有继承关系。所有资源都继承自DomainResource

2. 为了保证最大的适用度，资源中的绝大多数属性的最小基数都是0，意味着它们都可以为空

3. 资源的属性可以通过code(值集）、coding、CodeableConcept（术语）进行取值范围约束

4. 为了防止医疗错误，所有的属性都没有且不能有默认值

当需要对核心资源模型进行扩展和再约束时，FHIR提供了profile机制对所做的扩展和再约束进行画像（描述），这就是profile的意思。

这里把对FHIR资源模型的用户自定义扩展区分为“扩展”和“再约束”，差异是：

• 扩展指需要要增加新的资源属性
• 再约束指修改核心资源模型的属性的基数、值集绑定、必须支持、切片等

2023年6月底，世卫组织(WHO)和HL7签署了合作协议，利用HL7 FHIR提供互操作性，来支撑WHO的SMART指南(SMART Guideline)愿景 - 使用数智化的方式推动并加速一致化的健康干预措施建议，让世界上每个人都能立即从临床、公卫和数据使用建议中充分受益。

作为WHO的《2020-2025 年全球数字卫生战略》的一部分，SMART 指南使用 FHIR 、HL7的临床质量语言 (CQL) 和ICD标准以表达 WHO 的各种健康和临床指南，实现数据互操作、决策支持与指标、术语的一致性。这些标准被进一步利用来为各国及其合作伙伴开发一个由软件库、服务和工具组成的支持生态系统，并作为数字公共产品服务全球卫生健康事业。

为什么世卫组织会采用FHIR作为卫生信息互操作的标准在全球推广其一致化的健康干预措施建议？因为FHIR不仅标准成熟适用，而且还具有一个极具生命力的生态。

一个有生命力的标准会吸引生态的构建，而完善的生态将促进标准的成熟和演进。HL7 FHIR作为新一代的卫生信息互操作标准，其生态已经初具规模并蓬勃发展。

HL7 FHIR的知识产权类型

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

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

• 应用只能运行在其开发的技术体系下，无法跨技术体系复用
• 由于数据模型、术语、行业服务和API标准的缺失及应用范围不足，即便采用相同技术体系的应用和功能也没法为别的用户使用。以患者管理为例，每个业务系统都有患者管理，但没有一个系统将患者管理功能分享给别的业务系统使用，我们不得不在不同的业务系统间集成和同步患者信息
• 而应用一旦不满足需求了，新应用要重新建设所有三层，任何一层都没法复用、原来的数据也随之下线，造成宝贵的数据资产损失

我们的医疗信息化建设的现状就是在不断重复建设不能复用和分享的单体架构应用 - 架构很重、开发周期长、开发成本很高、后期集成难度大、数据被孤岛化、应用效果不佳。

英国国民医疗保健服务（NHS）简介

国民医疗保健服务（NHS）是英国的公共资助的医疗保健系统的总称，覆盖英格兰的、苏格兰和威尔士。它是世界上第二大单一付款人医疗保健系统，针对英国常住居民提供免费的、全面的卫生服务。这些卫生服务不仅是医疗服务，还包含社区护理服务、精神健康、临终关怀等。

NHS是最大的分级诊疗体系：先看全科医生或急诊，再由他们转诊到医院看专科医生、住院或者手术。它管理着9千万患者记录和6千5百万份病历；每天有100万的就诊、200万电子处方和75万电子转诊。

NHS有200万员工，是世界最大的、非军队的单一机构。一直被评为让英国人最自豪的英国机构，击败了皇室、武装部队和英国广播公司。

NHS面临的挑战和应对

作为政府买单的全国性医疗保健系统，提高治疗效果、提升效率、降低费用是NHS始终面临的挑战。

NHS广泛使用InterSystems的TrakCare作为电子病历系统以获得统一的、最新的患者视图；使用HealthShare作为医疗机构间健康信息共享和交换平台，合并和共享患者信息、治疗计划和临终愿望计划，让授权的医护人员查看患者完整、及时的护理记录小结；使用InterSystems IRIS医疗行业版支撑包括基于机器学习的辅助决策的创新应用，例如对阿尔茨海默氏症的早期发现与诊断。NHS还提供全国的电子处方服务 - 直接将电子处方发送到患者选择的药房，和电子转诊服务。

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

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

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

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

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

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

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

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

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

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

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

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

这造成了几个挑战：

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

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

3. 数据平台及数据应用建设依赖单一厂商的能力，而建设成果，包括数据工具、分析指标和应用都无法跨数据平台复用。往往项目都在做低水平重复建设。

面向对象编程的优势

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

为什么使用面向对象编程这么流行？因为它有诸多优势：

• 封装：将数据和操作数据的代码封装在一个单元中，在确定范围的数据上进行编程。方便代码的开发、管理与分享。
• 抽象：将业务数据概括为不同的对象类型，从而进行业务分组开发、简化程序。
• 继承：一个类可以从另一个类继承它属性和行为，从而实现更大范围的代码复用。
• 多态：多个对象可以创建自一个类，且可以有不同的行为。一段灵活的代码能实现多种形态的业务，它进一步降低了代码开发量和调用难度。

而这4个优势正是面向对象编程的核心特征。

关系型数据库的对象/关系错配

虽然面向对象编程是绝对的主流，但数据通常被保存到关系型数据库中。关系型数据库的行和列二维关系与复杂的对象并不匹配：

微服务架构作为一种软件开发架构，这些年越来越热。那微服务应用架构的优缺点有哪些？它是否适合我呢？以及如何做微服务架构应用的集成？

这里我谈谈自己的看法。

1.数据的价值 

数据的核心价值是帮助我们决策。 

我们无时无刻不在决策，大到战略决策——为一家新医院选址，还有战术决策——鉴别产品的目标市场或抵押贷款审批，更频繁的是操作决策——决定患者的手术方案或患者药物的调整。

这些决策要求不同的决策速度，传统的数据中心已经能较好地帮助我们做战略决策、战术决策，甚至一些操作决策。但新的业务需求要求我们的决策速度越来越快，甚至借助机器学习自动为我们做出即时的决策，例如批准还是拒绝一笔信用卡交易或基于算法自动交易。 

无论是人工决策还是基于机器学习的自动决策，决策的依据是数据。数据的速度和质量决定了决策的速度和质量。要支持决策，需要数据具有如下特征： 

（1）完整 ：关联且具有完整上下文； 

（2）干净 ：数据质量没有问题； 

（3）及时 ：在决策点上没有延迟。 

传统数据中心很难在及时性上满足要求。 

2.数据挑战

数字化浪潮下，我们面临更大的数据挑战： 

1. 新的系统SQL业务服务/业务操作

接连SQL数据源和操作SQL数据目标是常见的集成业务场景。使用SQL适配器监控SQL数据源和操作SQL目标库时，我们需要开发自定义BS或BO，写不少代码。例如开发自定义SQL服务需要：

1. 开发响应消息类，用于承接SQL快照数据；

2. 开发自定义业务服务BS类，用于将SQL快照按字段赋值给对应的消息，并将消息发送给目标（业务流程或业务操作）。

而要开发自定义SQL操作，更麻烦些：

1. 开发请求和响应消息类，用于向BO传输数据和接收返回数据；

2. 开发自定义业务服务BO类，设置消息响应表，根据不同请求消息类型编写方法；

3. 在方法中根据请求消息数据拼写SQL语句；

4. 在方法中将SQL执行结果存入响应消息。

虽然很简单，但编程过程枯燥乏味。而且当修改SQL语句时，还要修改对应的消息类和BS/BO类。

从2021.2开始，InterSystems IRIS增加了2套系统通用SQL业务服务和SQL业务操作：

在InterSystems IRIS医疗版里有一个文件压缩解压的适配器HS.Util.Zip.Adapter和对应的文件压缩解压业务操作HS.Util.Zip.Operations。集成产品可以使用它们进行文件的压缩和解压操作。这2个类的联机文档说明较少，这里介绍它们的使用方法。

1. 基础配置

InterSystems IRIS使用操作系统的压缩和解压缩能力，因此需要注册操作系统执行压缩解压的命令。

在管理门户的Health标签页下，选中配置注册（Configuration Registry）：

在其中增加2个注册项目：

\ZipUtility\UnZipCommand 和\ZipUtility\ZipCommand，分别代表解压和压缩命令。适配器HS.Util.Zip.Adapter会检查这2个注册项并得到相应的命令。各个操作系统的命令并不一样，示例如下：

\ZipUtility\UnZipCommand 解压缩命令

\ZipUtility\ZipCommand 压缩命令

最近一些用户问到监控集成平台业务行为查询的问题，例如如何查询服务的平均耗时、发生错误的服务数量...

业务行为监控对于集成平台来说非常重要，可以帮助我们：

• 监控系统健康情况 — 查看系统性能表现。例如发现队列积压和长耗时的消息处理，都可能是性能问题的表现。
• 排查异常 — 通过查看业务行为数据，帮助我们判断特定的业务组件配置是否是造成性能瓶颈的主要原因。
• 做业务规划 —  通过业务行为数据，了解各个业务量变化情况，并辅助我们做业务规划。
• 做硬件规划 —  通过长期跟踪消息吞吐量的变化了解性能的变化和业务量的增长，进而辅助我们做硬件计划，避免出现在性能问题。

仅提供这些查询是很容易的，但要更好地监控集成平台的业务行为，需要更深入的了解InterSystems集成架构。

InterSystems集成架构

无论Ensemble、Health Connect还是InterSystems IRIS，它们都具有下面的集成架构：

通过业务服务向外发布服务、通过业务操作连接第三方接口、通过业务流程协同业务操作，它们统称为集成业务组件。可以简单理解为业务行为是由这些业务组件完成的：

• 业务服务 = 服务，它启动一个业务流程；
• 业务操作 = 接口，它通过接口操作第三方业务系统；
• 业务流程 = 流程，它控制一笔业务需要按什么流程调用哪些接口。

要监控业务行为，服务、接口和流程都需要监控。

        关注FHIR的大侠们估计都注意到了，FHIR更新了它支持的互操作范式，除了消息、文档、服务、API这4种，增加了2个：资源仓库、订阅。前面4个好理解，为什么资源仓库和订阅会成为FHIR的新的互操作范式？互操作与应用集成是什么关系？

        这里借FHIR的新互操作范式，聊聊应用集成，看看集成平台是什么？有什么样的集成方案？以及怎么评价不同的方案。

任何技术总是有些自己独特的术语，尤其是一些英文术语，对于新的用户来说往往即陌生又迷惑。这里整理了一下常听到的InterSystems术语，帮助大家尽快进入InterSystems技术圈子。

什么是智慧医院？

国家卫健委提出建设智慧医院的目的是要不断增强人民群众的获得感，要求医院的流程更便捷、服务更高效、管理更精细，主要聚焦于三大领域，面向医务人员的智慧医疗、面向患者的智慧服务以及面向管理的智慧管理。

如果从技术角度进行高度抽象，我们把智慧医院的本质浓缩为一点，就是为智慧的科学决策以及基于科学决策的业务执行闭环。在现实世界里，我们要从真实业务（调查研究）中获得决策依据，同时还要有决策的方法，把决策应用在现实世界上，来影响和改变现实世界。

第一个时代是人工决策时代。我们医疗行业就是望闻问切，我们能拿到的数据非常有限，所以属于一个数据饥渴的时代。我们通过有限的数据来进行决策，非常容易落入我们经常批判的“三拍”型决策，“拍脑袋决策、拍胸脯保证、拍屁股走人”。显然这个决策效率不是很高。

人工决策时代：“数据稀缺”时代的决策

第二个时代是信息化时代。我们有了很多数据，能够把部分现实世界来进行数字化表达，我们也通过信息辅助人工决策进行智能决策，例如通过药品知识库推动合理用药，通过人工智辅助影像判断等等。

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

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

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

InterSystems规则引擎可以帮助我们解决这些问题，于构建、执行和记录消息路由规则和普通的业务规则，带给应用和集成方案充分的灵活性和可用性。甚至业务专家和临床信息学家都可以通过低代码的、图形化的规则编辑器修改规则和指定规则生效和失效时间。

InterSystems规则引擎是InterSystems IRIS数据平台和Health Connect与Ensemble集成平台的组件。创建的规则可以被单独调用，也可以被业务流程调用。

本篇介绍规则的如何使用InterSystems规则编辑器创建规则和规则引擎执行规则的逻辑。

1. 规则基本概念

    在设计规则前，先了解一下规则的基本概念。

1.1 上下文

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

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

使用InterSystems工作流程引擎    3

场景描述    3

环境配置与测试    5

任务管理    15

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

展望    17

15

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

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

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

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

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

8. 应用安全

InterSystems数据平台上可能运行着多种应用，例如Web网页应用、SOAP服务、REST API、HL7 接口、SQL服务等等。这些应用种类繁多，面临的安全风险也是巨大的，例如代码注入攻击和HTTP的跨站请求伪造攻击等。

这其中代码注入攻击和针对Web应用的攻击尤其需要重视。

8.1 代码注入攻击

代码注入攻击通常和我们编写的程序相关，需要在程序编写时注意避免。

8.1.1 SQL注入攻击

SQL注入攻击是典型的代码注入攻击，通过从外部注入恶意SQL语句获得数据权限并获得敏感数据。关系型访问方式都是通过客户端SQL语句传入执行的，因此它是数据库重点需要防范的。

InterSystems数据平台并不支持以分号分割的多条SQL语句作为一个SQL命令执行，因此它本身免疫了主要的SQL注入攻击手段。

InterSystems数据平台支持动态SQL，即允许SQL命令作为方法的字符串参数传入，这会给SQL注入攻击留有隐患。在编程时，应避免开放服务用于接受完整的SQL语句作为参数，而是通过SQL动态传参来构建运行时SQL。

InterSystems数据平台支持行级安全，这有助于避免在SQL注入攻击时，将所有数据返回给攻击请求。

8.1.2 $ZF

6. 用户与角色

InterSystems 数据平台对用户和角色提供全面的管理和安全配置功能。加强数据平台的安全，需要加强对于用户和角色的管理。

6.1 用户管理

系统提供了一系列预置的用户账户，这些账户管理对应特殊的系统功能：

6.1.1 系统级用户安全配置

InterSystems数据平台有一些系统级别的用户安全配置，例如密码模式、密码有效天数、无效登录限制（多少次登录失败后要禁用用户账户）、非活动限制（多少天未登录后禁用用户账户）等。这些系统级配置通过管理门户>系统>安全管理>系统范围的安全参数：

三级等保对于用户的密码强度是有要求的。弱密码只需要0.19毫秒就能被破解，而8位强密码破解需要上百年。密码强度可以通过上面配置页面的密码模式或密码验证routine来配置：

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

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

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

注：本文提到的InterSystems的数据平台，包括Caché数据库、Ensemble集成平台、HealthConnect医疗版集成平台和InterSystems IRIS数据平台。

三级等保的要求

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输出。

在InterSystems IRIS和InterSystems Caché 里，是否您遇到过执行一个SQL Insert/Update语句，明明给的是正确的日期值，但被告知“值‘2022-01-01’ 校验失败”的类似情况，并感到困惑？

如果有，那么您需要了解一下InterSystems IRIS和InterSystems Caché保存和显示数据的模式。

一 数据模式

InterSystems IRIS和InterSystems Caché里，数据有3种模式，称之为SELECT MODE：
逻辑模式：这是数据被保存到InterSystems IRIS和InterSystems Cache'时的格式。例如，%Date类型的数据，在数据库里被保存为一个整数，即从1840年12月31号到这个日期的天数，而不是YYYY-MM-DD的格式。

ODBC模式：这是ODBC对数据定义的格式。在这个模式下，%Date类型的数据就会显示为YYYY-MM-DD的格式。

显示模式：这是数据在InterSystems IRIS和InterSystems Caché里默认的显示格式。例如在美国语言环境下，%Date的默认显示格式是DD/MM/YYYY格式。

InterSystems IRIS和InterSystems Caché只会使用逻辑模式保存数据，但可以以任何模式显示数据。

二 数据类型与数据模式

各种技术在交换数据的时候，就需要知道对方给的数据使用什么字符集和字符编码，否则很可能就解码错了。这里列举了医疗行业常见的数据交换技术方式和它们对字符集使用的声明方式。