Payne Practical Guide to Clinical Computing Systems

Design, Operations, and Infrastructure
2. Auflage 2014
ISBN: 978-0-12-799919-7
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 242 Seiten

Although informatics trainees and practitioners who assume operational computing roles in their organization may have reasonably advanced understanding of theoretical informatics, many are unfamiliar with the practical topics - such as downtime procedures, interface engines, user support, JCAHO compliance, and budgets - which will become the mainstay of their working lives. Practical Guide to Clinical Computing Systems 2nd edition helps prepare these individuals for the electronic age of health care delivery. It is also designed for those who migrate into clinical computing operations roles from within their health care organization. A new group of people interested in this book are those preparing for Clinical Informatics board certification in the US. The work provides particular differentiation from the popular first edition in four areas: - 40% more content detailing the many practical aspects of clinical informatics. - Addresses the specific needs of the Clinical Informatics board certification course - for which it is presently recommended by the ABPM - Focus on new tech paradigms including cloud computing and concurrency - for this rapidly changing field. - Focuses on the practical aspects of operating clinical computing systems in medical centers rather than abstruse theory - Provides deepened and broadened authorship with a global panel of contributors providing new wisdom and new perspectives - reflecting inclusion of the first edition on the clinical informatics study guide materials - Presents a practical treatment of workday but often unfamiliar issues - downtime procedures, interface engines, user support, JCAHO compliance, and budgets

Autoren/Hrsg.

Payne, Thomas

Inhaltsverzeichnis

