随着当前网络技术的发展, 各个组织的业务实现与其他外部组织的参与联系越来越紧密, 对业务过程进行建模不仅可以描述各个任务之间的执行顺序和执行关系, 还可以描述任务交互过程中的资源和约束条件. 直接建立业务过程建模将导致跨组织交互活动和私有活动之间的关系紧耦合, 不具备灵活性^[1].

针对以上问题, 文献[1]基于关注点分离原则提出了一种基于Petri网的多视角跨组织业务过程建模方法; 文献[2]中结合Petri网和CCS提出了进程标号迁移系统PLTS, 在支持业务过程协同的形式验证的同时避免单一运用Petri网与进程代数建模业务过程时面临的问题; 文献[3]基于Petri网和pi演算提出了一种多视图建模方法反映跨组织业务过程协同中所表现出来的自治、异步等特性. 但是以上研究都只对业务流程中的活动关系进行描述, 并未对其中涉及到的资源信息和约束条件进行表达; 而且随着组织业务流程复杂程度的不断增加, 基于Petri网的业务建模容易产生活动节点过多, 状态空间爆炸等问题.

多色集合理论作为一种系统理论和信息处理的数学工具, 核心思想是使用标准的数学模型来仿真不同的对象及其元素间的层次结构和复杂关系. 目前多色集合在路线规划^[4], 装配序列规划^[5], 以及资源优化配置^[6]等方面都得到了广泛的应用. 同时, 多色集合在系统建模、复杂层次结构和关系描述、问题的形式化表示以及高效的计算机处理等方面也具有优势^[6]. 冉梅梅等人^[7]基于多色集合和多色图构建了医院异常工作流处理模型; Gao等人^[8]提出了基于多色集合理论的新的工作流动态变化和实例迁移方法, 对频繁的工作流动态变化进行建模和描述; Zhao等人^[9]采用多色集合理论的方法对模型中的对象、行为、约束以及相关关联等信息进行形式化描述, 实现了故障行为模型的形式化描述同时也便于计算机表达和操作. 以上文献对于多色集合的研究表明利用多色集合对组织的业务流程建模不仅能够提高形式化描述的效率, 而且可以清晰地体现出各活动之间的关联和约束关系; 基于多色集合的形式化可以更好地实现流程的推理且易于计算机进行实现.

在现阶段对电子病历进行共享的研究中, 数据的集成和共享往往在跨组织环境中进行, 信息跨越不同的组织边界进行交互. 本文拟提出一个跨组织支持电子病历调度的数据交互平台架构, 该平台作为一个调度中心并不存储电子病历数据, 只记录医院注册、请求、服务、转发、接收、使用电子病历的相关信息, 同时针对平台支持下的电子病历访问模型进行研究. 首先对多色集合和围道矩阵的相关概念进行介绍; 从多个视角分别将跨组织电子病历交互过程中各组织的内部活动和外部活动以及业务过程中涉及到的交互资源提取出来, 根据其业务流程构建围道矩阵描述活动之间的关系; 最后根据组织之间的交互规则构建外部活动—资源交互模型. 该模型具有良好的扩展能力, 同时能够对活动之间的约束关系进行描述.

1 多色集合理论

多色集合^[10]作为传统集合的扩展, 能够对集合整体本身及其组成元素同时涂上不同的“颜色”, 在表达出集合的整体性质的同时体现出集合内各个元素的性质^[7]. 多色集合由以下6个成分组成:

$\begin{gathered} PS = (A,F(a),F(A),[A \times F(a)], [A \times F(A)],[A \times A(F)]) \end{gathered} $

其中, A表示研究对象的集合, F(A)是对象的统一着色, F(a)表示集合中元素的个人颜色.

2 基于多色集合的跨组织建模

