Tenth International Workshop 
on Software Specification and Design 
(IWSSD-10) 
Case Study 
This case study is intended to help give some focus to IWSSD-10 submissions. You are 
encouraged, but not required, to use it. It will help attendees understand your paper and 
will clarify how different contributions fit together. You should feel free to interpret the 
case study as you choose, you may wish to extend it or cut bits out depending on what 
you want to say. Just make sure that you are clear about this. 
This case study is due to Paola Inverardi and Henry Muccini, with editing and comments 
by Debra Richardson.  It is motivated by a real system developed as part of a project 
carried out by University of L'Aquila and Parco Scientifico e Tecnologico d'Abruzzo, a 
regional consortium of public and private research institutions and manufacturing 
industries. Many of its features were inspired from experience in building a first 
prototype of the described system, while Stephen Fickas added features from his 
experience working on an internet-based system to deliver teleconsulting services to non-
specialists dealing with stroke.
The Teleservices and Remote Medical Care System (TRMCS)
Prologue
This preliminary description is deliberately intended to be sketchy and imprecise. 
Acquisition, formalization and validation processes are needed to complete it and 
illuminate the many shadowy areas. A number of the requirements of the TRMCS system 
have a strong impact on the choice of the physical and logical architecture, these include 
safety critical requirements and economical ones. 
The case study is available as ascii, word, pdf, or postscript.  Comments and additional 
information on the case study will be periodically updated on a related notes page. 

Domain Theory: providing assistance to remote users
The current trend in healthcare is to transition patients from hospital care to home care as 
quickly as feasible. This leads to a need for new medical services to be delivered to the 
home. This type of patient does not need continuous assistance but might need prioritized 
assistance when urgencies happen, in which case the patient would call a help center for 
assistance. 
 The following two scenarios illustrate these new types of services.
Both assume some prior events where a patient/user has seen a physician and has been 
approved to receive at-home assistance and that the help center has prior medical 
information stored about each user registered with it.
1. A patient with a medical emergency sends a help request to a help center. The patient 
expects to receive the best help suited for his/her case within a critical time range. 
This help may take the form of emergency ambulatory service or online diagnosis 
and treatment from a health professional at a distance. 
2. A patient may have internet-based medical monitors that give continuous readouts, 
e.g., EKG, EEG. A help center may contract to read these monitors over the net and 
raise alerts when dangerous values are detected. In essence, the monitoring software, 
as opposed to the patient, calls for assistance.
In both scenarios, the patient will typically be at his or her home. You can assume that 
the home has ³reasonable² Internet access. Some patients, however, may be mobile, in 
which case either scenario may involve mobile computing issues.
To gain approval from government regulatory agencies (e.g., the FDA), a help center 
must demonstrate that it can deliver the right care at the right time. In particular, 
monitoring software must be shown to be accurate in terms of detection and alert within 
specific critical time ranges. It must also be demonstrated that service availability can be 
provided reliably on a 24x7 basis. A ³log² storing the history of inter-communication 
information (e.g., date, hour, type of request, user requesting the service, state of the 
request) may be used to certify that the system correctly behaved in controversial 
situations since it is responsible for delivering a service upon request in the right amount 
of time.
In the most general case, more than one help center would be in business. Help centers 
may be run from hospitals, from group practices, or from new medical centers that spring 
up to meet the need. The centers might form a networked consortium to share patient 
data, which brings up issues of patient privacy, validation of transmitted data (e.g., is the 
user eligible for the service? has the message really been sent by the identified user?), and 
conformance to formatting standards.  In addition, the help centers might compete for 
business. Hence, a call for assistance might be put up for open bid and help centers 
compete to answer it. The system must guarantee that at least one center responds.
There are also economic issues. Patients are willing to have this kind of service but may 
not be willing to, or simply are unable to, pay for it. In other words, they might be willing 
to pay for the assistance once received but not for the services provided to issue the 
request. This means that costs in this domain are critical, which might have an impact of 
the chosen physical architecture in terms of hardware and communication technologies. 