1;Front Cover;1
2;Practical Guide to Clinical Computing Systems: Design, Operations, and Infrastructure;4
3;Dedication;3
4;Copyright;5
5;Contents;6
6;Contributors;10
7;Preface to the Second Edition;12
8;Preface to the First Edition;14
9;Chapter 1: Introduction and Overview of Clinical Computing Systems within a Medical Center;16
9.1;1. The healthcare setting;17
9.2;2. Rising dependence on clinical computing systems;18
9.3;3. The importance of computing operations and support;18
9.4;4. Importance of monitoring performance;20
9.5;5. Real-world problems and their implications;21
9.6;6. Introducing clinical computing systems can introduce errors;22
9.7;7. We need greater emphasis on safe operations of clinical computing systems;23
9.8;References;23
10;Chapter 2: Architecture of Clinical Computing Systems;26
10.1;1. What is architecture, and why is it important?;26
10.2;2. Architectural models;28
10.3;3. Architecture of computing systems in healthcare organizations;29
10.3.1;3.1. Core EHR (Electronic Health Record) Systems;29
10.3.2;3.2. Departmental Systems;30
10.3.2.1;3.2.1. Foundational Systems;30
10.3.2.2;3.2.2. Data Repositories;31
10.3.3;3.3. Interface Engines;31
10.3.4;3.4. Networks, Hosts, Servers, "Middleware," Workstations;31
10.3.5;3.5. Best of Breed versus Suite from a Single Vendor;32
10.4;4. End-user applications: strengths/weaknesses of web and other development choices;33
10.4.1;4.1. Application Delivery;33
10.5;5. Examples of clinical computing architectures;34
10.6;References;37
11;Chapter 3: Creating and Supporting Interfaces;40
11.1;1. Integrating and interfacing applications;41
11.1.1;1.1. What Do We Mean by Integration?;41
11.2;2. HL7 in the real-world;42
11.2.1;2.1. Integration before HL7;42
11.2.2;2.2. What HL7 Stands for;42
11.2.3;2.3. HL7 Definition, History, and Evolution;43
11.2.4;2.4. HL7 Communication Protocols;45
11.3;3. What is needed to succeed with interface development;46
11.3.1;3.1. Foundation;46
11.3.2;3.2. Interface Engines;46
11.3.3;3.3. Interface Development;49
11.3.3.1;3.3.1. Interface Development Methodology;49
11.3.4;3.4 Why isnt Developing an HL7 Interface Easier?;50
11.4;4. Other standards;50
11.4.1;4.1. X12;50
11.4.2;4.2. DICOM;50
11.4.3;4.3. Application Level Standards;51
11.4.4;4.4. Arden Syntax;51
11.5;5. Data exchange and meaningful use;51
11.6;6. Final thoughts regarding interfaces;51
11.7;References;52
12;Chapter 4: Infrastructure;54
12.1;1. Introduction;54
12.2;2. Data centers;55
12.2.1;2.1. Electrical Power;57
12.2.2;2.2. Power Distribution and Backup Power;59
12.2.3;2.3. Cooling;60
12.2.4;2.4. Data Center Reliability;61
12.2.5;2.5. Environmental Protection and Data Center Security;62
12.2.6;2.6. Data Center Management and Remote Data Centers;63
12.2.7;2.7. Future of Data Centers;64
12.3;3. Servers, operating systems, and databases;65
12.4;4. Managing the desktop and other clients;67
12.4.1;4.1. Standardizing Desktop Configurations;69
12.4.2;4.2. Patching, Updating, Cloning, and Inventory;70
12.4.3;4.3. Life Cycle and Desktop Replacement;70
12.4.4;4.4. Windows, Linux, and Mac OS Clients;70
12.4.5;4.5. Virtual Desktops, Single Sign-on, and other Desktop Support Middleware;71
12.5;5. Backup, redundancy, disaster planning, and recovery;71
12.5.1;5.1. Reliability, Availability, and Redundancy;71
12.5.2;5.2. Availability, Failures, and Backups;72
12.5.3;5.3. Disasters, Disaster Recovery, and Business Continuity;74
12.6;6. Operations;77
12.6.1;6.1. Daily Operations;78
12.6.2;6.2. Infrastructure Support and other Related Activities;79
12.6.3;6.3. Organizational Planning and other Organizational Activities;80
12.7;7. Cloud computing and outsourcing;82
12.8;8. Summary;83
12.9;References;84
13;Chapter 5: Security;86
13.1;1. Introduction;86
13.2;2. Security;87
13.2.1;2.1. Assets;88
13.2.2;2.2. Threats;89
13.2.3;2.3. Controls and Vulnerability;90
13.2.3.1;2.3.1. Network Level Controls;91
13.2.3.2;2.3.2. Computer Level Controls;92
13.2.3.3;2.3.3. Application and Data Level Controls;93
13.2.4;2.4. Risk Assessment;93
13.2.5;2.5. Security Incidents and Sanctions;95
13.3;3. Summary;95
13.4;References;96
14;Chapter 6: From Project to Operations;98
14.1;1. Introduction;98
14.2;2. System acquisition;99
14.2.1;2.1. Organizational Readiness;99
14.2.2;2.2. Understand the Drivers in your Decision to Implement a Clinical System;100
14.2.3;2.3. Recipe for Success;100
14.2.3.1;2.3.1. Organizational Will;100
14.2.3.2;2.3.2. Clinical/Operations Ownership and Leadership;100
14.2.3.3;2.3.3. Information Technology Skill and Experience;101
14.2.4;2.4. Request for Proposal Process;101
14.2.4.1;2.4.1. Defining Requirements;101
14.2.4.2;2.4.2. Relationship to Contract;102
14.2.4.3;2.4.3. Decision-making;102
14.2.4.4;2.4.4. Contract Negotiation;102
14.2.4.5;2.4.5. Budget;103
14.3;3. Project phase;103
14.3.1;3.1. Project Structure;104
14.3.2;3.2. Building and Retaining a Team;104
14.3.3;3.3. Management;106
14.3.4;3.4. Implementation Methodology-Follow the Recipe;106
14.3.4.1;3.4.1. Planning;107
14.3.4.2;3.4.2. Design;107
14.3.4.3;3.4.3. Building the System;108
14.3.4.4;3.4.4. Testing;109
14.3.4.4.1;3.4.4.1. Unit Testing;110
14.3.4.4.2;3.4.4.2. Application Testing;110
14.3.4.4.3;3.4.4.3. Integration Testing;110
14.3.4.4.4;3.4.4.4. Regression Testing;110
14.3.4.4.5;3.4.4.5. Peripheral Device Testing;111
14.3.4.4.6;3.4.4.6. Performance Stress/Volume Testing;111
14.3.4.5;3.4.5. Training;111
14.4;4. Summary;112
14.5;Reference;112
15;Chapter 7: Implementation and Transition to Operations;114
15.1;1. Introduction;114
15.2;2. Background;115
15.3;3. Planning for implementation;116
15.3.1;3.1. Project Personnel;116
15.3.2;3.2. Project Governance and Change Management;116
15.3.3;3.3. Benefits Achievement;116
15.4;4. Designing and building the system;117
15.4.1;4.1. Orders and Clinical Decision Support;117
15.4.2;4.2. Documentation and Results Review;117
15.5;5. Testing the system;118
15.6;6. Training, activation, and go-live support;118
15.7;7. Transition to operations and optimization;119
15.7.1;7.1. Downtime Planning;120
15.7.2;7.2. Business Continuity;120
15.7.3;7.3. Business Resumption;122
15.7.4;7.4. Incorporation into Emergency Management and Disaster Planning;122
15.8;8. Conclusions;122
15.9;References;123
16;Chapter 8: Troubleshooting;126
16.1;1. The grand challenge: complex systems;127
16.1.1;1.1. Evolution and Plasticity;127
16.1.2;1.2. Sustainability of Resources and Means;128
16.1.3;1.3. Migration;128
16.1.4;1.4. Non-stop Operation;129
16.1.5;1.5. Growth and Interoperability;131
16.1.6;1.6. Education, Change Management, and Inertia;131
16.2;2. Digging into reality: perfect redundancy...myth or reality?;132
16.2.1;2.1. Background;132
16.2.2;2.2. A Few Numbers;133
16.2.3;2.3. Technical Architecture;133
16.2.3.1;2.3.1. Two Locations;133
16.2.3.2;2.3.2. Redundant Technical Infrastructure;134
16.2.3.3;2.3.3. Thirty External Facilities;135
16.2.3.4;2.3.4. Standards, Standards, Standards;136
16.2.4;2.4. An Example of System Failure;136
16.2.4.1;2.4.1 The Grain of Sand;136
16.2.4.2;2.4.2. Never Believe Probabilities;138
16.2.5;2.5. So Why Pay so Much for Redundancy, if it is of No Use?;139
16.2.6;2.6. Is Monitoring the Answer?;139
16.3;3. How to deal with troubleshooting: mitigation strategies;140
16.3.1;3.1. "Anything Can Go Wrong, and Something Will Go Wrong";140
16.3.2;3.2. Awareness;141
16.3.3;3.3. Leadership;141
16.3.4;3.4. Handling Unplanned Outages;141
16.3.5;3.5. Competences and Education;142
16.3.6;3.6. Transparency;145
16.3.7;3.7. Accountability;145
16.3.8;3.8. An Important Tool: Traceability (Security Information Management);145
16.4;4. Conclusion;150
17;Chapter 9: Working with the User Community;152
17.1;1. Training and support;152
17.1.1;1.1. Strategic Vision for Training and Support;153
17.1.2;1.2. User Training;153
17.1.3;1.3. User Support;155
17.1.4;1.4. Training Tactics;156
17.1.5;1.5. Cost Considerations;159
17.2;2. MULTI-EMR environment considerations;160
17.3;3. Communications;161
17.3.1;3.1. Strategic Vision for Communication;161
17.3.2;3.2. Care Coordination Dimensions;162
17.3.3;3.3. Technical and Practical Challenges;163
17.4;4. Leadership and user engagement;165
17.5;5. Organizing teams and systems to work with users;165
17.6;6. Role of the help desk;166
17.7;7. Future trends;167
17.8;References;167
18;Chapter 10: Health Information Management and the EMR;168
18.1;1. Uses of the emr;169
18.1.1;1.1. The EMR Allows Clinical Information to be Available at the Point of Care;169
18.2;2. Goals of health information management within the medical centers;169
18.2.1;2.1. Typical Categories or Sections of a Medical Record;170
18.3;3. Hybrid of medical record media;172
18.3.1;3.1. How Information is Entered into the EMR;172
18.4;4. The transition to the emr takes years;173
18.5;5. Health information management;173
18.5.1;5.1. Coding Classification and Payment System;174
18.5.2;5.2. HIM Dictation and Transcription Services;177
18.5.3;5.3. Medical Record Analysis and Completion Monitoring;178
18.5.4;5.4. Document Imaging;178
18.5.5;5.5. Database Management;179
18.5.5.1;5.5.1. Master Patient Index (MPI);179
18.5.5.2;5.5.2. Provider Database;179
18.5.5.3;5.5.3. Release of Information;180
18.5.5.4;5.5.4. HIM Credentials and Certifications;180
18.5.5.4.1;Health Information Management;180
18.5.5.4.2;Coding;180
18.5.5.4.3;Healthcare Privacy and Security;180
19;Chapter 11: Legal Issues in Medical Records/Health Information Management;182
19.1;1. Organizational groups and regulations that affect medical records;183
19.1.1;1.1. Medical Staff Bylaws, Policy, and Procedures;183
19.1.2;1.2. Health Information Management (HIM) Committee;184
19.1.3;1.3. The Health Information Management Department;186
19.2;2. Federal laws and entities that affect medical records;187
19.2.1;2.1. Health Information Portability and Accountability Act (HIPAA);187
19.2.2;2.2. Centers for Medicare and Medicaid Services (CMS);188
19.3;3. State laws that affect medical record documentation;190
19.4;4. The joint commission;190
19.4.1;4.1. Information Management (IM) and Record of Care and Treatment (RC) Standards;191
19.4.2;4.2. Medical Staff Standards Related to HIM;191
19.4.3;4.3. Monitoring;192
19.5;5. Government mandates that impact him;192
19.5.1;5.1. American Recovery and Reinvestment Act;192
19.5.2;5.2. ICD-10;193
19.6;6. Conclusion;193
19.7;7. Links to additional information;193
20;Chapter 12: Working with Organizational Leadership;194
20.1;1. The leadership landscape-the information revolution;194
20.2;2. Shaping a new leadership landscape driven by health it;195
20.3;3. Developing new leaders;197
20.4;4. Working with organizational leaders on strategic change;199
20.4.1;4.1. Single System;200
20.4.2;4.2. Connectedness;203
20.4.3;4.3. Big Data;204
20.5;5. Leadership toolkits;206
20.6;6. Integrating the enterprise using information technology;207
21;Chapter 13: Careers in Biomedical Informatics and Clinical Computing;210
21.1;1. Introduction;210
21.2;2. The biomedical informatics workforce;215
21.3;3. Education and training in biomedical informatics;221
21.3.1;3.1. Competencies in Biomedical Informatics;221
21.3.2;3.2. Professional Certification in Biomedical Informatics;222
21.3.3;3.3. Education and Training in Biomedical Informatics;224
21.4;4. Resources;227
21.4.1;4.1. Professional HIT/Informatics Societies;227
21.4.2;4.2. HIT/Informatics Publications;228
21.4.3;4.3. HIT/Informatics Websites;228
21.5;5. Conclusions;229
21.6;References;231
22;Index;236

