System Implementation and CISs (Introduction to Medical Informatics) (http://www.cpmc.columbia.edu/edu/textbook) LAST REVIEWED: 28 November 1996 CIS = Clinical Information System IMPLEMENTATION impetus from above - based on strategic goals from below - based on user needs or desires needs analysis what inadequacy or inefficiency are you addressing must respond to needs as they are perceived by users (see example in Shortliffe p. 161) in clinical medicine, the basic functions include data acquisition record keeping communications integration surveillance data storage and retrieval data analysis decision support education in medcine, ultimately want to affect quality cost access next step define definition state system's objectives establish priorities warnings computer system does not fix a bad manual system development driven by technology often fails often move to solution too quickly computers don't reduce FTEs; they increase profits build vs buy build can meet exact needs can interface to other systems need team that can build it time: production system is 6 times prototype maintenance if key members leave buy "turn-key" system available more quickly need only team of installers, not builders less risk of getting nothing will not meet the exact needs vendor can maintain and improve system poor interfacing (until HL7?) what if vendor goes out of business buy and modify this is what is done most of the time can be best or worst of both worlds if build: software engineering management of the development process formal system analysis data processes knowledge structured programming testing methodologies project management performance measurement approaches to developing systems 1. waterfall model - perform each process in turn requirements specifications design implementation testing installation maintenance 2. structured anaylsis emphasis on what the system does data flow diagram: processes, data flow, databases 3. rapid prototype + iterative refinement chance to critique system as it grows top-down vs bottom-up analysis everyone really uses both formal approach is not always best miss informal methods of information management succes is largely political, sociological if buy: RA = Requirement Analysis = list of desired capabilities cynical view: but all vendors say yes to everything study of systems development DeMarco and Lister. Peopleware. 500 project histories surveryed since 1977 15% were cancelled, aborted, postponed, never used up to 25% for those that lasted > 24 person-years often no technological issue to explain failure another study 75% of software developed is never used 25% abandoned before completed 50% delivered but never used coding war games: important personnel factors pair of implementors that did not work together medium sized project with fixed specs 1984-1986: 600 developers at 92 companies results: best time to clean compile 2.1 x mean did not matter: language, experience, defects, salary mattered: who your pair was 1st quartile 4th quartile workspace 78 sq ft 46 quiet 58% yes 29 private 62% 19 silence phone 52% 10 divert calls 76% 19 interruptions 38% 76 (are these the cause or effect of good work?) ultimate factors for success leadership - persons responsible for allocate resources resources team - including team leader CLINICAL INFORMATION SYSTEM COMPONENTS in medical informatics communication is the single key issue user and system among systems among users admit-discharge-transfer (ADT) demographics: who is a patient tracking: where are they in the system business and financial charges accounts payable payroll materials management departmental systems often stand-alone, so need to be integrated allows institution to delegate functions that need not be centralized require domain experts to run them (pathology) centralized clinical systems medical records tracking results reporting order entry modern decision support CIS CASE STUDY: HELP System history: late 1970s by Warner, Pryor, Gardner, Clayton, Haug at LDS Hospital/University of Utah 3 important organizing principles optimize response time coded data decision support optimize response time data model: demand for output >> deminad for input therefore make data review faster than storage organize data by logical aggregate or "event" (e.g., BP, CBC) people most frequently review data by event w/i a patient then across events w/i a patient then across patients so, store events chronologically coded data value: free text difficult to parse and retrieve difficult to use in decision support (or any other application except a document display feature) want to use for other purposes besides that for which data are entered data entry: both users and instruments (IV flow; respirators; BP) via GQAP (General Question-Asking Program): allows users to design their own data entry screens easily decision support interpretive messages alerts and reminders (directly to MD or through other personnel, e.g. pharmacist) Clinical areas/interfaces pharmacy, radiology, ICU monitors, ECG, Nursing mgmt, pulmonary, order entry, ADT, medical records Patient Database = 6 files "data file": most inpatient data (e.g., lab results) demographic file charge transaction Master Patient Index: reconcile different identifiers abstract file: case mix and information on each admission (e.g., DRG code) PTXT file: data dictionary PTXT record = 7 fields internal code, cost (if chargeable), format of data, units, accounting procedure code, indexed keywords, text internal code = 8 bytes data class (e.g., antibiotics, chemistry tests) data type (relational or hierarchical model) field code = event in which term is stored final 5 bytes = model-specific (identifies where in relational table or hierarchy the term is stored) thus, allows different data models to be defined for a term (= flexibility; some relationships are better represented hierarchically, others relationally) CIS COMMENTARY why do CISs look so backward compared to current technology is the problem specific to medicine? (no) organization of health care: in hospitals: MDs, RNs do not dictate policy in private practice: insufficient time, resources less resources (2% of revenues vs 10% for others) insufficient examples to copy, lack of local experience focus on applications instead of strategic goals maybe existing systems are good enough future more chief information officers (architect vs czar) increased communications to private offices pocket or bedside terminals cost containment (protocols) related reading: Pryor TA. The HELP medical record systems. M.D. Computing 1988;5(5): 22-33.