最近一个项目中需要独自设计一个表单式工作流功能模块，在此将整个功能模块的设计思路分享出来。

---

---

1. 需求及分析

此处所有的需求是建立在医院临床信息管理系统之上的。这里只分析关于表单式工作流功能模块的需求。

关于表单式工作流功能模块的需求全部整理如下：

• 1.一个患者在不同时期要填写的表单不同。
• 2.每个患者的手术类型不同，也就意味着，每个患者的各个时期可能都不相同。
• 3.每个时期需要单独填写多张表单，相同时期要填写表单的相同。
• 4.在每个时期要填写的其中一张表单中，可能一条患者信息对应一条记录，也可能一条患者信息对应多条记录。比如在手术期的一张检查表单中，一条患者信息只对应一条记录，但是术后期的一张检查表单中，可能会有手术后30天的情况，也会有手术后60天的情况，也就是一条患者信息对应多条记录。
• 5.对于某一个患者，要能单独的处理它的工作流（也就是不同时期的表单）。
• 6.对于某一个时期，要能单独处理在这个时期的所有患者信息。
• 7.对每张表单要有增删改查操作，在每个时期，都要能通过各种方式查询患者的信息。

针对这些需求，对整个工作流功能模块初步的想法大概是这个样子：

• 1.每位患者可以绑定一个工作流程，称为表单式的工作流。
• 2.每个流程由若干个节点组成。
• 3.医生在一个时期处理完所有的表单后，点击完成该流程节点即可进入下一流程节点。
• 4.医生还可以修改一个患者已经完成的流程节点的数据，但是无法查看还未达到的流程节点的数据。

2. 功能实现分析

上述要实现的表单式的工作流跟oa系统中的工作流不大一样，oa系统中的工作流一般是这样几个步骤：

• 1.设计流程。上级设计一种办事的流程，其中包含若干个节点，一个节点代表着一个审批人，所有节点审批都通过后才算完成，一个节点不通过，就会被打回。
• 2.发起流程。由普通员工发起一个流程申请，发起后，员工无法修改这张表单，随后这张表单会跟随流程一级一级审批。
• 3.流程审批。有若干上级审批流程，点击审批通过，该表单就会进入下以流程节点，点审批失败，流程会终止或者打回。
• 4.流程通过。所有流程通过之后，会得到流程通过的凭证，就可以拿着这个凭证去处理相关的事情。

整个oa系统的工作流功能的核心就是多级审批机制，但我们需求中的表单式的工作流，并不设计审批机制，整个工作流的功能可以简单理解为：一条患者信息选择流程后会在各个时期不停流动，在一个时期需要填写非常多的表单，这些表单填写完成后，医生点击进入下一流程，患者信息即可进入下一流程，但是这条患者信息已经留在了每个时期的表单中，医生仍然可以查看和修改这条信息。

oa式的工作流的实现非常复杂，市面上也有商业化和开源的工作流框架和引擎，但是针对我们这个需求来看，如果硬加使用，只会使整个业务更加复杂，因此，最好的办法就是自己设计一种简单工作流机制，实现上述全部的需求。

3. 工作流结构设计

根据上面的需求分析和功能实现的分析，设计的整个工作流结构如下：

• 每个工作流包含若干个节点。
• 每个节点包含基本信息和若干个表单。
• 每个患者绑定一个工作流，患者在每个工作流节点需要处理多张表单。

4. 数据库设计

4.1 总设计思路

根据上面的分析，总的设计思路如下：

• 每个不同的时期有一张主表，主要记载患者的id，每当有患者信息到达该节点时，记录患者的id，一共有两种方式记载。两种方式各有好处。综合考虑还是第1种方式最好。
  • 1.只记载患者信息的id。
  • 2.记载同步记载所有患者信息。
  • 不管使用哪种方法，都需要将患者的id作为主表的主键，这样方便查询子表中的信息。
  • 如果使用第1种方法，那么每张主表中其实主要就是吧包含主键。但在每个时期，都需要联合患者表一起查询数据。
  • 如果使用第2种方法，那么每张主表需要同步患者的所有信息，且不管在哪修改了患者信息，都需要在所有主表同步患者的消息。