Leseproben

Chapter 2

Architecture of Clinical Computing Systems

Thomas H. Payne1; Kent A. Beckton2    1 Medical Director, Information Technology Services, UW Medicine; Associate Professor, Department of Medicine; Adjunct Associate Professor; Department of Biomedical Informatics and Medical Education and Department of Health Services, University of Washington, Seattle, WA USA
2Director, Technical Architecture, Information Technology Services, UW Medicine, Seattle, WA USA

Abstract

The purpose of this chapter is to give an overview of the fundamentals of clinical computing system architectures. This is changing with the advent of cloud computing and sophistication of web applications, but most large organizations follow architectural models that have been in place for decades.

Keywords

architectural models

electronic medical record

computerized physician order entry

HL7

electronic health record

best-of-breed solutions

workstations

Contents

1. What is architecture, and why is it important?   11

2. Architectural models   13

3. Architecture of computing systems in healthcare organizations   14

3.1 Core EHR (electronic health record) systems   14

3.2 Departmental systems   15

3.2.1 Foundational systems   15

3.2.2 Data repositories   16

3.3 Interface engines   16

3.4 Networks, hosts, servers, “middleware,” workstations   16

3.5 Best of breed versus suite from a single vendor   17

4. End-user applications: strengths/weaknesses of web and other development choices   18

