• Home

  • Documents

  • Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D...
32
iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology, Keck School of Medicine, University of Southern California, Los Angeles, CA, USA Andrew Georgiou, PhD Senior Research Fel low, Centre for Health Systems and Safety Research, Australian Institute of Health Innovation, Faculty of Medicine, University of New South Wales, NSW, Australia Ulysses GJ Balis, MD Associate Professor and Director, Division of Pathology Informatics and Fel lowship Program in Pathology Informatics, University of Michigan, Ann Arbor, MI, USA Michael J Becich, MD, PhD Professor and Chairman of the Department of Biomedical Informatics, Professor of Pathology, Information Sciences/ Telecommunications and Clinical/Translational Sciences, University of Pisburgh School of Medicine, Department of Biomedical Informatics, Pisburgh, PA, USA Bruce Beckwith, MD Chair, Department of Pathology, North Shore Medical Center, Salem, MA, Associate in Pathology, Codirector of Pathology Informatics Fel lowship, Massachuses General Hospital, Boston, MA, USA Alexis B Carter, MD Director of Pathology Informatics, Department of Pathology & Laboratory Medicine, Department of Biomedical Informatics, Emory University Hospital, Atlanta, GA, USA Yu Chen, PhD Assistant Professor of Bioengineering, Fischel l Department of Bioengineering, Electrical & Computer Engineering (Affiliated), University of Maryland, Col lege Park, MD, USA Bryan Dangott, MD Hematopathology Fel low, University of Utah, ARUP Laboratories, Salt Lake City, UT, USA Rita D’Angelo Manager of Quality Systems, Pathology and Laboratory Medicine, Henry Ford Health System, Detroit, MI, USA Michael D Feldman, MD, PhD Associate Professor of Pathology and Laboratory Medicine, University of Pennsylvania, Philadelphia, PA, USA Candace Golightly, MA, MLT(ASCP) Department Vice Chair, Clinical Associate Professor, Clinical Coordinator, Department of Clinical Laboratory Sciences, Stony Brook University, Stony Brook, NY, USA Walter H Henricks, MD Medical Director, Center for Pathology Informatics, Pathology and Laboratory Medicine, Cleveland Clinic, Cleveland, OH, USA Keith J Kaplan, MD Chief Information Officer, Carolinas Pathology Group, Charloe, NC, USA Joy Mammen, MD Department of Transfusion Medicine & Immunohematology, Christian Medical Col lege, Vel lore, India Ryan M McKnight, MD Fel low in Cytopathology, Department of Pathology & Laboratory Medicine, Emory University Hospital, Atlanta, GA, USA Federico Monzon, MD Director of Molecular Pathology and Associate Professor, Cancer Genetics Laboratory, Department of Pathology & Immunology and Department of Human & Molecular Genetics, Baylor Col lege of Medicine, Houston, TX, USA George William Moore, MD, PhD Deceased (1945-2011) Liron Pantanowitz, MD Associate Professor of Pathology & Biomedical Informatics, Director of Pathology Informatics Fel lowship, Associate Director of Pathology Informatics, University of Pisburgh Medical Center, Department of Pathology, UPMC Shadyside, Pisburgh, PA, USA Seung Park, MD Fel low in Pathology Informatics, University of Pisburgh Medical Center, Department of Pathology, UPMC Shadyside, Pisburgh, PA, USA Anil V Parwani, MD, PhD Associate Professor of Pathology & Biomedical Informatics, Director of Pathology Informatics, University of Pisburgh Medical Center, Department of Pathology, UPMC Shadyside, Pisburgh, PA, USA Luke Perchoca, MD, MBA Associate Professor, Pathology and Dermatology, Associate Director, Surgical Pathology, Department of Pathology, University of California San Francsico, San Francisco, CA, USA Mark J Routbort, MD, PhD Assistant Professor, Department of Pathology, MD Anderson, Houston, TX, USA Joel H Saltz, MD, PhD Professor of Pathology & Laboratory Medicine, Director, Center for Comprehensive Informatics, Emory University School of Medicine, Atlanta, GA, USA Gaurav Sharma, MD Clinical Fel low in Pathology Informatics, Department of Pathology, University of Pisburgh Medical Center, Pisburgh, Pennsylvania, USA J Mark Tuthill, MD Division Head, Pathology Informatics, Henry Ford Health System, Detroit, MI, USA Hal Weiner, BS MBA President, Weiner Consulting Services, Florence, OR, USA Ronald S Weinstein, MD Professor of Pathology, Department of Pathology, Director, Arizona Telemedicine Program, Col lege of Medicine, University of Arizona, Tucson, AZ, USA Dennis Winsten, MS, FHIMSS President of Dennis Winsten & Associates, Inc, Healthcare Systems Consultants, Tucson, AZ, USA Richard J Zarbo, MD, DMD Chairman, Pathology and Laboratory Medicine, Henry Ford Health System, Detroit, MI, USA Author Affiliations

Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

iv Pathology Informatics

Raymond D Aller, MDClinical Professor and Director of Medical Informatics, Department of Pathology, Keck School of Medicine, University of Southern California, Los Angeles, CA, USA

Andrew Georgiou, PhDSenior Research Fellow, Centre for Health Systems and Safety Research, Australian Institute of Health Innovation, Faculty of Medicine, University of New South Wales, NSW, Australia

Ulysses GJ Balis, MDAssociate Professor and Director, Division of Pathology Informatics and Fellowship Program in Pathology Informatics, University of Michigan, Ann Arbor, MI, USA

Michael J Becich, MD, PhDProfessor and Chairman of the Department of Biomedical Informatics, Professor of Pathology, Information Sciences/Telecommunications and Clinical/Translational Sciences, University of Pittsburgh School of Medicine, Department of Biomedical Informatics, Pittsburgh, PA, USA

Bruce Beckwith, MDChair, Department of Pathology, North Shore Medical Center, Salem, MA, Associate in Pathology, Codirector of Pathology Informatics Fellowship, Massachusetts General Hospital, Boston, MA, USA

Alexis B Carter, MDDirector of Pathology Informatics, Department of Pathology & Laboratory Medicine, Department of Biomedical Informatics, Emory University Hospital, Atlanta, GA, USA

Yu Chen, PhDAssistant Professor of Bioengineering, Fischell Department of Bioengineering, Electrical & Computer Engineering (Affiliated), University of Maryland, College Park, MD, USA

Bryan Dangott, MDHematopathology Fellow, University of Utah, ARUP Laboratories, Salt Lake City, UT, USA

Rita D’AngeloManager of Quality Systems, Pathology and Laboratory Medicine, Henry Ford Health System, Detroit, MI, USA

Michael D Feldman, MD, PhDAssociate Professor of Pathology and Laboratory Medicine, University of Pennsylvania, Philadelphia, PA, USA

Candace Golightly, MA, MLT(ASCP) Department Vice Chair, Clinical Associate Professor, Clinical Coordinator, Department of Clinical Laboratory Sciences, Stony Brook University, Stony Brook, NY, USA

Walter H Henricks, MDMedical Director, Center for Pathology Informatics, Pathology and Laboratory Medicine, Cleveland Clinic, Cleveland, OH, USA

Keith J Kaplan, MDChief Information Officer, Carolinas Pathology Group, Charlotte, NC, USA

Joy Mammen, MDDepartment of Transfusion Medicine & Immunohematology, Christian Medical College, Vellore, India

Ryan M McKnight, MDFellow in Cytopathology, Department of Pathology & Laboratory Medicine, Emory University Hospital, Atlanta, GA, USA

Federico Monzon, MDDirector of Molecular Pathology and Associate Professor, Cancer Genetics Laboratory, Department of Pathology & Immunology and Department of Human & Molecular Genetics, Baylor College of Medicine, Houston, TX, USA

George William Moore, MD, PhDDeceased (1945-2011)

Liron Pantanowitz, MDAssociate Professor of Pathology & Biomedical Informatics, Director of Pathology Informatics Fellowship, Associate Director of Pathology Informatics, University of Pittsburgh Medical Center, Department of Pathology, UPMC Shadyside, Pittsburgh, PA, USA

Seung Park, MDFellow in Pathology Informatics, University of Pittsburgh Medical Center, Department of Pathology, UPMC Shadyside, Pittsburgh, PA, USA

Anil V Parwani, MD, PhDAssociate Professor of Pathology & Biomedical Informatics, Director of Pathology Informatics, University of Pittsburgh Medical Center, Department of Pathology, UPMC Shadyside, Pittsburgh, PA, USA

Luke Perchoca, MD, MBAAssociate Professor, Pathology and Dermatology, Associate Director, Surgical Pathology, Department of Pathology, University of California San Francsico, San Francisco, CA, USA

Mark J Routbort, MD, PhDAssistant Professor, Department of Pathology, MD Anderson, Houston, TX, USA

Joel H Saltz, MD, PhDProfessor of Pathology & Laboratory Medicine, Director, Center for Comprehensive Informatics, Emory University School of Medicine, Atlanta, GA, USA

Gaurav Sharma, MDClinical Fellow in Pathology Informatics, Department of Pathology, University of Pittsburgh Medical Center, Pittsburgh, Pennsylvania, USA

J Mark Tuthill, MDDivision Head, Pathology Informatics, Henry Ford Health System, Detroit, MI, USA

Hal Weiner, BS MBAPresident, Weiner Consulting Services, Florence, OR, USA

Ronald S Weinstein, MDProfessor of Pathology, Department of Pathology, Director, Arizona Telemedicine Program, College of Medicine, University of Arizona, Tucson, AZ, USA

Dennis Winsten, MS, FHIMSSPresident of Dennis Winsten & Associates, Inc, Healthcare Systems Consultants, Tucson, AZ, USA

Richard J Zarbo, MD, DMDChairman, Pathology and Laboratory Medicine, Henry Ford Health System, Detroit, MI, USA

Author Affiliations

Page 2: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

Pathology Informatics v

Table of ContentsPreface · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · xvForeword · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · xvi

Chapter 1

Pathology Informatics: An Introduction1.1 Informatics Terminology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 11.2 Pathology Informatics as a Subspecialty · · · · · · · · · · · · · · · · · · · · · · · · · · · 21.3 Pathology Informatics Contributions · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 41.4 Pathology Informaticist Skills and Competencies · · · · · · · · · · · · · · · · · · · · · 41.4.1 Technical Skills · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 51.4.2 Communication Skills · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 51.4.3 Management and Administrative Skills · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 61.4.4 Data Mining and Research Skills · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 7

1.5 Pathology Informatics Organizations · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 71.6 Careers in Pathology Informatics · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 81.7 The Future of Pathology Informatics · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 8

Chapter 2

Computer Fundamentals2.1 Introduction · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 112.1.1 Historical Perspective · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 11

2.2 What is a Computer? · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 122.2.1 What Kinds of Computers Are There? · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 132.2.2 Central Processing Unit (CPU) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 142.2.3 Motherboard · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 152.2.4 Random-Access Memory (RAM) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 172.2.5 Hard Drives · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 172.2.6 Graphics Processors · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 192.2.7 Monitors · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 202.2.8 Networking · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 212.2.9 Peripherals · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23

2.3 Software · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 242.3.1 Firmware · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 242.3.2 Operating System · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 252.3.3 Drivers · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 272.3.4 User Programs · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 272.3.5 Malware · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 29

2.4 Handheld Computing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 302.4.1 Historical Overview · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 302.4.2 Hardware · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 312.4.3 Software · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 322.4.4 Applications · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 322.4.5 Recommendations · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32

Author Affiliations

Page 3: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

vi Pathology Informatics

Table of Contents

2.5 Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 322.5.1 Physical Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 322.5.2 Social Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 332.5.3 Network Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 332.5.4 Software Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 332.5.5 Data Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 33

Chapter 3

Databases3.1 Introduction · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 353.1.1 Historical Perspective · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 35

3.2 Criteria for Reliable Persistent Storage · · · · · · · · · · · · · · · · · · · · · · · · · · · 363.2.1 CRUD (Create, Read, Update, Delete) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 363.2.2 ACID (Atomicity, Consistency, Isolation, Durability) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 37

3.3 Database Models · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 403.3.1 The Flat Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 423.3.2 The Hierarchical Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 433.3.3 The Network Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 463.3.4 The Relational Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 473.3.5 The Object-Oriented Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 593.3.6 The Document-Oriented Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 603.3.7 The Graph Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 613.3.8 The Entity-Attribute-Value (EAV) Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 613.3.9 The Dimensional Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 62

3.4 Miscellaneous Programmatic Concepts · · · · · · · · · · · · · · · · · · · · · · · · · · · 633.4.1 Stored Procedures · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 633.4.2 Triggers · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 64

3.5 Health Level 7 (HL7) and Future Medical Databases · · · · · · · · · · · · · · · · · · · 64

Chapter 4

Networking4.1 Connectivity and Switching · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 674.1.1 Circuit Switching · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 684.1.2 Packet Switching · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 68

4.2 Network Types · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 694.2.1 Network Scale · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 694.2.2 Connection Method · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 694.2.3 Network Topologies · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 704.2.4 Network Architecture · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 704.2.5 Complex Network Topologies · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 70

4.3 Open System Interconnection Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · 724.3.1 OSI Level 1: Physical Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 734.3.2 OSI Level 2: Data Link Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 734.3.3 OSI Level 3: Network Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 734.3.4 OSI Level 4: Transport Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 734.3.5 OSI Level 5: Session Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 734.3.6 OSI Level 6: Presentation Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 744.3.7 OSI Level 7: Application Layer · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 74

4.4 Wired Network Standards · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 744.5 Wireless Network Standards · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 75

Page 4: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

viiPathology Informatics

Table of Contents

4.6 Network Connection Devices · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 754.6.1 Network Interface Cards · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 754.6.2 Hubs · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 754.6.3 Switches · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 754.6.4 Routers · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 76

4.7 Network Bandwidth · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 764.8 Network Workstations · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 764.8.1 Client-Server Architecture · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 764.8.2 P2P Networks · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 77

4.9 Interfaces and Data Exchange · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 774.9.1 Hardware Interface · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 784.9.2 Software Interfaces · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 784.9.3 HL7 Communication Protocol · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 784.9.4 Hospital System Interfaces · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 78

4.10 Network Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 794.10.1 Network Threats · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 794.10.2 Authentication · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 804.10.3 Firewalls · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 804.10.4 Encryption · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 804.10.5 Virtual Private Networks · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 80

4.11 Grid Computing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 814.12 Cloud Computing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 814.13 Private Networks · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 824.14 The Internet · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 824.14.1 The TCP/IP Standard · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 834.14.2 Accessing Online Content · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 834.14.3 Accessing E-mail · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 844.14.4 Web 2.0 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 84

Chapter 5

Laboratory Information Systems Overview5.1 LIS Building Blocks and Architecture · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 855.1.1 Basic Components of the LIS · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 855.1.2 LIS Architecture · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 86

