The Importance of Abstraction & Modeling in Healthcare.

On the first day of my second year in UCSF's clinical informatics master's program, Professor Charlie Mead, MD, initiated an engaging activity. He called for volunteers to demonstrate a transaction at an ATM. Among the first and second-year students present, five individuals courageously raised their hands. As we eagerly awaited instructions, we lined up with our backs to the whiteboard, anticipating the scenario. Charlie, our professor, instructed us to simulate an interaction with an ATM.

The first volunteer, somewhat hesitant, described the initial steps one might take at an ATM: touching the screen to commence the transaction. Acting out the action of touching the ATM screen, the student passed the "transaction" to the second brave volunteer. All eyes turned to Charlie, awaiting further guidance. With a marker in hand, Charlie proceeded to draw the following on the whiteboard, setting the stage for our simulated ATM interaction:

"Did you overlook something?"

Charlie remained silent, awaiting our response. We exchanged glances, a sense of embarrassment washing over us as we acknowledged our first blunder.

Turning to each other, we recognized that we were solely responsible for navigating this challenge. Determined, we engaged our minds. One of us, lost in contemplation, stepped forward to the first person in line and solemnly uttered, "Did we forget to insert the ATM card?" We collectively turned our gaze towards Charlie.

Charlie remained silent, but his subtle facial cues confirmed our correctness. Charlie wrote the following on the whiteboard:

As we observed Charlie's reaction, it became evident that he expected us to perform a sequence of steps in our role play. After a brief period of discomfort, Charlie asked us: "Who are the actors in this scenario we're simulating?" Confusion painted our expressions as we grappled with the inquiry. Charlie defined an actor as "a role played by a user or any other system that interacts with the user." Considering this explanation, we tentatively responded, "There's Courtney and the ATM."

Charlie proceeded to change the picture on the whiteboard:

We began to grasp the level of detail and precision Charlie expected in our role-play, realizing the need to identify the subsequent steps. "Next, the ATM requests our password or PIN, and we enter it," someone volunteers. Charlie passes the marker to the responder, signaling their turn.

Our peer contributes the following two actions to enrich the unfolding scenario:

At this juncture, our anticipation surges because we gleefully identify the next step. "The ATM inquires about the account from which we desire to withdraw funds!" someone eagerly interjects.

Charlie remains silent, prompting our collective attention.

Charlie then explains that the ATM, represented by the visible screen, is termed a "User Interface." Its role and responsibility lie in furnishing a graphical or tactile interface, enabling users to input commands and receive information regarding their actions in a user-friendly manner. With these insights in mind, he changes the depiction to the following:

Charlie elaborates on the composition of software systems, emphasizing the presence of distinct components. He informs us that each component carries out a specific role and responsibility, collaborating harmoniously to achieve a common objective.

At this point, we recognize that the User Interface (UI) is not actually tasked with PIN validation, a crucial aspect of privacy and security. Realizing the necessity of a separate Actor for security purposes, one of the students modifies the depiction accordingly:

With a few additional missteps and redirection from Charlie, we proceed through the process to the conclusion of the exercise, culminating in the following diagram.

This exercise served as our introduction to the foundational "Abstraction and Modeling" class in the Clinical Informatics Master's Degree Program at the University of California, San Francisco (UCSF), where we delved into mastering the Unified Modeling Language (#UML) standard. Abstraction and Modeling is the process of simplifying the complexity of technology and its behavior into UML visual diagrams that are digestible and understandable by both technical and non-technical individuals. These diagrams serve as a "bridge," enabling effective communication and understanding across diverse audiences, regardless of their level of technical expertise. Through abstraction, intricate technical concepts and system behaviors are distilled into easily digestible representations, allowing for more straightforward communication, improved collaboration, quicker consensus, and more informed decision-making among stakeholders with varying backgrounds and skill sets.

The Sequence Diagram marked the beginning of a series of five abstraction and modeling diagrams that would be explored in depth during the second year of our curriculum. Through the creation of sequence diagrams, my peers and I internalized several pivotal principles crucial for adeptly designing and implementing technology used in the clinical setting:

1. Software systems typically comprise multiple components, each assigned specific roles and responsibilities. Such elements include end users (physicians, nurses, etc), user interface modules, data processing modules, communication modules, and more.
2. Each component within the system possesses a defined role and set of responsibilities, which can vary depending on the desired outcome. These roles generally involve tasks such as entering data, ingesting data, processing data, managing user input, and interfacing with other components or external systems.
3. Components collaborate by communicating and interacting, often by exchanging data or messages, invoking each other's functions and methods, or engaging in more intricate forms of collaboration to achieve desired outcomes.
4. Expertly orchestrated collaboration among software system components is paramount to achieving specific goals or tasks while avoiding end-user burnout. This collaborative effort may involve various activities, such as processing user requests, performing calculations, managing resources, surfacing information, and interacting with external systems, many of which are part and parcel of clinical workflows. The exchange of information between clinicians, interfaces, and diverse software components forms the foundation of our interactions as clinicians utilizing technology.

