Introduction

In the age of rapidly-developing economies and aging societies, customer-centered healthcare is becoming a common trend [1]. Tailored, long-term care has never been more necessary than it is now, and healthcare customers are expected to participate in their own health care [2]. The importance of the customer as a full participant in health promotion and disease management has grown rapidly. The home and the community are expected to be the most common sites providing health care.

However, health care in China is still hospital- or physician- centered. Hospital-centered health care lays stress on hospital administration. The design of hospital processes more likely concerns about profit. For example, to ensure accuracy in hospital charges, customers are forced to register every time when they seek services. Physician-centered health care emphasizes efficiency of physicians. The processes are designed to make sure the full use of physicians’ time.

Compared with a customer-centered healthcare model, the models on hospital- and physician- centered healthcare have many disadvantages. 1) Lack of long-term care. Healthcare delivery in these models is crisis oriented; that is, it takes place in hospitals after customers become aware of their health problems. Hospitals provide few services to customers either before they come or after they leave. 2) Lack of customer participation [3, 4]. Hospitals pay little heed to efforts to enhance customer knowledge or empower customers to become partners in their own health care. 3) Unnecessary bureaucracy in the healthcare systems. 4) Serious waste of healthcare resources [5].

To solve the problems above, patient-centered healthcare is proposed. Patient-centered healthcare is closely congruent with and responsive to patients’ wants, needs, and preferences [6, 7]. Because healthcare is provided not only to patients, but also to people with health questions and problems—often denoted as healthcare customers (shortened to customers) [1]. For our purpose, we use the broader term, customer, in this article.

In customer-centered health care, information technologies are needed to support the healthcare process. A workflow management system (WfMS) is a type of information technology that can effectively support the customer-centered healthcare process [8]. A WfMS is defined as “a system that completely defines, manages, and executes workflow processes through execution of software whose order of execution is driven by a computer representation of the workflow process logic” [9]. When applied to the healthcare environment, it is referred to as a “careflow management system (CfMS)” [10].

A CfMS effectively reduces cost and supports the customer-centered healthcare process, which emphasizes customer participation, long-term care, and tailored care. Firstly, participation, customers need a CfMS to manage their own care process towards health, communicate with health professionals, learn healthcare knowledge [2], access clinical records, and contribute to timely observations. Secondly, for long-term health care, the healthcare provider must manage customer healthcare records and teaching, encouraging, and reminding customers to participate. A CfMS can deal with such missions in a cost-effective way. In addition, for tailored health care, each customer has his/her own health problems and perceptions of threats and barriers. Such tailoring improves the quality of the healthcare delivery process, but it is time-consuming and labor-intensive, which increases costs. A CfMS can provide customers with condition- and disease-specific healthcare assistance and knowledge at an affordable cost.

Currently, a CfMS integrates both organizational and medical knowledge, the latter of which is represented by clinical practice guidelines (CPGs) to support the decision of physicians [10, 11]. Most CfMSs are mainly hospital or physician centered. To realize customer-centered health care, healthcare organizations still consider process modeling an unresolved issue. Because it provides customers with more services and requires more knowledge, it is much more complex than hospital or physician centered health care modeling. Thus, because it is not only cost prohibitive but also difficult for a healthcare organization to build, establishing a customer-centered careflow model in a cost-effective way is a key challenge for the customer-centered CfMS applications.

Methods

As process modeling is based on knowledge, we first analyzed various kinds of knowledge used in different stages of customer-centered process modeling, and then used a method of inference to establish the lifecycle of process modeling.

In general, knowledge can be classified as explicit and tacit ones [12]. Explicit knowledge can be codified and stored on paper or in electronic form and easily transmitted and shared with others. In contrast, tacit knowledge is harder to formalize and share with others. A large part of the knowledge involved in health care is tacit knowledge, which can heavily influence the physicians’ decision when he/she follows the course of care [12, 13]. However, as computer can only handle explicit knowledge, we will focus on this kind of knowledge in the remainder of this article. The explicit knowledge involved in customer-centered care process modeling could be categorized as four types.

Medical knowledge

The principle of medical treatment is evidence-based medicine (EBM), which comprises an observation stage, a reasoning stage, and an action stage, shown in Fig. 1 [14]. Medical knowledge is used by physicians for reasoning and action-taking.