5.2 Core LIS Elements · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 875.2.1 LIS Dictionaries · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 885.2.2 LIS Worksheets · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 895.2.3 LIS Interfaces · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 90

5.3 LIS Functions in Laboratory Workflow · · · · · · · · · · · · · · · · · · · · · · · · · · · · 915.3.1 CP-LIS Preanalytic Phase Information Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 915.3.2 CP-LIS Analytic Phase Information Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 945.3.3 CP-LIS Postanalytic Phase Information Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 965.3.4 AP-LIS Preanalytic Phase Information Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 975.3.5 AP-LIS Analytic Phase Information Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 985.3.6 AP-LIS Postanalytic Phase Information Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1005.3.7 Other LIS Reports · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 101

5.4 LIS Models That Extend Beyond the Hospital · · · · · · · · · · · · · · · · · · · · · · 1015.4.1 Multifacility LIS Capability · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1015.4.2 Outreach Testing and the LIS · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1025.4.3 Web Portals and Interfaces · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1035.4.4 ASP Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 103

Page 5: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

viii Pathology Informatics

Table of Contents

Chapter 6

LIS Selection and Implementation6.1 Selection Factors · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1056.1.1 Selection Process · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 105

6.2 Summary · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 115

Chapter 7

Laboratory Information System Operations7.1 Health Information Professionals and the LIS Team · · · · · · · · · · · · · · · · · · 1177.1.1 Desktop Support and Help Desk Support · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 118

7.2 Change Control · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1187.2.1 Types of Instruction for Change Control · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1197.2.2 Software for Change Control Management Process · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 119

7.3 LIS Security · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1197.4 System Backup · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1207.4.1 Patient Database Backup · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1207.4.2 Master Table Backup · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1217.4.3 Operating System Backup · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 121

7.5 Management Reporting · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1217.6 Total Cost of Operating an LIS · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1227.7 LIS Validation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1227.7.1 Regulatory and Accrediting Agencies for LIS · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1237.7.2 Rational for Validation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1237.7.3 Components Included in the Validation Process · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1237.7.4 LIS Validation Phases · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1247.7.5 Prospective Validation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1247.7.6 Validation Process · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1247.7.7 Standard Operating Procedures (SOP) for Test Plans · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1257.7.8 Stress Test and Disaster Plan · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1257.7.9 Revalidate for QA · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1257.7.10 Automating the Validation and Stress Testing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 125

7.8 Accreditation and Regulatory Agencies · · · · · · · · · · · · · · · · · · · · · · · · · · 1267.8.1 Centers for Medicare and Medicaid Services (CMS) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1267.8.2 Clinical Laboratory Improvement Amendments of 1988 (CLIA ’88) · · · · · · · · · · · · · · · · · · · 1267.8.3 College of American Pathologists (CAP) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1267.8.4 Commission on Office Laboratory Accreditation (COLA) · · · · · · · · · · · · · · · · · · · · · · · · · 1267.8.5 Food and Drug Administration (FDA) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1277.8.6 The Joint Commission · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1277.8.7 International Organization for Standardization (ISO) · · · · · · · · · · · · · · · · · · · · · · · · · · · · 127

7.9 Health Insurance Portability and Accountability Act of 1996 · · · · · · · · · · · · 1277.9.1 Covered Entities and Business Associates · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1277.9.2 HIPAA, Title II: Administrative Simplification, Standards and Implementation Specifications · 128

7.10 Administrative, Physical and Technical Safeguard Regulations · · · · · · · · · · 1297.10.1 Administrative Safeguards §164.308 (a)(1)(i) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1297.10.2 Physical Safeguards §164.310 (a)(1) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1327.10.3 Technical Safeguards §164.312 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 133

Page 6: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

ixPathology Informatics

Table of Contents

Chapter 8

Information Systems Interfaces and Interoperability8.1 Health Level 7 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1358.1.1 HL7 Fundamentals · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1368.1.2 HL7 Structure · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1368.1.3 Australian Healthcare Messaging Laboratory · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 137

8.2 Patient-Centered Data Model · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1388.3 Service-Oriented Architectures and Web Services · · · · · · · · · · · · · · · · · · · 1388.3.1 Match-and-Tag Heuristics and Algorithms · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 139

8.4 Regional Health Information Organizations · · · · · · · · · · · · · · · · · · · · · · · 1408.4.1 Fundamentals of RHIO Architecture · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 140

8.5 Multienterprise Master Person Index · · · · · · · · · · · · · · · · · · · · · · · · · · · 140

Chapter 9

Laboratory Automation9.1 Clinical Pathology Automation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1489.1.1 Preanalytical Phase · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1489.1.2 Analytical Phase · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1499.1.3 Postanalytical Phase · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 150

9.2 LAS Software · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1519.3 Middleware · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1529.3.1 Types of Middleware · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 152

9.4 Anatomic Pathology Automation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1539.4.1 Tracking and Routing Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1549.4.2 Advanced Automation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 154

9.5 Future Directions · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 155

Chapter 10

Information Systems for Specialized Laboratories10.1 Cytopathology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 15710.2 Transfusion Medicine Service · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 15910.3 Microbiology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 16210.4 Point-of-Care Testing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 16410.5 Molecular Pathology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 16710.6 Tissue Typing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 17110.7 Forensic Pathology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 17210.8 Customer Relationship Management · · · · · · · · · · · · · · · · · · · · · · · · · · · 17410.8.1 Logistics Support · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 17410.8.2 Customer Service Center Support · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 17410.8.3 Analytics · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 17410.8.4 CRM Information Technology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 175

10.9 Billing and Accounts Receivable Systems · · · · · · · · · · · · · · · · · · · · · · · · · 17510.10 Inventory Management Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 17610.11 Electronic Document Management Systems · · · · · · · · · · · · · · · · · · · · · · · 176

Page 7: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

x Pathology Informatics

Table of Contents

Chapter 11

Coding11.1 Definitions of Key Terms · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 18011.2 International Classification of Diseases · · · · · · · · · · · · · · · · · · · · · · · · · · 18011.3 Current Procedural Terminology (CPT) · · · · · · · · · · · · · · · · · · · · · · · · · · 18111.4 Logical Observation Identifiers and Codes (LOINC) · · · · · · · · · · · · · · · · · · · 18211.5 Systematized Nomenclature of Medicine Clinical Terms · · · · · · · · · · · · · · · 18411.6 Autocoding · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 18511.7 Unified Medical Language System (UMLS) · · · · · · · · · · · · · · · · · · · · · · · · 185

Chapter 12

Leadership, Management & Project Management Skills for the Informaticist12.1 Leadership, Management and “Business Skills” · · · · · · · · · · · · · · · · · · · · 18712.2 Leading and Managing Strategically · · · · · · · · · · · · · · · · · · · · · · · · · · · · 18812.2.1 Tools for Strategy Development: The Discipline of Strategy · · · · · · · · · · · · · · · · · · · · · · · · · 18812.2.2 Planning vs Doing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 189

12.3 Operations Management and Improvement · · · · · · · · · · · · · · · · · · · · · · · 19012.3.1 Operations in Manufacturing and Service Industries · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 19012.3.2 The Role of IT in Operations and its Adoption in Healthcare · · · · · · · · · · · · · · · · · · · · · · · · 19012.3.3 Quality and Process Improvement in Operations: Theory and Practice · · · · · · · · · · · · · · · · · 191

12.4 Legal and Regulatory Environment for Healthcare IT · · · · · · · · · · · · · · · · · 19412.5 Financial Literacy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 19612.5.1 “Profit” and “Not-for-Profit” Entities · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 19612.5.2 Finance and Managerial Finance · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 19612.5.3 Accounting Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 19712.5.4 Accounting Basics · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 19712.5.5 Important Managerial Accounting Concepts and Activities · · · · · · · · · · · · · · · · · · · · · · · · 19812.5.6 The Revenue Cycle in Healthcare · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20112.5.7 Informatics-Related Financial Management Considerations · · · · · · · · · · · · · · · · · · · · · · · · 202

12.6 Project Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20312.6.1 Project Characteristics · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20312.6.2 The Importance of Project Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20312.6.3 What Is Being Managed? · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20312.6.4 The Project Life Cycle · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20412.6.5 Project Management Tools, Documentation and Software · · · · · · · · · · · · · · · · · · · · · · · · · 20412.6.6 The Project Management Team · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 205

Chapter 13

Reporting & Transcription13.1 Report Format · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20813.2 Report Content · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20813.2.1 Synoptic Reports · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 209

13.3 Report Interfaces · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21113.4 Macros and Quicktext · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 211

Page 8: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

xiPathology Informatics

Table of Contents

13.5 Voice-Activated Technology (VAT) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21213.5.1 Speech Recognition Technology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21213.5.2 Clinical Application · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 212

13.6 Regulatory Issues · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21313.7 Future Reports · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 213

Chapter 14

Electronic Health Records14.1 Components and Functions · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21714.1.1 Patient Identification · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21814.1.2 Clinical Documentation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21814.1.3 Ancillary Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21814.1.4 Clinical Decision Support Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21814.1.5 Computerized Provider Order Entry · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 218

14.2 Implementation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 21914.3 Standards · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22014.4 Result Reporting · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22014.5 Pros and Cons · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22214.5.1 Benefits · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22214.5.2 Disadvantages · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 224

14.6 Roles and Responsibilities · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22514.7 eHealth: The International Perspective · · · · · · · · · · · · · · · · · · · · · · · · · · 22614.8 Public Health · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22714.8.1 Reportable Disease · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22714.8.2 Population-Based Surveillance · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 227

14.9 Organizations and Associations · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22714.9.1 Healthcare Information and Management Systems Society (HIMSS) · · · · · · · · · · · · · · · · · · 22714.9.2 Association of Medical Directors of Information Systems (AMDIS) · · · · · · · · · · · · · · · · · · · 22714.9.3 American Medical Informatics Association (AMIA) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22714.9.4 Integrating the Healthcare Enterprise (IHE) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22814.9.5 Health Information Technology Standards Planning Panel (HITSPP) · · · · · · · · · · · · · · · · · · 22814.9.6 Certification Commission for Healthcare Information Technology (CCHIT) · · · · · · · · · · · · · 22814.9.7 openEHR Foundation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22814.9.8 Regional Health Information Organization (RHIO) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 228

Chapter 15

Digital Imaging15.1 Digital Images · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23115.1.1 Pixel Resolution and Density · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23115.1.2 Color and Bit Depth · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23215.1.3 Image Files · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23415.1.4 Image Compression · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 234

15.2 Digital Cameras · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23515.2.1 Handheld Cameras · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23515.2.2 Digital Microscope Cameras · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23515.2.3 Specialized Cameras · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23615.2.4 Digital Camera Components · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 236

15.3 Gross Pathology Workstations · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 238

Page 9: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

xii Pathology Informatics

Table of Contents

15.4 Digital Photography · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23915.4.1 Macro Photography · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23915.4.2 Photomicroscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 239

15.5 Digital Imaging Process · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23915.5.1 Image Acquisition · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 23915.5.2 Image Storage · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24015.5.3 Image Manipulation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24215.5.4 Image Sharing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 242

15.6 Whole Slide Imaging · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24515.6.1 Historical Perspective · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24515.6.2 WSI Technology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24615.6.3 WSI Image Files · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24815.6.4 Digital Slide Viewers · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24815.6.5 Applications of WSI · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 249

15.7 Image Analysis · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 25115.7.1 Multispectral Imaging · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 251

15.8 Image-Based Searches · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 254

Chapter 16

Telepathology16.1 Telehealth · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 261

16.2 Historical Telepathology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 261

16.3 Applications · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 26216.3.1 Primary Diagnosis · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 26316.3.2 Secondary Consultation · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 26316.3.3 Education · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 263

16.4 Telecommunication · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 264

16.5 Modes and Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 26416.5.1 Static Telepathology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 26516.5.2 Robotic Telepathology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 26616.5.3 Whole Slide Imaging · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 267

16.6 Selection, Implementation and Maintenance · · · · · · · · · · · · · · · · · · · · · · 268

16.7 Legal and Regulatory Issues · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 269

Chapter 17

Advanced Imaging Techniques17.1 Light Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 273

17.2 Polarization Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 274

17.3 Phase-Contrast Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 275

17.4 Fluorescence Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 275

17.5 Confocal Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 275

17.6 Laser Capture Microdissection and Optical Tweezers · · · · · · · · · · · · · · · · · 275

Page 10: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

xiiiPathology Informatics

Table of Contents

17.7 Optical Coherence Tomography (OCT) · · · · · · · · · · · · · · · · · · · · · · · · · · · 27617.7.1 Principles of OCT · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27617.7.2 Ultra-High-Resolution OCT · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27717.7.3 Optical Coherence Microscopy (OCM) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27717.7.4 High-Speed 3D-OCT · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27717.7.5 Endoscopic OCT · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 278

17.8 Super-Resolution Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27817.8.1 4Pi Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27817.8.2 Structured Illumination Microscopy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27817.8.3 Stimulated Emission Depletion (STED) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27917.8.4 Photoactivated Localization Microscopy (PALM) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 27917.8.5 Stochastic Optical Reconstruction Microscopy (STORM) · · · · · · · · · · · · · · · · · · · · · · · · · 27917.8.6 Lens-Free Super-Resolution Imaging · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 280

Chapter 18

Specimen Tracking and Identification Systems18.1 Positive Patient Identification (PPID) · · · · · · · · · · · · · · · · · · · · · · · · · · · 28318.2 Identification Failures · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 28418.3 Patient Identification Systems · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 28418.4 Machine-Readable Codes and Systems · · · · · · · · · · · · · · · · · · · · · · · · · · 28518.4.1 Optical Character Recognition · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 28618.4.2 Barcodes · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 28618.4.3 RFID Technology · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 29618.4.4 Issues Unique to Blood Banks · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 298

18.5 Issues Related to Phlebotomy · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 29918.6 Databases and Schema For Tracking · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30018.6.1 Incremental Classes · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30018.6.2 Classes of Trigger Events · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 300

18.7 Interfaces and Workflow · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30118.7.1 User Interfaces · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30118.7.2 Color Coding · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30118.7.3 Technology to Drive Workflow · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 302

18.8 Barcode and Tracking Implementation · · · · · · · · · · · · · · · · · · · · · · · · · · 30218.9 Standards in the Clinical Laboratory · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30218.9.1 CLSI: AUTO4 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30218.9.2 CLSI: AUTO12-A · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 303

Chapter 19

Error Reduction & Quality Management19.1 The Basis of Lean · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30519.2 The Toyota Production System (TPS) · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30519.3 Other Quality Improvement Methodologies · · · · · · · · · · · · · · · · · · · · · · · 30619.3.1 Six Sigma · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30619.3.2 Lean-Six Sigma · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 306

19.4 The Deming Quality Chain Reaction · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30619.4.1 Deming’s 14 Points for Management · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 306