4.1 Application delivery   18

5. Examples of clinical computing architectures   19

References   22

1 What is architecture, and why is it important?

To build a medical center requires expertise in engineering, human factors, design, medicine, and also architecture. It is the architect who melds design and function with engineering and practicality. We look to the architect to keep parts functioning together, and to plan for changes and additions that fit with the original design. Similarly, clinical computing systems have an architecture and often an architect behind them. Particularly in an era when most organizations license software from multiple computing system vendors, it is important to maintain an overall architecture to meet the organization’s current and future needs.

The goals of a good architecture are that the resulting system:

• Is scalable

• Is supportable

• Is cost effective

• Is flexible for innovations

• Is available for intended use

• Has acceptable performance

• Has functional processes for testing and change

Architecture varies between organizations. Making the organization’s architecture clear permits vendors to offer and supply elements needed within the architecture. For example, where are Master Patient Index services provided? Are departmental systems from a single vendor or several vendors? An additional challenge is that the application vendor’s architecture is often different from the organization’s architecture.

When components or systems are developed by internal teams, the relationship between existing and newly developed systems is understood by review of the architecture and understanding of messaging and other standards used within it. Similarly, when healthcare organizations combine computing resources as a result of a merger or in another manner, existing systems or components may be combined to form the computing of the new, larger entity. How will all these components fit together? What will be shared or duplicated?

