UCML工作流系统与现有应用系统集成

2024-09-09

UCML工作流系统与现有应用系统集成(共3篇)

UCML工作流系统与现有应用系统集成 篇1

UCML工作流系统与现有应用系统

集成实现方案说明

金富瑞(北京)科技有限公司

Goldframe Technologies Co., Ltd.一 总体说明

UCML.Net工作流系统是国内领先的工作流平台,涵盖了从流程开发、发布、管理配置到运行、监控的整个过程。UCML工作流系统主要包括可视化的流程设计环境、独立的工作流引擎服务、WEB客户端管理、可视化的流程监控、流程套路生产线几个部分,是.Net领域用户最多,覆盖面最广的工作流平台。

一方面,UCML工作流系统与UCML平台其它部分(业务单元开发,Web报表)无缝集成,可以完成复杂的业务处理及流程流转;另一方面,UCML工作流系统与业务之间采用松耦合设计,不仅可以与UCML业务系统集成,还可以与其它现成的应用系统实现无缝集成。

UCML工作流在与其它应用系统集成时,一般有两种方式: 第一种:保留UCML现有的组织机构、用户及权限体系

第二种:完全屏蔽UCML提供的组织机构、用户及权限体系,完全采用客户原有的组织机构权限体系。

对于第一种方式,需要另外实现UCML系统与客户现有应用系统之间的数据同步,具体方法可采用程序同步方式,在这里就不详细介绍了。

下面主要介绍一下采用第二种方式时的处理方法。二 UCML Workflow会话编程接口

UCML Workflow 提供了WorkFlow.WorkFlowSession会话类来访问工作流引擎, WorkFlow.WorkFlowSession以.Net Remoting服务形式形式存在于工作流引擎的独立进程中,客户端可以创建WorkFlow.WorkFlowSession的Client端来来调用服务端的接口。

创建工作流会话对象

WorkFlow.WorkFlowSession

FlowSession

