Domain Modelling some Healthcare Sector Concepts

Dines Bjrner
Department of Information Technology
Technical University of Denmark
DK{2800 Lyngby, Denmark
E{Mail: db@it.dtu.dk
September 14, 2000

Abstract
As2 part of a student term and a programming methodology research project we
explore the informal and formal description of a health care sector concept. The student
term project shall show that the project students understand the various concepts of
abstraction & modelling, of domain attribute & facet, and of documentation principles
and techniques. The research project shall test the relevance of these principles and
techniques. At the same time the combined project can hopefully also serve as a basis for
further, application-specic applied research and experimental, prototype development of
a software system for the support of patient and health care unit (eg. hospital) operations.
The3 concept of healthcare sector is, in this document, explored along two, of several
axes:
 Which are the players of the healthcare sector, to wit: citizens (healthy and sick),
family doctors, pharmacies, community nurses, clinics, hospitals, health insurance
companies, pharmaceutical industries, government regulatory agencies, etc. ? Who
communicates with whom ? What is communicated: information, medicine, pa-
tients, test samples, etc. ?
 Patient/hospital treatment cases: Which are the actions that are performed by
patients and by hospitals (their sta etc.), for each of a number of \standard"
treatment cases (to wit: hip operation) ? Can these be semi-formalisable in the
1 The present document is a torso: Incomplete. It drafts the initial parts of a report that a pair of students
in the fall 2000 course, 493_ 51 Advanced Software Specication, is supposed to complete according to all the
\bells-&-whistles" of what is prescribed to be best, modern practices of software engineering. In another
document, avaliable over the web, we detail, for that course, specics for how the eventual report is to cover
the subject, ie. how it is to fullll the project brief (See Sect. 2). Lecture notes for 493_ 51 Advanced Software
Specication can be found at:
 http://www.it.dtu.dk/~db/courses/notes.ps
 http://www.it.dtu.dk/~db/courses/domain.ps
 http://www.it.dtu.dk/~db/courses/wg23.ps
2 This paragraph basically outlines a `project synopsis'
3 This paragraph basically outlines a `product synopsis'

1
2 September 14, 2000. Dines Bjrner

form of possibly diagrammatic \programs" in some language in which a \largest"

class of such treatment cases can be \prescribed", according to which they can
be \executed" and wrt. which hospital sta can record (\white box recorder") all
emerging information ?
That is we examine ows, synchronisation and communication in a healthcare sector, and
the systematic, procedural treatment of hospital patients.

Contents
1 Introduction 3
2 Project Brief 3
3 Synopses 3
3.1 Project Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Product Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Rough Sketch Scenarios 4
4.1 Scenario 1: Patient Flow in the Healthcare Sector . . . . . . . . . . . . . . . . 4
4.1.1 Flow Partners (\The Player") . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2 Flow Components: Informational and Material . . . . . . . . . . . . . 6
4.1.3 Flow Component Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Scenario 2: Hospital Treatment Cases . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1 Treatment Case I: A Generic, Surgical Case . . . . . . . . . . . . . . . 9
4.2.2 Towards a Case Treatment Planning Language . . . . . . . . . . . . . 13
4.2.3 Treatment Case II: Hip Operation . . . . . . . . . . . . . . . . . . . . 13
4.2.4 Treatment Case III: Organ Transplantation . . . . . . . . . . . . . . . 13
4.2.5 Treatment Case IV: Acute/Burst Appendicites . . . . . . . . . . . . . 14
4.2.6 Treatment Case V: Pneumonia . . . . . . . . . . . . . . . . . . . . . . 14
5 Analysis and Concept Formation 14
5.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 Concept Terminology 15
6.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7 Narrative 16
7.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8 Formalisation 16
8.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
c Dines Bjrner, 2000 September 14, 2000, 20:56
Domain Modelling some Healthcare Sector Concepts. September 14, 2000 3

9 Validations 17
9.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10 Verications 17
10.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11 Discussion 18
11.1 Healthcare Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.2 Hospital Case Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12 Conclusion 19
13 Bibliographical Notes 19

1 Introduction
The present document, when completed, shall, when reading just the informal text (with
its easy-to-understand diagrams &c), help decision makers in the healthcare sector to decide
whether to embark on a review of their business, or on a business process [re{]engineering
eort, and/or on new software product acquisiton.
Thus the present document shall illustrate, to IT professionals of the healthcare sector,
that new ways of looking at their business are being studied by academia, and that informatics
candidates will soon emerge from universities, candidates who are able quickly, at a high
level of computing and mathematical modelling (operations analysis, etc.) professionalism |
candidates that they should probably be demanding and hiring.
Meanwhile we invite healthcare sector management to collaborate with us on our better
understanding their domain and on advanced prototype development projects.

2 Project Brief
The healthcare sector project has to deliver on two fronts: (i) Explorations of what is meant by
the healthcare sector concept, and (ii) methodology experiments wrt. how one might develop
healthcare sector [computing] systems | from domain via requirements to software design.
The project brief is to document both [(i){(ii)], intertwined: Present domain, requirements
and software design proposals for healthcare sector systems, thus, at the same time, providing
answers to both (i) and (ii): What is a healthcare sector system, and how to develop software
for it !

3 Synopses
There are two kinds of synopses for the undertaking of this document4 :
4 See the Abstract (Page 1) footnotes 2 and 3, respectively.

September 14, 2000, 20:56 c Dines Bjrner, 2000

4 September 14, 2000. Dines Bjrner

3.1 Project Synopsis

As part of a student term and a programming methodology research project we explore the
informal and formal description of a health care sector concept. The student term project shall
show that the project students understand the various concepts of abstraction & modelling,
of domain attribute & facet, and of documentation principles and techniques. The research
project shall test the relevance of these principles and techniques. At the same time the
combined project can hopefully also serve as a basis for further, application-specic applied
research and experimental, prototype development of a software system for the support of
patient and health care unit (eg. hospital) operations.
3.2 Product Synopsis
The concept of healthcare sector is, in this document, explored along two, of several axes:
 Which are the players of the healthcare sector, to wit: citizens (healthy and sick), family
doctors, pharmacies, community nurses, clinics, hospitals, health insurance companies,
pharmaceutical industries, government regulatory agencies, etc. ? Who communicates
with whom ? What is communicated: information, medicine, patients, test samples,
etc. ?
 Patient/hospital treatment cases: Which are the actions that are performed by patients
and by hospitals (their sta etc.), for each of a number of \standard" treatment cases
(to wit: hip operation) ? Can these be semi-formalisable in the form of possibly dia-
grammatic \programs" in some language in which a \largest" class of such treatment
cases can be \prescribed", according to which they can be \executed" and wrt. which
hospital sta can record (\white box recorder") all emerging information ?
That is we examine ows, synchronisation and communication in a healthcare sector, and the
systematic, procedural treatment of hospital patients.

4 Rough Sketch Scenarios

We encircle the problem | as stated in the Product Synopsis (Section 3.2) | by infor-
mally, and not necessarily systematically, (hence the term `rough') sketching some situations
centering on . . .
4.1 Scenario 1: Patient Flow in the Healthcare Sector
The objective of presenting this scenario is to start the process of identifying (i) who are
actors, \the palyers", the partners, of the healthcare sector | as seen primarily from the
perspective of citizens (ie. potential patients), (ii) what is the communication paths between
thses partners and what is being communicated (information and materials), and (iii) which
are the actions that are performed by single or combinations of partners on information
and material | where patients constitute one form of material (medical drugs [medicine]
constitutes another form of material, etc.).
Hence we have three subsections.
c Dines Bjrner, 2000 September 14, 2000, 20:56
Domain Modelling some Healthcare Sector Concepts. September 14, 2000 5

4.1.1 Flow Partners (\The Player")

 Citizens (c : C ) | this is the term we shall us for healthy and sick people | are born,
live, and die.
 They may be born healthy, or sick.
{ They may be born within | ie. at an institution of the healthcare sector, for
example at a maternity ward of a hospital (h : H ), or in a maternity clinic (k : K ).
{ Or they may be born outside such an institution.
{ If the latter, the mother may visit, or may choose not | or have no opportunity |
to consult an institution of the local healthcare sector, for example a community
(rural, village, township, or city) nurse (n : N ), or a hospital (h : H ) or clinic
(k : K ), as appropriate.
 They may die, \healthy or sick".
{ At a hospital (h : H ),
{ or at home.
 During their life, when feeling, or actually being ill,
{ the citizen may choose, or be brought, to consult an institution of the healthcare
sector, for example a community (rural, village, township, or city) nurse (n : N ),
or a family doctor (m : M ) (a physician), or a hospital (h : H ) or clinic (k : K ) as
appropriate.
{ Or they may choose not, or not be brought | or have no opportunity | to consult
an institution of the local healthcare sector.
 When choosing not to consult a medical professional, or when so directed by a medical
professional, they may choose to visit a pharmacy (drug{store d : D) to buy non{
prescription or, in case the medical professional has issued one, prescription medicine.
 The medical professionals sought out by seemingly and/or actually ill (sick, ailing)
citizens may include:
{ community nurses (n : N ),
{ family physicians (medical doctors (m : M )),
{ including specialist physicians (m : M ) | as so directed for example by the family
physician, or at their own volition,
{ a clinic (k : K ) | such as
 a chiropractor (clinic),
 physiotherapeut (clinic),
 or other.
{ hospital (h : H ),
September 14, 2000, 20:56 c Dines Bjrner, 2000
6 September 14, 2000. Dines Bjrner

{ clinical test laboratory (k : K ) | for X{Rays, electro-cardio-grams (ECGs), and

other such tests which the referring agents (medical professional) cannot perform
themselves,
{ or other !
 One medical professional may refer a patient, ie. a citizen to another medical profes-
sional.
 Citizens may insure themselves, or are, by their employer or the state, insured wrt. costs
of medical (and surgical) care | so citizens also have contact with insurance brokers
and companies (i : I ).
 Medical doctors (m : M ), clinics (k : K ), hospitals (h : H ) and nurses (n : N ) may, or
have to, communicate with state government healthcare regulatory institutions (g : G).
 Typically medical doctors and hospitals also communicate with the pharmaceutical
industry (p : P ).
Figure 1 on the facing page indicate the players outlined above, as rouded, shaded boxes,
and their inter-communication as double, dashed arrows. There could be other players, not
shown, and other communication \paths" (channels), also not shown. For example: Providers
of equipment and general supplies to medical doctors, nurses, clinics, test labs., and hospitals;
equipment such a medico-technical instruments, surgical knives, etc. Above we have outlined
basically those with which a citizen may be involved.5

4.1.2 Flow Components: Informational and Material

 The rounded, shaded boxes (D; I; C; M; G; N; P; H; K ) denote entities, manifest phe-
nomena: people and/or institutions (\buildings, bricks and mortar"),
 the dashed, double headed arrows denotes ways and means of communication: This
communication
{ is either synchronous
{ or is asynchronous,
 and this communication
{ either is physical: involving the synchronous meeting of people or people and
equipments,
{ or is informational: involving messages being | typically asynchronously | com-
municated (medical records, invoices, phone calls, etc.).
Examples of material and informational ows are:
5 One may claim that citizens rarely, if ever, communicate with pharmaceutical industries (p : P ), but two
cases in point are: (i) citizens read, hear and see about pharmaceutical industry (p : P ) products and tests,
and (ii) some citizens actually participate in such tests.

c Dines Bjrner, 2000 September 14, 2000, 20:56

Domain Modelling some Healthcare Sector Concepts. September 14, 2000 7

Figure 1: Flow in a Schematic Healthcare Sector

pm

D D: Drug store, pharmacy

dg I: Insurance (health)
id C: Citizen
cd dm M: Medical doctor
G: Government
ic cm mg
I C M G incl. Regulatory authority
N: Nurse (community)
cn nm H: Hospital
ni ng K: Clinic or clinical test laboratory

ih hg One or more
ck N km instantiations
dp ip
ik ch mh kg
pm nh Communication
pg

P H
ph

hk

K
A healthcare process graph

 Citizen ! Doctor: A citizen visits or otherwise arranges a visit to a medical doctor.

The information communicated and established is I, citizen c wishes to consult medical
doctor m; and an appointment is established, immediately or subsequently. In the for-
mer case, the visit, which will happen anyway (subsequently), not only information is
communicated, but material (the patient) is also \communicated".
 Citizen $ Doctor: The medical doctor analyses (interviews and `tests') the citizen,
henceforth referred to as patient; establishes a diagnosis, possibly issues a precription,
possibly gives the patient some drugs or other treatment.
The information established is of the following kind: establishment or, or updates to, a
patient medical record; notes (scribbles) in the medical doctors oce calendar and/or
note books, etc.
 Patient $ Drugstore (Pharmacy): A patient goes to a pharmacy to buy drugs (either
on, or without prescription).
The material and information communications (ie. ows) taking place are: handing over
a prescription or a non-prescription order, receiving the drugs, paying for these (cash or
on credit), as per an invoice, etc.
In some countries pharmacists may interview, analyse and diagnose the people who come
to the pharmacy | thus performing functions as are medical doctors.
September 14, 2000, 20:56 c Dines Bjrner, 2000
8 September 14, 2000. Dines Bjrner

The material and information communications, for such situations are therefore as for
medical doctors.
 Doctor['s Oce] ! Patient: The medical doctor | or his oce secretary or nurse |
leaves a message with, sends a letter to, the patient: Please contact us by phone or come
to our oce, or: here is the result of the clinical tests you recently underwent.
 Patient $ Clinic:
 $ :
 $ :
 $:

 $ :
 $ :
4.1.3 Flow Component Actions
Above we have `sans serif' emphasized certain terms. They designate actions: observer and
generator functions performed on ow materials (including people) and information. We now
examine these:
 schedule: (make an appointment)
 interview:
 analyse:
 diagnose:
 prescribe:
 treat:
 medicate:
 refer:
 order:
 invoice:
 pay:
 :
 :
 :

c Dines Bjrner, 2000 September 14, 2000, 20:56

Domain Modelling some Healthcare Sector Concepts. September 14, 2000 9

 :
This ends our scenario on ows in the healthcare sector. It is, as scenarios usually are,
incomplete, but, we believe, sucent for subsequent analysis, concept formation, narration
and formalisation.
4.2 Scenario 2: Hospital Treatment Cases
The objective of presenting this scenario is to start the process of identifying the ways and
means of treating | especially | conventional cases of patient hospitalisation: We refer to
such cases as treatments for: (i) cardio arrest, (ii) burst appendicites, (iii) kidney stones, (iv)
hip replacement, etc.
By a treatment case we mean the set of regular, commonly established procedures: inter-
views, analses, diagnoses, tests, medicination, other treatments, sugrical operations, rehabil-
itations, etc., that a patient undergoes during hospitalisation.
The longer range aim of understanding varieties of treatment cases, is to understand the
resource management consequences: Schedulings and allocations, involved in patient treat-
ment so as to provide for optimum patient satisfaction and hospital resource management.
4.2.1 Treatment Case I: A Generic, Surgical Case
We distinguish between (i) a preamble, the actions performed by patient and hospital, before
an unscheduled treatment plan is established, (ii) the establishment of an unscheduled treat-
ment plan, (iii) the scheduling and allocation of resources to fulll the treatment plan | we
refer to the result of this phase as the scheduled treatment plan, and (iv) the treatment plan
execution.
Preamble:
 (IN) The patient, somehow (by phone, or letter, or at the family doctor's oce, or by
own initiative) turns up at the hospital for a standard treatment.
 (ADM) At the admissions oce the type of case is [re{]conrmed by a medical sta (a
medical doctor, a nurse, or other).
 (TPL) The case is registered and a treatment plan established.
Unscheduled Treatment Plan:
An unscheduled treatment plan essentially prescribes:
 (I&T) The plan may st precribe a series of interviews and tests by hospital sta:
{ (RIS) For example: X{rays are to be taken,
{ (ECG) an ECG (electro-cardiogram) likewise,
{ (BLD) blood tests for blood sugar, cholesterol, etc.
{ (TST) blood pressure, urine sample tests, faeces tests,
{ (EYE) eye tests,
September 14, 2000, 20:56 c Dines Bjrner, 2000
10 September 14, 2000. Dines Bjrner

{ (ETC) &c.
 (BED) The plan also prescribes; registration and `bedding' in an appriate ward.
 (SOP) and the lowing sequence of procedures:
{ (FST) fast the night before the surgical operation,
{ (WAK) wakening up the morning of the day of the surgical operations,
{ (PRE) bathing, medication and dressing for the operations,
{ (MOV) movement to the operating theatre,
{ (SUR) the surgical operation itself,
{ (IPO) immediate post-operation observation and treatment
{ (CWD) possibly ina special, critical observation ward, and
{ (MOV) movement back to the ward.
 (POR) The plan then goes on to prescribe the daily post-operation routine:
{ (MED) medication,
{ (MEL) normal or special dietary meals,
{ (REG: RIS, ECG, BLD, TST, EYE, and/or ETC) regular tests of various kinds:
blood pressure, temperature, blood tests, urine tests, ECGs, eye test, throat in-
spection, etc.
{ (INT) daily interviews by medical doctors,
{ (RTR) retraining,
{ &c.
 (?) Finally the plan species conditions for
{ (RPL) alteration of plans, ie. replanning | in case of unforeseen contingencies:
Failure of prescribed treatment, lack of healing, etc. | possibly leading to another
surgical opration.
{ (TRT) termination of individual treatments | in case of foreseen healing,
{ (OUT) and release from hospital | when cured.

Scheduling a Treatment Plan:

 Resources are required in order to perform any of the activities designated by the solid,
fat line round corner boxes.
 These resources are combinations of the patient, sta, rooms, equipment and time.
 Some activities can proceed in any order, some can proceed concurrently (==), ie. in
parallel.q
c Dines Bjrner, 2000 September 14, 2000, 20:56
Domain Modelling some Healthcare Sector Concepts. September 14, 2000 11

Figure 2: A Generic Surgical Case Flow

SOP

I&T
POR
FST

RIS BED
WAK MED

ECG
PRE MEL

BLD
MOV REG

IN ADM TST
SUR INT
TRT
EYE
IPO RTR ? REL

ETC
VWD RPL

MOV
continuously
until test (?)

TPL

 The POR action cluster is an example of the latter.

 Any, but necessarily sequential order activities, can have their order t availability of
otherwise serially reusable resources.
 The I&T actions form an example of `any order' activities that must be sequentialised
since they all involve, amongst many, one and the same resource, the patient. The I&T
column is therefore, by the dashed, vertical, downward going arrowed line, an example
of some such sequential ordering.
 Some set of actions are forced by logical necessity to be executed in a specic order.
 The SOP [column] actions seems to be such an example. As do the clusters of actions
labelled I&T, BED, SOP, POR, and ? (TRT, RPL, REL).
 Some activities, here illustrated by a cluster of such, are executed \continuously, for
some period, until it is time for a planned review (test, ?)". This is illustrated by the
backward, dash-dotted arrow at the bottom of the POR cluster.
Scheduling an unscheduled treatment plan is an operation that is applied not only to the
unscheduled treatment plan (ie. an annoytated version of for example a diagram like Figure 2,
but also to some representation of the totality of free and bound hospital resources: Sta,
rooms, equipment and time. Usually such a scheduling operation also takes a number of
September 14, 2000, 20:56 c Dines Bjrner, 2000
12 September 14, 2000. Dines Bjrner

\subjective measures" into account, for example patient, patient family and hospital sta
preferences.
Treatment Plan Execution:
 The treatment can now be set in action and according to the scheduled treatment plan.
 We can, colloquially, speak of an \execution" of the scheduled treatment plan.
 Such a scheduled treatment plan \execution" can be characterised in a number of ways:
{ We think of someone, one or more hospital sta, monitoring & controlling the
\execution" of the scheduled treatment plan.
{ At any point in time the locus of monitoring & control resides at one sequentially
\executed" action, or at any number of such actions in a cluster of concurrently
executable actions.
{ \Execution" of an action usually takes time.
{ \Execution" of a next action takes place either \after" the end of execution of a
previous action, or, when of a cluster of concurrently \executable" actions, only
\after" execution of all of these have terminated.
{ By \after" we sometimes mean `immediately after', and sometimes, `sometimes
after' !
{ Execution of an action may fail for a number of reasons:
 One or more of the prerequisite resources, incl. the patient, hospital sta, fail
to be present at the time and place for which the action was scheduled,
 or some equipment does not function properly,
 or seemingly performed action leaves an inconclusive result: The patient dies,
or test measurements are contradictory, or other.
{ A (scheduled) treatment plan can prescribe what should be done in case of failures.
To keep matters simple in this explorative document we have concentrated such
\exception{like" conditions to the ? (TRT, RPL, REL) test two of whose outcomes
which prescribes \repetitions" of actions or actions clusters.
 The actual behaviour of a patient/hospital system seen in the context of a scheduled
treatment plan for that patient and in that hospital, can be recorded | by attaching
information to the nodes, clusters and arrows of the scheduled treatment plan.
{ These notes record when the respective action (or action cluster) was (were) ac-
tually executed: Time (start and end), by whom, with what results (outcomes),
etc.
{ These notes also record contingencies: Exceptions, remedial actions taken, etc.
{ We call the resulting, so annotated scheduled treatment plan for the case trace.
{ The case trace thus records how many times loops backward to previous clusters
were taken, when, etc.
c Dines Bjrner, 2000 September 14, 2000, 20:56
Domain Modelling some Healthcare Sector Concepts. September 14, 2000 13

{ Thus annotations wrt. any given action box notes to which iteration of treatment
(1st, ith) the pertinent information (the notes, the annotations) relate.
So, surgical procedures, which were prescribed once, may have to be performed repeatedly, or
replanning may presctibe new surgical procedures, etc. Independent of such exception-based
repetitions or emergencies, one can, of course, have treatment plans that explicitly, from the
very planning stage, foresees several surgical events.

4.2.2 Towards a Case Treatment Planning Language

We have seen one, a generic, case treatment plan and its derivatives: Schedulings, executions
and traces.
The plan shown was generic. Below we present actual-life, ie. realistic, unscheduled case
treatment plans.
Common to the above and below is that we have introduced a concept of a graph{like, ie.
a diagrammatic rendition of case treatment plans. Similar to our own itemised explications, a
case treatment plan (whether unscheduled or scheduled) is annotated with planning notes. In
other words, we expect, after the next examples, to be able, later to design an semi-formalised
diagrammatic language for use by hospital sta when planning, scheduling, executing and
tracing case treatments.

4.2.3 Treatment Case II: Hip Operation



4.2.4 Treatment Case III: Organ Transplantation



September 14, 2000, 20:56 c Dines Bjrner, 2000

14 September 14, 2000. Dines Bjrner

4.2.5 Treatment Case IV: Acute/Burst Appendicites



4.2.6 Treatment Case V: Pneumonia



5 Analysis and Concept Formation

We analyse the above scenarios. The intention of the Analysis is to formulate the concepts,
to dene the professional notions, that are central to the healthcare sector, and to identify
such which can be made part of a hospital case treatment plan language.

5.1 Healthcare Flow



c Dines Bjrner, 2000 September 14, 2000, 20:56

Domain Modelling some Healthcare Sector Concepts. September 14, 2000 15

5.2 Hospital Case Treatment



6 Concept Terminology
The following concepts have (so far) been identied:

6.1 Healthcare Flow



6.2 Hospital Case Treatment



September 14, 2000, 20:56 c Dines Bjrner, 2000

16 September 14, 2000. Dines Bjrner

7 Narrative
7.1 Healthcare Flow


7.2 Hospital Case Treatment



8 Formalisation
8.1 Healthcare Flow


c Dines Bjrner, 2000 September 14, 2000, 20:56

Domain Modelling some Healthcare Sector Concepts. September 14, 2000 17

8.2 Hospital Case Treatment



9 Validations
9.1 Healthcare Flow


9.2 Hospital Case Treatment



10 Verications
10.1 Healthcare Flow


September 14, 2000, 20:56 c Dines Bjrner, 2000

18 September 14, 2000. Dines Bjrner

10.2 Hospital Case Treatment



11 Discussion
11.1 Healthcare Flow


11.2 Hospital Case Treatment



c Dines Bjrner, 2000 September 14, 2000, 20:56

Domain Modelling some Healthcare Sector Concepts. September 14, 2000 19

12 Conclusion
13 Bibliographical Notes
The present document builds upon and continues a long research endeavour: [1, 2, 3, 4, 5, 6,
7, 8, 9, 10, 11]

References
[1] Dines Bjrner, Souleimane Koussobe, Roger Noussi, and Georgui Satchok. Michael Jack-
son's Problem Frames: . In Li ShaoQi and Michael Hinchley, editors, ICFEM'97: Intl.
Conf. on Formal Engineering Methods, Los Alamitos, CA, USA, 12{14 November 1997.
IEEE Computer Society Press.
[2] Dines Bjrner and Jorge R. Cuellar. Software Engineering Education: R^oles of for-
mal specication and design calculi. Annals of Software Engineering, 6:365{410, 1998.
Published April 1999.
[3] Dines Bjrner. Domains as Prerequisites for Requirements and Software &c. In M. Broy
and B. Rumpe, editors, RTSE'97: Requirements Targeted Software and Systems Engi-
neering, volume 1526 of Lecture Notes in Computer Science, pages 1{41. Springer-Verlag,
Berlin Heidelberg, 1998.
[4] Dines Bjrner. Where do Software Architectures come from ? Systematic Development
from Domains and Requirements. A Re{assessment of Software Engneering ? South
African Journal of Computer Science, 1999. Editor: Chris Brink.
[5] Dines Bjrner. Software Engineeering: A New Approach. From domains via requirements
to software. Formal specication and design calculi. 2000. Presently this document is
a rather extensive (approx. 900 page) set of lecture notes. It is accessible over the web:
http://www.it.dtu.dk/~db/s2000.

[6] Dines Bjrner. Domain Modelling: Resource Management Strategics, Tactics & Op-
erations, Decision Support and Algorithmic Software. In J.C.P. Woodcock, editor,
Festschrift to Tony Hoare. Oxford University and Microsoft, September 13{14 1999.
[7] Dines Bjrner. A Triptych Software Development Paradigm: Domain, Requirements
and Software. Towards a Model Development of A Decision Support System for Sus-
tainable Development. In ErnstRudiger Olderog, editor, Festschrift to Hans Langmaack.
University of Kiel, Germany, October 1999.
[8] Dines Bjrner. Pinnacles of Software Engineering: 25 Years of Formal Methods. Annals
of Software Engineering, 2000. Eds. Dilip Patel and Wang Yi.
[9] Dines Bjrner. Domain Engineering, Elements of a Software Engineering Methodology |
Towards Principles, Techniques and Tools | A Study in Methodology. Research report,
Dept. of Computer Science & Technology, Technical University of Denmark, Bldg. 343,
September 14, 2000, 20:56 c Dines Bjrner, 2000
20 September 14, 2000. Dines Bjrner

DK{2800 Lyngby, Denmark, 2000. One in a series of summarising research reports

[12, 13].
[10] Dines Bjrner. Domain Engineering, A Software Engineering Discipline in Need of Re-
search. In SOFSEM'2000, Lecture Notes in Computer Science. Springer Verlag, 18{24
November 2000.
[11] Dines Bjrner. \What is a Method ?" | A Study of Some Aspects of Software Engi-
neering. MacMillan, 2001.
[12] Dines Bjrner. Requirements Engineering, Elements of a Software Engineering Method-
ology | Towards Principles, Techniques and Tools | A Study in Methodology. Research
report, Dept. of Computer Science & Technology, Technical University of Denmark, Bldg.
343, DK{2800 Lyngby, Denmark, 2000. Not available. One in a series of summarising
research reports [9, 13].
[13] Dines Bjrner. Software Design: Architectures and Program Organisation, Elements of
a Software Engineering Methodology | Towards Principles, Techniques and Tools |
A Study in Methodology. Research report, Dept. of Computer Science & Technology,
Technical University of Denmark, Bldg. 343, DK{2800 Lyngby, Denmark, 2000. Not
available. One in a series of summarising research reports [9, 12].

c Dines Bjrner, 2000 September 14, 2000, 20:56