19.5 Lessons Learned from Toyota · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 308

Page 11: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

xiv Pathology Informatics

Table of Contents

19.6 Culture of Change in Healthcare · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30819.7 Creating a Culture of Quality in Healthcare— Mirroring the Toyota Production System · · · · · · · · · · · · · · · · · · · · · · · · · 30919.7.1 Establishing Culture · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30919.7.2 Workforce Training · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30919.7.3 Core Principles · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 310

19.8 Creating Measurement Tools to Identify In-Process Waste · · · · · · · · · · · · · · 31219.8.1 Distribution of Survey to Staff · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31219.8.2 Preparation for Data Collection · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31319.8.3 Value Stream Maps · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 313

19.9 Worker-Driven Process Improvements That Define Successful Continuous Change · · · · · · · · · · · · · · · · · · · · · · · 31419.9.1 Work Rules · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31419.9.2 Customer-Supplier Meetings · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 314

19.10 Putting PDCA to Work · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31519.11 The Role of Technology in Lean Work Design · · · · · · · · · · · · · · · · · · · · · · 31619.12 Applying Informatics to Lean · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31619.12.1 Digital Radiology and Lean Gross Examination Process Redesign · · · · · · · · · · · · · · · · · · · · · 31619.12.2 Barcode-Specified Work Processes Standardization in Surgical Pathology · · · · · · · · · · · · · · · 317

Chapter 20

Biomedical & Research Informatics20.1 Bioinformatics · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32020.2 Tissue Banking · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32220.3 Research and Human Tissue · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32320.4 Data Nomenclature, Coding and Structure · · · · · · · · · · · · · · · · · · · · · · · · 32520.4.1 Text Parsing · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32520.4.2 Structured Data · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32620.4.3 Data Setbacks · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 327

Chapter 21

Pathology Informatics Training & Education21.1 Medical Technologists · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32921.2 Pathology Residents and Fellows · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 33021.3 Medical Students · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 33121.4 Curriculum Content · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 33121.5 Assessment of Trainees and Programs · · · · · · · · · · · · · · · · · · · · · · · · · · 33221.5.1 Performance Appraisal · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 33221.5.2 Program Quality Control · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 332

21.8 Appendix A · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 333 Index · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 337

Page 12: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

Pathology Informatics 117

Chapter 7

Laboratory Information System OperationsCandace Golightly MT (ASCP), J Mark Tuthill MD

F or over 2 decades, pathology laboratories have been implementing computerized laboratory information systems (LISs) to manage

information generated in the laboratory. The mission of clinical laboratories is to process and provide precise and accurate analyses of patient’s specimens. These results must then be delivered in a timely and clearly organized manner. This mission is unique to the laboratory and differentiates it from the work and workflow of other medical or healthcare departments. In today’s healthcare environment, not only must this mission be realized, but the clinical laboratory is also required to improve quality services, expand the test menu of test services offered and increase workflow. These tasks must be done while enhancing and ensuring cost-effective operations, thus enabling laboratories to be competitive as well as rigorous. Information systems are crucial to meeting this plurality of goals.

Although the pathologists’ and laboratorians’ fundamental roles may remain relatively constant, the analytical methodologies and computer information systems at their disposal are growing and changing rapidly. While LIS vendors are beginning to address many of the needs of the laboratory with regard to recent technologies in automation, digital pathology imaging, cytogenetics, flow cytometry, molecular genetics and translational medicine, many areas of the laboratory do not have the necessary standards and associated ability to send their results in digital fashion to the electronic record; the resulting stopgap approach has been to depend on forwarding of image files or, worse yet, scanned printed materials (with neither of these constructs allowing for simplified information retrieval). For quite some time several pathologists have suggested that pathology informatics necessarily should become a recognized subspecialty [Friedman  1990, Buffone  1993]. Although greater numbers of pathology departments have appointed directors of pathology informatics over recent years, still more are needed to bring administrative attention and added value to the LIS division in the pathology department. Optimal operation of the LIS depends on identifying and retaining adequate numbers of dedicated and skilled staff; advocacy as well as medical directorship by the pathologist are important. The pathologists’ contributions toward implementing novel technologies, data management, data integration and a

lean workflow process at a time when laboratories are facing budgetary constraints and staffing shortages, makes good business sense.

7.1 Health Information Professionals and the LIS Team

LIS implementation started as far back as the 1970s. Since then, laboratory technologists have been asked to leave their routine laboratory work and take on a new role, to become a working member of the LIS team or manage the LIS. While these LIS team members, with a laboratory background, have the excellent advantage of understanding the “language” (workflow, people and culture) of the laboratory and often possess good troubleshooting skills, they may lack some of the specialized skills that information analysts and project managers exhibit. Nevertheless, with adequate and ongoing training and application experience, LIS staff recruited from laboratory personnel usually perform well, successfully taking on ownership of what they know best (ie, laboratory operations and the preanalytical, analytical and postanalytical testing process). With the exception of routine hardware maintenance, LIS staff with a laboratory background (former technologists and/or laboratory managers) are generally focused on specific clinical LIS applications software. By comparison, the information services department’s staff (eg, information analysts, programmers, network engineers) is usually responsible for hardware and network communications, and tend to focus more on system management, including operational support, data transmission and system backups. It is easy to see why many information technology (IT) projects in the pathology department call for the cooperation of staff from both the LIS division and the information services department. IT project management is covered in great detail in Chapter  12. Specific issues that may arise include supporting lines of communication between these departments to support LIS projects and aligning IT team priorities with the needs of the laboratory. LIS team members are generally stretched thin as a result of being asked to work on multiple internal and external projects while simultaneously troubleshooting and maintaining hardware, instrument and system interfaces, implementing software upgrades, handling

F

Page 13: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

118 Pathology Informatics

7: Laboratory Information System Operations

incoming calls and complaints, querying databases, participating in quality improvement programs, evaluating new products, and managing various unscheduled and scheduled downtimes.

Daily operations of the LIS team include t7.1 maintaining system security in compliance with the Health Insurance Portability and Accountability Act (HIPAA) regulations, performing database management, performing data backup and recovery tasks, performing interface monitoring, maintaining hardware (including printers) and software, carrying out LIS validation, and authoring documentation to support regulatory and accreditation requirements. This chapter provides an overview of the basic operations required to manage LIS operations.

7.1.1 Desktop Support and Help Desk Support

The LIS desktop support specialist may be expected to provide technical support for the LIS personal computer (PC) hardware components and services and educate users on proper use of these components. This role often includes assisting users with procedures and use of desktop computers, printers and related peripheral devices. This can be a daunting task, particularly when such support is expected to extend beyond intrinsic LIS functionality on the PC to other ancillary applications and hardware such as digital cameras, multimedia software for presentations and other sophisticated applications (eg, databases, spreadsheets, etc). Customers may have little appreciation of the complexities and depth of knowledge required for such broad support of desktop computer hardware and software. Customers cannot realistically be expected to separate functioning desktop operating systems and hardware from the applications needed to accomplish their daily work in addition to LIS usage. Often, the LIS analysts may be called on for this support. In fact, this may not be the best use of the LIS analyst’s skills, which are more oriented to the LIS and laboratory business processes rather than support of

general purpose computing. In many healthcare settings, the strategy used is to have a desktop support team that can maintain, troubleshoot and rebuild customer PCs. This team may work in conjunction with laboratory-based analysts, whose primary focus is support of the LIS components. The roles and responsibilities of these team members as well as their reporting relationships will vary based on the model used in a particular institution. This can be challenging to delineate and can be a significant source of friction as well as customer dissatisfaction. The key is to plan for, architect and manage acceptable support processes and procedures as well as manage customer expectations. Central IT desktop and support specialists who have the job of assisting customers and end users can face a challenge. LIS users frequently can be unfamiliar with LIS technical terms, hardware and software, and so the support specialist or help desk support specialist is often required to ask many questions to assess and resolve performance problems. Large laboratories or multiple laboratory organizations may elect to implement help desk support software applications to manage an otherwise unmanageable volume of job and problem requests. It is imperative that the support specialist be skilled in analyzing hardware- and software-related malfunctions and be able to determine effective solutions as well as possess effective verbal and written communication skills. This may or may not be the case. A common approach is to provide help desk team members with triage questions that can help customers to better describe problems. Simple issues such as password resets, a common problem encountered by any help desk, can be easily triaged and supported. For more complex issues, expedited triage becomes increasingly challenging, with this reality being compounded as the number of supported applications increases. Many laboratories have both anatomic pathology (AP) and clinical pathology (CP) LIS core services, outreach systems and other applications that should ideally be covered by on-call support on a 24/7 basis.

7.2 Change ControlChange control is a process that ensures that

potential changes are recorded, evaluated, authorized and monitored in a controlled and coordinated manner. Change control applies to any and all changes, revisions, alterations, additions, enhancements or upgrades to the hardware, software or overall operations of the LIS. Such changes may be vendor-driven or a result of department changes. Documentation of all changes is essential for accurately tracking exactly which part of a process has been altered. LIS managers are responsible for such change control documentation. Change control documentation is also mandated by regulatory bodies such as the College of American Pathologists (CAP), but this mandate is not

t7.1 LIS team operations Change control System security (access control and HIPAA compliance) System data backup Interface monitoring Database maintenance Administrative and management reporting Budgeting and cost analysis System validation Hardware (including printer support) and software maintenance and trouble-shooting External information services department Initiatives Documentation

Page 14: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

119Pathology Informatics

7: Laboratory Information System Operations

the only reason to document changes. Controlling the process of change up front will more than likely prevent the laboratory from making costly mistakes [Lorenzi  2000]. Similarly, tightly controlled documentation can avoid reinventing the wheel and concurrently reduce system-related risks, including system crashes, project failures, security breaches and data corruption. The process need not slow down the change process, but can actually allow for an opportunity to seek out the best ways to add value and better align LIS services with laboratory business plans.

7.2.1 Types of Instruction for Change Control

Different types of instruction can be used by the LIS manager when implementing a change control process. The type and degree of change should be determined on a case-by-case basis. Minor changes (eg, replacing a cable) may not warrant a full standard operating procedure (SOP), but a large alteration (eg, software version upgrade) certainly would. No matter what type of instruction is put into place (eg, simple instructions, policies, SOPs), they will be used to guide the documentation process. If possible, a dedicated person should oversee change control for continuity and better communication of pre- and post-change communications with users. Along with recording the date and time, there are many other important factors that require standardized documentation t7.2 for change control.

7.2.2 Software for Change Control Management Process

Software products are now available for LIS/IT project management, product life-cycle management and change control process management. These products reduce complexity of the project management and change control processes by helping to evaluate resource capacity and skill sets of personnel. They also provide process modeling to measure new project change requests in comparison to previous ones, and predict the costs of such projects. Examples of such products currently being used for this purpose are Daptiv (Seattle, WA) and @Task (Orem, UT).

7.3 LIS SecurityThe LIS administrator is responsible for the

overall security of the system, which includes assigning user access, auditing and enforcing HIPAA regulations, as well as maintaining the software, master tables and operating system. The security level and access are based on the functions that a user needs to perform his or her job. For example, while clerks will be permitted to view or read data, order tests and input patient demographics, they will be unable to edit a result. On the other hand, technologists may input as well as edit results. HIPAA 1996 (Title II Security Rule), requires that policies and procedures are in place to limit the access of users based on the functionality needed to do their job. It is the role of the LIS administrator to assign access levels of all users to the LIS. This is typically done by assigning access levels based on job title, which has been predefined by laboratory management. The user has a 2-part log-in: the first part is assigned, and the second password is user-determined and unknown by the LIS administrator and changed at regular (eg, 3- or 6-month) intervals.

The LIS must provide rapid access to complete and accurate patient results while safeguarding patient privacy and confidentiality (ensuring that information is accessible only to those authorized to have access). As a result, the LIS manager must exercise measures to protect identifiable patient health information (PHI) to comply with HIPAA Security Rule requirements and protect patient information. The HIPAA Security Rule mandates that the healthcare organization determine risks due to threats and accordingly implement adequate measures to protect information in all formats. To ensure patients’ privacy and confidentiality, one must have a clear understanding of the terms:

ο  Confidentiality: Legal protection and assurance of one’s right to privacy; applied to all communication pertaining to situations in which a patient relationship has been established and some type of private (and thus, protected) information is shared.

t7.2 Documentation of change control itemsDocumentation items

Explanation of the change

Description of change

Exact and detailed explanation of what the change will be

Reason for change State the need and benefit of implementing the changePerson responsible for implementing the change

Allows the organization to be able to go to the implementing person, if there is more than 1 individual involved

Change category Determine and indicate if it is a hardware, software, process, procedural or other change

Degree of change Minor or major changes based on impact to the overall LIS system, healthcare IT system and laboratory. Cost of the change can be placed here as well.

Signature of approval or sign-off for change

Shows which individual is responsible for the overall change

Mitigation or risk assessment

Allows for complete assessment of problems that may incur as a result of the change, and planning for resolution of problems

Evaluation and monitoring implemented changes

As part of the overall cycle of a change process, it is necessary to evaluate the outcome as well as determine the success of the change implementation. This will benefit the LIS team with future changes which may or may not be similar.

Page 15: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

120 Pathology Informatics

7: Laboratory Information System Operations

ο  Privacy: The right to determine how and which information is collected, and how it is used, along with one’s right to access the information.

In the laboratory, information system security is an ongoing process that requires constant planning. Planning for loss (temporary or permanent) of information stored in the system, for whatever reason, is good practice and helps to ensure that patient information will not be compromised. Planning includes performing a risk analysis to assess vulnerabilities in the information system. Professionals may be hired to test the laboratory system and use intrusion detection and audit software to facilitate the process. Risk assessment is mandated by HIPAA and is usually the responsibility of the appointed security officer in an organization. Although LIS managers may not be responsible for this process, they should be familiar with various types of potential threats to their system and be proactive in training their LIS and laboratory staff on how to prevent possible threats from not logging out of systems, careless file sharing or spreading of computer viruses.

Viruses and other malicious computer programs (malware) can destroy patient data and should be prevented at all costs. Viruses are computer programs that infect executable software and thereby use a host computer to reproduce and disseminate themselves. Viruses may also contain a payload (software) that performs other actions, which are often malicious. They may not always be detected. Stealth viruses are viruses that change their binary computer pattern each time a new copy is spawned to a new file or computer. A Trojan horse is a non–self-replicating malware program that appears to perform a desirable function for the user, but instead facilitates unauthorized access to the user’s computer system. Worms are destructive programs that actively transmit themselves over a network to infect other computers. As the computer’s resources are consumed by malicious attacks, eventually the host operating system will slow down or fail. A denial-of-service attack is an email system attack whereby a mail or Web server is deliberately overloaded by a deluge of externally launched network packets to prevent it from responding to the remaining minority of valid ones. Another form of malware is spyware, which are commercially produced programs intended to gather information about computer users (eg, displaying targeted pop-up ads based on prior Web browsing history, which has been illicitly discovered). Any of the above malware forms may destroy or compromise a single computer, operating system, application, the LIS, or entire network. Therefore, it is imperative that anti–malware software programs be used for antivirus and spyware protection. In addition to the LIS, security measures are also required to protect in vitro diagnostic instruments and other software systems in the clinical laboratory [Knafel 2006].