=(WorkFlow.WorkFlowSession)Activator.GetObject(typeof(WorkFlow.WorkFlowSession), “tcp://”+WorkFlow.UCMLInitEnv.WorkflowEngineAddr+“:”+WorkFlow.UCMLInitEnv.WorkflowEnginePort+“/WorkFlowSession”);

程序启动工作流程

public Guid CreateInstance(string FlowID,Object UserOID,Object PostnOID, Object DivisionOID,Object ORGOID, bool startNow)

通过调用CreateInstance函数,可以启动指定的工流程。

返回值:流程实例句柄。

参数名称 FlowID UserOID PostnOID DivisionOID ORGOID startNow

类型 string Object Object Object Object Bool

参数说明

要启动的流程编号

起动流程的用户OID,实际类型为GUID 起动流程的员工OID,实际类型为GUID

起动流程的员工所在部门的OID,实际类型为GUID 起动流程的员工所在组织的OID,实际类型为GUID ==true 流程是马上启动; ==false 流程暂不启动,要启动流程需调用StartInstance函数,这种情况一般用于在业务(如客户订单)提交成功后,先写入订单号到流程实例中,然后在启动流程。

 向流程全局数据写入数据

public void WriteFlowData(string FlowID, Object InstanceID, string FieldName,Object Value)

参数名称 FlowID InstanceID FieldName Value

类型 string Object string Object

参数说明

数据项所属的流程编号

流程的实例句柄,实际类型为GUID 数据的属性名称 数据的属性的值

从流程全局数据读出数据

public Object ReadFlowData(string FlowID, Guid InstanceID, string FieldName)

返回值:读取数据属性的值

参数名称 FlowID InstanceID FieldName

类型 string Object string

参数说明

数据项所属的流程编号

流程的实例句柄,实际类型为GUID 数据的属性名称

向流程局部数据写入数据

public void WriteActivityData(string FlowID, Guid InstanceID,string ActivityID, string FieldName,Object Value)

参数名称 FlowID InstanceID ActivityID FieldName Value

类型 string Object string string Object

参数说明

数据项所属的流程编号 流程的实例句柄,实际类型为GUID 活动节点的编号 数据的属性名称 数据的属性的值

从流程局部数据读出数据

public Object ReadActivityData(string FlowID, Guid InstanceID,string ActivityID, string FieldName)

返回值:读取数据属性的值

参数名称 FlowID InstanceID ActivityID FieldName

类型 string Object string string

参数说明

数据项所属的流程编号 流程的实例句柄,实际类型为GUID 活动节点的编号 数据的属性名称

完成已分配的任务

public string FinishTask(string strAssignTaskID)FinishTask代表设置已分配出去的任务已完成 返回值:提示信息

参数名称 strAssignTaskID

类型 string

参数说明

分配任务的唯一标志号

设置任务结果及状态

public void SetTaskResolution(Guid TaskID,TTaskResolution Resolution)

设置任务执行结果,代表任务执行完毕

参数名称 类型 参数说明

TaskID Resolution

Guid

任务的Key值

TtaskResolution 任务的状态{UNRESOLVED,SUCCESS,FAIL,EXCEPTION} 含

义分别为{未处理,成功,失败,异常}

 编写节点分支条件

UCML Workflow用abstract public class Transition类来描述一个分支条件

类属性名称 类型 可见度 属性说明

TransResult

Boolean

protected

TransResult==true 则代表流程分支条成立

TransResult==false 则代表流程分支条不成成立

FromActivity

WorkFlowActivity

public

分支来源节点对象实例 ToActivity FlowModel

WorkFlowActivity WorkFlowModel的子类

public public

分支目标节点对象实例

其实是流程模型的实例对象,通过它可以访问流程所有属性(或状态)数据

方法名称

类型

可见度 public

方法说明

virtual public bool OutgoingCondition()

在UCML Workflow里,节点的一条流出分支是否成立完全取决于这个函数,编程人员员可以它的子类里编写它的具体实现代码,在编写代码时可以结合流程的状态数据。在这函数中一定要设置TransResult的值,也就是说如果TransResult==true 分支成,否则分支不成立,也就不走这条分支。

IncomingCondition

bool

public

virtual public bool IncomingCondition()OutgoingCondition()bool

OutgoingCondition()这函数是在Transition的子类中已覆盖函数形式实现,在UCML环境里的流出条件编辑,就是实现此函数。如下图示:

 9.编程实现智能任务分配

wm_assign()-UCML Workflow提供回调函数,为开发者提供完成复杂分配的可能,详见回调函数接口

 10.终止流程

方法名称 Abort()

类型 void

可见度 public

方法说明

public void Abort(string FlowID, Guid InstanceID)终止某个流程实例

 9.挂起流程

方法名称 Pause()

类型 void

可见度 public

方法说明

public virtual void Pause()暂时挂起一个流程

 10.唤醒流程

方法名称 Resume()

类型 void

可见度 public

方法说明

public void Resume(string FlowID, Guid InstanceID)重新运转流程

 11.节点手动跳转

方法名称 GotoActivity()

类型 void

可见度 public

方法说明

public void GotoActivity(string FlowID, Guid InstanceID,string FromActivityID,string

ToActivityID,string Performers)作用 : 流程跳转 FlowID:流程ID

InstanceID:流程实例句柄 FromActivityID:来源活动名称 ToActivityID:目标活动名称 Performers:执行人的群组串. 回退任务

///

/// 回退任务 /// ///

任务ID public void Rollback(Guid TaskID) 回收任务

///

/// 收回任务 ///

///

任务ID

 获取某个活动节点执行人

///

/// 获取某个活动节点执行人

///

///

活动节点ID

/// public string GetActivityPerformer(string ActivityID)

 获取当前节点即将流向的目标节点,如果是并发输出将会多个流向。用于在当前节点完成时,马上选择下一节点执行人

///

/// 获取当前节点即将流向的目标节点,如果是并发输出将会多个流向

/// 用于在当前节点完成时,马上选择下一节点执行人

///

///

流程ID

///

实例ID

///

活动ID

/// 返回要输出的节点ID数组

public string[] GetOutgoingActivitys(string FlowID, Guid InstanceID, string ActivityID)

 获取节点状态

///

/// 获取节点状态

///

///

///

///

///

public int GetActivityStatus(string FlowID, Object InstanceID, string ActivityID) 修改节点状态

///

/// 修改节点状态

///

///

///

///

///

public void ChangeActivityStatus(string FlowID, Object InstanceID, string ActivityID, int ActivityStatus) 不结束当前节点,而激活下一节点

///

/// 不结束当前节点,而激活下一节点

///

///

流程ID

///

流程实例ID

///

流转到活动ID

///

来自活动ID

///

流转到活动节点执行人

public void GotoActivityNotFinishTask(string FlowID, Guid InstanceID, string FromActivityID, string ToActivityID, string Performers)

 完成已分配的任务,但不流转

///

/// 完成已分配的任务,但不流转

///

///

工作流活动节点对象

///

public string FinishTaskNotRun(WorkFlowActivity Activity)

 加签或者转签

///

/// 加签或者转签 /// ///

流程ID ///

实例ID ///

任务ID ///

当前用户OID ///

执行人 ///

按照顺序执行 ///

true:加签;false:转签 ///

///

消息类型 ///

消息内容

public void AddSignPerformer(string FlowID, Guid InstanceID, Guid AssignTaskOID, Guid CurrentUserOID, string SignPerformers, bool fSignOneByeOne, bool InsertBefore, bool IsDeleteSigner,int MessageType,string MessageContent)

 协办或会签

///

/// 协办或会签

///

///

流程ID

///

实例ID

///

任务ID

///

当前用户OID

///

执行人

///

消息类型

///

消息内容

///

3:协办;1:会签

public void AssignSignPerformer(string FlowID, Guid InstanceID, Guid AssignTaskOID, Guid CurrentUserOID, string SignPerformers,int MessageType, string MessageContent,int TaskKind)

 手工正常分配任务

///

/// 手工正常分配任务 /// ///

///

public void MansualAssignTask(string TaskTicketOID,string Performer) 分配参阅任务

///

/// 分配参阅任务 /// ///

///

public void MansualAssignReadTask(string TaskTicketOID,string Performer) 悔签任务,对在任务分配表AssignTask中acceptFlag置为1的标记设为4悔签

悔签

///

/// 悔签任务,对在任务分配表AssignTask中acceptFlag置为1的标记设为4/// ///

public void RepentSignforTask(string assignTaskID) 任务跳回到执行人

///

/// 任务跳回到执行人

///

///

流程ID

///

流程实例句柄

///

节点ID

public void TaskReturn(string FlowID, Guid InstanceID, string ActivityID)

 获取某个已完成节点的执行人

///

/// 获取某个已完成节点的执行人

///

///

流程ID

///

流程实例句柄

///

节点ID

/// 返回执行人OID数组

public Guid[] GetExecuteUser(string FlowID, Guid InstanceID, string ActivityID)

 唤醒已完成的任务

///

/// 唤醒已完成的任务

///

///

public void WakeFinishedAssignTask(string AssignTaskOID) 12.任务超时处理及编程

UCML Workflow 的是否超时由下图的完成期限和延长时间两个属性决定:

当完成期限不填内容时,代表这个活动节点产生的任务没有时间限制 延长时间代表完成期限倒了之后,还可以再延长多少时间

 即将超时处理

当完成期限到了之后,会回调wm_willtimeout函数,如果想在此时放个邮件通知或短信,就可在wm_willtimeout函数内调用。

 超时处理

同样的当完成期限到了之后,如果有延长时间,而且延长时间也到了,会回调wm_deadline函数,如果想在此时放个邮件通知或者短信,就可在wm_deadline函数内调用。如下图示:

如果任务在截止期限和延长时间内都没有完成,此时任务做超时处理,流程是继续流转还是停止由截止期限到达时系统行为这个属性决定,如为SYNCHR(同步),则流程停在这里,如果为ASYNCHR(异步)则流程继续流转。

三 UCML工作流开放性介绍

UCML 引擎底层框架的基类源码不开放,包括引擎调度代码和流程类、活动类和分支类基类代码。而根据定义可以直接生成引擎源码都是开放的,可以在这些源码的框架扩展时刻(回调函数)之内注入C#代码来进行,如下面活动节点代码的时刻函数

任务分配时刻函数

override public void wm_assign(Object taskTicketID,Object[] UserList,ref Object[] AssignUserList,ref int[] TaskKindList,Boolean reassignFlag){ } 任务分配后时刻函数

override public void wm_afterAssignTask(Object assignTaskID,Object UserOID){

base.wm_afterAssignTask(assignTaskID,UserOID);}

任务分配前时刻函数

override public void wm_beforeAssignTask(SysDBModel.AssignTaskInfo AssignTaskInfo){ }

任务完成时刻函数

override public void wm_afterTaskFinish(Object taskTicketID,TTaskResolution TaskResolution){ }

任务超时时刻函数

override public void wm_deadline(Object taskTicketID){ }

任务完成规则函数

override public bool wm_finishTaskRule(SysDBModel.TaskTicketInfo taskTicketInfo){

return false;} 任务创建函数

override public void wm_createTask(SysDBModel.TaskTicketInfo taskTicketInfo){ }

任务回滚前函数

override public void wm_beforerollback(Object taskTicketID){ } 任务回滚后函数

override public void wm_afterrollback(Object taskTicketID){ }

override public void wm_onactivate(){ }

override public void wm_willtimeout(SysDBModel.TaskTicketInfo taskTicketInfo){ }

override public bool wm_activityInComeCondi(){

return false;}

} }

