关于段落之间的衔接，也就是各业务流之间的交互，两个业务流之间至少要有一对交互点，即一个业务流中附加了另一个业务流中的一个活动，对这个业务流来说这个附加的活动就是一个出口点，对另一个业务流来说这个本来的活动就是一个入口点。

各个业务流本身是相对稳定的，多变的是业务流之间的交互。

RIM所包含的4个状态图（实体、角色、参与、活动）就是单个业务流的抽象表达。

看医生就要交钱，看医生是一个业务流，以病人为中心，交钱是一个业务流，以收费为中心，病人的入出转不会有太多变化，收费退费也不会有太多变化，但是看病什么时候交钱就会有很多变化，预约时交？挂号时交？就诊时交？就诊后交？一次性交？分批交？批量交？

应用系统要适应这些变化就有多种方式，固定一种交互，如产品模式和定制模式；修改代码，如二次开发模式；预先准备多个版本，如构件模式；修改参数或模型，如参数配置模式和模型驱动模式。

关于这六种模式：管理软件的生产模式大致可以分为三个阶段六种模式，标准产品模式和完全项目模式为第一代，二次开发模式和参数配置模式为第二代，构件装配模式和模型驱动模式为第三代。

目前的管理软件生产模式以第二代为主，但已经开始逐步向第三代演化了。

原文出在http://xjcxp.mblogger.cn/，这是一个个人网志，虽然都是些只言片语，但很有些有价值的东西。

回到标准上来，如果能够搞出一个《医院信息系统流程规范》，按照各个业务流分章节，定义清楚每个业务流中所包含的活动，该活动所实现的功能，该活动的输入输出所包含的业务对象。

我觉得这是对功能规范的一个发展。

当然这个业务对象的定义是需要跨流程的，这本身也是一件艰巨的工作。

我觉得这是对最小数据集的一个发展。

各个厂商可以测试并声明各自产品所实现的流程活动，这个测试声明也可以由权威或中立机构来作。

各个医院可以按照各个厂商产品所声明的流程活动进行组合，这个组合从理论上可以是流程间的，也可以是流程内的。

当然，上述都是理想化的，实际作起来会有诸多问题。

如果按流程间整合，则医院部门职能是跨流程的，必然出现一项工作要使用多个系统，界面整合就有需求了，看来要用上CCOW了。

如果按流程内整合，则可能是每个活动都要提供外部接口，这样作系统也太累了，不大现实。

如果这些都不算什么，那么以前暂时忘掉的词汇表和技术实现的问题也是无法回避的。

难！难！难！

但是再难，这件事情也是要作的，问题是永远不会自动解决的。

没有标准，各厂商产品很难集成，迫使各老厂商、新厂商、大厂商、小厂商都作大而全的或小而全的，就有了低水平重复。

其实，就算按照理想化的来作，虽然对于系统集成的最终目标实现不了，但对于业务模型的共享至少是可以实现的。

按照MDA的4层模型，不是M3到M0，那是另外一个维度的： CIM计算无关模型 PIM平台无关模型 PSM平台相关模型最底层是系统实现（这个我记不清楚了，有兴趣可以去上面的连接查原文，我没见过OMG的原文）

所以我认为流程规范＋业务对象＋词汇表，虽然并不能够真正实现系统集成，但已经作到了平台无关模型，可以对各厂商的需求分析提供极大的帮助，对于医院的业务流程管理也具有一定的指导意义。