7.4 System BackupDisaster recovery is a coordinated effort (process,

policies and procedures) to enable the recovery or continuation of critical IT infrastructure after a disaster. This process is also referred to as “business continuity planning,” which addresses disaster recovery in a more comprehensive manner. While most laboratories would certainly like zero data loss and zero time loss, the cost associated with that level of protection may be significant. In addition to preparing for the need to recover systems, the laboratory should implement precautionary measures. These include data backups, replication of data to off-site locations, use of disk protection technologies such as redundant array of independent disks, uninterruptible power supplies and/or backup power generation to keep systems going in the event of a power failure, fire alarms (eg, delayed actuation sprinkler cut-off switches) and appropriate extinguishers (ie, containing dry chemicals and not water) in the vicinity of computer equipment, as well as antivirus software and other security measures mentioned before.

To save valuable data from being lost and putting the laboratory and organizational data at risk, it is important that regularly scheduled data backups be performed. Most LIS instances require that one perform at least 3 general types of data backups on a routine basis. These include (i) the patient database backup, (ii) the system software master tables, and (iii) the operating system (OS) backup. The backup and system restore process should be part of an overarching disaster recovery plan for the data center and may include redundant off-site servers and shadow databases. Newer hardware design including clustered computer, virtual servers and network attached storage devices has mitigated some of the daily concerns related to system restoration. However, physical media are still relied upon. The goal of backup and recovery is the restoration of a failed server in the event of disaster or system corruption. To that end, recovery and validation of system integrity should be rehearsed. This can be challenging to perform on the LIS, because it may require entirely redundant system hardware.

7.4.1 Patient Database BackupThe patient database backup is perhaps the most

important dataset because it holds patient data from the previous day’s work. This backup should be automatically scheduled, ideally after peak hours of LIS use. Should the backup fail and there is an overall major system failure, then the data will be permanently lost. Media typically used for backup t7.3 may include reel-to-reel tape cartridge drives, robotic multitape drives, CD-ROM, optical media, redundant hard disk storage systems, or sometimes various media used in combination. Some

Page 16: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

121Pathology Informatics

7: Laboratory Information System Operations

laboratories used to rely on microfiche (small sheets of microfilm on which many pages of material are photographed), but this practice has become increasingly uncommon. If used, cartridge tapes need to be labeled, 1 for each day of the week, and used repeatedly until they show evidence of wear or cease to validate when

periodically tested for read integrity. In addition, a cohort of tapes should be periodically cycled into permanent off-site storage as a further preventive measure. It is advisable to have an alert system built into the system that provides error messages if a backup process fails to complete successfully. Depending on the data center configuration, backups may be performed by LIS or central IT staff and may be automated using robotic tape systems. Copies of such data should ideally be stored off site (ideally, at more than 1 location) in case of physical disaster in a data system.

7.4.2 Master Table BackupThe system software contains all LIS master

database tables. It is thus equally important to back up these tables at least once a month, and it is a good idea to make 2 copies.

7.4.3 Operating System BackupBackup of the OS is necessary in case of a system

failure or corruption of the hard disk. Many technologies are available for rapid OS restoration, including “ghost” copies of server configurations, such as snapshots and system images. The modern server OS may also include a system state rollback feature to restore the system to any previous functional configuration.

7.5 Management ReportingLIS staff rely on the LIS for various management

reports t7.4. Some are produced daily, whereas others can be obtained as needed. While the LIS allows access to and management of patient test reports, it also provides for a wide range of management reports. An LIS should allow for queries to be run facilitating the production of various ad hoc reports. A number of reports may be required to document and improve quality assurance (QA) performance for compliance with regulatory bodies, while others may be used for dissecting workflow, analyzing productivity and finance, monitoring efficiency and performance, and forecasting trends. It is a good idea to have LIS vendors periodically meet with LIS staff to review their workflow and suggest innovative ways to better mine the laboratory’s data. This service is generally initiated on the request of the LIS administrator. Management reports that are typically used include turnaround time (TAT) reports, exception reports, abnormal results report, quarterly financial report, infectious disease report, morbidity and mortality report, billing summary reports, reimbursement problem reports, rejected orders log, user action logs, recurring order definition reports, completion reports, collection list reports, quality control (QC)-Levy-Jennings report,

t7.3 Different types of backup media and technologiesTypes of Backup and Storage Media DescriptionDisk arrays A disk array is a disk storage system that contains

multiple disk drives.Optical discs CD-R and DVD-R

Optical disc drives use laser light or electromagnetic waves as a process of reading and writing to or from an optical disc such as a CD-R (compact disc–recordable) and DVD-R (digital video disc–recordable) or “writeable” discs.

Tape storage Tape (referred to as linear tape) is magnetic tape stor-age technology. Current data capacities are 1.5 TB with encrypion capability.

Solid state storage Solid state storage (SSD) is a data storage device that uses solid-state-memory to store data, with no mov-ing parts so that it is less fragile than hard disks.

RAID Redundant array of independent disks (RAID) are 2 or more hard disc drives. Various arrangements or data stor-age schemes divide and replicate data among 2 or more hard disk drives to achieve better performance, data reli-ability and larger data volume. Each RAID scheme affects reliability and performance in different ways.

Virtual servers Virtual server computers, also referred to as a virtual dedicated server (VDS), are a method of splitting a server whereby each server can run its own full-fledged operating system and each server can be independently rebooted.

Clustered computer A computer cluster is a group of linked comput-ers, working together so that they seem to form a single computer to improve the performance of an information system. Components of the cluster can be connected to each other through fast local area networks (LANs).

Networked computers Simply referred to as a collection of computers and devices working together over a network.

Technologies for System Backups DescriptionClouding Cloud-based backup services, where data is mirrored

to an off-site location to protect data in the event of disaster.

Snapshot data backup To avoid downtime, computer systems may perform a backup on a snapshot or read-only copy of the dataset, frozen in a certain point in time. For the LIS, the operating system backup should take place on a monthly basis. This type of backup allows for a system emulating host, an OS in a virtual machine, or in-house machine for future redirection or use. When sent to a virtual or off-site machine for backup, it is referred to as virtualization. More robust systems can make simultaneous multiple backups on more than 1 server.

Page 17: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

122 Pathology Informatics

7: Laboratory Information System Operations

Westgard rules-based reports, modified result report, change log, inventory report and result delivery logs. Refer also to the customer relationship management (CRM) section in Chapter 10 for additional LIS reports.

7.6 Total Cost of Operating an LISIf you are investing in stock you would seek a return

on capital, or a percentage on your initial investment. While it is common to wish to measure value in monetary terms, this is not so easy to do with IT investments. Hardware and software costs are tangible and can thus be added into the cost equation, but how does one place a monetary return value on intangibles such as patient and customer satisfaction, when measuring return? From a business perspective, added value is priceless. The cost of purchasing, implementing and maintaining an LIS can be millions of dollars. However, given the value of laboratory data, these costs are justifiable and often account for only a small percentage of the total laboratory and health system budget. In some industries the cost of IT can run upwards of 10% of gross revenues. Healthcare has typically been reluctant to invest to this degree (3.5% being the healthcare industry average; personal communication, Raymond Aller, MD), which may be why healthcare IT has lagged behind other industries.

One cost analysis model used by many IT organizations is the total cost of ownership model. Total cost of ownership provides a financial estimate. Organizations have found it to be a valuable tool in understanding costs and evaluating their organization’s IT investment. Many organizations use the total cost of ownership method because it allows both direct and indirect costs of a product or system to be factored in over its life cycle. IT system managers need to monitor and budget for costs related to (i) hardware and software including warranties, licenses and availability of upgrades, (ii) any indirect costs incurred or operation expenses such as production lost over a downtime or the cost of training users, and (iii) long-term expenses like hardware replacement or expenses due to future scalability. A budget (ie, a list of all planned expenses and revenues) related to the LIS may be partially under the control of the IT department. Typically, costs, budget items and cost-sharing models will need to be negotiated with laboratory administrators, the IT division, health system financial leadership, and in some cases, other departments. In designs where multiple hospitals use a single LIS, costs may be shared across hospital cost centers using a charge back or service charge model.

7.7 LIS ValidationLaboratories are in the business of providing

quality test results and information. The professionals working in the laboratory who are responsible for these tests follow rigorous measures to ensure the quality of their services and information they provide. The purpose of the LIS is to collect, process, disseminate and archive laboratory information. Thus, the LIS must be validated

t7.4 Types of management reportsCommon Report DescriptionBilling summary report

Provides a summary of all patient orders placed in the system for the selected range of dates.

Change log All changes made to patient records and orders, as well as changes made to the locations, personnel, laboratory tests and formula tables can be seen from this report. The log shows the type of change made, the date and time of the change, who made the change and a description of the change.

Collection list report

This report shows which collections need to be performed as specified by the start or end date and the type of order (routine, stat, timed).

Completion report

This report is a list showing information for each patient with a completed (approved) order in the selected date range.

Inventory report This report can save time and eliminate paper by allowing one to enter information on new lots of reagents and other laboratory supplies, including the lot number, quantity and dates received, opened, closed and expired. One can print total inventory, near expiration and low quantity reports.

Modified result log

This log displays each time patient results are edited, patient records are merged, patients are deleted and patient identifications are changed.

Recurring order definition log

This report lists open standing orders that have the next scheduled date in the selected date range.

Rejected orders log

This lists all the order choices that have been rejected, along with required documentation for reason rejected, within a user-defined date range.

Result delivery log

This log shows how patient reports were delivered, includ-ing the date and time the report was sent, the type of report that was sent, and the origin of the report. One may track personnel reviewing Web-delivered results, along with the date/time of review.

Reimbursement problem report

This report is a list of order choices, sorted by provider name, for which there may be difficulties in receiving pay-ments. It can be arranged for any given date range, and may be programmed to print daily or automatically.

Quality control-Levy-Jennings report

Quality control (QC) files can be reviewed using a Levy-Jennings graph. Color-coded graphs are usually provided along with all QC file data. In addition, multiple or single QC levels can be viewed and printed.

Qualitative qual-ity control file

LIS QC data is displayed, including Westgard analyses, for desired dates.

Turnaround time report (TAT)

Provides a report displaying the time it takes for orders to be processed from the time a sample is obtained/drawn to the time the results are reported/delivered.

User action log This log documents major user actions, such as viewing patient results and signing in and out of the system.

Utilization report A summary that calculates the total of each order choice made by providers over a defined period. In addition, a test utilization report can be run which further breaks down the information to show a summary of test usage.

Page 18: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

123Pathology Informatics

7: Laboratory Information System Operations

to verify that it is functioning properly and as intended. This is similar to validating an analyzer before it is used to process patient specimens in the laboratory to determine that it is performing accurately. Validation is defined as the documented act of verifying that a procedure, process and activity will consistently lead to the expected results. As part of a laboratory quality management system, all laboratories, no matter what type or size, in any organization, must ensure that all the components that make up their LIS perform as intended. This falls under the rubric of QA and regulatory compliance, which address proper LIS functioning through a process of information system validation. Several state, federal and other voluntary accrediting agencies require that LIS validation be performed and documented. Given that fact, it is surprising that there are so few publications actually detailing this process. Validation is a prerequisite for systems that handle regulatory data and is required for compliance with the Food and Drug Administration (FDA) Good Manufacturing Practices, 21 CFR part 11 [Turner  2002]. Finally, it is really up to laboratories to determine their own procedures and methods for how they will proceed with their LIS validation process. The following discussion should serve only as an overview of the considerations and issues regarding planning and executing the LIS validation process.

To have a successful validation, careful planning, execution, documentation and analysis of all validation testing and activities are crucial. The process is primarily manual and very resource intensive, requiring extensive documentation. This process may be so onerous that you may use a company that offers validation services. There are also technologies available that can be used to assist validation by automatically generating a wide variety of results and patient scenarios. An example of such technology is the laboratory validation testing software available from Software Testing Solution (Tucson, AZ), which has been designed to support validation of Sunquest’s Clinical Laboratory and CoPath modules [Tuthill  2009]. Once created, these scenarios can be replayed to revalidate the LIS in the future. Depending on the number of people dedicated to the LIS department, one may need to outsource the entire validation process, or at least that of certain departments in the laboratory that may be regulated by multiple regulatory agencies (eg, blood bank information system software that has to comply with the FDA).

7.7.1 Regulatory and Accrediting Agencies for LIS

The FDA requires that all blood bank software be validated under the Safe Medical Devices Act of 1990 [FDA  1996]. Further details of this process are described

under the transfusion medicine services section of Chapter  10. The FDA has determined that the blood bank is a manufacturer of biological blood products and thus must be held to current good manufacturing practices. Accordingly, FDA standards for validation of the computer information system must be followed whenever they are used in conjunction with the manufacture, storage or distribution of biologicals and drugs. Software in the blood bank and all other clinical laboratory departments are also governed by the Centers for Medicaid and Medicare (CMS) under the Clinical Laboratory Improvement Amendments Act of 1988 (CLIA ’88). Voluntary accreditation also requires computer validation to meet the needs of The Joint Commission (TJC), the Commission on Office Laboratory Accreditation (COLA), the American Association of Blood Banks (AABB) and CAP.

7.7.2 Rational for ValidationValidation of the LIS is a process undertaken

to ensure that the entire LIS is managing information accurately, efficiently, and most importantly, as it is intended. Throughout this QA measure, the laboratory must retain documentation that each component of the LIS has been checked and not overlooked. As with other QA measures in the laboratory, this validation effort could make the difference between a laboratory that is functioning successfully and one that is failing. Hence, it is a key component to the survival of the laboratory business. [Winsten  1992] The validation process is also an opportunity to identify ways in which to make improvements. Finding inefficiencies or weaknesses in the system early on allows corrections to be made sooner rather than later, thus avoiding needless cost and incremental effort.

7.7.3 Components Included in the Validation Process

It is important to include all components of the LIS in the validation process. This will include hardware, software applications, system processes and operations, peripheral equipment and users of the system. All of these elements must be documented to be working accurately and as intended. Computer hardware, while often under the responsibility of the IT department, may be running fine when it is purchased and during an installation, but can wear out over time, stop functioning properly at any time, or may be altered with the addition of other components in the computer network. Computer software, usually vendor supplied, is also not without errors, especially once it is altered during the implementation phase or following integration with other systems. An insignificant change in software code

Page 19: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

Pathology Informatics 147

Chapter 9

Laboratory AutomationLiron Pantanowitz, Ulysses J Balis, Anil V Parwani

Automation is a software problem, not a hardware problem.—Rodney S Markin

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.—Bill Gates

A utomation is defined as the use of automated equipment and information technology (IT) for a manufacturing or production process.