• 每个时期的若干小表都是主表的子表，包含该小表需要填写的所有数据字段，外键是主表的id。
• 流程节点表中绑定一张主表。
  • 这样设计的好处就是，在每一个流程节点处，还能看到许多该流程节点的其它信息。
• 工作流表绑定若干个流程节点。
• 一个患者绑定一个工作流，并且存储当前节点，下一节点。

4.1 各时期主表设计

各时期的主表主要干的事情就是存储患者信息的id，代表着患者正处于当前流程节点或者已经完成该流程节点。

患者id模式

• 这种模式很简单，基本上不需要什么字段。

字段	说明
id	患者id
…	权限管理需要的其它字段

同步所有患者信息模式

• 这种方式需要同步主表的所有字段。

字段	说明
id	患者id
…	患者表所有字段

4.2 每个时期的若干小表

存储基本信息，关键是外键是主表的id。

字段	说明
id	唯一id
…	所有数据字段

4.3 流程节点表

主要是绑定主表，还可以添加一个时期的额外数据，比如一个时期的表单填写提示。

字段	说明
id	唯一id
master_table	主表名称
…	权限控制相关字段
…	该时期的其它数据字段

4.4 工作流表

在工作流表中绑定多个工作节点有两种方式：

• 1.根据最多节点数目设置若干个节点字段，存储流程节点的id。
• 2.设置一个字段，字符串拼接的形式，存储所有流程节点id。

同样，两种方式各有好处：

• 使用第1种方式，需要需求中最多节点个数完全确定，才方便设计合适的字段。
• 使用第2种方式，可以存储任意个节点，但在拿出处理的时候有些麻烦。

一个字段模式

字段	说明
id	唯一id
process_name	工作流名称
process_des	工作流描述
process_ndoes	所有节点id
…	权限控制相关的其它字段

多个字段模式

• 其中哈希值主要用来工作流判重。

字段	说明
id	唯一id
process_name	工作流名称
process_des	工作流描述
node_num	节点数目
process_hash	工作流哈希值
node1	节点1
node2	节点2
node3	节点3
…	若干节点
…	权限控制相关的其它字段

4.5 患者表

患者表中和流程相关的一共三个字段：工作流id，当前节点id，下一节点id。其中存储下一节点id的做法类似单链表。

字段	说明
id	唯一id
process_id	工作流id
current_node_id	当前节点id
next_node_id	下一节点id
…	所有数据字段

5.接口设计

5.1 针对工作流节点的接口

• 1.新增工作流节点。

  • 需要保证工作流节点所绑定的主表id和名称是唯一的。

• 2.修改工作流节点。

  • 如果修改了工作流绑定的主表，先要判断这个节点所在工作流是否被患者绑定，如果绑定了，那么将无法修改主表。

• 3.删除工作流节点。

  • 需要保证该节点未绑定任何工作流。

• 4.查询工作流节点。

  • 查询该节点的所有数据。

5.2 针对工作流的接口

• 1.新增工作流。

  • 需要保证工作流节点不重复，重复就会出错。
  • 需要保证节点数大于0.
  • 需要保证整条节点链表不重复。
  • 如果是多字段模式的，还需要检验是否依次填写节点。

• 2.修改工作流。

  • 如果已经有患者绑定了工作流，那么将不能修改工作流的节点。

• 3.删除工作流。

  • 如果已经有患者绑定了工作流，那么将不能删除工作流的节点。

• 4.查询工作流。

  • 查询工作流的所有字段。

5.3 针对患者的接口

• CRUD操作略。

• 查询患者流程信息。

  • 需要获取患者所处流程的所有节点信息。
  • 需要判断哪些节点已经完成，正处于哪个节点，哪些节点还未到达。

• 患者流程通过。

  • 患者的信息将会插入下一节点对应的主表。
  • 修改患者当前节点，下一节点。

6. 前端页面设计

6.1 针对化患者信息处

• 在操作一栏中能够处理患者的流程。
  

6.2 患者流程处理处

6.3 具体时期处

7.其它

这种表单式工作流的设计，理论上是可以抽取出来成为一个独立的框架，待日后有时间精力再去尝试。

---

ATFWUS 2021-08-26