Draft eHealth Use Case Definition
Stephen Kay
Executive Summary
This paper describes an initiative to produce the ‘eHealth use case template’ standard that would meet the
business need of eliciting, specifying and communicating requirements to and between various
stakeholders. In particular, it is seen as a way of bridging the gulf that can exist between policy-makers and
implementers of eHealth interoperability by constraining the meaning of ‘use case’ and specifying content
appropriate for, and relevant to the domain.
The on-going preference for ‘use cases’, ‘the use case approach’, and ‘use case driven projects’ in eHealth
initiatives is arguably a ‘good thing’ but its value is undermined to a large extent by the lack of consensus as
to what a ‘use case’ actually means.
This paper describes an early attempt by CEN/TC251 to produce an eHealth use case template standard
that would meet this communication need. To date, the draft ideas have been used/modified by two EU
projects (Antelope and Trillium Bridge), and one UK based project which was intended to provide
interoperability guidance for commissioners. The latter has been proposed (not yet adopted) for use by the
a new EU project which has just started in 2015. If it is, the feedback received will be used to produce a
further iteration based on good practice.
The implementation experience is intended to refine the initial idea so that a useful and usable eHealth
template can be shared by the community in this specialised domain, based upon sound principles. The
critique of this template will further input so as to improve its quality, and achieve the long-standing goal of
a shared use case description standard that works for eHealth.
1 Introduction
The on-going preference for ‘use cases’, ‘the use case approach’, and ‘use case driven projects’ in eHealth
initiatives is arguably a ‘good thing’ but its value is undermined to a large extent by the lack of consensus as
to what a ‘use case’ actually means. There are a range of descriptions, which are at different levels of
granularity and specificity, and because the content too is often described in very different ways, the use
and application of the term is in danger of becoming meaningless; a hindrance rather than a help to
effective communication.
These differences make it difficult to assess or compare different use cases and, that difficulty in turn,
significantly complicates any attempt to derive a repository of use cases for subsequent prioritisation,
comparison, and testing. As well as making a complex domain more confusing, it also leads to duplicate
effort and hinders the re-use of existing work. Ironically, in the EU context, ‘use case driven projects’ are
often funded to advance ‘interoperability’ which fundamentally requires ‘consistent agreements,
specifications and systems’ if it is to succeed at all!
As might be expected, what is meant by ‘use case’ is often coloured by the stakeholder that uses the term.
Although ‘Use cases’ originated in the technical, modelling area of information systems and computer
science, its simple, sometimes simplistic portrayal of complex requirements, has seen the general idea
being taken up by the non-technical, business oriented stakeholder in order to express their ‘system’
problems. The ‘use case’ is attractive for that very reason; it potentially offers a way of bridging the
communications gap that can exist between the non-technical and technical stakeholders. This potential,
however, is rarely realised because the stakeholders have very different interpretations of the same
concepts, and the two sides misunderstand, almost, by design. The problem-holder and the solutionprovider fail in their serious (and often costly) attempts to specify and meet the ‘known’ requirements. A
further frustration is that the use cases generated by a single project are hardly ever reused by any other,
9th July /2015
Page 1 of 11
Draft eHealth Use Case Definition
Stephen Kay
resulting in both a loss of learning and of investment. A use case approach, like a messaging approach can
become uncontrollable with instances increasing dramatically at the expense of management and safety.
2 Previously…
Appendix 1 has a diagram from the Interop Report. The report was developed by a collaboration of the
European Standards Organisations led by CEN/TC251 (principal author was Melvin Reynolds) as preparation
for the Mandate 403 on ‘Interoperability’. The diagram shown was created back in 2009 but I believe it is
still relevant to the on-going work on ‘interoperability’. In particular, I believe the top, right hand side
rectangle, labelled 1, is particularly relevant to this work.
As CEN/TC251 WG1 convenor, I initiated a technical report (TR) proposal to create an European Definition
of a use case for eHealth, addressing what I perceived as being the most important, and tractable part of
the whole process. I did some preliminary work as the initiating project lead, and the TR was approved by
the member states. However, M403 did not go the way that CEN expected and no resource/funding was
received, so the TR faltered. The original TR’s scope statement in 2010 was:
“‘Use case’ methods are common place in the development of healthcare
applications. However, although the methodology is mature, the actual practice is
varied and, as there is no standard specific to the healthcare sector, the usage is
problematic.
This Technical Report will use existing taxonomies of ‘use cases’ to differentiate one
type of ‘case’ from another. This report’s focus will be directed at the business level,
and is concerned with ‘use cases’ intended to inform people of what is being done.
The creation of this type of ‘use case’ precedes, and is different from, those which are
aimed at a more technical level, intended to guide design and implementation.
There are however overlaps in what is documented for each type, but beyond the
taxonomic positioning, this latter type is explicitly out of scope. It is the purpose of
this report to achieve the desired objective of clarity by constraining what is
documented and, in the longer term, to facilitate reuse of ‘use cases’ for business
requirements within healthcare.
The immediate intention of this report is to present a generic framework that can
gain wide consensus as to how to deploy the use case technique for high-level
appraisal and reuse. The specific target was the ‘Interop’ application, as part of the
M403 mandate initiative, but the broader ambition is to benefit the healthcare
sector in general by providing a common way of presenting high level requirements.”
In terms of the ‘Interop Model’ in Appendix 1, this piece of work enacts the missing feedback link between
the [virtual] Best Practice Forum (5) to the Definition and Prioritisation of European Use Cases (1). The work
to be carried out will also ensure that the template can be improved by other projects and relevant
standards to make it relevant and to facilitate reuse. One goal will be to agree how such a template can be
standardised to meet the interoperability needs of business and stakeholders in this domain.
9th July /2015
Page 2 of 11
Draft eHealth Use Case Definition
Stephen Kay
Building profiles (usually linked to technical use case) is recognised as requiring base standards to be in
existence (Appendix 1 shows a graphical view of how they relate). Nevertheless to get a domain-wide,
principled approach to interoperability, rather than an ad hoc or partial one, it requires a specific type of
standard to provide a reference or ‘big picture’ to make such an approach coherent and effective for
eHealth. This specific type of standard is also not shown or made explicit in the simplified diagram in
Appendix 1, but it may comprise several instances. A single information model for interoperability will not
work, even if it was possible to produce such a mammoth blue-print. Co-existing standards are what we
have now, concurrent use, however, will need a different approach if interoperability is to be realised.
3 Rationale for producing a Use Case Template
Our understanding of use cases has evolved a great deal since Ivar Jacobson first described them to the
public in 1987. Hailed as a great breakthrough, they have nevertheless remained controversial in Software
Engineering and most of the debate on usefulness has been to do with how formal or informal their
representation should be.
“Jacobson’s original usage scenarios were intentionally informal. He found out
that people did — and still do — resist writing them whenever they become more formal.” [1]
If too formal is too hard, the converse of too much informality results in confusion as to their purpose and
use. Achieving the correct balance for any representation of a use case is probably impossible as it will
remain a subjective notion and therefore a matter of personal preference.
Achieving a consistent
application, however, suggests that it would be better to err on more formality for the greater benefit but
to make it as easy and relevant as possible to the would-be user so as to encourage use and minimise
resistance.
The idea of ‘templates’ for many similar tasks has long been recognised as being one solution and,
unsurprisingly, many use case templates have been proposed/developed over the years. It makes sense
because automated support is often provided via templates and if a use case is simply a prose description
then it is amenable to basic tooling such as that found in most if not all of today’s word processors.
It has
the added bonus that no expensive or complex software is required to produce such a template-supported
description and therefore there is no access problem… so why develop a new template?
If ‘degree of formality’ has been a technical problem for uptake, then the problem of how general, or how
domain specific a use case description must be, is a socio-technical one. Jacobson originally invented use
cases to describe system architectures and system behaviour. This is very abstract and in such Software
Engineering applications the objective is always to be generic so as to be operationalised as widely as
possible. The formality question would necessarily be to the fore. However, the evolution of use cases has
led to ‘business use cases’ being developed, and these even have a different notation, but more
importantly, seek to operate in a different environment to engineers and computer scientists. It would
seem that the internet boasts many different templates that claim to succeed, and do so precisely because
they are tailored or targeted at a particular business domain, often with a different, yet focused audience in
mind.
The traditional use case, enhanced by business-oriented notation has not succeeded for many business
users. The new notation applies to the model, and the graphical model comes with the connotations of
9th July /2015
Page 3 of 11
Draft eHealth Use Case Definition
Stephen Kay
being part of the technical UML approach. The stylised stick men do not scale for complex requirements.
The need to link multiple drawings/models to satisfy a set of requirements is a daunting task and time
consuming, whereas the trend is towards ‘agile’ solutions and the favouring of user stories to drive
development, in a faster and more expressive way. User Stories, like the sketched Rich Pictures, can be
very expressive for an individual communication need but at a potential cost of being too specialised and
difficult to generalise, and rely too much on the skillset of the communicating author/artist. Such stories
and pictures are not easily reusable.
In addition to finding an appropriate way to express concepts in an audience friendly way, it is also a real
challenge to identify a relevant set of common concepts for a particular domain. Why is it that health care
system people dismiss ‘banking success’ stories as being irrelevant to eHealth?
If the success story of
business use-case templates is proven for specific domains, however, then why not develop a standardised
one for eHealth that takes the context and content of the healthcare domain into consideration? To the
author’s knowledge, it was true in 2009, and is still true even now, that no such agreed template for
eHealth deployment exists or is being widely used.
3.1 The requirements for an eHealth Use Case Template
The table following provides a starter set of requirements for such a template:
Reference
1
2
3
4
5
6
7
8
9
Short Description
Domain Specific
Domain Wide
Standards-based
Policy friendly
Sufficiently Formal
Implement bridge
Easily referenced
Reusable
Extensible
Longer explanation of requirement
Unique concepts and characteristics of/for eHealth
Broad, coherent coverage for interoperability across eHealth domain
Consensual and stable product, providing confidence in deployment
Communicate business concerns and considerations effectively
Enough to ensure consistency, concise enough to assist compliance
Clear path from high-level of abstraction to fine-detailed, concrete use
Ensure would-be users can find relevant use cases in a timely way
Components to minimise fragmentation but allow local customisation
Link to Agile methods and/or UML model approaches as required
These initial 9 requirements will be used to critique the development and use of the templates used in the
projects.
One concrete result from this will be a proposal for an eHealth use case template for
standardization.
It will take into account the relation to the ISO TC215 WG1 work item on re-usable
components.
4 Framework for the eHealth Use Case Definition
There is a significant range of meanings for what a ‘use case’ actually means. Amongst other possibilities, it
can mean anything from a general area of concern, to a simple example, to a fully specified technical
model, spanning many pages. Given that new initiatives should both respect and prioritize the
stakeholders’ representation of requirements, then it is a reasonable strategy to develop a framework
which can facilitate understanding between the existing representations and thereby derive a more formal
use case specification.
The figure in Appendix 1 has the clear merit of emphasizing the primary role of stakeholders to make
interoperability a feasible proposition. It suggests too that stakeholders will have their own individual
9th July /2015
Page 4 of 11
Draft eHealth Use Case Definition
Stephen Kay
versions of ‘use case specification’ at local, national and regional levels which is then somehow mapped to
the European definition.
This work acknowledges the reality of that situation. However, this work also emphasizes the need to
actively reduce the gap or mismatch between the stakeholders’ independent versions and the
standardization community’s desire to harmonise the use case definition. This will be done by providing a
usable framework that defines a stakeholder-oriented eHealth use case template; one that can be accepted
then productively used by both parties to facilitate interoperable solutions.
The following points show why this approach is a desirable one:
1. to reduce miscommunication of requirements (introducing cost, error, and safety concerns),
2. to avoid the unnecessary and repetitive work in mapping case by case, and
3. to facilitate re-use of use cases for the benefit of multiple stakeholders.
The requirements in 3.1 were derived for a generic use case template. However, most of the requirements
can also be applied to the idea of a wider ‘Framework’ in which the use case template will be defined and
subsequently deployed.
5 The Anatomy of the eHealth Use Case Template and Framework
From a simple classification of the given requirements it is possible to describe the main elements of a
business-friendly, domain-specific eHealth use case framework. The whole framework will provide the
means to reference all the use cases developed to facilitate wide-spread re-use and to make links between
similar use cases for comparison and assessment. Its focus is on the back-office management of the
eHealth use cases in an accessible repository. It will be addressed later, but suffice to say it relates to
requirements 6-9 in the above table.
In this section the focus is on the ‘template’ to describe the proposed use case which attempts to be a
fusion of a normal business case and a simplified business use
case offered in UML. The five block anatomy diagram will be
explained before a full example is given. Its primary audience
is the policy/decision maker/manager rather than the
technician. It embodies the requirements 1-5 in the above
table, and also 9 as it can be extensible to new emerging
requirements.
5.1 Summary
Each use case will have a name. In addition there will be a
‘user story’ (ala Agile Development), which is a requirement
formulated in everyday business language. Together these
two make up the Use Case Summary. The Use Case Summary
provides the short-version public handle of the use case
described by the template.
5.2 Goal
As with formal Business Cases, a goal is paramount to a Use
Case’s success. What is intended to be achieved is
9th July /2015
Page 5 of 11
Draft eHealth Use Case Definition
Stephen Kay
fundamental and must be stated clearly, upfront. As Cockburn says, “Linking use cases to actors’ goals is
so very significant because it shifts the writer’s attention away from the function lists that most programmers
worry about and puts it back on the users: What the users really want to accomplish with the software are
their goals when using the software. If the software supports those goals, the software will yield the greatest
business value.” Without a ‘goal’ the use case is useless, with a Goal present, a major criterion is
automatically provided to measure success or failure. Goal driven behaviours are also part of our domain
business and complement the other parts of the Anatomy related to the business model.
5.3 Participants
This is the easiest, yet hardest block in the anatomy to get agreement on (or at least the most controversial if
the various trials are to be considered.) Everyone agrees that ‘PEOPLE’ are at the heart of use cases, one
way or another; the ‘stick people’ on the use case diagrams have made this seemingly obvious. ‘Participant’
is perhaps the most neutral term (suggested in the Antelope project). However ‘Actor’ and ‘User’ are the
original and usual modelling terms for use case characters. There is also the matter of the ‘organisation’,
the ‘device’ and the ‘system’ and how these stakeholders are managed. It will be important to make it clear
in practice, certainly, but at least for the anatomy block, ‘participants’ defers the discussion! Participants (of
various sorts) occur in several places within the proposed template.
5.4 Domain Sensitized Business Model
This is the unique part of the Template, differentiating it from other domain-specific templates, and satisfies
requirements 1, 2, 4 and 5. The need to be both domain-specific (1) and domain-wide (2) points to the
specialised concerns of Health Informatics. By way of brief background, alongside the traditional use case,
there is also now the more recent ‘misuse case’ which specifically describes the threats to the system, either
deliberate or accidental, as well as introducing the ‘misuser’ who initiates the action or causes the problem.
These ideas have also been woven into this proposed template.
Personal (or patient) safety is a core principal for Health Informatics, and some authorities devise ‘safety
cases’ as part of the system specification. Security, privacy and governance are also core. It is appropriate
that any business model used in this template should explicitly represent or document these concerns when
relevant to do so. Domain-wide reflects the use of the WHO definition of ‘Health’ in Health Informatics; the
template must therefore be appropriate and capable of being used for any of the domain systems and must
be able to refer to an individual or a cohort as well as to an organisation, be it local, national, regional or
global.
The template must be able to communicate business concerns and considerations effectively (4) but also
needs to permit decision-makers to express their ideas in a formal way, sufficient enough to ensure
consistency, and concise enough to assist compliance (5). This is also about usability; UML business use
cases do not seem to be popular, partly because the extended notation is not widely adopted. We know
too that more formal representations seem to turn off would-be users. Business use cases should be
independent of technology, concentrating on events and processes rather than products; they should be in
the language commonly used and should have familiar concepts. In an attempt to encourage policy
9th July /2015
Page 6 of 11
Draft eHealth Use Case Definition
Stephen Kay
makers and the like to use the template, it was decided to incorporate a business model within the
template to bridge from their ‘world’ to a more formal one. [Note 1: The Antelope project adapted the
original template and specified another lower level of use case description in order to map specifications
and standards for use; this may be useful for describing the content of the ‘bundle’. Note 2: Trillium Bridge
also adapted the original template, and work will be on-going to synthesize the best practice.]
In theory any well-known/well used business model would do. The candidates are numerous, but I went
with the SWOT model, which is perhaps the most, widely used and earlier attempt to understand the
business concerns in a semi-formal way. The Strengths & Opportunities fit well with the so-called happy
day scenarios in Use Cases, whereas the Weakness & Threat quadrants can satisfy the concepts from the
misuse case scenarios. The ‘pre and post conditions’ of the UML models are also accommodated and the
Internal/External concepts are relaxed to suit the domain wide requirements of granularity.
5.5 Key Events
The more process-oriented aspect of the business use case fits well with the importance of events. There is
the initiating or ‘trigger’ or ‘starting’ event, as well as the event sequences recorded in the different type of
scenarios. It is common to have a primary or ‘happy day’ scenario where everything proceeds as intended,
and one or more adverse event scenarios that show contingencies etc. This can be made as extensive and
as elaborate as required and various modelling diagram methods (UML again) can be introduced to
represent the various paths, timing etc. My suggestion is that the trigger event is highlighted and the
happy day scenario are the only events presented within the template; the other material whilst obviously
important is likely to be too much detail and therefore too much effort for those prepared to use the
template. A further suggestion is that this other material is part of the extensible Use Case Framework and
it can be used as reference material.
The same is true with all the diagram notation/ rich pictures and the like. The use case template described
here should be common-use, easily understood prose, ideally limited to 1 to 3 pages at the most. A
template could be set up in a word processor, with no esoteric software for models required; this means
that the template can be made readily available and accessible to all in the community.
The following gives two illustrations of the template. The first is the original template destined for the CEN
report; it provides the outline and description of the content as I saw it then back in 2009. The second is
one that is filled in as part of an education guide intended for commissioners of interoperability in the UK.
This was done in the last part of 2014.
I intend to analyse the uses made and the adaptions made by the Trillium Bridge and the Antelope projects,
before providing an update and revision for the CEN report. This is on-going. This current document will
also be passed to Gary Dickinson who is doing some complementary work in ISO. Hopefully, this might be
of use here and if JIC buys into it then requirement 3 will have been satisfied and we will all know what we
mean by ‘use case’ in our domain.
9th July /2015
Page 7 of 11
Draft eHealth Use Case Definition
Stephen Kay
6 The Original Template with descriptive rules
The grey background refers to the proposed Use Case Framework, which needs to reference each use case
for re-use purposes. The greyed out parts at the bottom, are optional ways of extending the description
with more detail. The suggestion is that these too are part of the Framework, not the template.
2
9th July /2015
Page 8 of 11
Draft eHealth Use Case Definition
Stephen Kay
7 The Latest modified version (sections labelled), and filled in
This is an example created for a clinical commissioning group in the UK. Some details have been omitted,
e.g. some steps in the scenarios; CCG is the acronym for a clinical commissioning group.
Sections
Use Case Description #2
A. Name
Rebalance non-acute services
B. Stakeholder
story
CCGs are facing a deficit because of an excess of inpatient admissions due to
demands from changing demographics and lifestyle. The CCG and with the
Health and Wellness Board the CCG determines with its main providers and
social services that attention needs to be directed towards re-balancing
support in the community. However, resources are below budgeted
manpower levels and non-acute based services have not worked in a coordinated manner in part due to geography and use of limited IT
administrative systems.
C. Starting event
The movement to establish integrated care budgets and pioneers combined
with the CCG’s own financial challenges has encouraged the CCG to put in
place a strategy that will re-balance the scales in favour of greater
community based interventions.
D. Actor and
users
The CCG and the acute, mental health and community trusts, all GP
practices and social services.
E. Goal
To re-organise community and home based services in conjunction with
social services such that the use of existing and planned nursing home
visitor resources can be maximised combined with a more effective coordination between community and mental health services. Additionally,
the goal is to provide improved access to local GPs / community locality
based minor injuries services so that pressure on A&E is reduced.
F. Stakeholders
In addition to D above, patients themselves will be directly affected by less
hospital visits and improvements to accessing the appropriate healthcare
professionals.
G. Primary
scenario
1.
2.
3.
4.
Develop a multi-faceted approach that combines new initiatives in care
access and pathway management that can be supported by a new
technology infrastructure to underpin the sharing of information across
all parties.
Produce an inventory of the separate systems across all of the
organisations concerned and assess the extent to which they can share
patient information. Particular attention should focus on silos &
duplicates of service user information.
Extend the use of existing facilities by agreeing appropriate staffing
regimes, increasing visibility and access to ‘minor injury’ services across
the population.
…
5. Provide a common view of client information across all organisations.
9th July /2015
Page 9 of 11
Draft eHealth Use Case Definition
H. Strengths
1.
2.
3.
I. Weaknesses
1.
2.
3.
4.
J. Opportunities
& safety
context:
1.
K. Threats &
security
context:
1.
2.
3.
2.
3.
L. Assumptions,
Additional
details and
context
9th July /2015
Stephen Kay
Some systems already in place
Vision to adopt a specific strategy aimed at reducing the pressure on
acute services the CCG plans to create a unified working environment
across the locality strongly supported by interconnected information
architecture.
Commitment to address culture change and provide more accessible
facilities especially for minor conditions.
Legacy systems in place; not a ‘green field’ site.
Patients need to be convinced that quality care can be provided in the
community
High risk women with post natal depression and many younger to
middle aged patients with a range of non-critical problems are being
handled by acute services.
When (3) do receive support from community, mental health and social
services, they are often visited by three care workers when one
appropriately skilled could provide the same level of support.
Improved co-ordination of services with all parties able to access a
consolidated history and status for each patient.
…
The potential exists for other agencies to become involved e.g. the
police and education establishments in the future.
No information standards yet established so that common terms could
be used with social services required to identify service users by NHS
number.
…
A growing movement to integrated health and social care as per the
change in budgets £3.8 billion away from NHS to a combined NHS/social
care programme
Assumptions: None. Additional Details & Context: To achieve the goal will
require a co-ordinated series of activities. One possible way of supporting
this is by the creation of an integrated digital care record (IDCR) to provide,
as a minimum, all patient continuity of care data for review. This is not
necessarily a single database, but it may be a federated source of data. With
an established, comprehensive and shared data source the various health
agencies can create a more unified approach to those patients making
greatest demands on care services through a combination of technology
deployment and pro-active management of the patients. The health
economy with which the CCG healthcare organisation does most contracting
comprises a large number of GP practices each with EHR systems but not all
of which are from the same supplier and operate largely independent of
each other.
Page 10 of 11
Draft eHealth Use Case Definition
Stephen Kay
Appendix 1: Figure from the Interop Report for M403
Stakeholders: contribute to European eHealth
Interoperability activities and includes (e.g.) - National, Regional, or Local projects
- Health Professionals
- Citizens
- Industry
European eHealth Interoperability Activities:
a European eHealth Interoperability Coordination Committee
empowers and accredits the numbered activities below (1-5)
Local, Regional or
National eHealth
Project Use Case
Specification
1. European Use Case Definition and
Prioritisation
Portfolio of
Base
Standards
Prioritised
Use Cases
2. Base Standards
Development and
Maintenance
Feedback
System
Implementation
Interoperability
Specifications
Portfolio of
Recognised
Profiles
Profiles Test
Plans and
Tools
3. Profile
Development and
Maintenance
4. Profile Quality
Assurance
Feedback
Feedback
Feedback
Deployment of
Live Systems
9th July /2015
Feedback
5. Best Practice
Forum
Page 11 of 11