企业官网建设流程全解析

简介：面向医疗信息化开发者的HIS系统Caché数据库开发文档合集，覆盖数据库安装配置、多维数据建模、MUMPS编程、API接口调用、高可用集群与安全管控等核心主题，适合需要从零搭建或优化Caché版HIS系统的工程师，也可作为医疗IT运维人员排查问题的参考。压缩包共145个文件，以143个PDF为主，另含1个HTML入口页和1张系统示意图，总大小约77.18MB，PDF按主题拆分为基础教程、设计指南、开发者手册、接口参考及报表分析等模块，目录结构清晰，便于按需查阅。截至目前已有1031人学习使用。通过这套文档可系统掌握Caché的高性能存储模型与集成开发环境，并借鉴医疗业务场景下的高可用部署和灾备策略；资源内还包含实际示例代码与报表分析说明，能帮助开发者在项目中快速定位问题、优化系统性能。

1. 医疗HIS系统为什么把Caché当成自己的“存储底板”

很多做惯了关系型数据库的开发者在第一次接手医疗HIS系统时，都会经历一段困惑期：需求文档里写着“患者表”“医嘱表”，打开Caché的终端却只看到一堆^号开头的数组名字；SQL确实能查，但真正的高频交易根本不走SQL。这种割裂感不是错觉——Caché是一种以多维数组为存储核心的后关系型数据库，医疗HIS系统选它当存储底板，核心原因就一条：患者主索引、挂号号源、医嘱、收费记录这些数据天然带层级关系，用全局变量（Global）的下标空间来组织，读写路径短、事务锁可控，扛得住门诊早高峰那种密集读写。

这篇文章按“数据模型 → 业务代码 → SQL集成 → 踩坑 → 诊断”的顺序来写，适合正要参与某区域医院HIS系统开发或维护的工程师，也适合做技术选型时想拿Caché和关系库放在同一把尺子上比较的人。不保证覆盖所有运维场景，但你接手后最先撞上的几件事，基本都在这里了。

2. 读懂Caché的数据模型：全局变量与HIS表结构设计

2.1 先忘掉“表”这个词：全局变量才是Caché的存储底层

Caché里最重要的存储单位是全局变量，语法上像带^前缀的多维数组。例如^Patient(1001)="张三^男^1980-01-01"表示主索引1001的患者记录，^Patient(1001,"ORD",1)表示该患者的第一条医嘱。下标可以是整数、字符串甚至空串，每个节点存一段字符串，字段之间习惯用^分隔。这和“数据行+索引文件”的关系库模型完全不同：全局变量的下标本身就是索引，取^Patient(1001)是直接定位目标节点，不需要先走主键索引再回表。

HIS系统里大量业务数据天然具有“一个患者带多次就诊、一次就诊带多条医嘱”的层级结构。关系库要满足第三范式，得把数据拆成患者表、就诊表、医嘱表，查询时靠join拼回来；Caché把这层关系直接写在下标层级里：^Patient(1001,"VISIT",1)和^Patient(1001,"VISIT",2)在物理上相邻，$ORDER(^Patient(1001,"VISIT",0))原地拿到下一个就诊序号。存储局部性好，读一串相邻记录几乎不产生磁盘随机IO。

提示：整库的全局变量就是一个巨大的命名空间，开发时千万别随手KILL ^某变量。实在要清理，先在Management Portal里看这个节点是不是业务数据，再做备份。

2.2 一个门诊号表的全局变量设计：下标、子节点与$i自增

以门诊号源为例，我一般会在某个命名空间下先开终端徒手验证结构，确认后再写进正式类。终端里的操作长这样：

ZN "HISDB" KILL ^REG SET ^REG("QUEUE",1)="1001^内科^64180^可挂" SET ^REG("QUEUE",2)="1002^外科^64180^可挂" SET ^REG("COUNT")=2 WRITE ^REG("QUEUE",1)

逻辑说明：^REG("QUEUE",序号)是号源主节点，4个字段依次是患者号、科室、日期（用$h的天数段表示）、状态。^REG("COUNT")只是辅助计数，可留可删。这里故意不用自增号，是想说明“号源序号”这种业务号最适合在挂出前由窗口程序分配好，而不是靠数据库自增。

更常用的流水号生成方式是靠$i，在Caché里它专门干“无锁自增”这件事：

SET seq=$i(^REG("SEQ")) SET ^REG("QUEUE",seq)="1005^儿科^64180^可挂"

