The data flow diagram is one of the most commonly used systems-modeling tools, particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates. DFDs were first used in the software engineering field as a notation for studying systems design issues (e.g., in early structured design books and articles such as (Stevens, Myers, and Constantine. 1974), (Yourdon and Constantine, 1975), (Myers, 1975), et al.). In turn, the notation had been borrowed from earlier papers on graph theory, and it continues to be used as a convenient notation by software engineers concerned with direct implementation of models of user requirements (Yourdon, 1988)
The Data Flow Diagram (DFD) method is an element of object-oriented analysis and is widely used. Some advantages include (Le Vie, 2000):
Use of DFDs promotes quick and relatively easy project code development DFDs are easy to learn with their few-and-simple-to-understand symbols (once you decide on a particular DFD model) The syntax used for DFDs is simple, employing English nouns, or noun-adjective-verb constructs Good for functional decomposition
DFDs for large systems can be cumbersome, difficult to translate, and read, and be time-consuming in their construction Data flow can be confusing to programmers DFDs are useless without the pre-requisite detail Different DFD models employ different symbols (circles and rectangles, for example, for entities) Can’t distinguish data and control signals
Current Uses in the Health Care System
Using Data Flow Diagrams to identify and prevent product & process problems before they occur (in health care processes from prescription, up to and including administration of chemotherapy (vincristine) in the pediatric oncology inpatient setting)
The VHA, with assistance from the director of risk assessment and loss prevention at Tenet HealthSystem, developed Healthcare Failure Mode and Effect Analysis (HFMEA) as "a systematic approach to identify and prevent product and process problems before they occur.”
Five key steps are involved in conducting an HFMEA analysis:
Define the HFMEA topic. This should include a clear definition of the process to be studied. Assemble the HFMEA team. The personnel should be multidisciplinary and include subject matter experts and an adviser. Graphically describe the process. Develop a flow diagram; number each process step; identify the area of the process to focus on; identify all sub-processes; create a flow diagram of the sub-process. Conduct a failure analysis. List all possible failure modes under the key sub-process; determine the severity and probability of each potential failure mode; use a Decision Tree to determine if the failure mode warrants further action; list all failure mode causes where the decision has been made to proceed.
Evaluate actions and outcome measures. Determine if you want to eliminate, control, or accept each failure mode cause; identify a description of action for each failure mode to be controlled or eliminated; identify outcome measures to test the redesigned process; identify an individual responsible for completing the action; indicate whether top management concurs with the recommended action (van Tilberg, 2005) An Example:
The Michigan Department of Community Health is launching a project called: Implementation of a Statewide Information System for Sickle Cell Disease in Michigan (Principal Investigator: Corinne Miller, MD)
The purpose of the project is to develop a state-wide information system to provide a method of supporting and evaluating a seamless system for the early detection, proper management and treatment of sickle cell disease and other complications of sickle cell disease.
The first year will involve meeting with the project advisory committee, hiring a change management specialist, verifying detailed flow charts of data flows to and from each partner, purchasing necessary hardware, and programming software. The directors of the partner organizations will identify follow-up protocols for sickle cell disease to be programmed into the DocSite program. The interest and willingness of physicians to utilize the DocSite program will be assessed by survey. During the second year, the partner organizations will begin pilot testing the DocSite software.
MDCH staff will then modify the program and develop user manuals. MDCH staff will also begin disseminating information about the information system to other programs and physicians, through internal meetings with Children with Special Health Care Services, and professional meetings in Michigan. The staff will plan a state-wide conference for physicians and relevant social service program personnel to demonstrate the information system and provide a training .in use of the system. MDCH staff will be available to train
Individual physicians or other program personnel as requested. Quality assurance, data monitoring (which will make use of data flow diagrams), and program evaluation will occur continuously throughout the implementation period. Specific clinical measures, such as time to prophylactic antibiotic will also be collected and compared to baseline measures. Periodic surveys of families will also be conducted.
Authors Krol M. and Reich D. L. have created an object-oriented analysis and design of a Health Care Management Information System.
They have created a prototype for a universal object-oriented model of a health care system compatible with the object-oriented approach used in version 3.0 of the HL7 standard for communication messages. A set of three models has been developed: (1) the Object Model describes the hierarchical structure of objects in a system—their identity, relationships, attributes, and operations; (2) the Dynamic Model represents the sequence of operations in time as a collection of state diagrams for object classes in the system; and (3) functional Diagram represents the transformation of data within a system by means of data flow diagrams. Within these models, we have defined major object classes of health care participants and their subclasses, associations, attributes and operators, states, and behavioral scenarios. We have also defined the major processes and sub-processes.
Data Flow Diagrams to create scenarios for the effective management of disease outbreaks.
Smallpox is significantly more complex; therefore, flow design is broadly divided into pre-event and post-event scenarios (ex. pre-event mass vaccination campaign). DFDs will be used to facilitate the patient flow into the stations (ex. Symptomatic patients are treated immediately).(Hupert, 2004).
Flow diagrams provide an aid to trialists when writing trial results and assist readers in the critical appraisal of the internal and external validity of a trial.
Characteristics of flow diagrams used for trials yielded results for eligibility. Sixty-five diagrams (46.8%) included the number of patients assessed for eligibility, and 94 (67.6%) reported the number found to be eligible. The number assigned to each study group was reported in 129 flow diagrams (92.8%), and 73 (52.5%) indicated whether interventions had been received as allocated. Most flow diagrams (114 [82.0%]) indicated how many patients in each group were lost to follow-up, but only 32 (23.0%) reported the number included in the analysis (Egger, 2001).
Data Flow diagrams are associated with improved quality of reporting of randomized controlled trials, and an increased efficiency of information flow. However, the structure of current flow diagrams is less than ideal (see disadvantages). More research should be done for the construction of DFDs that will perfectly complement the Health Care Industry.