Practical Guide to Clinical Computing Systems (eBook)

Design, Operations, and Infrastructure

Thomas Payne (Herausgeber)

eBook Download: PDF | EPUB

2014 | 2. Auflage
242 Seiten
Elsevier Science (Verlag)
978-0-12-799919-7 (ISBN)

Infos

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.

Inhalt

Front Cover 1
Practical Guide to Clinical Computing Systems: Design, Operations, and Infrastructure 4
Dedication 3
Copyright 5
Contents 6
Contributors 10
Preface to the Second Edition 12
Preface to the First Edition 14
Chapter 1: Introduction and Overview of Clinical Computing Systems within a Medical Center 16
1. The healthcare setting 17
2. Rising dependence on clinical computing systems 18
3. The importance of computing operations and support 18
4. Importance of monitoring performance 20
5. Real-world problems and their implications 21
6. Introducing clinical computing systems can introduce errors 22
7. We need greater emphasis on safe operations of clinical computing systems 23
References 23
Chapter 2: Architecture of Clinical Computing Systems 26
1. What is architecture, and why is it important? 26
2. Architectural models 28
3. Architecture of computing systems in healthcare organizations 29
3.1. Core EHR (Electronic Health Record) Systems 29
3.2. Departmental Systems 30
3.2.1. Foundational Systems 30
3.2.2. Data Repositories 31
3.3. Interface Engines 31
3.4. Networks, Hosts, Servers, "Middleware," Workstations 31
3.5. Best of Breed versus Suite from a Single Vendor 32
4. End-user applications: strengths/weaknesses of web and other development choices 33
4.1. Application Delivery 33
5. Examples of clinical computing architectures 34
References 37
Chapter 3: Creating and Supporting Interfaces 40
1. Integrating and interfacing applications 41
1.1. What Do We Mean by Integration? 41
2. HL7 in the real-world 42
2.1. Integration before HL7 42
2.2. What HL7 Stands for 42
2.3. HL7 Definition, History, and Evolution 43
2.4. HL7 Communication Protocols 45
3. What is needed to succeed with interface development 46
3.1. Foundation 46
3.2. Interface Engines 46
3.3. Interface Development 49
3.3.1. Interface Development Methodology 49
3.4 Why isnt Developing an HL7 Interface Easier? 50
4. Other standards 50
4.1. X12 50
4.2. DICOM 50
4.3. Application Level Standards 51
4.4. Arden Syntax 51
5. Data exchange and meaningful use 51
6. Final thoughts regarding interfaces 51
References 52
Chapter 4: Infrastructure 54
1. Introduction 54
2. Data centers 55
2.1. Electrical Power 57
2.2. Power Distribution and Backup Power 59
2.3. Cooling 60
2.4. Data Center Reliability 61
2.5. Environmental Protection and Data Center Security 62
2.6. Data Center Management and Remote Data Centers 63
2.7. Future of Data Centers 64
3. Servers, operating systems, and databases 65
4. Managing the desktop and other clients 67
4.1. Standardizing Desktop Configurations 69
4.2. Patching, Updating, Cloning, and Inventory 70
4.3. Life Cycle and Desktop Replacement 70
4.4. Windows, Linux, and Mac OS Clients 70
4.5. Virtual Desktops, Single Sign-on, and other Desktop Support Middleware 71
5. Backup, redundancy, disaster planning, and recovery 71
5.1. Reliability, Availability, and Redundancy 71
5.2. Availability, Failures, and Backups 72
5.3. Disasters, Disaster Recovery, and Business Continuity 74
6. Operations 77
6.1. Daily Operations 78
6.2. Infrastructure Support and other Related Activities 79
6.3. Organizational Planning and other Organizational Activities 80
7. Cloud computing and outsourcing 82
8. Summary 83
References 84
Chapter 5: Security 86
1. Introduction 86
2. Security 87
2.1. Assets 88
2.2. Threats 89
2.3. Controls and Vulnerability 90
2.3.1. Network Level Controls 91
2.3.2. Computer Level Controls 92
2.3.3. Application and Data Level Controls 93
2.4. Risk Assessment 93
2.5. Security Incidents and Sanctions 95
3. Summary 95
References 96
Chapter 6: From Project to Operations 98
1. Introduction 98
2. System acquisition 99
2.1. Organizational Readiness 99
2.2. Understand the Drivers in your Decision to Implement a Clinical System 100
2.3. Recipe for Success 100
2.3.1. Organizational Will 100
2.3.2. Clinical/Operations Ownership and Leadership 100
2.3.3. Information Technology Skill and Experience 101
2.4. Request for Proposal Process 101
2.4.1. Defining Requirements 101
2.4.2. Relationship to Contract 102
2.4.3. Decision-making 102
2.4.4. Contract Negotiation 102
2.4.5. Budget 103
3. Project phase 103
3.1. Project Structure 104
3.2. Building and Retaining a Team 104
3.3. Management 106
3.4. Implementation Methodology-Follow the Recipe 106
3.4.1. Planning 107
3.4.2. Design 107
3.4.3. Building the System 108
3.4.4. Testing 109
3.4.4.1. Unit Testing 110
3.4.4.2. Application Testing 110
3.4.4.3. Integration Testing 110
3.4.4.4. Regression Testing 110
3.4.4.5. Peripheral Device Testing 111
3.4.4.6. Performance Stress/Volume Testing 111
3.4.5. Training 111
4. Summary 112
Reference 112
Chapter 7: Implementation and Transition to Operations 114
1. Introduction 114
2. Background 115
3. Planning for implementation 116
3.1. Project Personnel 116
3.2. Project Governance and Change Management 116
3.3. Benefits Achievement 116
4. Designing and building the system 117
4.1. Orders and Clinical Decision Support 117
4.2. Documentation and Results Review 117
5. Testing the system 118
6. Training, activation, and go-live support 118
7. Transition to operations and optimization 119
7.1. Downtime Planning 120
7.2. Business Continuity 120
7.3. Business Resumption 122
7.4. Incorporation into Emergency Management and Disaster Planning 122
8. Conclusions 122
References 123
Chapter 8: Troubleshooting 126
1. The grand challenge: complex systems 127
1.1. Evolution and Plasticity 127
1.2. Sustainability of Resources and Means 128
1.3. Migration 128
1.4. Non-stop Operation 129
1.5. Growth and Interoperability 131
1.6. Education, Change Management, and Inertia 131
2. Digging into reality: perfect redundancy...myth or reality? 132
2.1. Background 132
2.2. A Few Numbers 133
2.3. Technical Architecture 133
2.3.1. Two Locations 133
2.3.2. Redundant Technical Infrastructure 134
2.3.3. Thirty External Facilities 135
2.3.4. Standards, Standards, Standards 136
2.4. An Example of System Failure 136
2.4.1 The Grain of Sand 136
2.4.2. Never Believe Probabilities 138
2.5. So Why Pay so Much for Redundancy, if it is of No Use? 139
2.6. Is Monitoring the Answer? 139
3. How to deal with troubleshooting: mitigation strategies 140
3.1. "Anything Can Go Wrong, and Something Will Go Wrong" 140
3.2. Awareness 141
3.3. Leadership 141
3.4. Handling Unplanned Outages 141
3.5. Competences and Education 142
3.6. Transparency 145
3.7. Accountability 145
3.8. An Important Tool: Traceability (Security Information Management) 145
4. Conclusion 150
Chapter 9: Working with the User Community 152
1. Training and support 152
1.1. Strategic Vision for Training and Support 153
1.2. User Training 153
1.3. User Support 155
1.4. Training Tactics 156
1.5. Cost Considerations 159
2. MULTI-EMR environment considerations 160
3. Communications 161
3.1. Strategic Vision for Communication 161
3.2. Care Coordination Dimensions 162
3.3. Technical and Practical Challenges 163
4. Leadership and user engagement 165
5. Organizing teams and systems to work with users 165
6. Role of the help desk 166
7. Future trends 167
References 167
Chapter 10: Health Information Management and the EMR 168
1. Uses of the emr 169
1.1. The EMR Allows Clinical Information to be Available at the Point of Care 169
2. Goals of health information management within the medical centers 169
2.1. Typical Categories or Sections of a Medical Record 170
3. Hybrid of medical record media 172
3.1. How Information is Entered into the EMR 172
4. The transition to the emr takes years 173
5. Health information management 173
5.1. Coding Classification and Payment System 174
5.2. HIM Dictation and Transcription Services 177
5.3. Medical Record Analysis and Completion Monitoring 178
5.4. Document Imaging 178
5.5. Database Management 179
5.5.1. Master Patient Index (MPI) 179
5.5.2. Provider Database 179
5.5.3. Release of Information 180
5.5.4. HIM Credentials and Certifications 180
Health Information Management 180
Coding 180
Healthcare Privacy and Security 180
Chapter 11: Legal Issues in Medical Records/Health Information Management 182
1. Organizational groups and regulations that affect medical records 183
1.1. Medical Staff Bylaws, Policy, and Procedures 183
1.2. Health Information Management (HIM) Committee 184
1.3. The Health Information Management Department 186
2. Federal laws and entities that affect medical records 187
2.1. Health Information Portability and Accountability Act (HIPAA) 187
2.2. Centers for Medicare and Medicaid Services (CMS) 188
3. State laws that affect medical record documentation 190
4. The joint commission 190
4.1. Information Management (IM) and Record of Care and Treatment (RC) Standards 191
4.2. Medical Staff Standards Related to HIM 191
4.3. Monitoring 192
5. Government mandates that impact him 192
5.1. American Recovery and Reinvestment Act 192
5.2. ICD-10 193
6. Conclusion 193
7. Links to additional information 193
Chapter 12: Working with Organizational Leadership 194
1. The leadership landscape-the information revolution 194
2. Shaping a new leadership landscape driven by health it 195
3. Developing new leaders 197
4. Working with organizational leaders on strategic change 199
4.1. Single System 200
4.2. Connectedness 203
4.3. Big Data 204
5. Leadership toolkits 206
6. Integrating the enterprise using information technology 207
Chapter 13: Careers in Biomedical Informatics and Clinical Computing 210
1. Introduction 210
2. The biomedical informatics workforce 215
3. Education and training in biomedical informatics 221
3.1. Competencies in Biomedical Informatics 221
3.2. Professional Certification in Biomedical Informatics 222
3.3. Education and Training in Biomedical Informatics 224
4. Resources 227
4.1. Professional HIT/Informatics Societies 227
4.2. HIT/Informatics Publications 228
4.3. HIT/Informatics Websites 228
5. Conclusions 229
References 231
Index 236

Textauszug

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...

Produkt-Details

• Erscheint lt. Verlag: 21.11.2014
• Sprache: englisch
• Themenwelt: Medizin / Pharmazie
• Themenwelt: Technik ► Medizintechnik
• ISBN-10: 0-12-799919-1 / 0127999191
• ISBN-13: 978-0-12-799919-7 / 9780127999197