In the pathology laboratory, automation systems electronically transfer, analyze and process information related to diagnostic testing of patient specimens, controls, calibrators, standards and images [Chou  2009]. Automation is intended to reduce the need for human work in this process. t9.1 highlights some of the benefits and disadvantages of automation. Drivers for automation in the pathology laboratory include demands for high-volume testing, faster turnaround time, staff shortages, cost savings, less maintenance, fewer downtimes, and reducing laboratory errors [Boyd 2001, Gochman 1999, Hawker 2002, Holland 2006,

Sarkozi 2003, Seaberg 2000]. Automation helps eliminate the so-called “3 D tasks” (dull, dirty, dangerous), thereby providing safer working environments for laboratory technologists [Hoffmann 1998]. By diminishing several of the manual tiresome and repetitive tasks required to perform various laboratory tests, potential human errors (eg, erroneous sample

identification) can be ameliorated. A plethora of different automation tools exist t9.2, many of which are used to operate a laboratory automation system (LAS) [Boyd 2001,

Boyd 1996, Felder 1991, Graves 2000, McPherson 1998]. Advanced computer-aided technologies and engineering are being used to design, implement and monitor current automated systems. Automation is intimately associated with computer systems, and in the pathology laboratory, that involves interfacing instruments, devices and robotics with the laboratory information system (LIS) and/or middleware (the “glue” between software components). In fact, the LIS itself automates many tasks that would otherwise require manual intervention.

Automation in clinical laboratories has been available since the mid-1950s when manual testing moved to instrument platforms [Sasaki  1998, Sunheimer  2011].

A

t9.1 Advantages & disadvantages of automationAdvantages Increased productivity Offset staff shortages (ie, full-time equivalents, or FTEs) Economic gains Error reduction Improved turnaround time Avoid operator exposure to hazards (eg, biologic materials) Avoid operator exposure to injury (eg, performing repetitive tasks)

Disadvantages Need for highly technical personnel (eg, to troubleshoot systems) Technology cannot automate all tasks Facility constraints (eg, floor space) High initial cost of investment Downtime

t9.2 Different types of automation toolsTool DescriptionArtificial neural network (ANN)

Computational algorithms that “learn” to perform tasks or solve problems (eg, pattern recognition, sequential decision making)

Distributed control system (DCS)

Manufacturing system in which different control-ler elements are spread throughout the system network, collectively used to monitor and control distributed equipment

Human-machine interface (HMI)

The interaction between humans and machines that makes it easy and effective to operate and control the machine

Supervisory control and data acquisition (SACDA)

Computer systems that monitor and coordinate manufacturing or production processes based on data acquisition

Programmable logic controller (PLC)

Computer with programs used for the automa-tion of electromechanical processes

Programmable automation controller (PAC)

Control device that combines the advantages of PLC-style process control with the more flexible and integrated strengths of PC-based systems; they communicate over network interface protocols such as TCP/IP

Middleware Computer software that connects other software components running on a separate PC to add functionality

Instrumentation Devices designed to measure control processes and/or gather data

Motion control Devices used to control the position and/or veloc-ity of machines and robotics (eg, hydraulic pump, feedback sensors)

Robotics Technology related to robots that involves elec-tronics, engineering, mechanics, and software

Page 20: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

148 Pathology Informatics

9: Laboratory Automation

Since then, laboratory testing, particularly chemistry and hematology, has experienced innovative changes achieving near-total laboratory automation (TLA). This includes the introduction of automated instruments such as hematology cell counters (1960s), computerization related to implementation of LISs (1970s), conveyor belts and transport tracks used to move samples from 1 workstation to another (1990s), as well as barcoding and middleware solutions (2000s). Additional key factors in automating the clinical laboratory include multitest platforms that permit high-volume testing, integration of instruments with the LIS (unidirectional and bidirectional interfaces), ADT interface (collects admission, discharge, and transfer information over the hospital network), and autoverification (auto-release of verified test results). Components of a clinical LAS include (i) information systems (eg, LIS), (ii) automation systems (eg, process control software, middleware), (iii) analytical instruments (eg, analyzers), and (iv) process instruments (eg, transportation conveyance system, autostainer, data manager, etc).

Automation has been applied to the preanalytic, analytic, and postanalytic stages of laboratory testing. Today, commercial TLA systems are being used in many hospital-based laboratories, as well as smaller modular automated systems. True TLA couples several instruments to an integrated specimen management and transportation system and involves process control software that is seamlessly interfaced with the LIS [Markin 1992]. As the number of LAS installations grew, standards in the field were developed [Hawker  2000]. In anatomic pathology, while several aspects of the testing process are undergoing the transition to automation (eg, automated stainers and cover slippers, application of barcoding and labeling), this is far behind the level of automation that exists in the clinical pathology. One of the greatest hurdles to overcome in developing and implementing an LAS is the integration of disparate systems, including commercial laboratory instruments and user-defined work cells. Other factors that need to be taken into consideration when implementing TLA include selecting the “best fit” automation system for one’s laboratory, the capabilities of the existing LIS, operation costs, test volume growth potential, process improvement (workflow), patient safety, and facilities infrastructure (eg, space accommodation, electrical power) [Middleton  2000, Peck-Palmer  2009]. With constantly changing drivers of automation and incorporation of new technologies into existing systems, so too will the approach to the overall practice of healthcare [Berman  2001]. Advances in automation technology have also begun to place demands for new skills in the pathology laboratory including IT and data management (informatics). This chapter covers those aspects of automation that are of interest to the practicing informaticist.

9.1 Clinical Pathology AutomationIn the clinical pathology laboratory, automation

has been adopted at all stages of the testing process [Streitberg  2009]. Intralaboratory transportation systems have been used to convey barcoded samples along tracks between devices that perform centrifugation and decapping/capping, high-throughput analyzers capable of performing many different tests using 1 platform, and automated storage facilities. This array of equipment is integrated with the LAS, LIS, and in many clinical laboratories and middleware systems. Automation can involve isolated workstations (instruments devoted to a defined task) or work cells (a cluster of instruments with a central control module). Many laboratories still harbor individual instruments that require some degree of “walk-up” operation (ie, human intervention is still required), as opposed to direct-track sampling-ready instrumentation. Automation technology has been applied mainly to chemistry, immunology, urinalysis, hematology and coagulation instruments. This is not surprising, because these constitute the bulk of testing performed in most clinical laboratories.

9.1.1 Preanalytical PhaseThe preanalytic stage focuses on specimen

transportation and sample processing. Relying on courier services to deliver specimens to the laboratory typically involves a batch process and is often plagued by staffing and scheduling issues. Some laboratories have explored using mobile robotic vehicles for transport of patient specimens [Howanitz  1996]. Pneumatic tubes were introduced as an early solution to replace human specimen carriers [Plebani 2011]. However, these systems may be costly and complex to design and operate [Isken  2002]. A computer-controlled pneumatic tube system relies on cylindrical containers f9.1 being propelled via a network of tubes using compressed air or a vacuum. They are commonly used for point-to-point delivery of blood samples and small patient specimens, as well as other items within the hospital (eg,

f9.1 Pneumatic tubing system. Cylindrical containers are shown (right) that are used to transport specimens from various locations within the hospital directly to the receptacle within the laboratory (left).

Page 21: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

149Pathology Informatics

9: Laboratory Automation

blood products, drugs, documents) [Brooks  1986, Bruner  1980]. To reduce damage to sensitive laboratory samples, the tubes are often encased (eg, with a foam-type material), and using controlled airflow, the containers are slowed down for a soft landing at their destination station. The use of a pneumatic tube system to deliver blood samples from all over the hospital (eg, operating rooms, emergency room) to the laboratory has been shown to significantly reduce the turnaround times of results [Fernandes 2006, Guss 2008], without a major reduction in sample quality. Cylinders sent as a “stat” should receive the highest priority. However, laboratories should be aware that transportation effects (eg, G forces during rapid acceleration and deceleration) may alter samples, causing hemolysis (less so with serum-containing gel samples), changes in relative blood gas concentrations, and impaired platelet aggregation [Astles 1996,

Bolliger  2009, Ellis  2009, Hübner  2010, Sodi  2004]. With point-of-care testing (POCT), fewer pathology departments now actually rely on specimens to be sent to the central laboratory. Some institutions have even created a remotely controlled automated clinical laboratory that provides testing near the patient’s beside, while maintaining the distinct advantage of central laboratory control [Felder 1995].

After arriving in the laboratory, several tasks need to be accomplished with specimens, including identification, labeling, sorting (by tube characteristics and destination), centrifuging, decapping, aliquoting (splitting of samples), recapping, storage and potentially retrieval for add-on tests. If performed manually, these tasks are fraught with potential safety hazards (eg, exposure to aerosolized and direct contact with blood), are at risk for errors, and may cause potential delays in test processing. Fortunately, almost all of these steps have been automated in the clinical laboratory f9.2 [Dadoun  2000, Holman  2002]. Laboratories may use stand-alone

automated units that perform some of these tasks or a “hands-free” modular system designed to automate the entire process. Container/carrier identification (CID) and the use of barcode labels for specimens and their derivatives (eg, pour-off tubes, dilution cups, send-out specimens) have facilitated automation, helping to drive the workflow while concomitantly reducing the time required and potential error related to manual labeling. Chapter 18 discusses barcoding of pathology specimens in great detail.

9.1.2 Analytical PhaseThe analytical phase involves the segment of

laboratory workflow used to produce analytical test data. The analytical phase requires tubes to be directly placed onto instruments (autoanalyzers). Once on the analyzer, the following steps occur: introduction of samples into cuvets or dilution cups, volume checks, clot detection, addition of reagent into mixing chambers or reaction vessels, analysis (detection), calculations, read out and result reporting. Contemporary instruments have consolidated most high-volume tests into a single platform, offering a large menu of varied assays. Such analyzers produce high specimen throughput rates (ie, up to thousands of tests per hour) with great flexibility (eg, permit random access testing). Some analyzers have robotic arms to handle samples, stopper piercing components, precise pipetting devices with disposable tips that directly sample and transfer specimens, and sensors to determine liquid levels and detect short samples. The computer in most chemistry instruments can also maintain a real-time inventory of reagents stored within its compartments. Such reagents can be tracked with barcode labels containing specific information (eg, lot number, expiration date, concentrations of calibrants) and/or a liquid level sensor using a reagent probe. On-board computers can even offer troubleshooting and training protocols.

Several automated instruments have capitalized on digital imaging. Such sophisticated instruments may contain a camera station capable of recognizing different tubes, sample material, and performing sample volume calculations. Other examples are certain hematology analyzers (eg, CellaVision) that use automated microscopy analysis and contain software applications designed for remote viewing (telepathology) [Briggs  2009]. Automated digital cell morphology is the process by which cells are automatically located on a stained peripheral blood or body fluid smear, preclassified, stored and presented for confirmation by a technologist. In cytopathology, automated screening systems have developed under 2 major system designs: (i) those that perform primary screening without cytotechnologist

f9.2 Automation equipment used to handle samples in the clinical laboratory. Conveyer system for sample transportation (left); automated sample sorter (top right); automated sample decapper, aliquoter and labeler (bottom right). (Images courtesy of Mohamed A Virji, University of Pittsburgh Medical Center.)

Page 22: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

150 Pathology Informatics

9: Laboratory Automation

interaction (eg, BD FocalPoint using SurePath Pap tests), and (ii) an interactive design that serves as the “cytotechnologist’s cytotechnologist,” in which both the cytotechnologist and the computer depend on each other for Pap test interpretation (eg, ThinPrep Imaging System) [Pantanowitz 2009a]. With such interactive screening systems, the cytotechnologist benefits from improved overall job satisfaction, decreased fatigue and increased throughput [Pantanowitz 2009b].

Instruments harbor their own on-board computer that is linked to the LIS or some other master controller computer system (see Section 9.3, “Middleware,” below). These instruments can have unidirectional or bidirectional interfaces (eg, RS232) with the LIS. For a unidirectional interface, the laboratory technologist has to manually enter the test orders on the device; after the analysis, the results get transmitted electronically to the LIS. With a bidirectional interface, the LIS transmits the test order to the device and also receives the final results. Electronic test orders may be transmitted to instruments (i) directly on receipt or entry of the order in the LIS (broadcast type LIS-instrument interface) or (ii) when a tube gets placed onto the analyzer (query-type interfaces). For the latter interface, reading of the barcode on the specimen tube by the analyzer triggers a query to the LIS for any orders related to the order number or accession number. Today, many instrument computers are capable of linking to the Internet via a transmission control protocol/Internet protocol (TCP/IP). This allows the instrument to link up with the manufacturer’s own site to monitor the device’s performance in real time and help resolve any problem that may arise.

9.1.2.1 AutoverificationThe role of the instrument’s computer is to support

signal processing, data handling, and process control. With signal processing, analog (electrical) data from the detector (microsensor) gets converted to digital signals. The computer not only acquires data, but also calculates, monitors and displays data (eg, warnings, Levey-Jennings charts, calibration curves), which facilitates communication between the analyzer and operator. The instrument’s computer can be programmed for several purposes, such as adding new tests or to flag data. Linking instrument computers to the LIS has had a major impact on improving automation in the clinical laboratory. For example, the LIS can easily perform calculations (eg, delta check) and execute algorithms, reflex testing, or rules [Vermeer  2005]. Many of these rely on rule-based logic (decision trees or expert systems), which refers to the comparison of specific base information with a set of actions typically based on “if, then” statements. This improves productivity and consistency, reduces staff needs, lowers errors, and speeds up workflow.

A popular example now adopted in many laboratories is autoverification (autoreleasing), the automatic review and release (verification) of results received from a laboratory instrument without technologist review [Crolla  2003, Duca  2002, Pearlman  2002,

Torke  2005]. Autoverification is also covered in Chapter  5. Autoverification is an application of rule-based logic that allows communication between a laboratory instrument and the LIS to generate an action based on a set of predefined rules or algorithms. With this mechanism, a test result transmitted over an instrument interface is evaluated for “pass” or “fail” by the LIS, based on parameters that the laboratory defines in the system. If it passes, then the result is automatically released by the system (ie, no manual review is required). Any value that fails (ie, falls outside defined parameters) requires manual review by a designated operator (eg, laboratory technologist). Without this technology, the release of laboratory results would require manual intervention before such results could be transmitted, thus increasing labor costs and decreasing turnaround time. Many customized rules can be used for this purpose, such as reference ranges, checks that quality control was passed, critical values, delta checks, dilution needs, instrument flags, laboratory review policies, and specific patient locations or ordering physicians. Autoverification can be set up for any test, though the greatest benefits may be obtained from frequently ordered tests (eg, automated chemistry assays and routine hematology tests such as a complete blood count) [Miller  2006]. It is important that the laboratory be able to suspend autoverification if a problem arises. Autoverification expert systems can be enabled through the laboratory instrument, middleware, or LIS [Pfeiffer 2010]. The Clinical and Laboratory Standards Institute (CLSI) has published guidelines for autoverification (AUTO 10A). The autoverification rules and process must be tested at least annually to comply with regulatory requirements.

9.1.3 Postanalytical PhaseThe postanalytical portion of the workflow