Fig. 1
figure 1

Diagnostic-therapeutic cycle [14]

Full size image

Medical knowledge, the result of medical research, is independent of individual patients [15]. Medical knowledge comes in many formats such as textbooks or literature. However, when physicians make decisions, they will typically not have the time to search in textbooks or the literature while a customer is waiting in the office. Therefore, the provision of medical knowledge in a more compact and applicable form is a key challenge to the careflow system.

This challenge can be resolved by representing medical knowledge with CPGs, which are systematically developed statements that assist physicians and improve the quality and cost effectiveness of health care by fostering best practices [16]. Nevertheless, physicians should not blindly follow the guidelines step by step because CPGs contain only explicit medical knowledge that is insufficient for accurate decision making. Instead of providing a strict code of conduct, the CPGs offer physicians the best available evidence in a readily understandable and applicable way.

Till now, guidelines have been published in several official websites. Well-known websites include the National Guideline Clearinghouse for evidence-based clinical practice guidelines (www.guidelines.gov) and the National Institutes for Health and Clinical Excellence for published clinical guidelines (www.nice.org.uk/Guidance/CG/Published). Most of these guidelines are in narrative form, which requires translation into a computer-interpretable format.

Organization knowledge

The ultimate goal of workflow management is to ensure that the right person does the right thing at the right time [17], which implies that workflow processes with the same functionality may differ in various organizational patterns and locations. Thus, careflow, as one kind of workflow, needs to be supported by knowledge of organizational patterns that describes the care-related resource hierarchy concerning departments and human resources. In addition, in different organizations, particularly those in different regions, different medical standards are used (e.g., differences between anemic diagnosis standards in the US and those in China). These standards are parts of careflow, which is essential knowledge in care process modeling. This kind of knowledge is referred to as care-related regional difference knowledge. Because both kinds of knowledge above relate to specific organizations, we will refer to these kinds of knowledge as “organization knowledge”.

Ontology has been proved as one of best methods for knowledge representation. According to Borst [18], ontology is defined as “a formal specification of a shared conceptualization.” It is a formal description of concepts and their relationships in a certain domain. Many organization ontologies such as the Enterprise Ontology [19] and Toronto Virtual Enterprise (TOVE) [20] have been well studied.

For our purpose, organization ontology should be able to describe medical tasks, organizational structures (units, positions, and agents of an organization), and regional differences of clinical standards from between the World Health Organization (WHO) and the specific healthcare organization. We have developed ontology for the healthcare organization by protégé [21] in the OWL format [22], part of which is shown in Fig. 2.

Fig. 2
figure 2

Part of healthcare organization ontology

Full size image

Health Promotion and Illness Prevention (HPIP) knowledge

A growing number of researchers have found that health customers with rich knowledge in HPIP are much better equipped to change their health-related behaviors, influence the course of their diseases, and reduce psychological stress, thus be successful to cope with their diseases [23, 24]. However, currently most CPGs, which are physician-oriented and designed to support the decisions of physician, include little HPIP knowledge diffusion, resulting in hospitals’ ignoring long-term knowledge diffusion based on customer’s needs. Furthermore, HPIP knowledge should be used not only in customer education but also in careflow process modeling because HPIP knowledge serves not only for the knowledge diffusion but also for design of care processes such as periodic physical examination.

To integrate HPIP knowledge into the careflow process in a compact way, service items are used in our project (as shown in Table 1) to describe HPIP knowledge. The related knowledge in these items is extracted from literature, medical books, or the Internet.

Table 1 Service items in HPIP
Full size table

Customer-specific knowledge

Different customers have different health conditions and face different health problems. Healthcare services should be tailored to specific conditions and problems. Therefore, customer-specific knowledge, including the health condition, the medical history, and the current problem of a customer, will influence the process of healthcare. It should be considered in careflow modeling.

However, because the health conditions of the customers cannot be predicted, also careflow models of all customers would consist of myriad careflow paths, it is impossible to build careflow models for all special customers at the beginning. Therefore, a feasible solution would be that with a number of typical models provided, physicians could modify these models based on customer-specific knowledge to generate final customer-tailored careflow models. Realization of this solution requires flexibility to modify the careflow process model, which should be satisfied by the careflow engine.