跨组织业务过程中, 私有活动作为组织内部流程的内部视角, 描述组织内部进行信息交互时各个活动的依赖关系, 私有活动的进行只与组织内部的资源信息有关, 不参与和其他组织的交互; 交互活动的进行则需要组织之间满足特定的资源交互进行触发. 对交互活动的抽取可以满足在隐藏组织内部的流程关系同时表达组织之间的活动关系.

2.1 基于多色集合的工作流活动之间的关系

定义工作流程图中的活动集合为A, $A = \{ {a_1},{a_2}, $ $ {a_3},\cdots, {a_n} \}$ , 各组织内部活动节点之间执行的顺序关系表示为矩阵 $\left[ {A \times A} \right]$ , 同时该矩阵也可以描述此时组织内部的工作流程, 定义矩阵中的元素如下:

$ \begin{array}{c|ccccc} & a_{1} & a_{2} & \ldots & a_{i} & a_{n} \\ \hline a_{1} & a_{11} & a_{12} & \ldots & a_{1 i} & a_{1 n} \\ a_{2} & a_{21} & a_{22} & \ldots & a_{2 i} & a_{2 n} \\ \vdots & \vdots & \vdots & \ddots & \vdots & \vdots \\ a_{i} & a_{i 1} & a_{i 2} & \ldots & a_{i i} & a_{i n} \\ a_{n} & a_{n 1} & a_{n 2} & \ldots & a_{n i} & a_{n n} \end{array} $

其中,