System Requirements 
The purpose of the TRMCS system is to provide and guarantee assistance services to at-
home or mobile users. 
Any system delivered must meet medical information standards and regulations. This 
includes privacy standards enacted by government, and industry standards developed by 
consortia. 
The system shall operate on near-future network and computing infrastructure and should 
scale as new technology becomes practical. For instance, personal medical-monitoring 
devices will be net-ready in the future, either through wired or wireless connections. A 
help center must be feasible given near-term compute servers and projected band-width 
to the home and mobile devices. The system should provide an architecture that allows 
new medical components to be brought into the mix. Similarly for the computational 
side, the system should support a range of compute servers, with a mixture of local (at-
home) and remote (computational farms) resources.
The players or stakeholders of the system include individual patients, healthcare 
professionals who enter and maintain patient data, healthcare professionals who make 
treatment judgements in emergency situations (e.g., call for an ambulance, call for a 
teleconsulting session with a consulting physician), healthcare professionals who carry 
out online diagnosis and treatment, patient family members who provide assistance, and 
quality assurance professionals who provide initial testing of the system (e.g., to pass 
federal regulations) and runtime monitoring to verify the system continues to meet its 
goals.
Synthetically, the system should at least provide the following capabilities:
_ Allow the user or monitoring software to issue help requests to the assistance center; 
requests are issued asynchronously.
_ Guarantee continuous service of the system.
_ Guarantee the delivery of help service in response to a help request in a specific 
critical time range. 
_ Guarantee secrecy of user data and secure communications.
_ Handle several help request in parallel that compete for service by overlapping in 
time and space. 
_ Support conflict resolution according to resolution policies that minimize user 
damage. 
_ Be open to new service installation.
_ Handle users that are geographically distributed and heterogeneously connected, 
offering homogeneous service costs. 
_ Handle dynamic changes to the number and location of users.
_ Provide persistent repository of data and history log.
_ Conform to medical information standards and regulations (e.g.ISO-9001, with 
careful attention to the CE Medical Device Directive).

Epilogue
We have not attempted to list or prioritize the set of requirements for the system, other 
than what we have provided above. We know of several researchers who specialize in 
requirements elicitation and prioritization, and want to encourage them to participate. 
And frankly, we do not know what the requirements are in detail: to produce them will 
require an interesting integration of many stakeholders in the system, as well as some 
attention paid to regulations, standards bodies and economics.
We see the major issues raised by the case study as follows:
_ From an RE perspective, how can one both integrate the many stakeholder views 
(including the regulatory stakeholders), as well as place the system in the context 
of standards and cost-effectiveness?
_ From a Safety Critical perspective, what can be done to convince regulatory 
agencies to accept the system? If current regulations are outdated given new 
technology, what arguments can be made to the agencies to change them? For 
instance, can formal models be used in conjunction with traditional testing 
techniques as documentation? Can formal models be used where traditional 
testing techniques are infeasible? If a workshop participant shows that a formal 
model can prove an important property of the system (e.g., that mobile users can 
be guaranteed time-critical service), it might be worthwhile to mount a lobbying 
effort by the community to convince agencies such as the FDA to modernize 
their regulations to take into account new software engineering verification tools. 
_ From a Security perspective, how can the system meet federal patient privacy 
issues and guarantee data integrity given transmission over the open Internet?
_ From a Design perspective, what is the architecture that best serves the system? 
At least one middleware layer has been proposed (e.g., CorbaMed, see links on 
notes page). Are better designs available? How does the need to address mobile 
users and mobile computing impact the design? 
_ From a UI perspective, what new interface ideas are needed in a home-care 
setting? The patient and family members are not medical specialists. How can 
they interact with specialists from a distance?
Our goal is to convince you to apply your research tools and techniques to the case study. 
We believe the case study is both realistic (it is drawn from our fledgling forays into the 
telemedicine area) and compelling (the integration of computing and medicine is 
predicted to continue to grow, both in practice and in research funding). 
Comments? Suggestions? Related Links?
If you have any comments on the case study, please send them to iwssd-chairs for 
considered inclusion on the notes page, which will be updated periodically. That page 
will also maintain a list of related links. You may also email links you believe to be 
relevant to iwssd-chairs for inclusion.