Results

Careflow modeling involves a vast amount of knowledge, thus the building procedure of careflow model is very complex. To build the model in a cost-effective way, we emphasize the reusability of the model. In this section, we propose a methodology to manage whole lifecycle of the process modeling. We illustrate the system architecture supporting the process modeling and its lifecycle. An example is given to demonstrate the implementation of the careflow system.

Lifecycle of the process modeling

In this part, we design the lifecycle for the careflow process modeling. The steps of the lifecycle are numbered in Fig. 3. The clue of the lifecycle is knowledge, and each step of the lifecycle involves the addition, the translation, the extraction, and feedback of knowledge.

Fig. 3
figure 3

Lifecycle of careflow process modeling

Full size image

Because medical knowledge is stored in the format of textbooks, literature, to ensure efficiency and effectiveness of decision-making, common understandings on CPGs among medical experts should be achieved (Step 1). Nevertheless the guidelines developed by experts are physician oriented, which include little knowledge about HPIP, customers, and organizations.

HPIP service items (including related knowledge diffusion), which are the consulting results from healthcare experts, should be added to the CPGs according to target population and delivering stage of healthcare service (Step 2). The generated guidelines are named care guidelines (CGs).

CGs are still text-based, which could be available online in electronic format. However, CGs are not readily accessible to physicians when they are at the point of care. Due to the limitations of current computer technologies, analyzing unstructured text-based guidelines is not feasible [9]. Thus, text-based CGs should be translated into computer-interpretable care guidelines (CICGs), which is modeled in high-level Petri net [25] in this paper, by healthcare experts and process engineers (Step 3).

Petri net [26], whose mathematical theories and tools are used to support system analysis, is a directed bipartite graph. These theories and tools can be used to analyze the various characteristics of the model, such as, reachability, liveness and soundness. After the process model is established or modified, the soundness property should be verified. However, considering that the size of Petri net model is very large, we use high-level Petri net to represent the computer-interpretable process model in this paper. High-level Petri net is a kind of Petri net, can represent process model in a more succinct way, and can be transformed into executable process define language (such as WPDL [27], BPEL [28], GLIF3 [29]) conveniently. These languages can be executed in WfMS Oracle Workflow, Oracle BPEL Process Manager, or GLEE [29, 30] respectively. In order to ensure the flexibilities of the execution, we use AristaFlow BPM Suite [31–33]. The AristaFlow BPM Suite is the technology of the next generation WfMS for supporting dynamic processes, which realizes the idea of process composition in a “plug & play” style. It supports “correctness by construction” during process composition, and also guarantees correctness in the context of dynamic process changes [32].

After CICGs are generated, it could be diffused to board healthcare organizations. Specialties for different organizations are considered for modifying CICG. During the modifications, CICG is tailored by adding organization knowledge for healthcare localizations (such as adding operators to the task, revising different diagnosis standards) (Step 4), hence forming Organization-Special Careflows (OSCs), which are also represented in forms of high-level Petri nets.

As discussed above, organization knowledge includes organization pattern knowledge and care-related regional difference knowledge. The knowledge is concluded individually by or come from discussions among healthcare service providers (such as medical experts, physicians, nurses, managers, process engineers).

According to customer specific knowledge, selection and modification of OSCs are carried out by consultations between customers and their physicians. As the result, the final customer-centered care plans (CCCPs) are generated (Step 5). It should be noted that a CCCP could be a combination of instances of several different OSCs.

Variations in the course of a healthcare process are normal phenomenon, which is deeply inherent to healthcare. These variations could be caused by many reasons, such as a new progress of the illness, failure of the equipment, trial use of a new medicine. Thus, the running instance of the CCCPs might be frequently modified (Step 6). As the result of these modifications, the actual careflow might deviate from the CCCP plans. For the reasons of legality and knowledge discovery, the actual careflow logs and related data must be saved in case log database (Step 7).

Process mining, which is a kind of knowledge discovery technology, is used to extract knowledge form these logs [34]. The technology mines not only process models but also organizational knowledge. PROM, an open-source framework for process mining [35], is a suitable tool for supporting this technology. The extracted process models can be used to compare with OSCs models to find out the optimal models. These optimal models are added to the OSCs model database for the future utilization. In the meantime, organization knowledge can be revised by referring the mining results. Furthermore, healthcare experts could use the event logs and related data to find or prove potential knowledge, which forms the feedback that would influence the clinical practice guidelines’ revision (Step 8).