$ {a}_{ij}=\left\{\begin{array}{l}0,\;活动之间是顺序关系; \\ 1,\;活动之间是与分关系; \\ -1,\;活动之间是或分关系; \\ 2,\;活动之间是与合关系; \\ -2,\;活动之间是或合关系.\end{array}\right.$

2.2 基于多色集合的交互活动定义

将跨组织交互业务过程中两个组织的活动集合分别定义为A和B, 其中, $A = \left\{ {{a_1},{a_2},\cdots,{a_i},{a_{{n}}}} \right\}$ , $B = \{ {b_1}, $ $ {b_2},\cdots,{b_k},{b_{{m}}} \}$ , $\left[ {A \times B} \right]$ 表示两个组织活动之间的关系, 该活动矩阵可能并非是对称矩阵, 活动 ${a_i}$ 可以触发活动 ${b_j}$ 的执行, 但是活动 ${b_j}$ 可能并不能影响活动 ${a_i}$ 的执行.

$ \left[ {A \times B} \right]= \begin{array}{c|ccccc} & b_{1} & b_{2} & \cdots & b_{k} & b_{m} \\ \hline a_{1} & a b_{11} & a b_{12} & \cdots & a b_{1 k} & a b_{1 m} \\ a_{2} & a b_{21} & a b_{22} & \cdots & a b_{2 k} & a b_{2 m} \\ \vdots & \vdots & \vdots & \ddots & \vdots & \vdots \\ a_{i} & a b_{i 1} & a b_{i 2} & \cdots & a b_{i k} & a b_{i m} \\ a_{n} & a b_{n 1} & a b_{n 2} & \cdots & a b_{n k} & a b_{n m} \end{array} $

如果 $a{b_{ij}}$ 的取值不为空, 表示活动 ${a_i}$ 需要与其他组织的活动 ${b_j}$ 进行交互, 执行顺序按照2.1节所述, 此时定义活动 ${a_i}$ 和 ${b_j}$ 为外部交互活动; 如果 $a{b_{ij}}$ 取值为空, 表示两个组织之间的活动 ${a_i}$ 和 ${b_j}$ 的进行互不相干, 两者没有交互关系, 此时定义活动 ${a_i}$ 和 ${b_j}$ 为各组织的内部活动. 根据矩阵 $\left[ {A \times B} \right]$ 可以分别得到两个组织的对外交互活动集合 ${A_O}$ 和 ${B_O}$ .

2.3 基于多色集合集合的外部交互资源定义

由于资源的交互需要各组织中的活动进行交互来传递, 将跨组织业务交互过程中的资源信息定义为集合 $M$ , $M = \left\{ {{{{m}}_1},{{{m}}_2},\cdots,{m_j},{m_m}} \right\}$ . 业务过程中的资源信息分为组织之间交互资源 ${M_O}$ 和组织内部资源 ${M_I}$ , 资源 $m$ 分割为 $ < {m_O},{m_I} > $ . 定义交互活动和资源之间的矩阵为 $\left[ { < {A_O} \times {A_O} > \times M} \right]$ .

如果 ${d_{ij}} = 1$ , 表示资源 ${m_j}$ 为各组织之间的外部交互资源, 两组织交互时活动的进行需要对资源进行传输来触发; 如果 ${d_{ij}} = 0$ , 表示资源 ${m_j}$ 为各组织内部资源.

$ \begin{split} & \left[ { < {A_O} \times {B_O} > \times M} \right] = \\ & \begin{array}{c|ccccc} {}& {{m_1}}&{{m_2}}& \cdots &{{m_p}}&{{m_m}} \\ \hline { < {a_1},{b_1} > }& {{d_{11}}}&{{d_{12}}}& \cdots &{{d_{1p}}}&{{d_{1m}}} \\ { < {a_2}, b_2 > }& {{d_{21}}}&{{d_{22}}}& \cdots &{{d_{2p}}}&{{d_{2m}}} \\ \vdots & \vdots & \vdots & \ddots & \vdots & \vdots \\ { < {a_k},{b_k} > }& {{d_{k1}}}&{{d_{k2}}}& \cdots &{{d_{kp}}}&{{d_{km}}} \\ { < {a_n},{b_n} > }& {{d_{n1}}}&{{d_{n2}}}& \cdots &{{d_{np}}}&{{d_{nm}}} \end{array} \\ \end{split} $

2.4 基于多色集合的组织间交互过程建模

在不同的业务场景中, 参与组织对外提供不同的交互活动, 根据不同的场景进行外部活动建模, 在组织内部流程发生改变时并不会对其他交互流程产生影响, 实现了各组织之间交互建模的弱耦合性. 分别提取各组织中的内部活动集合 ${A_I}$ , 交互活动集合 ${A_O}$ , 内部资源集合 ${M_I}$ 和交互资源集合 ${M_O}$ . 以组织A和组织B为例, 建立矩阵 $\left[ { < {A_O} \times {B_O} > \times {M_O}} \right]$ 描述A和B之间的交互过程.

$\begin{split} & \left[ { < {A_O} \times {B_O} > \times {M_O}} \right] = \\ & \begin{array}{c|ccccc} {}& {{m_{O1}}}&{{m_{O2}}}& \cdots &{{m_{Op}}}&{{m_{Om}}} \\ \hline { < {a_{O1}},{b_{O1}} > }& {{w_{11}}}&{{w_{12}}}& \cdots &{{w_{1p}}}&{{w_{1m}}} \\ { < {a_{O2}}, {b_{O2}} > }& {{w_{21}}}&{{w_{22}}}& \cdots &{{w_{2p}}}&{{w_{2m}}} \\ \vdots & \vdots & \vdots & \ddots & \vdots & \vdots \\ { < {a_{Ok}},{b_{Ok}} > }& {{w_{ki}}}&{{w_{k2}}}& \cdots &{{w_{kp}}}&{{w_{km}}} \\ { < {a_{On}},{b_{On}} > }& {{w_{n1}}}&{{w_{n2}}}& \cdots &{{w_{np}}}&{{w_{nm}}} \end{array} \\ \end{split} $

其中, ${w_{ij}} = 1$ 时, 表示外部活动 ${a_{Oi}}$ 和 ${b_{Oi}}$ 之间的交互需要外部交互资源 ${m_{Oj}}$ 的参与才能进行; 反之, ${w_{ij}} = 0$ 时, 外部活动 ${a_{Oi}}$ 和 ${b_{Oi}}$ 之间的交互与外部交互资源 ${m_{Oj}}$ 无关.

3 医院间电子病历互访平台的跨组织工作流过程交互建模

跨组织电子病历互访平台作为一个调度中心并不存储电子病历数据, 由相关的医院提供所需的病历, 平台只负责对用户身份注册进行审核, 对病历请求进行审核转发, 转发病历并记录电子病历交互过程的相关信息; 在病历的交互过程中需要得到患者的授权, 保证患者对其病历的控制权.

在医院间电子病历互访平台的交互过程中:

(1)首先由医院医务处在平台进行身份审核认证;

(2)注册成功以后当病患在医院就医时, 病患提供身份证明;

(3)由医生提交病历访问申请, 在申请中要添加能够证实患者身份的信息;

(4)平台进行身份审核确认身份无误后将病历申请单转发到被申请医院;

(5)核实当前该病历是否被外借出去进行研究或已被他人作为诊断依据;

(6)当病历未被其他医院申请作为诊断依据时, 响应方医院将病历发送给平台, 由平台进行转发;

(7)在病历被接收并且确认无误后, 申请方医院向平台发送反馈确认单, 由平台转发给响应方医院;

(8)最后要将整个过程中出现的错误、冲突等交互记录生成相应的记录单保存在平台中作为交互各方的交互证明和信誉凭证.

根据整体流程建立的交互过程图如图1所示. 在整个交互过程中, 涉及到的组织包括申请方医院A, 交互平台, 以及响应方医院B, 根据业务流程, 定义三者的业务集合以及涉及到的资源信息集合.

申请方医院业务集合Q={q₁, q₂, q₃, q₄, q₅, q₆, q₇, q₈, q₉}: q₁ 医生在医务处认证, q₂ 医务处在平台认证, q₃ 完成注册, q₄ 病患就医, q₅ 医生经医务处发送病历申请, q₆ 病患接收并填写验证码, q₇ 接收申请结果反馈单 ,q₈ 接收病历 ,q₉ 发送确认反馈单.

响应方医院业务集合R={r₁, r₂, r₃, r₄, r₅, r₆, r₇}: r₁ 医生在医务处认证, r₂ 医务处在平台认证, r₃ 完成注册, r₄ 核实病历当前状态, r₅ 发送申请反馈单, r₆ 发送病历, r₇ 接收反馈单.

交互平台业务过程集合A={a₁, a₂, a₃, a₄, a₅, a₆, a₇, a₈, a₉, a₁₀, a₁₁, a₁₂}: a₁ 验证医务处注册申请, a₂ 接收病历申请, a₃ 发送验证码验证病患身份, a₄ 核实验证码, a₅ 转发病历申请, a₆接收申请反馈, a₇ 转发申请结果反馈, a₈ 接收病历, a₉ 转发病历, a₁₀ 接收反馈, a₁₁ 转发反馈, a₁₂ 生成记录.

资源信息集合M={m₁, m₂, m₃, m₄, m₅, m₆, m₇, m₈ }: m₁身份信息, m₂身份许可证明, m₃病历申请单, m₄验证码, m₅申请结果反馈, m₆病人病历, m₇反馈单, m₈记录单.

3.1 组织内部流程建模

在整个跨组织病历访问过程中, 包含申请方医院A、交互平台以及响应方医院B三个组织. 分别定义三者的私有流程为 $\left[ {Q \times Q} \right]$ , $\left[ {A \times A} \right]$ 以及 $\left[ {R \times R} \right]$ .

3.2 组织间交互过程建模

根据各组织之间的活动交互关系, 建立交互矩阵 $\left[ {Q \times A} \right]$ 和 $\left[ {A \times R} \right]$ .

以申请方医院和平台的交互过程为例, 平台接受申请、验证病患身份、转发病历、接收反馈确认等活动和响应方医院并无交互, 属于可以对响应方隐藏的活动.

由此抽象出此时平台的外部活动集合 ${A_{_{OQ}}} = \{ {a_1},{a_2}, $ $ {a_3}, {a_4},{a_7},{a_9},{a_{10}} \}$ , 申请方外部活动集合 ${Q_{OA}} = \{ {q_2},{q_3},{q_5}, $ $ {q_6},{q_7},{q_8},{q_9} \}$ ; 同理抽象出与申请方医院交互时, 平台的外部活动集合 ${A_{OR}} = \left\{ {{a_1},{a_5},{a_6},{a_8},{a_{11}}} \right\}$ , 申请方外部活动集合 ${R_{OA}} = \left\{ {{r_2},{r_3},{r_4},{r_5},{r_6},{r_7}} \right\}$ ; 根据此时的交互流程图, 对于各组织内部的资源状态未知, 此时已知的资源m均涉及到了各组织与其他组织之间的活动交互, 因此此时 ${M_O} = M$ .

$\begin{aligned} & \left[ {Q \times A} \right] = & \begin{array}{c|cccccccccccc} {} & {{a_1}} & {{a_2}} & {{a_3}} & {{a_4}} & {{a_5}} & {{a_6}} & {{a_7}} & {{a_8}} & {{a_9}} & {{a_{10}}} & {{a_{11}}} & {{a_{12}}} \\ \hline {{q_1}} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{q_2}} & 0 & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{q_3}} & 0 & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{q_4}} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{q_5}} & {} & 0 & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{q_6}} & {} & {} & 0 & 0 & {} & {} & {} & {} & {} & {} & {} & {} \\ {{q_7}} & {} & {} & {} & {} & {} & {} & 0 & {} & {} & {} & {} & {} \\ {{q_8}} & {} & {} & {} & {} & {} & {} & {} & {} & 0 & {} & {} & {} \\ {{q_9}} & {} & {} & {} & {} & {} & {} & {} & {} & {} & 0 & {} & {} \end{array} \end{aligned}$ $\begin{aligned} & \left[ {A \times R} \right] = \\ & \begin{array}{c|cccccccccccc} {} & {{a_1}} & {{a_2}} & {{a_3}} & {{a_4}} & {{a_5}} & {{a_6}} & {{a_7}} & {{a_8}} & {{a_9}} & {{a_{10}}} & {{a_{11}}} & {{a_{12}}} \\ \hline {{r_1}} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{r_2}} & 0 & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{r_3}} & 0 & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} \\ {{r_4}} & {} & {} & {} & {} & 0 & {} & {} & {} & {} & {} & {} & {} \\ {{r_5}} & {} & {} & {} & {} & {} & 0 & {} & {} & {} & {} & {} & {} \\ {{r_6}} & {} & {} & {} & {} & {} & {} & {} & 0 & {} & {} & {} & {} \\ {{r_7}} & {} & {} & {} & {} & {} & {} & {} & {} & {} & {} & 0 & {} \end{array}\end{aligned}$

