Electronic Health Record

A Systems Analysis of the Medications Domain

MD, Alexander Scarlat, Alexander Scarlat, MD

• Publisher: Productivity Press
• Year: 2012
• Print ISBN: 9781439878521
• eBook ISBN: 9781466559226
• Topic: Business
• Subtopic: Management
• Index: Business

An accessible primer, Electronic Health Record: A Systems Analysis of the Medications Domain introduces the tools and methodology of Structured Systems Analysis as well as the nuances of the Medications domain. The first part of the book provides a top-down decomposition along two main paths: data in motion workflows, processes, activities, and tas

Chapter 1

Short Primer on Structured Systems Analysis

Everything should be made as simple as possible but not simpler.

Albert Einstein

The first chapter is a short primer on structured systems analysis: It explains what a system is, why systems analysis is needed, and the reasons this book is based specifically on structured systems analysis.

We discuss the methodology and introduce a set of tools that will be used throughout the book. If you are familiar with structured systems analysis, you may skip to the next chapter.

What Is a System?

According to the Merriam-Webster dictionary online (1), a system is

a regularly interacting or interdependent group of items forming a unified whole … an organized set of doctrines, ideas, or principles usually intended to explain the arrangement or working of a systematic whole … an organized or established procedure … harmonious arrangement or pattern.

We are continuously interacting with natural and human-made systems all our lives. Some systems have been thoroughly analyzed (digestive system, highway system, solar system), and some like Electronic Health Record (EHR) systems and the medications domain are only sparingly documented.

Why Systems Analysis?

As no one would build a house without a set of blueprints, no one should consider building a nontrivial computer application without a systematic, structured set of plans. As seen in this book, healthcare information technology (IT) in general and software applications for prescribing, ordering, dispensing, and administering medications specifically are far from trivial systems. The rationale for writing this book is to present the medications domain in a structured, systematic manner. The goal of systems analysis is to create an efficient model of users’ needs, the plan for the system under consideration (2,3). When done correctly, systems analysis:

Creates a set of communication tools for clinicians and IT professionals

Optimizes all stages of a system life cycle: scope definition and control, requirements elicitation, analysis, design, code writing, testing, implementation, training, and maintenance

Defines the system in a complete, correct, and concise manner

Emphasizes certain aspects of a system while deemphasizing other areas

Partitions a huge thing—“the system”—into smaller work chunks

Increases consistency between the system parts: modules and data structures

Minimizes redundancy between components of the system

Improves maintainability of the system

Can we achieve the same goals using only text documents? Can systems analysis be done with text and spreadsheets? This is not really possible for the following reasons:

Text-based and spreadsheet documentation of a system tends to grow into intimidating monsters of hundreds and even thousands of pages. Nobody really likes to read this stuff. The old saying about a picture being worth a thousand words is painfully true when documenting IT systems.

Text and spreadsheets are monolithic and thus cannot be systematically chunked or partitioned into smaller working units. IT systems are usually developed by a number of teams (database, application, user interface, testing, etc.), and the capability to work in parallel on several parts of a system can be advantageous from a productivity perspective.

It is easier to document ambiguous statements and requirements in text and spreadsheets than in structured diagrams.

Due to the dynamic interactions between users and developers while defining and refining the system and the ever-changing nature of the requirements, the moment a text document or spreadsheet is published, it is already outdated, irrelevant, and out of sync with reality. Maintaining text documents and spreadsheets is more difficult than maintaining a set of diagrams.

Text documentation is more prone to suffer from redundancy issues: The same fact—be it a requirement or a solution—may be documented in more than one place. If a fact is updated on one page, there is an immediate need to update all other pages that may document this fact. Redundancy breeds inconsistency unless a significant effort is invested in keeping multiple documents in sync.

The truth is systems analysis is not optional; this is a paraphrase on Simsion and Witt’s famous adage, “Data modeling is not optional” (4). While it may seem to be a self-evident point, I have seen my share of software applications being developed without a blueprint, usually with less-than-satisfactory outcomes. “Some text and spreadsheets in a folder” do not count as a blueprint, and one cannot expect become efficient in systems analysis if one uses only text and spreadsheets as the sole tools.

Why Structured Systems Analysis?

There are two main systems analysis methodologies: Structured Systems Analysis (SSA) and Unified Modeling Language (UML) (5). When comparing the two methodologies, I prefer SSA to UML since the former is easier to understand, learn, become efficient with, and explain to nonexperts. SSA is also less prone to misunderstandings and errors than UML. In his book, Modern Structured Analysis, Ed Yourdon listed the characteristics of SSA tools (3):

It is graphical, with appropriate textual support.

It allows the system to be viewed in a top-down, partitioned fashion.

It suffers from minimal redundancy.

It helps predict the system’s behavior.

It is transparent and easy to learn, understand, and use.

To this list, I would like to humbly add a sixth characteristic:

It is technology and implementation independent—the modeling tools should not be limited to any particular implementation or platform technology during the analysis phase. Nor should the clinicians or IT professionals waste precious time on discussing technology-related issues at this early embryonic stage.

Processes and Data

Using the house-building analogy, as the builders need more than one kind of plan (architectural, structural, plumbing, electricity/wiring, etc.), the IT craftspeople need several modeling tools as well. If we agree that an information system is a data-processing system, it will not come as a surprise that SSA proceeds from two main perspectives: processes and data (3,6). A top-down analysis of system functions reveals the following concepts at an increased resolution and higher details:

System → Workflow → Process → Activity → Task

A system may have multiple workflows. Each workflow may be a collection of several processes. A process can be decomposed into several activities. An activity can be decomposed into several tasks. An activity or task can be defined in one page of graphic or text. For example,

System: Medications → Workflow: Prescribe → Process: Modify Rx [prescription] → Activity: Select medication → Task: Select dose unit

Similar top-down analysis of system data structures uncovers the following terms:

System → Repository → Database → Table → Record → Field

A system may use multiple repositories. Each repository may be composed of several databases. One database usually has many tables. A table has many records, and one record is composed of several fields. For example,

System: Electronic Health Record → Repository: Clinical Repository → Database: Medications → Table: Patient Medication → Record: Patient ID, Drug ID, Strength, Strength Unit, … → Field: Strength

The following modeling tools are used throughout the book:

Dataflow diagram (DFD) details the functions the system is to perform and represents data in motion.

Entity-relationship diagram (ERD) details data structures used by the system for storage and represents data at rest.

These modeling tools create diagrams that show the main components of a system and the interactions between these components. A technical specifications document (but not this book) may also have two sets of highly structured supporting documents to provide the meaning and definiti...

Table of contents

• Cover
• Title Page
• Copyright Page
• Dedication
• Contents
• List of Figures
• Foreword
• Preface
• Acknowledgments
• About the Author
• 1 Short Primer on Structured Systems Analysis
• 2 The Medications Domain Workflows and Data Structures
• 3 Prescribe/eRx
• 4 Order/CPOE
• 5 Dispense/ePharmacy
• 6 Administer/eMAR
• 7 User Interface
• 8 Clinical Decision Support
• 9 Report
• 10 Interoperability Standards and Vocabularies
• Appendix
• Index