The generation of the final CCCPs from knowledge requires a great deal of work and cost a substantial amount of money, which cannot be accomplished by a single physician or organization. Thus, it is of vital importance to make these guidelines consensual and widely used, no matter they are evaluated from an economic or authoritarian consideration. To generate CCCPs in a cost-effective way, we design the diffuse mode of guidelines between organizations in the lifecycle, as shown in Fig. 4.

Fig. 4
figure 4

Guidelines diffuse mode

Full size image

This mode aims to provide better reusability of the guidelines. Currently, there are numerous CPGs published on the internet by medical scientific communities. These CPGs should be diffused to the healthcare scientific communities. These communities add HPIP knowledge in CPGs, and translate the generated CGs into CICGs. In this way, healthcare organizations do not need to establish each CICG individually. They could localize these CICGs to form the OSCs. Physicians only need to adopt and modify these OSCs to establish CCCPs for their customers. In this mode, guidelines can be shared and reused as much as possible, while satisfying the specific needs of different organizations and customers.

As mentioned in the diffuse mode above, a number of the modifications should be taken place. These modifications bring not only flexibility and convenience but also mistakes. These mistakes can be divided into two categories, syntactic mistakes and semantic mistakes.

Syntactic mistakes refer to modifications that lead to an unsoundness of the process (Ability that a process can always terminate properly is called soundness, otherwise called unsoundness [17]). As mentioned above, the careflow model is represented in form of high-level Petri net, and soundness can be verified by Petri net tools. Error messages will be given by these tools if there is any syntactic mistake.

Semantic mistakes come from inaccurate modifications which contradict knowledge (including medical, HPIP knowledge, organizational knowledge, etc.), e.g., excessive drug dose use, careless ignoring the skin test before using penicillin.

To avoid semantic mistakes, restrictions for the process models modification are attached into the tasks in the models when CICGs translated. We classify these restrictions into four levels/kinds based on knowledge would be used during the modification. Three kinds of roles (organization, physician, and customer) and their authority to modify these restrictions are defined in Table 2.

Table 2 Role’s authority of the restrictive levels
Full size table

The restrictions of level four are determined by medical knowledge, thus they cannot be modified by neither individuals nor organizations. As an example of the restriction: a skin test must be executed before using penicillin.

Restrictions of level three can be modified by organizations based on their own organization knowledge, but not individuals. As an example, the healthcare organizations in Guangdong should modify the hemoglobin threshold from 110 g/L to 100 g/L in the careflow model of anemia in pregnancy. This threshold is organization knowledge, which cannot be modified by individuals. As another example is modification model of diagnosing a suspicious fracture. Magnetic Resonance Imaging (MRI) or conventional radiography is recommended in the diagnosing careflow model. If an organization has both types of equipment, the careflow model does not need modification. In the point of care, physician can choose equipment based on the customer’s condition. For a healthcare organization that only has conventional radiography equipment, the route of using magnetic resonance imaging in the model must be removed to prevent mischoices of physician. This kind of modification can only be done by organizations.

Restriction at level two means that tasks in a process model could be modified by physicians based on customer’s condition (customer specific knowledge) and physician’s experience(tacit healthcare knowledge of the physician). For example, for a customer with influenza and a history of penicillin allergy, other drug treatment that both the physician and the customer agree on could be chosen. Also, restrictions in this level can be modified by organization, as these tasks are related to the situation of the organization too.

Restriction at level one means that tasks in a process model can be modified by customers based on their preferences (customer specific knowledge). Such as items involved in a physical examination. Restrictions in this level can be modified by physicians or organization too, for they are closely related to the tasks.

Meanwhile, data security is considered. The EHR data and CCCPs can be only accessed by customers and their physicians. Task executors, such as laboratory technician, radiologist, pharmacist, nurse, can only get their task-related data respectively. After filtered out of personal information and authorized by customers, execution data and related logs could be delivered to healthcare experts and process engineers of the healthcare organization for discovering various knowledge.

Architecture of careflow system

