Users rarely have any input into technical standards. “User representatives” are more often technologists or policy specialists than the people who will use products created with the standard. This is especially true in healthcare technology. Doctors, nurses, care attendants, and various specialists are rarely IT-savvy, and are seen as “too valuable” to participate in detailed standards work. Creating and approving a new standard is a slow process. Mistakes in early user and task analysis may not show up until after the standard is approved, sometimes five years later. Any usability professional can predict the result: systems built on mistaken assumptions about workflow and information needs that are simply not usable.
To its credit, throughout the long standards-making process, HL7, one of the largest healthcare standards organizations, has created a methodology that incorporates input from real healthcare providers. I learned about HL7 “storyboards” from a nurse who showed me some of the storyboards, explaining how exciting it was to really understand the material. She introduced me to Isobel Frean, who shares with us how one project in Australia used the HL7 methodology to involve healthcare providers in documenting requirements for aged-care facilities.
—Whitney Quesenbery, special guest editor
In countries like the UK, Australia, and the USA, providers of healthcare to older people, including home healthcare, respite care, and long-term care workers, play a key role. Healthcare reforms have started to address the growing number and distinct types of demands that older people make on health and welfare systems. Goals to create effective care depend on the success of advances in information and communication technology (ICT), particularly in the ability of systems to work together.
Unfortunately, aging services providers have had little involvement in developing requirements and standards that inform national or regional e-health investment in social care, e-health infrastructure, or electronic client record systems.
Even in national initiatives such as the UK’s National Health Service (NHS) National Programme for IT (NPfIT), there has been no real commitment at this stage by either government or the private sector to the development of standards to meet the communication needs of aging services providers. The focus has tended to be on hospital and physicians. This leads to incorrect assumptions; for example, that the needs of providers in residential facilities and private homes are similar to those in larger institutions, such as hospitals.
In 2001, three care provider organizations partnered with the University of Wollongong, in New South Wales, Australia, to support a requirements-gathering project funded by the Australian Research Council (ARC). They wanted to ensure that the electronic communication needs of providers were explicitly captured and not assumed by developers of the national health IT system.
Our Australian project used narrative stories and standardized modeling techniques to involve aging services providers in a systematic approach to requirements. The approach ensured that the documentation requirements of health and social care workers were obtained in ways meaningful to them, while also providing the information needed by designers and developers of healthcare and medical computer systems.
Gathering Healthcare Requirements
Many failures of health ICT projects arise from a failure to capture the needs of the end user. Over the past two decades, health information specialists have placed increased emphasis on standardizing methods for capturing user requirements. These methods have their foundation in information modeling.
Unified Modeling Language (UML) has emerged as the leading method for modeling healthcare information. UML uses unambiguous picture-based symbols and labels. It is relatively accessible to the novice reader. The international healthcare messaging standards organization, Health Level 7 (HL7), has also adopted the use of UML because it provides a common language and method for representing complex healthcare concepts.
The HL7 V3 methodology includes UML in the requirements documentation and analysis phase. Application of a formal methodology ensures that requirements documentation truly reflects the needs of all domain users.
Use Cases Capture High-Level Communication Needs
We solicited the communication needs of approximately eighty domain experts from three aging services providers and similar organizations for one year. We employed a “ Delphi” approach—using three rounds of focus groups and questionnaires to reach a consensus of opinion among the domain experts. Experts included clinical decision-makers ( nurses, doctors, personal assistants, therapists, etc.), as well as administrative and financial personnel working in admissions, hospitality, and accounts.
The Delphi approach allows multiple experts dispersed over a large geographical area to reach consensus on a new area of understanding—in this case, business requirements for information exchange in healthcare for seniors.
The first round of consultations involved interviews with personnel from each of the business processes involved in the provision of aging services, including care delivery, management, and hospitality. We also interviewed individuals from outside the organization who interact with internal personnel (doctors, hospital discharge planners, etc.).
The interviews captured high-level communication needs as use cases. Each use case described a communication between an actor (human or device) interacting with a system of interest (for example, a medication management system) to receive a product of value from the system.
Use cases were a new concept to domain experts, so we used the term ”conversation” instead to elicit discussion about the most frequent, time-consuming, and inefficient interactions with external parties. Since domain experts could readily describe the conversations and interactions they have with others, this terminology made them more comfortable with the process.
Following the first round of interviews, we created and presented sixty-six use cases to the domain users for validation. Once they understood how the use cases represented the conversations they had described, they provided feedback enthusiastically.
After review and refinement by domain experts, the initial sixty-six use cases were rationalized down to fifty-five. These represented a core set of business requirements for the exchange of information between aging services providers and other stakeholders.
Storyboards Capture Dynamic Elements in Communication
After creating the high-level use cases, the next step in the HL7 methodology is to understand the details of the interactions between the actors in each use case. This level of understanding is critical for informing the functional requirements that will be used by technical designers to build the eventual electronic solutions. Each unique information flow between clearly defined actors must be clearly described. The method for documenting this is the simple tool called a storyboard.
A storyboard documents a series of interactions in a given conversation in narrative format. The storyboard is the key mechanism used in the HL7 methodology to explain the purpose of the healthcare communication activity, the pre-conditions, the actions or interactions that take place, and outcomes or post-conditions.
The power of the storyboard is that domain experts can use real life scenarios to break down complex information flows by describing the content and sequence of the flow between the participating actors. If the scenario results in comments from domain users like, ”That’s not the way it happens in real life,” then it is back to the drawing board.
HL7 V3 storyboards also use UML diagrams within the storyboard to illustrate the static and dynamic elements of the conversation. These diagrams enhance the precision of the storyboard and frequently provoke domain experts to identify additional information flows. These additional flows usually address the many different contexts in which care is delivered. For example, “Securing a place in a nursing home,” proved to be one of the most complex storyboards; it involved multiple decision points for the care needs and eligibility of the client.
The first diagram used in a storyboard is typically an activity diagram. This helps visualize the activities and flow of a healthcare business process and clarifies and expands the content of the storyboard.
To show a message flow sequence, the storyboard uses UML interaction or sequence diagrams, which represent objects and their relationships to one another.
For each use case in the study, the team developed one or more storyboards, producing a total of eighty-two storyboards. The scope of the storyboards confirmed the need to develop ICT solutions to support business processes in each of four discrete areas: accessing services, clinician liaison, coordination of care delivery, and account management and claims.
Good Requirements Documentation is Validated by Users
The ARC project used a Delphi approach with additional groups of domain experts from another part of the country to validate the storyboards. During successive rounds of consultations, we made changes to the storyboards until there was consensus on their accuracy. The Delphi approach was instrumental in capturing what is possibly the most comprehensive set of aging healthcare requirements documented in Australia, and possibly worldwide.
The breadth and depth of domain expert involvement in the project set it apart from previous healthcare requirements-gathering projects, not least because the process was driven by the end users themselves, rather than by system developers representing what they believed to be the needs of end users. Most importantly, the detail contained in the storyboards provides a starting point for senior healthcare organizations to better understand their existing work processes and how to adapt them for technology solutions that support the delivery of healthcare services.
[greybox]
Storyboard: Request Waiting List Status Report
Purpose: This storyboard demonstrates the flow of communications associated with querying the status of a consumer’s positioning on a waiting list maintained by an individual or a regionally managed waiting list
Precondition: Peter Process, Hospital Discharge Social Worker at Good Health Hospital, has previously sent requests to several nursing homes for a bed for inpatient Mr. Adam Everyman. He has been advised by each of these that Mr. Everyman has been placed on their waiting lists. As Mr. Everyman is keen to go to one of the nursing homes close to his family, he has his name on the lists for, respectively, Living Legends Aged Services (LLAS) and Seniors Living Retirement Villages (SLRS). Peter Process is keen to place Mr. Everyman in the next 24-48 hours and wishes to establish the status of application to determine whether he needs to approach other nursing homes.
Storyboard narrative: As he is authorized to access both the LLAS and SLRV waiting lists, Peter Process requests a status report on where in each waiting list Mr. Everyman is positioned to give him some idea on the likely length of wait. He receives a response from the LLAS Waiting list advising that there are four persons ahead of Mr. Everyman on the Waiting list.
Postcondition: Peter Process discusses the outcome of the responses with Mr. Everyman and they elect to wait for a vacancy to become available.
ALTERNATIVE FLOW: Peter Process receives a response from SLRS Waiting system advising there are two other persons ahead of Mr. Everyman on the Waiting list, but Mr. Everyman’s ACCR for high care expires in one week, accordingly, should a vacancy arise he will not be eligible to be offered it (until a current ACCR) [Interaction: Waiting list Encounter Suspend, Confirmation or Care Transfer Promise Suspend, Confirmation].
POSTCONDITION: Peter Process immediately makes arrangements for the hospital ACAT to review Mr. Everyman’s ACCR so that it may be provided to Alice Admitter at SLRS to avoid jeopardizing at Mr. Everyman’s chances at imminent admission to SLRS.
[/greybox]