四 集成方案

在采用客户已有的人员权限体系时,主要用到UCML工作流系统的可视化流程设计环境、工作流引擎服务、工作流标准表结构、流程API、可视化的流程监控(可选)等。在集成时可能需要修改客户已有的Web系统或表的结构,主要是修改以下地方:  修改人员信息表

 引入流程接口(UCML工作流API) 客户登陆会话的改变

 加入工作流引擎需要的初始化程序  增加一个待办事宜模块

 引入平台中的可视化的流程监控模块(如果需要可视化流程监控那么就需要引入)在平台中主要有以下注意点:  在平台中设计工作流模型  添加流程状态数据

 在任务分配函数-wm_assign()中设置任务的执行人  修改人工节点上的业务标识符为为自己的页面

1、修改人员信息表

需要在客户现有的用户表(存储登录帐号、密码表)中增加一个Guid类型的字段,这个字段的值唯一标记一个用户,不影响客户现有的应用体系,起到与UCML工作流衔接作用。

这个字段的字段名命名规范为:客户表名+OID,即“客户表名OID”,字段类型为GUID类型,在MSSQL Server中是Uniqueidentifier,Oracle中为VARCHAR类型。在客户业务系统中客户的登录ID代表客户的身份,如果整合中客户表中有现存的数据需要手工给“客户表名OID”赋值;另外,在增加用户的程序中要同时给“客户表名OID”赋值。