To support the full lifecycle of the customer-centered careflow process modeling, the careflow system architecture is proposed in this section. As shown in Fig. 5, this architecture consists of four layers: data layer, careflow logic layer, careflow management layer, knowledge management layer.

Fig. 5
figure 5

Architecture of careflow system

Full size image

The data layer is the foundation of other layers. The CICGs, which are diffused by the medical scientific communities, are received and stored in the care guideline repository. The OSCs are kept in the organization-special careflow repository. Customer’s health history could be acquired from electronic health records. Referring to these records, physicians adopt and modify OSCs to make CCCPs for their customer. The generated CCCPs are saved in database of customer-centered care plan. The executive logs of the actual careflow are recorded in the case log database. The financial and other related information are stored in the hospital information database.

The careflow logic layer is the kernel layer of the system. The careflow engine implements CCCPs by executing tasks, which is encapsulated in form of services. In this work, we use AristaFlow BPM engine to satisfy the strong flexibility requirement of the modeling methodology. The interaction mechanism between the engine and services is achieved by worklist handler and worklist server. To save cost, some tasks in worklist are handled by legacy systems/applications.

We developed adapter/integration services to encapsulate legacy systems/applications. In legacy healthcare systems/applications, the healthcare process is realized through data exchange. In this way, only simple process can be realized. Also, it is hard to monitor, simulate, analyze, and improve the process. In legacy systems, two categories of data exchange exist. Thus, we use different method to integrate.

One category is exchanging data through database. As shown in Fig. 6a, communication between applications of the legacy systems is realized by writing/reading data item in the database. For example, a customer registers at the department of stomatology. Then a data item is written by registered application to the database. A diagnostic application in the department of stomatology queries the database, and notifies the physician. To integrate legacy system above, we developed adapter/integration services that directly read/write legacy system databases. When the workflow engine invokes the tasks which are running in legacy systems, firstly invoke adapter/integration services to write input data into the database. After the tasks in legacy systems are finished, the careflow system invokes adapter/integration services to read the output data from the database.

Fig. 6
figure 6

Integrations with legacy systems

Full size image

The other category is to use messages, which are typically based on medical communication standards (such as HL7 [36] or DICOM [37]). As shown in Fig. 6b, each legacy application has its own database, and messages are used to enable cooperation between these applications. Developed adapter/integration services invoke these applications by sending/receiving HL7/DICOM message.

Due to the existence of legacy systems and applications, users have to manage a set of authentication credentials (usually the username/password pair). To provide a unified interface of the careflow systems, we use SSO (Single Sign-On) technique. Under SSO, users only need to authenticate once and are automatically logged into all subsequent applications [38].

The careflow management layer offers tools to monitor and manage careflow instance at runtime. The runtime instance editor can modify running instance of the CCCPs, and verify the soundness of the instance. The organization model translator can translate the organization model from owl format to the careflow engine readable form. The careflow monitor could be used to monitor the usage and bottleneck of the resource. It also retains the ability to check up on and force shut-down the running CCCPs.

The knowledge management layer contains tools that used to manage knowledge. The careflow model editor could be used to establish, modify CICGs, allocate tasks to specific positions, and adopt OSCs to generate CCCPs. Nevertheless, it cannot be used to modify runtime careflow instance. The careflow model manager is utilized to manage the editions careflow process models. The organization knowledge editor (protégé) is used to model organization knowledge. Also a HPIP knowledge editor is developed for editing, modifying, and retrieving the knowledge. Process mining tool (PROM) is used to extract knowledge from execution logs.

Example of careflow modeling and execution

In this part, we will use an example of anemia in pregnancy to demonstrate the careflow system. Anemia in pregnancy is common; over half of all women in the world experience it during their pregnancy [39]. Anemia is often caused by iron deficiency. Generally during pregnancy, iron is diverted to fetal erythropoiesis, and also needed to make new blood which can carry the oxygen and nutrients to the fetus.

The first step to generate the CCCPs of anemia in pregnancy is to build CPGs based on medical knowledge. In this example, we acquired CPGs from the National Guideline Clearinghouse and literature [40]. These CPGs and HPIP knowledge items can be managed in careflow system, as shown in Fig. 7.

Fig. 7
figure 7

CPGs management

Full size image