involves the delivery of diagnostic information to healthcare providers and storage of specimens. Electronic transmission of laboratory results, which greatly speeds up the delivery process, is covered elsewhere in many chapters of this book, but should be recognized as an important form of automation. Specimen storage and tracking systems can also produce large gains in productivity and use sophisticated robotics to do so efficiently. Having labeled samples stored automatically in an organized fashion (eg, placed in numbered positions in numbered racks) in a refrigerator (or freezer) minimizes samples getting lost and/or difficulties

Page 23: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

151Pathology Informatics

9: Laboratory Automation

incurred trying to locate them for retesting. Storage and tracking systems can reduce the time to find a sample by as much as 60% [Dean  2009]. To retrieve a specimen, the sample accession number or patient medical record number (MRN) can be used to query the archiving system’s database. Such systems may be part of TLA design or a middleware solution. Several laboratories are still struggling with fully automating add-on test orders received via computerized physician order entry (CPOE), and inevitably wind up relying on paperwork or some human intervention. Some storage systems even include a mechanism for automatic sample disposal at predetermined times.

9.2 LAS SoftwareThe LAS is patterned after computer-integrated

manufacturing, which is a manufacturing approach of using computers (hardware and software) to “command and control” an entire production process [Craven 1988]. Such integration permits individual processes to exchange information with each other and initiate actions. Computer-integrated manufacturing relies on data (storage, retrieval, manipulation and presentation) and algorithms to modify processes. For LAS, software is required to support process control both at the level of instruments and unique specimens. The components of the LAS that are to be well integrated include:

ο  Input area for preanalytical sample processing

ο  Transportation system

ο  Queuing system to line up specimens before they are analyzed

ο  Buffer area to retain specimens until they are finalized

ο  Storage and retrieval systemIdeally, the LAS should be controlled by a

technologist-independent centralized computer system running a process management software program. Moreover, only a single operator should ideally be required to view all components and monitor the status of the LAS from a single console (PC workstation). Interfaces are one of the most important components of the LAS, because they connect the LAS with the instruments and LIS f9.3. Automation (process control) software may reside on different hardware (eg, data, instrument manager, virtual server) than that used by the LIS and the instrument’s on-board computers. If a laboratory relies on proprietary automation software tied to an instrument or that vendor’s instrument data manager, then this may constrain the level of automation that can be achieved (eg, inability to swap or add devices). LIS-LAS interfaces may support either Health Level 7 (HL7)

or American Society for Testing and Materials (ASTM; ASTM 1394) protocol for electronic data exchange. Whereas the ASTM protocol provides only simple functionality, the HL7 interface specification supports both the transfer of information and implementation of rules for automation. An external communication system/instrument interface manager (ECS/IIM) component may sometimes be used to perform protocol conversions. Software for automation typically uses a relational database strategy to control specimen routing, scheduling, and tracking. Some of the key process control functions are as follows [Markin 2005]:

ο  Passing order information to instruments or their data managers

ο  Transmitting results (verified or unverified) to the LIS

ο  Real-time sample routing and monitoring

ο  Assigning priority to instruments

ο  Automatic load balancing between instruments

ο  Specimen handling (eg, aliquotting) algorithms

ο  Rules engine (reflex testing and autoverification)

ο  Storage and disposal criteria

ο  On-board reagent inventory control

ο  Operator alerts and error notificationRules engines are clearly a key component of

process control software. They are used to implement client-specified decisions. A user may define many rules such as routing of specimens to optimize result turnaround time and/or autoverification of results.

f9.3 Schematic information technology (IT) hierarchical infrastructure of a laboratory automation system (LAS). Process control software of the LAS typically resides on its own computer hardware. Transactions arising from orders in the hospital information system (HIS) are relayed via the laboratory information system (LIS) and LAS to specific instruments. Analyzers, of course, may also connect directly to the LIS. The transportation mechanism (conveyor track) may be integrated into the automation system.

Page 24: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

Pathology Informatics 231

Chapter 15

Digital ImagingAnil V Parwani, Michael Feldman, Ulysses Balis, Liron Pantanowitz

A large component of pathology is dependent on processing visual information, which often relies on digital imaging [Hedvat  2010, Leong  2004].

With the advent of increased computing speed, rapid networking and cheaper storage, digital pathology images and their applications are being increasingly used in pathology practice. Compared with analog (ie, 35-mm film) photographs, digital images permit the image quality and content to be assessed at the time of capture, have no developing delays or costs, are easily duplicated and manipulated, and facilitate image storage, cataloging, retrieval, sharing and applications [Beals  2001]. Some clinical applications for digital images include capturing of gross and autopsy pathology specimen findings, image-enhanced pathology reporting, education (eg, conferences and presentations), interpretation for diagnosis (eg, telepathology), image analysis, and quality assurance (QA; eg, second opinions and archiving of slides).

The spectrum of digital images used in pathology ranges from static (still or “snapshot”) to whole slide (sometimes called “virtual”) images. In the late 1990s, whole slide imaging (WSI) scanners were developed, allowing entire glass slides to now be imaged for permanent storage at high resolutions. The technology behind WSI is to use a robotic microscope that captures a large area of a slide, field by field, and a computer that then “stitches” these individual fields together into a montage. Earlier WSI systems took a long time to capture a single extended field. WSI scanners based on traditional robotic microscopes are still used largely for education and QA studies. Today, these scanners are faster, smaller, and their cost has decreased considerably. The quality of the images produced by these devices is greatly improved and, arguably, generally of diagnostic quality. With viewing software it is now possible to have annotations and clinical metadata presented along with images.

Pathology technology vendors continue to introduce more sophisticated options for the capture, storage, retrieval and analysis of digital images. As the adoption and implementation of digital imaging become more widely used by many different pathology practices, greater understanding of digital imaging and its applications is needed. This includes an understanding of the technology involved and an appreciation for the capabilities and limitations of digital imaging, as well as the necessary practice accommodations related to

infrastructure, workflow, user acceptance, validation, regulations and reimbursement. The digital era threatens to replace the conventional light microscope, but hopefully not the pathologist [May  2010, Pantanowitz  2010]. Several digital imaging applications are emerging in pathology, such as image analysis using algorithms, computer-assisted diagnosis and 3D imaging, which have greatly benefitted the field of biomedical informatics. This chapter reviews the field of digital imaging covering both basic and advanced topics relevant to pathology.

15.1 Digital ImagesA digital image is composed of thousands of tiny

pixels (PIcture ELements) regularly arranged in rows and columns. Pixels are rectangular shaped. Each pixel contains data (binary 0 and 1), storing values such as brightness and color. A digital image is thus a numeric representation of an image captured with a device (eg, digital camera or scanner). A digital image is also called a raster or bitmap image. In comparison, a vector image (computer graphic) is based on mathematics (eg, geometrical lines, curves or shapes). A close magnification of 1 small area of a digital image shows the pixel-level detail of the composition of that area. When such an image is viewed from a distance, the pixels are relatively small and indistinct, and the overall image tends to appear clear and focused. However, when the same image is viewed more closely, the individual pixels become more apparent, and the image starts to appear less clear.

15.1.1 Pixel Resolution and DensityThe resolution of an image refers to the

detail that a digital image holds; ie, the pixel count for each dimension of the image (resolution = image width × height; measured in pixels). By convention, pixel resolution is noted with the first number representing the width (number of pixel columns) and the second the height (number of pixel rows), such as 1024 × 768. Alternatively, resolution can also be cited as the total number of pixels in the image (typically megapixels). The size of the image (width × height) depends on the actual size of the printed image (for example, 4″ × 6″ or 10 cm × 15 cm, which is the most commonly used print size in North America). Pixel dimension indicates

A

Page 25: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

232 Pathology Informatics

15: Digital Imaging

the height and width of an image multiplied by the dots per inch (DPI) to give you a measure of the image’s resolution. Thus, if an image has 300 DPI, a 3 × 5-inch image will have more than 1.3 million pixels (multiply 300 × 3 × 300 × 5). Image resolution differs from pixel density, which is a measurement of the “resolution” of an image with respect to the output device, such as pixels per inch (PPI) of the image displayed on a digital camera or computer monitor, or DPI when the image is printed using a printer. Pixel density is discussed in greater detail in Section  15.5.4. The higher the resolution, the more information the image contains (ie, the image gets sharper and more detailed). If the resolution of an image reduces without changing its size, the pixels get larger and there is less detail in the image. Alternatively, with higher-resolution images, larger images can be produced. f15.1 demonstrates how the same image may appear at different pixel resolutions.

Of note, image resolution can also be measured in other ways. Spatial resolution is a measure of how closely lines can be resolved in an image (ie, the number of independent pixel values per unit length). This type of resolution typically depends on the properties of the system creating the image. For example, with computer monitors the spatial resolution is often 72 to 100 lines per inch (or pixel resolutions of 72 to 100 PPI). Computer monitors display pictures by dividing the display screen into millions of pixels, arranged in rows and columns. Hence, a high-resolution monitor that offers a 768 × 1024

pixel array will have 786,432 pixels (768 × 1024). Spectral resolution refers to the ability to distinguish light of different spectra (wavelength) in color images. A multispectral image has high spectral resolution, where one can resolve finer differences of spectrum than is usually required to reproduce color. The resolution of digital cameras is discussed in Section 15.2.4.1.

15.1.2 Color and Bit DepthBlack-and-white digital images are made up of

pixels with different shades of gray (256 different grays), whereas color images are made up of colored pixels. Black and white is represented by 0 and 1 (1 bit). Thus, each black and white pixel is stored in a single byte (8 bits) of memory. The pixels in a color digital image each store 3 numbers that correspond to the red, green and blue (RGB) levels of the image at a particular location. RGB are the additive primary colors for mixing light f15.2 f15.3 f15.4. The subtractive primary colors used for mixing ink or paints are cyan (blue-green), magenta (purple-red), and yellow (collectively abbreviated CMY). Computer displays use the additive color model, whereas color printers use the subtractive

f15.1 Pixel density and resolution. When pixel density is at or beyond the spatial density for a given display or print technology, image quality is perceived as being satisfactory (A). While initial expansions of rendered pixel size (B) generate images that remain satisfactory, further expansion ratios (C) of the original size causes blurring of the subject matter. This perception is consistent with the Nyquist sampling theory, which stipulates that such continued expansions of fixed quantities of original imagery pixel data will result in “empty magnification” where high-frequency spatial information is lost. At extreme levels of empty magnification (D) the subject matter becomes unintelligible, owing to the extreme loss of high-frequency spatial information. For this reason, digital capture, storage and display systems should be designed to maintain suitable spatial density of pixels for every stage of image utilization.

f15.2 Color systems. Different color systems have been developed to represent different forms of color image reproduction. For emissive light systems (A), different ratios of red, green and blue (RGB) light are projected or otherwise generated and subsequently projected (as with liquid crystal display [LCD] monitors and/or digital projection). Emissive light is also termed the additive color system, where the combination of the primary colors RGB yields white. The subtractive (or reflective) color system (B) is used where ambient light is to be filtered by the correct placement of pigments on printed matter, which serves to subtract unwanted colors, thus allowing only the intended colors to be reflected. The 3 colors used in this system (the secondary colors) are cyan, yellow and magenta, with superimposition of the these 3 colors yielding complete attenuation of visible light, which is black-ness. The CIE 1931 chromaticity diagram (C) is yet another model of light, which serves to define the boundaries of possible realizable color for both additive and subtractive color systems, with the former having significantly greater latitude for dynamic range than the latter. The outer perimeter serves to depict wavelength of light at maximal color saturation. The CIE model is often used to calibrate color display systems to a common universal standard.

A

C D

B

Page 26: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

233Pathology Informatics

15: Digital Imaging

color model. To compensate for the impure nature of most printing inks, the color black (referred to as K) is added (ie, CMYK). Any color can be created by mixing the correct amounts of red, green and blue. Each value of 0 to 255 takes up 8 bits, so the total amount of space to define the color of each pixel is 24 bits. In other words, with 256 different (indexed) levels (or color values) available for the primary colors, each color pixel can be stored in 3 bytes (24 bits) of memory. For images of the same size, a black-and-white version uses 3 times less memory than a color version. A 24-bit digital image corresponds to roughly 16.7 million different possible colors, which is considered “photographic” quality. The human eye can only distinguish 100,000 different colors.

In addition to resolution, another important parameter that defines the clarity and fidelity of a digital image is its color depth, also called bit depth. Bit depth refers to the number of color choices (shades or gradations) per pixel. Bit depth is usually expressed in bits and denotes the actual number of bits of information that are used to define a given color t15.1. A bit is a single binary unit of information generally expressed as either a 0 or 1. For example, as alluded to before, a fairly common depth is 24-bit color, which means that the color is designated by a string of 24 zeroes and ones. The 24 bits are shared by all 3 primary colors (8 bits for red + 8 bits for green + 8 bits for blue). 8 bits of information can designate 256 different shades (28 = 256). Bit depth, by influencing the amount of data stored in pixels, can influence the digital image file. Image file size can thus be determined by multiplying the number of pixels with the number of bits per pixel (ie, resolution × color depth).

Different ways to specify color also include the hue, saturation and value (brightness) components of a color. Hue refers to the (spectrum) quality of color determined by its dominant wavelength (actual color) expressed from 0 to 360 degrees. Colors with the same hue are distinguished by their lightness and/or chroma (eg, “light blue” or “pastel blue”). Saturation is the intensity (0 to 100%) of a specific hue. As the saturation of a color decreases it becomes more pale (washed out) until it eventually fades to neutral. Value (brightness) refers to

f15.3 Red, green, blue (RGB) color spaces. The most commonly encoun-tered 24-bit RGB color space allots 8 bits of dynamic range for each of its 3 color channels. This yields 256 discrete luminance levels for each color, or 16,777,216 total possible distinct colors. (A) depicts the RGB cube as viewed from the white vertex (255,255,255), with the other primary color (RGB) and secondary color (CMY) vertices similarly annotated. As viewed from a con-ventional XYZ coordinate system (B), the RGB space reveals that the green, blue and red component colors form the major axes, with the secondary colors forming from the dot products of each of the possible pairs of major axes. In the alternative hue, saturation and value (HSV) color system (C), a linear matrix transformation allows for the reencoding of color information in a new 3-dimensional conical space, where deviation from the central axis represents saturation, elevation from origin represents brightness (or value) and angular position along the conical surface represents the particular color (or hue). Use of alternative color spaces, such as the HSV space, allow for classification of color pixels based on actual color, independent of either the degree of brightness or color saturation. This color space potentially simplifies image analysis of histopathologic material, which usually exhibits conserved color, even when staining intensity (and thus, RGB color ratio) varies between separate process batches. The CIE 1931 XYZ color space was created by the International Commission on Illumination (CIE) in 1931.

t15.1 Relationship between bit depth and colorBit Depth Colors Available1-bit Black and white2-bit 4 colors4-bit 16 colors8-bit 256 colors16-bit 32,768 colors24-bit 16.7 million colors32-bit 16.7 million + 256 levels of transparency**Transparent colors allow the background to show through the image.