针对不同的交互场景, 平台进行不同的交互活动. 一方面, 平台要和申请方医院交互完成身份审核、接收申请等任务; 同时, 平台还要和响应方医院交互完成病历状态验证、转发病历等任务. 因此, 定义申请方医院A和交互平台的关系矩阵为 $\left[ { < {Q_{OA}} \times {A_{OQ}} > \times {M_O}} \right]$ , 定义响应方医院B和交互平台的关系矩阵为 $\left[ { < {A_{OR}} \times {R_{OA}} > \times {M_O}} \right]$ .

$\begin{aligned} & \left[ { < {Q_{OA}} \times {A_{OQ}} > \times {M_O}} \right] = \\ & \begin{array}{c|cccccccc} {}& {{m_1}}&{{m_2}}&{{m_3}}&{{m_4}}&{{m_5}}&{{m_6}}&{{m_7}}&{{m_8}} \\ \hline { < {q_2},{a_1} > }& 1&{}&{}&{}&{}&{}&{}&{} \\ { < {a_1},{q_3} > }& {}&1&{}&{}&{}&{}&{}&{} \\ { < {q_5},{a_2} > }& {}&{}&1&{}&{}&{}&{}&{} \\ { < {a_3},{q_6} > }& {}&{}&{}&1&{}&{}&{}&{} \\ { < {q_6},{a_4} > }& {}&{}&{}&1&{}&{}&{}&{} \\ { < {a_7},{q_7} > }& {}&{}&{}&{}&1&{}&{}&{} \\ { < {a_9},{q_8} > }& {}&{}&{}&{}&{}&1&{}&{} \\ {< {q_9},{a_{10}} >}& {}&{}&{}&{}&{}&{}&1 &{} \\ {}& {}&{}&{}&{}&{}&{}&{}&{} \end{array} \end{aligned} $