2、引入流程接口(UCML工作流API)

 在客户现有系统的工程文件中引入UCML工作流API,并引用一个专门为第三方业务开发包装的接口源程序WorkflowClient.cs。

 相关工作流API:DBLayer.dll,SysDBModel.dll,UCMLBase.dll,WorkFlow.dll  把Workflowbin 目录下的UCMLConf.xml,DBLayer.xml文件拷贝到客户工程的bin目录下,注意:如果不是在客户工程的本机运行工作流引擎,则需要把UCMLConf.xml文件中引用工作流引擎地址的IP改为运行工作流引擎主机的IP地址。

3、客户登陆会话的改变

在用户登陆的程序中,在取得用户表中各项数据时,把用户表中新增的字段也读出来,并把该项也放入用户登陆会话中。

4、加入工作流引擎需要的初始化程序

在使用客户的应用程序中与工作流引擎打交道之前的任意时刻加入如下程序: UCMLCommon.UCMLInitEnv.fInServer=true;UCMLCommon.UCMLInitEnv.LoadEnvVariable();new DBLayer.LogicDBModel();UCMLCommon.UCMLLogicDBModelApp x = new UCMLCommon.UCMLLogicDBModelApp();x.PrepareModel();

5、增加一个待办事宜模块

待办事宜也叫待办任务。

需要客户自己新增一个待办事宜模块,其数据来源是UCML提供的任务分配表AssignTask,开发者可根据记录(任务)的完成与否状态过滤数据到待办任务模块内。