f15.4 Contemporary red, green, blue (RGB) image rendering. Composite RGB color images (A) are actually 3 coregistered images: red (C), green (D) and blue (E), which independently provide luminance information equivalent to each of the 3 visible spectrum ranges associated with human color vision. Pair-wise superimposition of each of the color pairs (red-green as F, green-blue as G and blue-red as H), depict the incremental value of specific color channel activation. When all chrominance information is removed by com-bining the 3 images via a linear transformation matrix, a gray scale composite image (B) is obtained, with this numerical transformation being irreversible.

Page 27: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

234 Pathology Informatics

15: Digital Imaging

how light or dark a color is. Any color with a brightness of zero is black, regardless of its hue or saturation. The luminance of a color is a measure of its perceived brightness. Chromaticity is an objective specification of the quality of a color based on hue and saturation, regardless of its luminance. The hue saturation value (HSV) color space characterizes colors according to their hue, saturation and value, based on a hexcone model. The hue saturation lightness (HSL) color space attempts to characterize colors according to their hue, saturation and lightness (brightness) based on a double hexcone model.

15.1.3 Image FilesThe size of a digital image file is expressed in

bytes. For example, the size of an image file needed for a 640 × 480, 24-bit color image is 921,600 bytes, or roughly 0.92  MB. File size depends on the number of pixels in the image and how much data about color each pixel holds. Therefore, file size = number of pixels (width × height) × bit depth (number of bytes used for each pixel). Larger file sizes can result in markedly decreased performance in terms of the time it takes the network to transfer the file, the computer to display the image on the screen, and the printer to print the image.

There are a number of standard image file types t15.2. The filename extension (such as .jpg or .jp2) is seen at the end of the image file’s name. Most image file formats are nonproprietary (GIF being a notable exception) and are therefore generally widely supported by most imaging applications. Each image format has specific strengths and weaknesses. Bitmap (BMP) supports noncompressed full-color images and are often very large files. GIF supports lossless compression of limited (8-bit) color images and line art. GIF images are particularly suitable for Web pages for fast downloading and for use in clip art with presentation software. PNG images are an alternative to GIF for use on Web pages, but they are not yet universally supported. JPEG (or JPG) is a 24-bit lossy compression format created in 1992 that performs particularly well with photographs.

JPEG allows variable compression to be set by the user on an image-by-image basis. JPEG 2000 is a new image compression standard and coding system created by the Joint Photographic Experts Group committee in 2000. The main advantage of JPEG 2000 relates to the flexibility of the scalable codestream obtained after compression of an image. By ordering the codestream in different ways, applications can achieve significant performance increases. As a result, JPEG 2000 requires complex encoders/decoders and may exhibit some visual artifacts (eg, ringing artifacts). The Tagged Image File Format (TIFF) supports uncompressed or lossless compression of images, and in pathology are good for printing photos.

15.1.4 Image CompressionFile compression can solve problems caused by

larger file sizes t15.3. Reduced image size helps with image processing, storage and transmission. Compression refers to compacting of an image by removing redundant information (eg, pixels of the same color). For example, a “raw” or uncompressed computer image file of an 8 × 10 color graphic in TIFF format can be nearly 2.8 billion bits in size. Since a “byte” is 8 bits, that translates into 2.8/8 = 3.5 million bytes, or 3.5 megabytes (MB). An 8 × 10–inch color print of a renal biopsy produced on 1200 DPI 24-bit printer requires a computer file size of 345.6 MB (9600 × 12,000 × 24/8 = 2,764,800,000/8 = 345,600,000 bytes = 345.6 MB). There are 2 fundamental types of compression, “lossless” and “lossy.” In lossless compression, no information is lost in the compression-decompression cycle, and the uncompressed file is exactly the same as the original. In lossy compression, some information is lost in compression. This results in a decompressed file that is not exactly the same as the original file. Lossy techniques are capable of much greater data compression than are lossless ones. However, because some data can be lost in lossy compression, image quality may be affected, especially at high levels of compression or after repeated cycles of compression-decompression.

t15.2 Different digital image file formatsAbbreviation File FormatBMP BitmapGIF or GIFF Graphics Interchange FormatPNG Portable/Public Network GraphicJPG or JPEG Joint Photographic Experts GroupTIF or TIFF Tagged Image File FormatPICT Short for “picture”PSD Adobe PhotoShop file formatEPS Encapsulated Post ScriptPDF Portable Document FormatEXIF Exchangeable Image FileDICOM Digital Imaging and Communications in Medicine

t15.3 Digital file format memory requirements for a 24-bit color image

Image Resolution JPEG TIFF16 × 16 2k 2k320 × 240 24k 226k640 × 480 56k 902k1024 × 768 104k 2306k1280 × 1024 147k 3842k1600 × 1200 161k 5627k3200 × 2560 458k 24,002k3840 × 3072 611k 34,562kImage size is represented in kilobytes (k)

Page 28: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

235Pathology Informatics

15: Digital Imaging

15.2 Digital CamerasDigital (filmless) cameras are available in a wide

range, including compact cameras, more expensive digital single-lens reflex (DSLR) cameras, desktop cameras (Webcam), integrated digital cameras incorporated into devices (eg, mobile phones), cameras designed to attach to light microscopes, and specialized digital cameras used for advanced imaging (eg, multispectral imaging) [Riley 2004].

15.2.1 Handheld CamerasCompact (point-and-shoot) cameras are designed

to be portable and may be suitable for taking occasional “snapshots” around the clinical laboratory. They usually have a retractable lens and built-in flash. Because compact cameras are designed mainly to be easy to use, they generally do not provide images of high picture quality. Bridge cameras are higher-end digital cameras, but still use a fixed (noninterchangeable) lens and small sensor. However, their highly specified lenses have a large zoom range. DSLR cameras have a unique viewing system, in which a mirror with specialized sensors reflects light from the lens through a separate optical viewfinder. These cameras have much larger sensors, which offer superior low-light performance. Also, because they use interchangeable lenses, the user can select a lens designed for the application at hand, such as macro photography of gross pathology and autopsy specimens. Consumer handheld cameras have also been used with a microscope for micrography, either by capturing a digital image through the eyepiece or using a microscope adapter [Pantola 2009]. They have been used for their versatility, being usable both on and off the microscope and for the ease with which they can be moved from 1 microscope to another. Handheld digital cameras typically include a liquid crystal display (LCD) screen as well as image management and editing software (firmware). The ability to preview your shot and delete images right on the camera is very helpful.

15.2.2 Digital Microscope CamerasThe major disadvantages of using consumer-type

digital cameras mounted on microscopes are unequal illumination and a colored background [Regitnig 2003]. Digital cameras manufactured to be attached to a microscope typically produce high-resolution and high-quality images. These digital microscope cameras are attached (coupled) to a microscope via a C-mount adapter f15.5 [Balis 1997]. The light available to the camera is determined by the microscope optics, not the camera. While magnification through the eyepieces of the microscope is not affected, some of the microscope’s light will be diverted to the onboard camera. This can often be controlled manually. Optical couplers for C-mount cameras may be configured

f15.5 (A) Digital camera shown attached to a microscope via a C-mount adapter. (B) The internal components of a microscope digital camera are shown (A = camera housing, B = cooling system, C = image sensor support circuitry, D = C-mount adapter, E = infrared cut-off window, F = computer system interface, G = CCD sensor). (Image courtesy of Michael W. Davidson, National High Magnetic Field Laboratory, Florida State University, Tallahassee, FL.)

A

B

Page 29: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

236 Pathology Informatics

15: Digital Imaging

with different magnification factors. The higher the magnification factor in the coupler, the smaller (more highly magnified) is the field of view (FOV) through the camera. This FOV may be slightly different from that seen through the microscope eyepieces. Occasionally when a C-mount coupler is too low in magnification for the digital camera being used, the cone of light coming through the coupler does not fill the camera’s imaging sensor because it is not magnified enough. This causes vignetting of the image (ie, corners are cut off in black or the entire FOV has a circular black border). Different cameras are suitable for varying contrast methods including light microscopy and fluorescent work. Several digital photomicroscopy cameras provide an ultra–high-quality image output and have low-noise circuit designs permitting the direct capture of darkfield and fluorescence images. Most of the cameras in this category are connected to personal workstations (PCs) via SCSI, FireWire or USB interfaces. USB 2.0 offers more bandwidth than IEEE 1394 (FireWire) or SCSI digital cameras. Connection to a PC may require the use of card adapters. Cameras may require specific drivers if they are to be supported by Apple Mac operating systems. Such cameras are accompanied by imaging software that needs to be installed on a computer. Such applications typically provide live preview of images, focusing aids, the ability to acquire images, perform measurements and annotation, as well as manipulate images (eg, rotate, crop, adjust contrast, etc). t15.4 lists some of the recommended features of a microscope digital camera.

15.2.3 Specialized CamerasDigital cameras have been developed for

specialized purposes and for advanced imaging purposes. Microscopic digital imaging technology has been used in various electron microscopes [Chen 2011]. The charge-coupled device (CCD) in these electron microscope imaging systems converts electrons that carry image information through electro-optical conversion devices to the light signal and sends the signal to the CCD. Digital cameras

are also one of the critical components of whole slide digitization systems [Rojo  2006]. For multispectral imaging, digital cameras can have complex optomechanics. For example, light of specific wavelengths gets captured by rotating a filter wheel in front of a grayscale digital camera, and then a picture is taken as each filter is positioned in front of the lens. To avoid any noise, vibration or potential for image shift due to the mechanics of the camera, electronically tunable filters without moving parts have been developed for some digital cameras [Mansfield 2008].

15.2.4 Digital Camera ComponentsThe different components of a digital camera can

be appreciated by tracing the pathway of light entering the camera all the way to storage of the digital image f15.6. In general, the optical system of a digital camera is the same as in film cameras. They contain a lens, diaphragm and shutter that focus light onto an electronic image capture device (sensor), converting photons into electrical signals.

15.2.4.1 Image SensorsThe photosensor (silicon chip) in a digital camera

is a light-capturing device. They are either a CCD or a complementary metal oxide semiconductor (CMOS)- type device. The CMOS device functions like a CCD, but uses less power. The sensor converts light (photons) into electrical (digital) signals. Sensors are covered with an array of light-sensitive square or rectangular photodiodes (eg, 5.25 µm across) arranged in a grid, 1 for each pixel. They produce an electric charge when exposed to light,

f15.6 Diagram showing the steps involved in the processing of a digital image inside a camera. (1) Light from the camera lens passes (2) through a Bayer color filter array made up of red, green and blue (RGB) primary colors overlying (3) the sensor (CCD or CMOS). The sensor is composed of an array (grid) of photosensitive diodes called photosites that capture photons and convert them to electrons. The electrons are then (4) transferred to an ampli-fier (gain) called a capacitor. CMOS devices at this stage use several transis-tors at each pixel to amplify and move the charge. The data then (5) gets converted using an analog-to-digital converter (ADC) from analog to digital data as a picture element (pixel). Within the camera’s microprocessor (6) the color information for each pixel may be derived by interpolation. At this stage (7) several postcapture processing steps may occur such as white balance or image compression. The pixels are then relayed in consecutive order and (8) stored as an image on the camera’s memory as a file or transferred to a removable memory card or drive.

t15.4 Recommended features for a microscope digital camera

High-speed imaging for real-time viewing High-resolution image capture High-dynamic (luminance) range Field of view (FOV) that closely matches the FOV in the microscope eyepiece Low-noise circuitry and electronic shuttering to eliminate vibration Cooling system to provide low-light performance FireWire or USB interfaces Imaging software with a third-party interface (eg, TWAIN) C-mount adapter

Page 30: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

237Pathology Informatics

15: Digital Imaging

capturing a numerical light intensity value at every distinct location on the sensor. The brighter the image that strikes a given point on the sensor, the larger will be the value (accumulated charge) recorded for that pixel. A CCD usually has only 1 amplifier at the corner of the entire array, whereas in CMOS sensors each individual photosensor has an amplifier (transistor) associated with it. CCDs exhibit great diversity in physical size, aspect ratio (often 4:3 ratio), pixel size and grid topology. For WSI scanners, 2 types of CCDs are encountered f15.7. Not all photosites produce effective pixels. Some camera manufacturers, for example, crop the CCD (eg, by masking areas of the sensor that include circuitry to measure the charge) to match lens coverage parameters. Some cameras contain “super CCD” sensors with diagonally arranged photodiodes to facilitate interpolation. Interpolation is used to produce a larger digital image (fills in pixels) than a sensor can capture (known as digital zoom, which differs from true lens optical zoom). Digital cameras may contain 1 or more CCDs f15.8, allowing different captured images to be analyzed separately or postprocessed with an image fusion algorithm to produce a better image.

The resolution of a digital camera is often limited by the image sensor. The sensor resolution is the total number of pixels forming the image. The pixel count

(usually displayed in megapixels) alone does not indicate the resolution of the entire camera. Other parameters are also important, such as the size of the sensor, color filter, lens quality and pixel organization. A larger sensor with the same number of pixels typically produces a better image than a smaller one. Photosites only keep track of the light intensity, not color. Therefore, color information is obtained by covering the photodiodes with a color filter array (CFA). The most commonly used color filter is a Bayer filter used to capture the primary additive colors red, green and blue (RGB). Usually there are twice as many green photosites (eg, 50% green, 25% red and 25% blue), which is why they are sometimes called RGGB, RGBG or GRGB filters. This is because the human eye is more sensitive to green light. Alternative less common filters include the CYGM filter (cyan, yellow, green, magenta) and RGBE filter (red, green, blue, emerald). When a sensor coated with an R, G, or B filter is read, the 2 missing colors for each pixel location are calculated from the surrounding pixels that contain the missing color. This color mosaic technology allows the color data to be captured in 1 shot. However, some cameras exploit 3-shot or 4-shot technology by adding an RGB changing filter in front of the CCD. In this case 3 consecutive images are captured (1 in each of the 3 color states—R, G and B) which measures every color value at each pixel, maintaining the full resolution of the CCD for each color. Such cameras can offer users the flexibility of capturing images in either color or monochrome. Reconstruction of a full (mosaic)-color digital image may need a demosaicing algorithm. Sometimes reconstruction may have color artifacts (so-called aliasing), often introduced by interpolation (“guessing” color intensity values not captured for each

f15.7 Contemporary charge-coupled devices (CCD) used in whole slide image (WSI) scanners. (A) In the case of tile-based WSI scanners, full frame aerial CCDs are used to capture complete square or rectangular regions of the slide surface area, with robotically-controlled X and Y direction step movements between image captures to realize acquisition of the full slide surface area. (B) In the case of WSI scanners based on line-scan, also known as time domain integration (TDI), a linear CCD is used to allow for the capture of extremely long image strips, under continuous Y axis motion and stepped X axis motion, to realize acquisition of the full slide surface area via multiple strip images.

f15.8 Different digital camera sensors. (Left) In a digital camera with a single chip charge-coupled device (CCD), a filter is used to split the light signal into RGB at each pixel. The information is then combined using soft-ware to create a final digital image. (Middle) In a digital camera with a triple chip CCD, a prism with filters is used to split the light signal into RGB signals for each of the 3 CCD arrays. The information is then combined to give a true color at each pixel. (Right) In digital cameras using progressive scanning the CCD array is moved across the field to capture information between pixels that a stationary CCD would miss.

A

B

Page 31: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

238 Pathology Informatics

15: Digital Imaging

pixel). To address this problem, an optical antialiasing filter can be placed in the optical path between the image sensor and the lens.