$i(^REG("SEQ"))先返回当前值再自增，多个进程同时调用也不会拿到重复序号，适合给就诊流水、医嘱序号这类无业务含义的编号做生成器。注意：号源状态从“可挂”变“已挂出”必须用锁或事务保护，否则两个窗口可能同时挂同一个专家号——这个场景在第3章的类方法里一起处理。

退号不建议直接KILL节点，而是把状态改成“已退”。原因很简单：卫生统计要算爽约率、退号率，留存轨迹比省那点存储重要得多。这也是HIS数据习惯和普通业务系统差异最明显的地方。

2.3 持久类与SQL表：对象里写的属性去哪了

开发时你很少直接操作字符串型的全局变量，Caché的常规姿势是写一个持久类，自动映射成“对象 + SQL表 + 全局变量”三个视角。看下面这个最小类：

Class HIS.Visit Extends %Persistent { Property RegNo As %Integer; Property PatientNo As %String; Property Dept As %String; Property RegDate As %Date; Property Status As %String; Index RegNoIdx On RegNo; }

逻辑说明：类保存后生成Storage定义，默认数据全局变量名为^HIS.VisitD，索引全局变量为^HIS.VisitI，SQL表名默认是HIS.Visit。每个Property成为一行里的一列，Index语句生成对应该属性的索引。之后在Management Portal的SQL页面里执行SELECT * FROM HIS.Visit能查到数据，在ObjectScript里也能直接##class(HIS.Visit).%New()建对象。

参数说明：RegNo如果是业务号且需要频繁查询，单独加索引；RegDate如果报表经常按日期范围统计，也值得加索引。Caché对这层映射的底层实现是——对象方法改写全局变量，SQL引擎读同一个全局变量，两边没有数据同步问题，这是它和“用关系库存业务数据再做一层对象封装”的本质区别。

2.4 对比一下传统关系库：Caché在这套业务里的取舍

Caché的存在不是要取代关系库，而是在HIS这个“少量高频、结构层次明显、7×24不能停机”的场景下更顺手。到报表分析和数据挖掘层面，不少实际项目还是会把数据同步到关系库或数仓去跑，Caché负责生产交易，数仓负责分析，两边的边界要心里有数。选型摇摆的时候，回到业务最疼的读写模式上做决定，比迷信任何一方的宣传语都靠谱。

3. 用ObjectScript写HIS业务：从挂号到发药单的最小代码

3.1 写业务代码的两种入口：终端临时调试与类方法落库

ObjectScript是Caché内置的编程语言，长得很像带标号的BASIC，但它真正有个性的是和全局变量、SQL的无缝混写。开发时习惯做法是先在Terminal里敲几行验证全局变量设计，确认下标和数据格式没问题，再把逻辑搬进Studio里的类方法。终端适合验证数据存取，类方法适合被其他业务模块和Web服务调用。

很多人刚上手时会犯一个毛病：把大段业务逻辑直接写在终端或MAC例程里。例程（Routine）在维护时会让你陷入“这段代码到底被谁引用”的泥潭，而类方法有清晰的入参、出参和状态返回，报错时能顺着调用栈定位。我的习惯是：一切会被多个窗口调用的业务动作——挂号、收费、退号、发药——都写成类方法，终端只用来查数据和做临时修复。

3.2 门诊挂号的类方法：占号、记录患者、扣号源一把梭

下面是一个去掉非核心校验的挂号方法，同时写入号源状态和患者就诊子节点：