6、引入平台中的可视化的流程监控模块(如果需要可视化流程监控那么就需要引入)

可视化流程监控的页面在平台中的业务模块是:BPO_FlowTrace 可以将BPO_FlowTrace相关文件拷贝到项目下: BPO_FlowTrace.aspx BPO_FlowTrace.aspx.cs BPO_FlowTrace.asmx BPO_FlowTrace.asmx.cs BPO_FlowTrace.htc

7、在平台中设计工作流模型

在平台中设计工作流模型,可以参考“工作流设计手册”。

8、添加流程状态数据

UCML工作流引擎和业务之间是松耦合处理模式,工作流和业务之间是通过流程状态数据进行交互。

流程状态数据是指工作流在运转过程中流程流转所需要的保存在流程实例中的数据,一般有三类业务数据要保存在流程中,一是业务单据的关键字段,用它可以决定一个任务对应的业务单据号,在UCML里一般把表单主键存到流程里;二是决定流程分支走向的数据,有可能是领导意见,也有可能是单据金额,这些数据是为了工作流引擎内部调用的;三是流程执行人信息。

流程和业务之间的状态数据交互方法很简单,如下所示:

写入流程状态数据:即把业务的数据写入到流程中去,调用的方法是WriteFlowData;

读出流程状态数据:即把流程状态读出来赋给业务,调用的方法是ReadFlowData。写入流程状态数据一般在数据提交时进行,读出流程状态数据一般在初始化时进行,读时可以把流程状态数据赋给业务中的某个属性,以方便业务中调用。

9、在任务分配函数-wm_assign()中设置任务的执行人

在工作流中任务分配的方式有几种:

通过群组配置分配任务

回调函数分配任务

手工执行执行人

由于组织机构等均不采用平台自带的组织框架,所以无法采用“通过群组配置分配任务”的方式,只能采用“回调函数分配任务”或

10、自己实现执行人群组解析接口,可以继续使用基于配置的任务分配

基于流程模型的执行人配置可以避免在wm_assign里写程序做任务分配,但必须必需特定某个组织机构,在这个组织机构基础之上可以定义群组,来描述人员、部门和岗位集合,也可以定义相对执行人如申请人的部门主管、申请人公司总经理等,只要实现自己的群组解析接口,就可以自己的群组串配置UCML的工作流执行人的字段里,就可以实现基于配置的任务分配实现步骤如下:

 自定义类实现如下接口

public interface IGroupParser { Object[] UserOIDList(string GroupStr, Object Starter, Object StartPostn, Object StartDivision, Object StartORG, Object Performer, Object PerformerPostn, Object PerformerDivision, Object PerformerORG);Object[] UserOIDList(string GroupStr);}

///

/// ///

群组字符串 ///

流程启动者GUID /// 根据组定义获取用户列表

///

流程启动岗位GUID ///

流程启动部门GUID ///

流程启动企业GUID ///

当前执行人GUID ///

当前执行人岗位GUID ///

当前执行人部门GUID ///

当前执行人企业GUID /// 返回GUID类型的用户ID  在UCMLCONF.XML文件里添加如下节点:

true dll名称 类名称11、12、修改人工节点上的业务标识符为为自己的页面 工作流计算工作日客户自定义接口

1.自定义类实现如下接口