15.2.4.2 Data Processing, Storage and TransferAs noted before, the sensor converts light into

electrical signals. The process by which analog information is transformed to digital is called analog to digital (A/D) conversion. A/D conversion by a microprocessor can occur in the sensor itself, inside the camera, or in the personal computer (PC). The latter type of conversion was used with older video camera (frame grabber) technology. Several postcapture processing steps may occur between the sensor and the camera’s memory. These may include color interpolation, image compression, white balance, color and tone correction, and edge enhancement. Most digital cameras use built-in and/or removable solid-state flash memory. Image data stored in the internal buffer memory chip of the camera is transferred to a removable memory card (eg, SD card) or directly to a connected computer. The direct transfer of data from a camera to PC into imaging software occurs though a TWAIN or plug-in (eg, USB) interface. TWAIN is a standard software protocol that regulates communication between software applications and imaging devices such as digital cameras or flatbed scanners. TWAIN and other industry standard interface protocols such as DirectShow, support the use of third-party software applications other than the imaging software that comes with the digital camera. Some cameras use wireless connections to transfer data or even cellular networks to connect for sharing images (eg, camera phones).

15.3 Gross Pathology WorkstationsDigital cameras are increasingly being used to

take images (ie, macro photography) of gross pathology specimens in the anatomic pathology laboratory or in the autopsy suite [Belanger 2000]. Availability of digital images is a welcome supplement to lengthy and/or vague gross descriptions. A workstation used to capture digital images may be located as a stand-alone imaging station in a separately designated area of the laboratory or ergonomically mounted into the hood of a grossing work bench f15.9. Digital cameras with either set-up should ideally be able to accommodate samples of varying size, include proper uniform lighting, be capable of controlling all major attributes of the camera (eg, image preview, focus, zoom, image capture, save) from a foot pedal or nearby computer in real time, and offer on-screen image preview and image editing, as well as calibrated image capture that permits measurements (eg, length) to be documented. A hands-free operation will prevent contamination of the camera with blood while

f15.9 Digital macro photography. (A) Stand-alone contemporary macro imaging station is shown for digital imaging of large gross pathology specimens. A foot-pedal is used to control the digital camera and lens. (B) Digital camera is mounted onto a gross dissection hood. (C) A digital imaging system used for small tissue dissection and needle biopsies. A digital camera is attached to a stereo (dissecting) microscope which uses incident light illumination rather than transillumination. (Images courtesy of SPOT Imaging Solutions, a Division of Diagnostic Instruments Inc)

A

C

B

Page 32: Raymond D Aller, MD Ryan M McKnight, MD · 2015. 7. 22. · iv Pathology Informatics Raymond D Aller, MD Clinical Professor and Director of Medical Informatics, Department of Pathology,

239Pathology Informatics

15: Digital Imaging

handling specimens. A gross imaging system coupled with a stereoscopic microscope for handling small tissue dissections and needle biopsies is also available. Some imaging systems allow for annotation of images via touch screen display. Ideally, acquired pictures will be captured directly into the laboratory information system (LIS). With the aid of a Webcam, teleconferencing software or virtual private network (VPN), gross telepathology can be used if needed.

15.4 Digital PhotographyThis section briefly addresses some key aspects

relevant to taking good digital images. As the final digital image is often only as good as the original source, it is important to take the time to prepare for good gross photography (eg, well-lit specimen, clean background) and photomicroscopy (eg, good tissue sections, optimize microscopic settings). Many automatic digital cameras do not provide much control over exposure. If manual exposure control is possible, the aperture (measured in f-stops) and shutter speed of the camera can be changed to control the amount of light (exposure) that reaches the sensor.

15.4.1 Macro PhotographyBecause off-the-shelf digital cameras have low

focusing range lenses, they are not well suited for macro (gross) photography. For close-up photography, a megapixel camera and good macro lens with a long barrel for close focusing (or close-up lens filter) are necessary. Macro photography is particularly important in forensics, where small details (eg, fingerprints) at crime scenes may need to be photographed. While digital zoom (accomplished electronically) makes objects appear bigger, no optical resolution is gained in the process, and therefore it should be avoided. Conventional fluorescent lamps as opposed to compact fluorescent lamps may produce some digital artifacts.

15.4.2 PhotomicroscopyWhen taking digital images with a microscope,

it is important to remember that low-magnification photomicrographs (eg, magnification of ×4) have more detail and thus will benefit from higher-image resolution (more pixels). Before taking a photograph, white balancing should be performed to calibrate the light source. Some digital cameras may have an automatic white balance feature. In microscopy, coloration can be affected by lamp voltage as well as the color of glass in the slide. White balancing requires manual selection of a reference point that represents white, supplying the ratio of RGB gains necessary to achieve proper color rendition. Most digital cameras feature automatic white balance,

whereby the camera looks at the overall color of the image and calculates the best-fit white balance. Flat-field correction is also helpful for display problems associated with uneven intensity or coloration in illumination or for artifacts (eg, dust) in the optical system or on the CCD.

15.5 Digital Imaging ProcessThe digital imaging process involves 4 key steps

related to the image: (i) acquisition (capture), (ii) archiving (saving and retrieval), (iii) editing (postcapture manipulation), and (iv) sharing (viewing, reporting, displaying, printing and sharing). Presently, there are no set standards regarding these various imaging steps in the field of pathology [Kayser 2008, Yagi 2005]. In a pathology laboratory that uses digital images, all of these phases in the imaging process are important to consider at implementation (eg, how will images be obtained, named and stored?), during use (eg, will annotation or manipulation of images be permitted?), and for maintenance (eg, will images be regularly backed up or purged?). Placing a WSI system in the clinical laboratory at the end of the slide creation process has been shown to stress the system, requiring significant modification to the laboratory workflow.

15.5.1 Image AcquisitionThe first step in the digital imaging process is

capturing the digital image. The process of converting an image to pixels is called digitizing or scanning. Apart from digital cameras and WSI scanners, digital images in the pathology laboratory can also be acquired with other devices such as flatbed scanners (eg, scanning of documents, reports or drawings). Flatbed (or reflective) scanners work by shining white light onto an object and reading the intensity and color of the light that is reflected from it. Flatbed scanners have been successfully used to create digital images of gross pathology specimens [Groneberg 2002, Mai 2001]. A flatbed scanner contains CCD arrays along with mirrors, a lens and filters. They usually rely on new contact image sensor technology. The processing and capture of digital images in the pathology laboratory

t15.5 Minimum computer requirements for supporting digital image acquisition

High-performance multicore microprocessor (core 2 duo or greater) Video card to feed signals to the monitor to support at least 24 bit with 70 Hz refresh rate (with no flicker) Adequate RAM Ports for USB 2.0 or Firewire connections Color monitor with sufficient pixel resolution Storage options (eg, hard disc space, card slots or adapters to download im-ages for removable media) Software (eg, image viewing, capture and editing software)RAM = read-only memory; USB = universal serial bus


The Spacefleet Project Space tourism and transport Dr. Raymond D Wright MD, Spacefleet Ltd

The Spacefleet Project Space tourism and transport Dr. Raymond D Wright MD, Spacefleet Ltd

Documents
11 EnergieRegion Aller-Leine-Tal Aller-Leine-Tal: Towards a 100% RES Region+ Rethem, Aller-Leine-Tal, 30. July 2013

11 EnergieRegion Aller-Leine-Tal Aller-Leine-Tal: Towards a 100% RES Region+ Rethem, Aller-Leine-Tal, 30. July 2013

Documents
Aller en vacances

Aller en vacances

Documents
1 20 September 2010 1 Training in Pathology Informatics: Lecture, Project, Rotation, Fellowship and beyond Raymond D. Aller, M.D. Director of Informatics

1 20 September 2010 1 Training in Pathology Informatics: Lecture, Project, Rotation, Fellowship and beyond Raymond D. Aller, M.D. Director of Informatics

Documents
Aller Et Al Report 1987

Aller Et Al Report 1987

Documents
Scientific Session I - Raymond H. Alexander, MD Resident Paper ... · Jonathan Friedman, MD, Lawrence N. Diebel, MD*, David Liberati, MS Wayne State University Presenter: Jonathan

Scientific Session I - Raymond H. Alexander, MD Resident Paper ... · Jonathan Friedman, MD, Lawrence N. Diebel, MD*, David Liberati, MS Wayne State University Presenter: Jonathan

Documents
Feria de la Miel 2010 - Aller

Feria de la Miel 2010 - Aller

Entertainment & Humor
Ecodriving training Pedro Aller Fernández

Ecodriving training Pedro Aller Fernández

Documents
Peut-on aller encore plus loin avec les antagonistes de l’Angiotensine II ? Antoine Sarkis, MD Associate Professor of Cardiology Hotel Dieu de France Hospital

Peut-on aller encore plus loin avec les antagonistes de l’Angiotensine II ? Antoine Sarkis, MD Associate Professor of Cardiology Hotel Dieu de France Hospital

Documents
Aller Paradigmas Criminologicos

Aller Paradigmas Criminologicos

Documents
Intraoperative complications of laparoscopic cholecystectomy · 459 Raymond Hasel MD, Sunil K. Arora MBBS FFARCS, Donald R. Hickey MD FRCPC Clinical Reports Intraoperative compli-

Intraoperative complications of laparoscopic cholecystectomy · 459 Raymond Hasel MD, Sunil K. Arora MBBS FFARCS, Donald R. Hickey MD FRCPC Clinical Reports Intraoperative compli-

Documents
Registration Brochure SEA 2020 Spring Meeting€¦ · Hindle, MD; Raymond A. Pla, MD; Marian Sherman, MD Upon completion of this activity, learners will: • Implement and utilize

Registration Brochure SEA 2020 Spring Meeting€¦ · Hindle, MD; Raymond A. Pla, MD; Marian Sherman, MD Upon completion of this activity, learners will: • Implement and utilize

Documents
Le passé composé du verbe aller

Le passé composé du verbe aller

Documents
Raymond B. Yates, MD, PC Profit Sharing Plan v. Hendon, 541 U.S. 1 (2004)

Raymond B. Yates, MD, PC Profit Sharing Plan v. Hendon, 541 U.S. 1 (2004)

Documents
LAWRENCE HUGH ALLER 1913 2003

LAWRENCE HUGH ALLER 1913 2003

Documents
LA County Dept. of Public Health Pathology Data to Public Health - Intro Raymond Aller, M.D. Director, Automated Disease Surveillance Los Angeles County

LA County Dept. of Public Health Pathology Data to Public Health - Intro Raymond Aller, M.D. Director, Automated Disease Surveillance Los Angeles County

Documents
Aller simple vers le futur

Aller simple vers le futur

Documents
Curriculum Vitae - Raymond · PDF fileRaymond Stein, MD, FRCSC Curriculum Vitae 1 Curriculum Vitae. Name: Raymond Mark Stein . Birthdate: ... Resident weekly seminars, Cornea & External

Curriculum Vitae - Raymond · PDF fileRaymond Stein, MD, FRCSC Curriculum Vitae 1 Curriculum Vitae. Name: Raymond Mark Stein . Birthdate: ... Resident weekly seminars, Cornea & External

Documents
Aznavour - Tu t'Laisses Aller

Aznavour - Tu t'Laisses Aller

Documents
RECOMMENDATIONS Canadian Cardiovascular Society Anti Platelet Guideline 2010 Alan D. Bell, MD, CCFP; Raymond Cartier, MD; Wee Shian Chan, MD, FRCP; James

RECOMMENDATIONS Canadian Cardiovascular Society Anti Platelet Guideline 2010 Alan D. Bell, MD, CCFP; Raymond Cartier, MD; Wee Shian Chan, MD, FRCP; James

Documents
5280 Live - Scott Aller Portfolio

5280 Live - Scott Aller Portfolio

Documents
INSTALLATION INSTRUCTIONS HELLER-ALLER PITCHER …lib.store.yahoo.net/lib/kingpumps/Heller-Aller-Model-PHB-Manual.pdf · INSTALLATION INSTRUCTIONS HELLER-ALLER PITCHER PUMP MODEL

INSTALLATION INSTRUCTIONS HELLER-ALLER PITCHER …lib.store.yahoo.net/lib/kingpumps/Heller-Aller-Model-PHB-Manual.pdf · INSTALLATION INSTRUCTIONS HELLER-ALLER PITCHER PUMP MODEL

Documents
MSc PAQC_dissertation_Cristina Aller

MSc PAQC_dissertation_Cristina Aller

Documents
Ortho ONE 2021 Resource Guide...Raymond Wurapa, md Hand & Upper Extremity POWELL Kenneth Westerheide, md Sports Medicine & Shoulder Reconstruction UPPER ... Primary Care Sports Medicine

Ortho ONE 2021 Resource Guide...Raymond Wurapa, md Hand & Upper Extremity POWELL Kenneth Westerheide, md Sports Medicine & Shoulder Reconstruction UPPER ... Primary Care Sports Medicine

Documents
INSTALLATION INSTRUCTIONS HELLER-ALLER PITCHER …lib.store.yahoo.net/lib/kingpumps/Heller-Aller-Fig-T-Manual.pdf · INSTALLATION INSTRUCTIONS . HELLER-ALLER PITCHER PUMP MODEL FIG-T

INSTALLATION INSTRUCTIONS HELLER-ALLER PITCHER …lib.store.yahoo.net/lib/kingpumps/Heller-Aller-Fig-T-Manual.pdf · INSTALLATION INSTRUCTIONS . HELLER-ALLER PITCHER PUMP MODEL FIG-T

Documents
PUBLISHED THE ALlER fILE '1

PUBLISHED THE ALlER fILE '1

Documents
Passe Composé of "Aller"

Passe Composé of "Aller"

Education
A an o Roadmap VerView oF for a · PDF filetimothy m. block, phd nathaniel brown, md carol brosgart, md Francis chisari, md raymond dwek, dphil, Frs lawrence Friedman, md robert gish,

A an o Roadmap VerView oF for a · PDF filetimothy m. block, phd nathaniel brown, md carol brosgart, md Francis chisari, md raymond dwek, dphil, Frs lawrence Friedman, md robert gish,

Documents
Aller and means_of_transport

Aller and means_of_transport

Documents
The Case for Place - proceedings.esri.comproceedings.esri.com/library/userconf/health07/docs/plenary/pdf/the...Health GIS Conference 2007 1 The Case for Place Raymond D. Aller, M.D.,

The Case for Place - proceedings.esri.comproceedings.esri.com/library/userconf/health07/docs/plenary/pdf/the...Health GIS Conference 2007 1 The Case for Place Raymond D. Aller, M.D.,

Documents