During our Clinical Informatics training, many of us felt like a fish out of water and wondered what we had signed up for, but the discomfort was worth it. Throughout the program's second year, we learned the importance of abstraction and modeling during the initial Health IT lifecycle phases and the five benefits the Sequence Diagram provides:

1. Clarity of System Functionality: Sequence diagrams?visually depict?interactions among different components or actors within a system. They provide administrative and clinical stakeholders with a comprehensive understanding of their software systems. They show how data flows between clinicians, user interfaces, and various components and depict which actions trigger subsequent steps. This understanding empowers clinicians to effectively engage with the IT department and communicate precise requirements for efficient and effective design and use of technology (human-centered design). For example, these diagrams help delineate the optimal sequence of entering, reviewing, and acting on information in a language clinicians, engineers, and developers can understand.
2. Informed Decision Making:?Sequence diagrams help leaders make informed decisions on how to optimize technology to achieve a desired goal. This encompasses identifying additional components or processes that may need integration and ensuring that the software accommodates the entirety of a workflow rather than just fragments of it. This holistic perspective reduces clinician burden by mitigating the need for clinicians to devise workarounds when the technology fails to align with their operational needs and patient care requirements.
3. Identification of Pain Points and Improvement Opportunities: By analyzing sequence diagrams, administrative and clinical professionals can identify potential bottlenecks, gaps, or inefficiencies in the clinical workflows the software systems support. Understanding the sequence of interactions can help pinpoint areas where processes can be redesigned to decrease the cognitive burden on clinicians and eliminate non-value-added steps.
4. Enhanced Communication with IT Teams: Administrative and clinical professionals must learn to effectively communicate their requirements and preferences to the IT teams responsible for configuring or maintaining software systems. Understanding sequence diagrams allows clinicians to articulate human-centered design needs more effectively, providing specific insights into current processes, how they expect the system to function, how data needs to flow, and potential options to trigger additional components.
5. Validation of System Requirements: Sequence diagrams are invaluable in validating system requirements and ensuring technical alignment with end-users needs and expectations. Clinical and administrative professionals leverage these diagrams to verify the comprehensiveness of the proposed system design and its harmony with desired outcomes and workflow requisites. Engaging in a collaborative inquiry process, requesting clarification, and challenging unconscious assumptions, all stakeholders cultivate a shared understanding pivotal for crafting effective solutions in the clinical setting. This proactive approach aids in circumventing suboptimal outcomes and avoids costly rework in the future.
6. Facilitation of Training and Onboarding: Sequence diagrams offer a valuable resource for training and onboarding new employees or users and enhancing the skills of existing staff. They present a visual representation of the interactions within the system for the engineers, fostering a deeper and more nuanced comprehension of both administrative and clinical domains. Additionally, sequence diagrams serve as essential documentation, mitigating the risk of institutional knowledge being confined to a single individual or lost due to staff reassignments or resignations. Additionally, administrative and clinical professionals can leverage these diagrams to acquaint new administrators and clinicians with IT system functionality, enriching training with contextual depth beyond the typical generic scenarios and click paths that mimic the "happy path" but bear little resemblance to the reality of day-to-day operations. This approach nurtures the capacity of end users to practically integrate new technology seamlessly into clinical practice, promoting efficiency and effectiveness.

Sequence diagrams are potent instruments that empower administrative and clinical professionals to participate actively in planning and designing the technology that supports care delivery. By comprehensively grasping the depicted flow of interactions, these professionals can not only make informed decisions and identify areas for process improvement but also pinpoint optimal integration points for Clinical Decision Support (CDS) and Artificial Intelligence (AI). Moreover, they can articulate their requirements clearly to IT teams. This collaborative approach fosters a shared understanding of user interactions and system functionality, thus facilitating the collective achievement of organizational goals by all involved.

If you'd like to explore more Sequence Diagram examples, follow the links to the HL7 website for International Patient Access (FHIR), Clinical Data Exchange (FHIR), and Requesting Attachments using FHIR Questionnaires.

?Of note, the sequence in which ATMs dispense cash before ejecting ATM cards was changed in response to usability concerns and security considerations. ?

Before this change, patrons sometimes forgot to retrieve their ATM cards after receiving cash, leading to security risks and inconvenience. By reversing the sequence to eject the ATM card before dispensing cash, patrons are prompted to collect their cards before receiving cash, reducing the likelihood of leaving cards behind in the machines. This seemingly insignificant modification transformed the user experience, minimized security vulnerabilities, and decreased the number of replacement ATM cards requested due to lost (or forgotten ATM) cards.

In technology planning and design, #SequenceMatters! :)