The UCLA researchers thought it a brilliant idea to adopt process modelling for health care evaluation in an electronic environment because of its dynamic capacities. The flow chart cycle offers the potential to integrate a continuous quality improvement (CQI) programme in the telehealth service. Unique patient needs can timely find their way into the system as individual variations in the detailed and unambiguous processing. All the steps taken are described top-down in the customer's terms. Wherever procedures might go wrong, the points of failure are identified. A series of contingency plans is defined and prepared to perfection for whenever the need occurs.
Because the flow chart has to be understandable for each party involved in a way that is unequivocal, a standardised notation is applied which is derived from the standard flow chart notation, used in industrial process modelling. The UCLA team has added a few symbols to express requirements specific to the improvement of the telemedicine service quality. These various symbols indicate processes, nested with substeps or not; decision branches, labelled with a yes-or-no-question; states and terminals, which are defined as initial or concluding conditions; resources; documents; and equally multiple choice branches to select among more than two alternative steps.
The flow chart is built top-down, first specifying the telemedicine service in its most high-level, generalised form, and next proceeding in different layers to reach the finest details. A timing diagram clearly illustrates which health professional is responsible for which action in the process. All symbols look like boxes with short describing texts that can be copied in sequence to serve as a procedural manual. A table of responsibilities can easily be drawn from the order in which the process symbols have been arranged within the chart. The flow chart is run through several times for evaluation, modification, and data refinement before the designers will have developed a sufficient number of detailed flow charts to start or proceed with the system implementation.
However, the process modelling approach is no complete bed of roses. One of the major drawbacks to have system developers use it without any reserve is the danger which exists in overanalysing parts of the process when other facets still need process modelling. As such, it is a matter of vast experience and insight to know exactly the right moment to start with implementation. In the end, it might even be possible to select existing flow charts of process models for a whole new telehealth service. In this regard, it is important to consider its features as axes in a 3D coordinate space and the service itself as a region within that space. Ideally, the most suitable process model has its regions contained within the telemedicine site's region.