$\begin{aligned} & \left[ { < {A_{OR}} \times {R_{OA}} > \times {M_O}} \right] = \\ & \begin{array}{c|cccccccc} {}& {{m_1}}&{{m_2}}&{{m_3}}&{{m_4}}&{{m_5}}&{{m_6}}&{{m_7}}&{{m_8}} \\ \hline { < {r_2},{a_1} > }& 1&{}&{}&{}&{}&{}&{}&{} \\ { < {a_1},{r_3} > }& {}&1&{}&{}&{}&{}&{}&{} \\ { < {a_5},{r_4} > }& {}&{}&1&{}&{}&{}&{}&{} \\ { < {r_5},{a_6} > }& {}&{}&{}&{}&1&{}&{}&{} \\ \begin{gathered} < {r_6},{a_8} > \\ < {a_{11}},{r_7} > \\ \end{gathered} & \begin{gathered} \\ \\ \end{gathered} &\begin{gathered} \\ \\ \end{gathered} &\begin{gathered} \\ \\ \end{gathered} &\begin{gathered} \\ \\ \end{gathered} &\begin{gathered} \\ \\ \end{gathered} &\begin{gathered} 1 \\ \\ \end{gathered} &\begin{gathered} \\ 1 \\ \end{gathered} &\begin{gathered} \\ \\ \end{gathered} \end{array} \end{aligned} $