Based on the HPIP knowledge items and CPGs, healthcare experts generate the CGs which are translated into CICG. The translated CICG of anemia in pregnancy is shown in Fig. 8 in the form of high-level Petri net.

Fig. 8
figure 8

CICG of anemia in pregnancy (partly)

Full size image

In this CICG, each task is annotated with different authority, which means different roles may have different authority to modify the CICG. As shown in this CICG, knowledge is diffused to customers before pregnancy. In the early stage of pregnancy, careflow system sends examination notifications. These notifications have many forms, such as notification in careflow system, email, and short message. These forms can be chosen by customers. Afterwards, the task of blood routine examination is taken place. This examination task contains many subtasks. Since this examination is essential for anemic diagnosis, it cannot be modified and level four authority is used. However, different organization has different medical standards of examination. Thus, organization needs level three authority to modify these standards. Based on the examination result, potential route is suggested to physicians and customers. It’s noteworthy that the route is only suggestion of the system, and physicians should choose the optimal route for their customer. Using microcytic anemia as an example, there are many possibilities cause it (e.g. lack of iron, thalassemia, and hereditary sideroblastic anemia). Further examination route is suggested, but not decided, by the system.

Then, the CICG of anemia in pregnancy is diffused to healthcare organizations. Nanfang Hospital in Guangdong province modifies the CICG according to its own organizational knowledge. The generated OSC of anemia in pregnancy is shown in Fig. 9. As shown, some modifications have taken place. The hemoglobin threshold is changed to 100 g/L. Because Guangdong province has particularly high thalassemia (which is a kind of microcytic anemia) rates, hemoglobin electrophoresis is added to microcytic anemic blood examination. Although parasitic infestations are the most common cause of iron deficiency anemia in worldwide [40], few occur in Guangdong. Thus, the parasitic infestation test is removed from CICG. Furthermore, tasks in OSCs are allocated to different operators. For instance, the laboratory technologist performs the blood routine examination, and the careflow system is responsible for notification and knowledge diffusing. In addition, the targets of notification are allocated, e.g., the targets of examination notification task are customers, physicians and laboratory technologists.

Fig. 9
figure 9

OSC of anemia in pregnancy (partly)

Full size image

These OSCs are stored and managed by the careflow system, which can be conveniently accessed and adopted by physicians. The new generated CCCP may contain one or more OSC. For example, the CCCP for a specific customer in pregnancy may include OSCs of anemia in pregnancy, viral hepatitis in pregnancy, and B ultrasound examination in pregnancy. The CCCP of anemia in pregnancy is shown in Fig. 10. Because the physician thought that there is little possibility that the customer has gastrorrhagia, faecal occult blood and endoscopy testing tasks are deleted.

Fig. 10
figure 10

CCCP of anemia in pregnancy (partly)

Full size image

The actual executed route of careflow is shown in Fig. 11. During the execution, the oral iron supplementation led to constipation. The side effect is too strong for the customer to tolerate it. Thus, physician changed the route by using parenteral iron dextran. The interface of the careflow system is shown in Fig. 12. Note that the system only provides the suggestion, but does not make the decision. Physicians make the final decision.

Fig. 11
figure 11

The actual executed careflow of anemia in pregnancy (partly)

Full size image
Fig. 12
figure 12

Interface of the careflow system

Full size image

Conclusion

Customer-centered careflow is becoming an inevitable trend. Compared with traditional careflow, customer-centered careflow emphasizes customer participation and long-term tailored care. Thus, the healthcare process is much more complex, and the establishment and management of these processes are costly. To provide an efficient way to build the process model and offer better reusability of the process model, we have analyzed the knowledge used in process modeling and designed the lifecycle of the process modeling. The purpose of the customer-centered careflow system is to support this lifecycle and manage these process models. In this system, the authority of modification is considered, and technology for invocation and integration of legacy systems is realized. At last, we demonstrate this system with an example.

Future work will focus on automatic parameters matching and tasks dependency inferring based on ontology. To provide a user-friendly interface, we will develop ontology to support automatic parameters matching, helping users add the default operator and match inputs and outputs for a new added task. Besides, when a task is removed, a reminder will notify users to delete the dependency tasks of the removed task if they are not used longer. Furthermore, we will use process mining technology to discover the most frequently used process model, as well as organizational and medical knowledge.