When teams within the organization plan upgrades, improvements in availability, software and hardware changes, they are better able to plan when there is a shared understanding of how the components within their responsibility relate to other elements in the organizational clinical computing architecture. Clear description of the architecture makes implications for planned changes clearer. Long-term planning (by IT teams and executives) for migration of systems, hardware, and computing infrastructure can be better understood by examining the larger view. For clinical informaticians supporting healthcare organizations, understanding architecture can aid troubleshooting in a similar manner as an understanding of human anatomy aids diagnostic reasoning.

The purpose of this chapter is to give an overview of the fundamentals of clinical computing system architectures. This is changing with the advent of cloud computing and sophistication of web applications, but most large organizations follow architectural models that have been in place for decades.

2 Architectural models

The simplest clinical computing system architecture is a single system, with a single database in which all data are shared between applications such as patient registration, laboratory, radiology, and others. Such a system may be developed within the organization or licensed from a single vendor. Early in the history of clinical computing, this model was common. Applications may have been based on a single vendor’s hardware and database management systems, with new applications added as new screens or small applications within the larger whole. Using this simple architectural model, data stored in one location could be much more easily shared between applications. For example, when a patient is registered, demographic information is stored in a database file. The laboratory module from the same system accesses the demographic information from the same database, as do the radiology and pharmacy applications. This sort of collection of applications developed from the same core system is said to be integrated together, in that they are all parts of a single, large system.

In medical centers and large clinics—the targets of this book—that simple architectural model rarely applies to clinical computing systems in use today. There are usually many separately designed computing systems, each contributing a portion of the data and functionality used in clinical care. Medical centers combine data and application functionality from many separate computer systems, some of which may be used by a large number of those involved in patient care, while others may be used by a small number of people specializing in some aspect of care. Instead of sharing a common database, many or all of these smaller applications have their own. To save the cost of re-entering information into each system, and to share data that each system contains, data are exchanged through connections called interfaces. For this reason, this model is referred to as interfaced systems.

In most organizations, the clinical computing architecture includes components of both these archetypes: integrated and interfaced systems. There may be a large core system containing integrated applications, and many smaller systems connected to this large system using interfaces. There are other methods that we describe later to permit users to view data originating from separate, smaller systems without realizing they are navigating to other systems.

Some clinical computing systems are presented to the user as a web application, and some have core services delivered through the cloud (see Chapter 4). This makes a difference in where the hardware providing functionality is located and maintained, but cloud applications can also be integrated or interfaced. If the cloud EMR (electronic medical record) is connected to a local laboratory and radiology system, the overall architecture is similar to an interfaced system as described above. Conversely, if most system components are within the cloud-based system, it resembles an integrated architecture.

The organizational clinical computing architecture defines how all the component systems fit together, how they exchange information, standards used within systems and in interfaces, what shared services exist for the benefit of all computing systems, and many other issues.1

An important starting point in planning an architecture is to establish standards, such as use of HL7 (Health Level 7). There may be more than one variation of the standard used within the organization, and this should be made explicit. Plan the architecture with an eye towards the future, and stay apprised of technical innovations.

3 Architecture of computing systems in healthcare...