ClassMethod Register(regNo As %Integer, patientNo As %String, dept As %String) As %Status { set ok = $$$OK set nowH = $h TSTART try { // 1. 检查号源是否存在 if $data(^REG("QUEUE", regNo)) = 0 { set ok = $$$ERROR($$$GeneralError, "号源不存在: "_regNo) quit } // 2. 检查号源是否已被挂出 set status = $piece(^REG("QUEUE", regNo), "^", 4) if status = "已挂出" { set ok = $$$ERROR($$$GeneralError, "号源已挂出") quit } // 3. 更新号源状态，写入患者就诊记录 set ^REG("QUEUE", regNo) = patientNo_"^"_dept_"^"_$piece(nowH, ",")_"^已挂出" set ^PATIENT(patientNo, "VISIT", $i(^PATIENT(patientNo, "SEQ"))) = regNo_"^"_dept_"^"_nowH TCOMMIT } catch e { if $TLEVEL > 0 TROLLBACK set ok = e.AsStatus() } quit ok }

逻辑说明：这段代码先做号源存在性和唯一性校验，再执行两次写入，事务包住整个写入区间。$data返回0表示节点不存在；$piece(串, "^", 4)取出第4个字段判断状态；$i自动生成该患者的下一个就诊序号，不需要提前查询“当前有几条就诊记录”。TSTART到TCOMMIT之间任何一行抛异常，都会进入catch块并回滚。

参数说明：regNo是号源序号，patientNo是患者主索引，dept是科室代码。方法返回%Status对象，调用方拿到后用$SYSTEM.Status.DisplayError(st)打印具体错误。注意nowH是Caché的$h格式，逗号前的整数是从一个固定基准日算起的天数，存进节点时如果直接展示给最终用户，需要先用$ZDATE转换。

3.3 事务嵌套别乱写：$TLEVEL会骗人

Caché事务支持嵌套，但很多开发者在嵌套上吃过亏：内层TCOMMIT并不会真正提交，只有最外层的提交才落盘；一旦内层逻辑判断出错想只回滚自己这部分，发现TROLLBACK把整个事务全回滚了。

我一般会避免嵌套TSTART，改成调用前判断事务层级：

set inTx = 0 if $TLEVEL = 0 { TSTART set inTx = 1 } // 业务写入... if inTx { TCOMMIT }

逻辑说明：$TLEVEL返回当前事务嵌套深度。进入方法时如果已经是0，说明没有外层事务，由本方法开启并提交；如果不是0，说明调用方已经开了事务，本方法只负责写入，提交与否交给调用方。这才是事务边界的正确切法——把“是否开事务”的决定权交给最外层业务入口。

参数说明：这个方法里没有硬编码提交点，适合被其他事务方法当作内部步骤调用。如果你写的方法永远是被窗口程序直接调用的，那就坚持用3.2里那种带try/catch的显式事务写法，不要混用。

3.4 错误处理别自作聪明：%Status比错误串更靠谱

ObjectScript里有个经典习惯：方法返回%Status而不是返回错误字符串。原因很简单，字符串没法结构化传参，也没法被调用方程序化判断。

set st = ##class(HIS.Visit).Register(501, "1002", "外科") if $$$ISERR(st) { do $SYSTEM.Status.DisplayError(st) }

$$$ISERR(st)是宏，判断状态是否为错误；显示错误后可以决定是抛给上层还是记录日志后继续。对HIS这种系统，窗口程序拿到错误后通常会弹提示并要求重试，而发药机这类自动化接口拿到错误则可能触发告警。用统一的%Status封装，业务方就能按自己的场景决定处理方式，而不是解析一段带颜色的控制台文本。

4. 从SQL窗口进Caché：HIS报表与第三方集成的正经路径

4.1 持久类怎么变成一张可查询的表：包名即Schema

Caché的SQL不是独立数据库，而是建立在全局变量之上的一个映射层。对于第2章的HIS.Visit类，默认映射规则是：包名HIS成为Schema名，类名Visit成为表名，SQL里写HIS.Visit；每个Property成为列，属性类型映射到SQL类型，%String映射为VARCHAR、%Integer映射为INTEGER、%Date映射为DATE。

这个映射也意味着：三个入口改的是同一份数据。窗口程序用ObjectScript方法挂完号，报表平台立刻能通过SQL查到这条记录，不需要ETL。很多人刚接触时会疑惑“为什么我在SQL里插入一条数据，用对象方法查不到”，实际上Caché会在对象访问时自动更新映射，不会出现两边数据不同步的反常现象。需要注意的反而是索引名的映射规则，Index RegNoIdx On RegNo映射到SQL里通常是RegNoIdx，写查询时用不上，但建表时它已经生效了。

4.2 嵌入式SQL：在ObjectScript里直接用&sql()

业务代码里经常需要按条件查一条数据再决定后续动作，不需要每次都用对象方法。嵌入式SQL是Caché的独特写法：

ClassMethod FindPatientByRegNo(regNo As %Integer) As %String { set patientNo = "" &sql(SELECT PatientNo INTO :patientNo FROM HIS.Visit WHERE RegNo = :regNo) if SQLCODE < 0 { do $SYSTEM.Status.DisplayError(%msg) quit "" } quit patientNo }

逻辑说明：&sql(...)在编译时被转换成查询代码，INTO :patientNo把查询结果写入变量；WHERE RegNo = :regNo里的:regNo是引用方法入参。执行完检查SQLCODE：0表示查到数据，100表示没有记录，负数表示SQL执行出错。注意%msg只在出错时有内容，成功时不用管。

参数说明：变量名区分大小写，:patientNo和:PatientNo是两个不同变量；嵌入式SQL适合单条查询和固定模板，动态拼接条件时别用字符串拼SQL，改用%SQL.Statement的动态SQL，既安全又不容易踩性能坑。

4.3 外部报表平台怎么接：ODBC/JDBC的最小连接配置

HIS系统几乎不可能孤立运行，检验系统、体检系统、上级数据平台都要来取数。最常见的对接方式是ODBC/JDBC。

配置步骤大致如下：

• 在Caché端创建独立账号，权限只授权给需要的Schema和表，别用超级用户给第三方。
• 客户端配置ODBC DSN，指向Caché服务器的地址、端口和命名空间。
• 报表端（如某报表工具或定制平台）通过DSN连接，SQL按照标准写法来，不要用ObjectScript专属函数。

import pyodbc conn = pyodbc.connect("DSN=HIS_CACHE;UID=report_user;PWD=report_pass") cur = conn.cursor() cur.execute( "SELECT RegNo, PatientNo, Dept FROM HIS.Visit WHERE RegDate = ?", ("2024-01-01",) ) for row in cur.fetchall(): print(row)

逻辑说明：?是参数占位符，日期作为参数传入，避免SQL注入，也避免不同客户端日期格式差异。Caché的ODBC驱动会把标准日期字符串转成内部日期格式，这比自己在SQL里拼字符串可靠得多。

参数说明：UID和PWD是第1步创建的独立账号；DSN名称要和客户端配置一致。连不上的时候先检查命名空间是否写对，再查账号权限，最后才是网络和端口——按这个顺序排查能省不少时间。

4.4 Caché的SQL性能边界：哪些写法在HIS报表里容易跑偏

Caché的SQL引擎不是全能的，HIS报表场景里常见的低效写法有三个。第一，SELECT *拉全字段，明明只要患者号和科室，却把整行所有属性都取出来；第二，在WHERE里对索引列做函数运算，例如WHERE UPPER(Status)='已挂出'，索引直接失效变成全表扫描；第三，非要用全局变量方式在SQL里拼接字段，比如SELECT $PIECE(列, '^', 2)——这等于逼SQL引擎去做字符串切片，一点好处都没有。

报表查询的正确思路是：能用索引列做等值或范围判断的，永远直接判断；需要复杂统计的，把数据同步到外部数仓再做；Caché的SQL引擎强在等值定位和按索引范围扫描，弱在模糊匹配和多表大join。认清这两头，你的报表接口就不会三天两头因为慢查询被业务方吐槽。

5. 开发中最常见的5个Caché翻车点与排查手册

5.1 现象：$ORDER遍历顺序乱套，“02”排到了“11”后面

某次查药房库存，按药品编码遍历^DRUG("STORE",编码)，期望是0001、0002、0003这样走，结果排序变成0001、0010、0002。原因：药品编码以字符串形式存进下标，$ORDER按字典序排列，字符串比较时“0010”排在“0002”前面，数字顺序与字典序天然不一致。解决：编码统一补位，位数不同时用$JUSTIFY(编码,4)统一转成等宽字符串，或下标改用纯数字编码由代码映射显示。这个坑在医嘱编码、收费项目编码里很常见，设计全局变量下标前先问一句“这个下标未来会被$ORDER遍历吗”。

5.2 现象：SQL按日期范围查，总是多一天或少一天

报表平台按WHERE RegDate BETWEEN '2024-01-01' AND '2024-01-02'查，结果把1月3日的数据也带出来了。原因：Caché内部日期是$h的天数整数，ODBC传入的日期字符串被转成天数后，BETWEEN右边界是当天0点，但业务写入时RegDate可能带了当天任意时间，某些版本映射下会隐含着当天23:59:59之后再比较。解决：日期范围统一写成WHERE RegDate BETWEEN ? AND ?并分别传当天和次日0点；如果要统计“某一天”，用>= 当日 AND < 次日的写法。血泪经验是：别把$h裸放在SQL里和日期字符串比较，两套格式体系混用是最难排查的玄学问题之一。

5.3 现象：写收费事务时偶发锁超时，报“Lock timeout”

现象是白天窗口高峰期，挂号和收费同时操作同一个患者节点时，某个操作卡几秒后报错。原因：Caché事务内的写入会自动加锁，超时时间用全局配置，两个事务分别持锁后又互相请求对方资源——一个是先写患者再写号源，另一个恰好反过来，形成死锁等待。解决：第一，所有事务内的写入顺序全库统一，比如约定“先号源后患者”，杜绝交叉顺序；第二，把锁等待时长调成一个可接受的业务值，宁可快速失败让窗口操作员重试，也别让整个界面卡死；第三，事务体保持短小，确认弹窗这类交互绝对不能放在事务中间。

5.4 现象：嵌套事务回滚把外层已提交的部分一起洗掉了

某药师退药操作调了一个“退回库存”的内部方法，该方法自己开了事务写库存，结果后续发药单写入失败，执行TROLLBACK时把库存退回也一起回滚了，账面库存和实物对不上。原因：内部方法没有判断$TLEVEL，盲目TSTART后又盲目TROLLBACK，回滚范围远超预期。解决：按照3.3的方式，所有可能被其他事务调用的方法都先判断$TLEVEL，只在没有外层事务时才自己开事务；回滚也一样，先看层级再决定是否TROLLBACK。教训就一句话：事务的边界不是方法边界，是业务动作的边界。

5.5 现象：批量删除数据后，SQL查询报索引空洞或结果缺漏

维护脚本直接KILL ^HIS.VisitD清表数据，之后按索引查RegNo时结果不对。原因：直接操作数据全局变量没有同步清理索引全局变量^HIS.VisitI，索引里的节点还指向已经不存在的数据，SQL引擎按索引回表时落空。解决：删除数据用schema的类方法或%SQL.Statement的DELETE语句，让Caché自动维护索引；如果确实需要手工清理，删完用Do ##class(%SQL.Statement).%ExecDirect(, "ALTER INDEX RegNoIdx ON HIS.Visit REBUILD")重建索引。记住一个原则：全局变量可以手工改数据节点，但索引节点永远交给引擎去维护，手动KILL索引的后果通常要在高峰时段才会暴露。

这几条算是Caché开发里最容易让新老手一起翻车的区域。排查顺序建议是：先看事务层级和锁，再看日期格式和下标类型，最后才怀疑驱动问题——九成故障都出在前两环。

6. 进阶：慢查询定位与全局变量诊断的三个日常习惯

6.1 用$ORDER按需遍历，而不是把整个数组拉进内存

$ORDER(^变量(下标))每次只返回下一个已存在的下标，配合循环可以一路走完整个层级。习惯好的人查大全局变量时，会从根节点一级级$ORDER下去，而不是先WRITE整棵global再过滤。前者走的是数据库内部的顺序访问，后者可能瞬间拉开巨大内存开销。养成“按需取节点、用$ORDER指导循环”的写法，HIS系统跑监控脚本时才不会把生产库拖垮。

6.2 SQL慢查询别靠猜：看Statement计划与缓存查询

Caché的Management Portal里能看到SQL Statement的查询计划，它会展示某个查询是走索引还是全表扫描，以及扫描了多少行。遇到报表慢，先在那里确认是否命中索引，而不是反复改SQL语序。另外Caché对相同文本的SQL有缓存查询机制，参数值不同但SQL文本一致时能复用计划；反过来，业务代码里用字符串拼SQL，每个不同模板都生成新查询计划，缓存失效到崩溃也就是几天的事。所以动态SQL一律用?参数，既安全又保住缓存的复用。

6.3 把归档做进下标设计里，别等文件膨胀再救火

老HIS系统最怕的不是慢，是数据涨到备份和恢复都变得难以控制。设计全局变量时就把时间维放进下标，例如^VISIT("ARCHIVE",年份,日期,患者号)，归档脚本直接按年份切分节点，归档时搬走整棵子树，比在行级数据上做DELETE再迁移轻松得多。这也是我吃过大亏后的固定习惯：每次新建一个大的全局变量，第一件事就是问“三年后这里的数据怎么挪走”。

我自己在这个方向上的教训是：接手HIS开发后第一周，别急着写业务接口，先用半天把库里的全局变量结构逛一遍，把^字号和它们对应的业务实体记进文档。数据模型没摸清就敢动手改业务代码，等来的大概率是某个统计报表在月初结算时突然对不上账。希望这个方向对正在做HIS系统选型或接手Caché开发的朋友有帮助。

本文还有配套的精品资源，点击获取