由于多色图模型能够更加直观地体现出整个业务过程, 因此根据以上活动关系矩阵, 得到跨组织电子病历交互的多色图模型如图2和图3所示. 使用多色图中的节点来表示参与跨组织交互的活动, 使用多色图中的边来表示在两个组织的交互过程中, 不同活动之间传输的资源, 同时这些资源中包含各自不同的属性. 如果两个活动之间存在资源的传输, 那么两个活动之间存在交互关系, 在多色图中就体现为两个活动之间存在一条边; 若两个活动之间不存在资源的交互, 则两个活动之间不存在交互关系, 在多色图中就体现为两个活动之间不存在边.

4 结论与展望

本文针对跨域跨组织的电子病历交互提出多医院间电子病历交互平台, 基于多色集合和多种视角对业务过程进行建模. 根据各组织之间的交互流程, 利用多色集合围道矩阵提取出各组织的私有活动和交互活动, 以及交互过程中涉及到的交互资源, 从交互过程中各组织的不同交互视角进行形式化描述, 该建模方法能够在描述出业务交互的同时, 对组织内部流程进行隐藏, 实现当组织内部流程发生改变时, 外部活动交互不受影响, 以保证组织内部流程的自治性和各组织之间的弱耦合.

基于多色集合的建模方法具有良好的可扩展性, 能够运用到其他跨组织业务交互中. 但在本文中并未对业务流中各活动的离散约束和连续约束进行表达, 在以后的研究中可以对当前的二维围道矩阵进行扩展, 使用三维结构的矩阵和三维可视化技术对业务流程中涉及到的离散约束和连续约束进行直观、清晰的表达.