The Clinical Business Process

Clinical business processes are the tasks that are undertaken to reach a particular care delivery objective. For example, booking an appointment, ordering an investigation, prescribing a drug and recording an admission all represent common processes with which most clinicians will be familiar. Each of these processes consists of a series of discrete steps involving a number of actors, one of which will typically be the patient. 

For example in a prescribing and drug administration process a clinician might take the following steps  

Review current medications, clinical conditions and allergies 

There may, in addition, be conditional branches in the process which only occur under certain circumstances, the medication is contraindicated, the patient is absent when the medication needs to be administered, etc. The processes can usually be mapped out quite easily using nse case diagrams, flow charts, user stories or other tools. What is key when looking at the clinical bnsiness process is that the steps are agnostic abont the tools which are nsed to achieve the objective, i.e. whether a particular electronic solntion is ntilised, paper systems or by some other means. The processes remain entirely in the clinical domain without any mention of screens, interfaces, data or hardware. 

---

Workflow - embodies the clinical business processes in which users operate in order to deliver care as well as the procedures to enter, process and retrieve data from the system. The workflows may be formally documented and agreed coexist culturally as a result of training and experience. Established local work-flows of course may or may not have been taken into consideration in the design of a particular HIT system. 

The clinical business processes and workflows that the system will support... 

System business processes are the steps undertaken to achieve a particular objective in the HIT solution under examination. Thus, this aspect of the assessment allows the processes derived from the clinical business process analysis to be augmented with individual system interactions and behaviours. For example, consider the following flow ... 

Note the key difference from our examination of the clinical business process each step is a system interaction or system behaviour rather than a description of what individuals are doing or thinking. 

Remember that not all system business processes are necessarily associated with an obvious clinical business process but they might still have the potential to impact cUnical care. For example, there may be a system background task to find information in the database which has become detached from a patient record. Any association with a clinical business process is not immediately obvious but clearly, should the process fail to execute, this could contribute to harm (or at least represent an unreliable control). There is nearly always therefore the need to consider both clinical and system business processes in their own right. 

Tracing the system and clinical business processes throngh in a logical end-to-end manner ensures that hazards and causes are not missed. The methodology itself is an important component of the SMS as its application demonstrates attention to completeness, logical thonght and confidence. 

It is naive to think that all HIT systems, in aU care settings, influence clinical care to the same extent. The reality is that there is a broad spectrum ranging from those systems which hardly touch clinical business processes to those on which clinicians utterly rely. Similarly, the same system implemented in different settings may influence care to different degrees. Even when one studies individual users there will typically be variability in the significance that a system plays in their day-to-day delivery of care. Whilst one cannot separately evaluate a hazard for each individual... 

The degree of clinical dependency is strongly influenced by the role that the HIT system plays in a particular clinical business process. The role itself is affected by the functionality provided, the maturity of its implementation and the clinician s ability to access alternative sources of information. Table 14.1 outlines the relationship between a system s influence on care delivery and its ability to affect clinical decision making. 

Whether the defect affects a clinical business process known to be associated with significant clinical risk. 

What clinical business process is the system supporting What does this system/ function do under normal conditions ... 

A proof of concept (or development of a prototype) is a key step in the clinical translation process. It demonstrates that it is possible to translate the idea or solution into a product (albeit premature) that possesses the desired performance characteristics and that it can be assembled at a reasonable cost. A proof of concept is important in convincing potential grant supporters or investors. A proof of concept also allows one to refine the manufacturing process and cost of the product for marketing and business planning. 

The second gap in the drug development process occurs when pre-clinically validated candidate drugs fail to enter the clinical study phase because of profit-minded choices made by pharmaceutical companies. While it is not as expensive to develop drugs as the pharmaceutical lobby claims, it is still a costly and risky business (MSF 2001 17). Where a substantial reward at the end of the development process is clearly absent, corporate decision-makers are ill disposed to incur this risk. 

The NICE has a board reflecting a range of expertise including the clinical professions, patients and user groups, NHS managers, and research bodies. The Board ensures that the NICE conducts its business on behalf of the NHS in the most effective manner. Details of the appraisal process and membership of the Appraisals Committee are available on the NICE Web site (www.nice.org.uk). Because the NICE was new at the time of completion of this article, its impact on the pharmaceutical industry is still not clear. 

---