public interface IWorkDay { ///

/// 计算任务完成期限,用于扩展节假日等非工作日的完成时间的计算

///

///

任务开始时间 ///

任务计划用时,单位为秒 ///

任务执行人OID /// 返回任务最终完成时间 DateTime GetLimitDateTime(DateTime startTime, long delayTime, Guid UserOID);}

2.在UCMLCONF.XML文件里添加如下节点:

< fCustomWorkDay>true < WorkDayAssembly>dll名称 < WorkDayClass>类名称

13、///

/// 流程切面时刻

///

public interface IWorkFlowRuntime { /// /// 流程创建时刻

///

///

工作流时刻切面接口

1.自定义类实现如下接口 ///

void OnCreateInstance(WorkFlowModel FlowInstance, DateTime CreateTime);///

/// 流程完成时刻

///

///

///

void OnFinishInstance(WorkFlowModel FlowInstance, DateTime EndTime);///

/// 流程终止时刻

///

///

///

void OnAbortInstance(WorkFlowModel FlowInstance, DateTime AbortTime);} ///

/// 活动节点切面接口时刻

///

public interface IActivityRunTime { /// /// 任务创建时刻

///

///

///

///

void OnCreateTask(WorkFlowModel FlowInstance, WorkFlowActivity Activity, DateTime CreateTime);///

/// 完成任务分配时刻

///

///

///

///

void OnFinishAssignTask(WorkFlowModel FlowInstance, WorkFlowActivity Activity, DateTime FinishTime);///

/// 完成整个任务时刻

///

///

///

///

UCML工作流系统与现有应用系统集成 篇2

目前, 我国的医疗保险基本已实现了全覆盖, 定点医疗机构将面对全新的医疗保险给付体系。医保的管理已经在医院医疗管理和经营管理中占主导地位, 特别是对于门诊量>2000人次的三级甲等医院, 其病源病情重、治疗费用高、人员结构复杂、各项统计和财务数据繁多, 要求医院信息系统 (HIS) 向更加全面化、科学化、精细化、标准化和个性化的方向发展[1]。

1 HIS在现有医疗保险制度下面对的问题

1.1 现行医保制度对患者医疗费用的限制

现行医保制度对患者医疗费用的限制主要表现在以下几个方面[2]: (1) 住院患者的治疗费用和药品费用必须与医嘱的起止时间相一致; (2) 辅助检查项目开立的医嘱必须与化验单或报告单相一致; (3) 一般的三级医院都设有特殊疾病门诊, 不同门规病种其限定的药品处方和检查有所区别; (4) 患者在门诊就医或住院就医时, 系统应标识自费用药或限病种用药; (5) 住院病种超过病种规定限额有系统警示等。这几方面与传统的HIS设置和工作模式不相适应。

1.2 报销比例不同对HIS的要求

医疗保险分为:职工医保、城镇居民医保、新型农村合作医疗保险、医保门规、离休医保、工伤医保等。不同的医保类型其报销比例不同, 对应着不同的支付标准, 这就要求HIS给予区别对待[3]。

1.3 系统对初始化和标准化的要求

医保农合对HIS的初始化要求比较高。对于系统中的各类字典库、医嘱项目、诊疗项目及价格表等初始化内容, 既要求名称规范、编码准确、项目齐全、价格准确, 还必须符合医保要求和临床习惯。如同种药品, 若生产厂家不同, 则医保报销的比例和范围可能会不同[4]。

1.4 系统流程与传统工作习惯不相适应

HIS是在充分考虑医院的管理模式和工作习惯的基础上设计的, 基本符合医院工作规律和工作流程。但随着医疗保险的全覆盖和一些个性化政策的实施, 不同地区、不同类型的定点医疗机构必须适应这种改革和转变。

1.5 大数据时代给HIS提出更高的挑战

当前社会进入大数据时代, 数据的采集、获取、分析及使用同样适用于医疗机构, 每天医院产生的数据量非常大, 数据分析工作任重道远。合理控制费用、提高医疗质量需要以数据分析为基础。

2 HIS的改进措施

2.1 解读医保政策规定, 扩展HIS功能

医院的管理者很少参与HIS的设计与开发, 开发人员需了解医院管理的需求以及不同地区医疗机构的运行规律, 通过对医院实际情况的调查来设计和修改程序, 这个过程需要使用者、管理者和工程技术人员共同合作[5,6]。决策者和开发人员需对HIS的功能进行整合和统一, 最大限度地满足医保政策和院内医保管理的需求。如: (1) 在门诊收费子系统设置不同病种处方药品的限量范围, 超量时HIS会自动显示提示窗口, 替代专职医保审核人员在收费前对每张处方的审核, 提高工作效率[7]; (2) 在医生工作站、护士工作站、门急诊收费处、中心摆药工作站等子系统的药品字典库中, 务必标识药品的报销类别和限指征用药品的范围, 以便提醒操作人员正确选择药品的计价属性, 提高了医护人员对医保患者用药范围掌握的准确性; (3) 其他系统应根据不同的医保方案、报销比例及限额, 设置相应的项目对照以做区别; (4) 若政策规定发生变化, 应指定工作人员随时进行调整和完善, 院内管理部门, 如经管、临床、药品等部门需进行协调合作; (5) 在内部收费系统与LIS、PACS、ORIS、病理管理系统等之间, 设置了按即时执行医嘱发生的实际费用进行计价收费, 避免多收费或漏收费, 确保患者和医院双方的利益[8]; (6) 在HIS的门急诊系统中, 采用“一卡通”规范就诊流程, 对初次就诊患者的基本信息进行登记, 以方便后期的信息管理。

2.2 建立规范化、专业化、标准化的管理制度

医保制度的全面覆盖使定点医疗机构传统的工作观念、流程、方法和管理模式发生了重大变革[9,10]。如:医嘱的转录与查对, 药品的领取方法与途径, 出院、转科的操作流程, 以及药品、检查检验的计价和收费等都发生了重大变化。因此, 必须建立完善、严格、规范的管理制度。在参照《医疗护理技术操作常规》有关网络技术的应用与管理要求的基础上, 制定医院信息系统运行操作规程, 如医生、护士电子病历操作流程, 住院药房及中心摆药站操作流程, 医护工作站电子医嘱审核制度, 住院门诊收费子系统运行程序。同时, 应根据医院诊疗工作的特点调整管理模式, 加强沟通与交流, 注重网络技术与管理流程相结合。例如, 为避免医嘱更改, 病人转科、出院, 手术改期或停止等特殊情况造成退药或药品收费与医嘱不符等情况, 可通过协调护士工作站与住院药房等部门, 采取病区备2 d用量的药品基数, 中心药房将隔日摆药改为当日摆药[11]。

同时, 应对网络运行的安全性、可靠性, 医嘱录入的准确性、规范性, 医嘱与费用的准确对应等提取细致的量化指标, 将系统的运行情况纳入质量考核体系中, 落实质量控制, 明确责任, 奖罚分明, 确保HIS有序、优质、高效地运行。

2.3 建设兼容性、前瞻性的标准化编码

定点医疗机构和医保经办机构是密不可分的两个部门, 其数据要实行共享。共享数据包括住院病人的基本信息、疾病名称、费用明细等, 所以设置科学化、标准化、通用化的编码非常重要[12]。否则, 医保部门将无法识别、统计、汇总来自定点医疗机构的信息源。因此, 建立一套标准化、科学化、通用化、前瞻性强的医嘱字典, 对于分析检查、治疗和用药的合理性具有重要意义。

2.4 加强对HIS使用者的培训

HIS的应用者是医院的全体员工, 员工的年龄、专业、素质不同, 决定了其对计算机的接受程度参差不齐。人员的流动以及应用程序的不断改进和系统的不断升级, 决定了计算机的培训工作需要不断进行[13]。管理者必须把培训工作作为一项系统工程, 有计划、有步骤地进行。

(1) 抓住骨干, 强化培训。组织系统应用培训, 其内容包括网络技术基本理论、基础操作、工程系统, 以及各个应用系统的窗口功能操作等[14,15]。将医保政策、有关规定与信息网络技术在院内的运行机制有机结合, 使医生、护士和收费员掌握操作程序, 适应日常的工作流程。

(2) 以点带面, 全员培训。逐步形成常规的培训流程, 由前期培训合格的骨干担任管理协理员, 将“传帮带”运用到日常工作中, 使医护间、科室间相互交流协作。

(3) 现场指导, 有针对性地培训。HIS网络管理组成员要去医院科室进行调研, 解答特殊科室存在的个性问题, 并有针对性地组织培训, 集中解答普遍存在的共性问题。

3 总结

医保管理系统的逐步完善, 使HIS更加多样化并转变了应用模式。如何将这两个系统有机融合, 形成编码统一、资源共享、需求各异、功能特色的系统, 需要医院决策者和管理者提供大量详实的数据, 需要开发者和管理者不断升级完善系统。利用信息化手段来支撑医保管理工作, 用事实、数据进行管理, 对医疗服务行为、药品适应症、患者用药行为等进行网络实时监控, 可使医院医保管理有新的提升。

摘要:本文介绍了在现有医疗保险制度下, 医院信息系统所面对的问题, 并提出了相应的改进措施, 以加强医院的医保管理。

UCML工作流系统与现有应用系统集成 篇3

一、现有系统与ERP项目是否需集成

企业上ERP系统之前如果已经有了一个财务管理系统。而在ERP系统中本身就包括一个财务管理模块。现在企业的项目管理员有三个选择。一是抛弃原来的系统,利用ERP系统中的财务模块来代替。二是不使用ERP系统中的财务管理模块,让ERP系统与财务管理系统各行其道。三是继续保留财务管理系统,而将财务系统与ERP的相关模块进行集成。

在实际工作中,IT项目管理人员要做出一个合理的选择,具有一定的难度。如选择第一种方式,即抛弃原有的系统,那么无疑会造成重复性的投资。现在ERP系统基本上是按模块来购买与实施的。如果利用ERP系统的财务模块来代替现有的财务管理系统,那么无疑在软件购买的费用上或者在项目实施费用上都会增加许多。而且上ERP系统时又需要对财务用户进行重新的培训,其项目风险也会比较大。

而如果采用第二种方式,即原有系统与ERP系统各行其道,那么会增加员工的工作量。如仓库每天需要生成并审核出货与收货数据。而这些数据是财务部门生成相关应付与应收凭单的依据。如果让两个系统并向运行的话,那么仓库人员与财务人员的工作量就会有重叠,无法将仓库模块中的数据直接传递到财务系统中,降低了员工的工作效率。这也是一种浪费。

第三种方式是保留原有的财务管理系统,而是将ERP系统与财务管理系统进行集成,以方便在ERP系统各个模块的数据与财务管理系统中的数据进行交互。这的确是一种理想的解决方案。但是需要注意的是,这个集成并不是一个小项目,其具有一定的风险,而且企业需要投入的资金可能也不在少数。

其实企业不仅是要考虑财务管理系统与ERP系统的兼容性。类似的情况还有很多。如现在国家推出了发票管理系统、出口外汇核销系统等等。企业有这些系统的话,那么也同时需要考虑其与ERP系统的兼容性。ERP系统所涵盖的范围比较广,如发票管理模块,就与国家推行的发票管理与认证系统有重复的地方。

总之,考虑兼容性的问题,可以帮助企业降低重复投资带来的浪费,同时还可以降低项目的风险与项目周期。

二、什么情况下适合项目集成

通过项目集成的方法,让现有的信息化系统仍然保持活力,并通过新的应用来扩展管理的范围,确实是一种比较理想的方案。但是在上面的文章中,笔者也分析过,其存在着比较多的风险。也就是说,并不是在任何情况下都适合采用项目集成的方法。

通常情况下,如果所采用的ERP系统与原有的信息化系统是同一个厂家的,那么比较适合采用项目集成的机制。如国内的金蝶和用友两家软件公司,他们都是以财务管理系统起步的。国内很多企业采用的都是这两家企业生产的财务管理系统。现在他们也同时提供ERP系统。不过他们的ERP系统,是在原有的财务管理系统上衍生出来的。即ERP系统中财务管理模块的内容与原先的财务管理系统基本上一致,或者说工作思路上是相同的。即使变化,也只是外在形式的变化。在这种情况下,如果采用的ERP系统,也是相同供应商提供的,那么项目集成就相对来说比较容易。有时候就相当于是一个系统升级。况且,有些企业内部还有集成的项目小组。企业就不用第三方的帮助。此时采用项目集成的方法,项目的风险与成本都能够很好的控制。

另外,如果企业现有的系统应用牵涉到的范围比较广,应用比较完善,也适合采用项目集成的手段。如笔者以前给一家企业实施项目时,发现这家企业虽然信息化管理只集中在财务管理部门,但是已经非常的完善。如财务管理系统中还包括财务预算控制、财务成本分析、业绩考核等等。在这种情况下,如果要替换这些系统的话,那就相当的浪费。而且根据笔者的经验,即使上了ERP系统,要达到其原先的应用效果,也有一定的难度。为此在这种情况下,企业项目管理员最好尽量的选择项目集成的方案。

上一篇:《宪法是国家的根本大法》教学实录下一篇:大一电气工程概论论文