A Formal Model of Healthcare Security Policy - Semantic Scholar

A Formal Model of Healthcare Security Policy Prof. B Cohen, City University

1.

Introduction

This paper has been motivated by a conflict between the NHS Executive and the BMA [Anderson] concerning the requirements for, and the provision of, security in the NHS-wide Networking Programme [NHSE-IMG]. It cannot attempt to resolve that conflict, because the documents from both parties to it lack the precision required of a Healthcare Security Policy Model. The NHS document is, quite correctly, more concerned with the mechanisms on which secure communications services must rely than with the purposes to which those mechanisms will be put. The BMA document is, quite correctly, concerned with the principles of confidentialty. It is critical of the mechanisms it but does not provide a statement of security policy in a form that admits the verification of its internal consistency, or its validation with respect to the purposes of Healthcare and the expectations of its pracitioners and patients. We hold such a formal statement to be both necessary and possible to construct. In fact, we construct a prototype Formal Healthcare Security Policy Model as a proof of concept. This expressed as a statebased (popularly known as object-oriented), set-theoretic model in the style of [Schuman]. For readers unfamiliar with discrete mathematics, the earlier parts of the model are accompanied by a tutorial in the notation, and a guide to the basic set-theoretic operators is appended.

2.

A 'Systems View' of Healthcare Security Policy

Healthcare is a system in which professionals provide health-related services to patients. Because of the life-critical nature of these services, and of the confidential nature of the relationship between patient and healthcare professional, the healthcare system's constituents expect the services to be safe and the relationship sacrosanct. A Healthcare Security Policy (HSP) is a statement of: ¥

the constituents' expectations of safety and confidentiality;

¥

the rules (or 'laws') that the system must observe in order to satisfy them; and

¥

the audits required to detect and record violations of those laws.

This statement must admit the validation of the security policy that it expresses. In particular, it must be possible to demonstrate ¥

that the laws are strong enough to ensure that the constituents' expectations will be met by any system that observes them, and

¥

that the audits are sufficiently rigorous to detect violations of the laws, even if they are committed by agencies outside of the system's control.

These properties cannot be convincingly demonstrated, or refuted, of a security policy expressed only in an informal notation, such as natural language.

A Formal Model of Healthcare Security Policy

Version 2

B Cohen 1996

1

2.1.

Lessons from Military Security Policy Modelling

This has become apparent in the military domain, where security policy has been most deeply studied. There, a hierarchical security policy is required where levels of security, from unrestricted to 'top secret' (or higher), are allocated both to documents and to the operatives who read and write them. Each operative should be provided with access only to those documents rated at or below the operative's level of 'clearance' (and for which the operative can demonstrate a 'need to know'). The celebrated Bell and La Padula Security Policy Model sought to inhibit the 'leakage' of sensitive information by demanding (roughly) that every document that includes information culled from others be allocated a security level equal to the maximum of the levels of those documents and of the clearance of the operative responsible for creating it. The original, natural language, presentation of the Bell and La Padula model met with widespread approval. However, when a formal version of the model was constructed, it was shown to have some unanticipated consequences. In particular, it was possible to prove that all documents in a system operating under the Bell and La Padula policy tend to migrate to the highest security level, at which only those operatives with the highest clearance (e.g. the President) can read them! 2.2.

The Need for Formality

Only in a formal model of a system can the validity of its laws, and the adequacy of its audits, be rigorously assessed. The part of a formal system model that expresses the system's security policy is called a Security Policy Model. In order to construct and validate a security policy for Healthcare, therefore, one must first construct, and validate, a formal model of those parts of the healthcare system to which the policy refers. Since the constituents' expectations concern, among other things, the confidentiality of the patientprofessional relationship, those aspects of this relationship which are mediated by the healthcare system must be formally modelled. [This argument applies equally to the constituents' expectations of the safety of the healthcare system, which are usually dealt with separately.]

3.

What a Formal Model Must Say

The confidentiality relationship pertains between known professionals who offer known services to known patients. Furthermore, the status of these entities, and of the relationships among them, change over time. In formulating our model, we need to denote only those aspects of these entities necessary to articulate the relationships and the laws that they must respect. Thus, although the services provided by the professionals include the whole of clinical practice, we will not need to incorporate that in our model (even if that were feasible, which is unlikely ever to be the case). From the model that we articulate, we may derive formal consequences in the form of predicates which may be interpreted as explicit statements about the system and the expectations of its constituents. Some of these may turn out to be false, necessitating a revision of the model (or of the sincerely held beliefs of some stakeholders), but none will be ambiguous and their mutual coherence will be guaranteed by the internal logical consistency of the model.


Version 2

B Cohen 1996

2

Here is a trivial example of such a statement: ¥

A service may be delivered to a patient only by a professional who offers that service, at that time.

And here is a less trivial one: ¥

In order to gain access to any part of a patient's record, a professional must be delivering a service to that patient and must have been granted access rights to that part of the patient's record by the professional who is responsible for it.

In the frame of reference of the above statements, we may identify the patient record , which is the subject of the confidentiality relationship, as the history of all services delivered to a patient together with the identities of the professionals who delivered them. We need not model the clinical content of the record Ñ observations, tests, diagnoses, treatments etc. Ñ because clinical practice is not our concern here. However, confidentiality demands that 'access' to some parts of the record is to be restrictable to certain named professionals or groups thereof. Our model of the record must therefore allow such parts to be identified, even though their clinical content is not. One way to achieve this degree of abstraction is for the model to equate 'parts' of the record with the deliveries of service that generate them. An access control list (see [Anderson] pp. 12 et seq.) may then be modelled by a relation between professionals and the (records of) deliveries of service to which they have access. Such a model abstracts away both from clinical practice and from the physical, and even the logical, representation of the record. It need not, therefore, refer to 'fields' or 'records' (in the database sense) and need not even distinguish between paper and electronic forms.

4.

How To Say It (in Set Theory)

Such a model is usually constructed out of smaller parts, since the system is usually too complex to be contemplated as a whole There is no unique formal notation for representing all such models, nor is there a 'standard' procedure for constructing them. The modeler must choose one with the expressive and analytical power appropriate to the system being modelled and to the purpose of the model. In the construction that follows, we will adopt a formal notation based on set theory, which provides relational structures of arbitrary complexity without losing its analytical power. The set-theoretic operations used in the model are defined in Appendix 1, and the notation is explained as the model is elaborated. We will begin by modelling the health care record in terms of time-varying relations among sets of professionals, services and patients. This model says nothing about the nature of the service, the representation of the record, or the locations of the patients and professionlas. We will then define access rights as relations among: subsets of the record: the patients to whom these subsets belong; the services to which they refer; and the professionals who created them, who control access to them and who require access to them. The Security Policy will be expressed as the model's invariants (denoting the 'laws' of the system) and preconditions (denoting the constraints that must apply to events in the system if the laws are not to be violated).


Version 2

B Cohen 1996

3

4.1.

The Basic Classes: Time, Patients, Agents and Services

Purely as a notational convenience, to avoid the potential ambiguity of 'p' as an abbreviation for both patients and professionals, we shall refer to professionals as agents.

4 . 1 . 1 . Time The class CAL, for Calendar (see Appendix 2), models the passage and measurement of time . The period of the calendar is not significant here; we may read it as being one day, for example. now refers to 'today', past is the sets of days before (and including) now and future is the set of days from now on.

4 . 1 . 2 . The Class of Patients Notation: PS is the name of the schema that represents the state space of (a model of) an isolated Patient System. Such a system knows only about: ¥

the measurement and passage of time, through its inheritance of the class CAL.

¥

a set of (distinct) identifiers, drawn from an arbitrary set P; and

¥

a relation, patients, comprising a set of ordered pairs: a time and an identifier.

The set P may be construed as uniquely identifying every person who ever was, or ever will be, a patient. The relation provides for uniquely identified people to be recognised as patients at different times, not necessarily continuously. The 'state components' of the class are patients and the inherited state components of CAL. The state space may be constrained by an 'invariant' (none here) which asserts a predicate that must always be satisfied by the values of the state components. In the schemas below, the invariant will be indented to distinguish it further from the state component declarations. The values of state components immediately after initialisation (under the double line) are referred to by decorating the component name with a prime, thus: patients'= Æ, the empty relation. Thus, when a Patient System is initialised (i.e. created, at day 1), it knows of no patients, now or ever. Initialisation is inherited, so only patients need be initialised here; i.e. in an intialised PS, now' is 1. The formal model is presented on the left and its intended interpretation, in natural language, on the right.

PS CAL patients: T « P patients' = Æ


Patients are known of throughout some period of time. Initially, the system knows of none.

Version 2

B Cohen 1996

4

4 . 1 . 3 . Events in the Class of Patients Notation: Each event in a class is defined in its own 'schema', which has similar structure to the class schema itself. The name on the event is prefixed with the name of the class in which it is defined and succeeded by its paramter list (parameters are passed by value). Each parameter must be declared with its type (the set over which its values may range). An event may be guarded with a precondition which constrains the values of the state space and parameters at which the event is enabled. If the precondition is false, the event will not occur. The parameter declaration is really part of the precondition in that the event is disabled for all values of the parameters which are not of the declared type. The postcondition (under the double line) relates the values of the state components and parameters before and after the occurence of the event , those after being decorated with a prime. PS.new(p)

A patient, who may or may not have been

p: P

known of before,

(future ´ {p}) Í patients'

is to be known of from now on

PS.delete(p)

A patient ceases to be registered with the

p Î cod patients

system. The fact that the patient had been

(future ´ {p}) Ç patients' = Æ

known at earlier times is not deleted.

4 . 1 . 4 . The Class of Professionals ('Agents') and its Events Notation: AS is a model of another isolated system, an 'Agent System', unconnected (as yet) to the Patient System. It also inherits its knowledge of time from CAL and relates unique identifiers for professionals, taken from the arbitrary set T, to the times at which these professionals are known to the system. The classes PS and AS are 'isomorphic', identical in structure, even down to the definitions of their events, and differing only in the names of their components and arbitrary sets. AS CAL agents: T « A agents = Æ

Professionals, referred to here as agents (see above), are also known to the system for periods of time.

AS.new(a)

A professional

a: A

is registered with the system

(future ´ {a}) Í agents'

from now on.

AS.delete(a)

A currently known professional

a Î cod agents

ceases to be registered

(future ´ {a}) Ç agents' = Æ

from now on.


Version 2

ÓB Cohen 1996

5

4 . 1 . 5 . The Class of Services and its Events SS

Healthcare (i.e. clinical and other related)

CAL

services are also identified. This class is also

services: T « S

isomorphic to patients at this stage and its

services' = Æ

events are omitted for brevity.

The tick event from the calendar should be 'promoted' to each of the classes that inherit from it.

4.2. A Simplified (record-free) Healthcare System We now proceed to the definition of a healthcare system, in which professionals provide services to patients during periods of time. At this stage in its development, the model defines the structure that will later be used as the patient record, but it does not yet represent professionals' access to the record. HCS

The Healthcare System knows what services

AS; PS; SS

each professional offers at any time (the

offers: T «A ´S

professional and the services offered must be

offers Í agents & services receives: T «P ´ (A ´S) receives Í patients & offers HCS.deliver(p, a, s, t) PS.new(p) a: A; s: S; t: set T t Í future; now Î t (now,(a,s)) Î offers

known at that time) and by what patients (who must also be known at the time) these services have been received. A professional delivers a service, for a period of time, starting now, to a patient who is henceforth registered with the system. The professional must be known to offer the service at the time.

(p,(a,s))Î receives'[t] HCS.transfer(p, a1, a2, s1, s2, t) p: P; a1, a2: A; s1, s2: S; t: set T (p,(a1,s1)) Î receives[{now}] (a2,s2)) Î offers[{now}] t Í future; now Î t

A patient is transferred from one professional, from whom the patient is currently receiving a service, to another in order to receive a service, currently offered by the latter, for a fixed period of time starting from now.

(p,(a2,s2)) Í receives'[t]

Note: the patient continues to receive the

HCS.stop(p, a, s)

original service until:

p: P; a: A; s: S

The delivery of a service to a patient by a

(p, (a, s)) Î receives[{now}]

professional is terminated,

(p,(a,s)) Ï receives'[future]

as of now.


Version 2

ÓB Cohen 1996

6

As the model stands, the system becomes aware of patients only when they start to receive some service. This seems reasonable for the purposes of confidentiality, but it is not so clear when a patient should be deregistered. We make the explicit (and therefore refutable) assumption that: HCS.delete(p) PS.delete(p) p Ï dom(cod receives)

The system may cease to know about a patient only if the patient is not currently receiving a service. On the other hand:

HCS.dereg(a)

A professional may be deregistered at any time.

AS.delete(a) Note that, since the AS.delete event alters agents so as to remove all trace of the professional from now on, and since receives is derived from offers, which is in turn derived from agents, a deregistered professional cannot subsequently offer any service to any patient (until the professional is reinstated). No further predicate is therefore needed in this promotion. We should also define the events at which a professional starts and ceases to offer a service, and we should promote all the other events from AS and PS. Again, these definitions are all straightforward, and have been omitted for brevity. 4.3. A Healthcare System with Patient Records We now proceed to the definition of a Healthcare Record System, in which the record of each patient is just the set of services that that patient has received from professionals in the past. This will allow us to associate with any 'part' of a patient's record an access control list of professionals authorised, by the patient, to access that part. Exactly one professional in each access control list will be designated as 'responsible' for approving any attempted extension of that access control list (as required by the BMA's Security Principles 2, 3 and 4 ([Anderson] pp.13-15). HCRS

The Healthcare Record System extends

HCS

the Healthcare System by

record: P ® receives

associating with each patient

dom record = patients[past]

who has ever been registered with the system

cod record = receives - past

all the services provided to that patient and

dom ° cod ° record Í Id(dom record)

only that patient.

acl: P ® (receives « A)

Each service record for each patient is

dom° acl = record

accessible by a set of professionals who are

cod(cod(acl)) Í agents[{now}]

currently registered,

resp: P ® (receives ® A) resp Í acl


just one of whom is deemed to be responsible for it.

Version 2

ÓB Cohen 1996

7

HCSR.deliver(p, a, s, t, r) HCS.deliver(p, a, s, t)

A professional who delivers a service to a patient and requires access to

r: T «P ´ (A ´S)

a specified part of

r Í record(p)

the patient's record, must be on that part's

(r, a) Î acl(p)

access control list.

HCRS.takeresp(p, a, s, r)

A professional may take responsibility for the

p: P; a: A; s: S

access control list of

r: T «P ´ (A ´S)

part of a patient's record only if he

(r, a) Î acl(p)

currently has access to it and

(p, (a, s)) Î receives[{now}]

is offering a service to the patient.

resp'(p)(r) = a

HCRS.transfer(p, a1, a2, s1, s2, r, t)

Access is granted to part of a transferred

HCS.transfer(p, a1, a2, s1, s2, t)

patient's record only if the professional to

r: T «P ´ (A ´S)

whom the transfer is made is already on the

r Í record(p)

access control list for that part.

(r, a2) Î acl(p) HCRS.addacc(p, a1, a2, r) p: P; a1, a2: A; s: S r: T «P ´ (A ´S) resp(p)(r) = a1

Only the professional who is responsible for part of a patient's record may add another to

(r, a2) Î acl'(p)

HCRS.stopacc(p, a1, a2, r) p: P; a1, a2: A; s: S

or delete one from its access control list

r: T «P ´ (A ´S) resp(p)(r) = a1 (r, a2) Ï acl'(p) Once again, the events from inherited classes should be promoted here. By this stage of construction, it is likely that these promoted events will require stronger preconditions in order not to violate the stronger invariants of the higher classes. Although most of these event promotions are technically trivial, the necessary strengthening may reveal previously unnoticed aspects of the domain being modelled. These often concern conflicts between 'housekeeping' events, which are principally concerned with the manipulation of 'name space'


Version 2

ÓB Cohen 1996

8

Ñ i.e. the registration and deletion of individuals (in our case, patients, professionals and services) Ñ and 'executive' events, which update the relationships among the individuals as the system 'behaves' (in our case, the provision of healthcare services). This issue reflects one of the major concerns of confidentiality Ñ the inhibition of access by those who no longer are entitled to it. The promoted 'administrative' events from the lower classes, particularly AS where professionals are registered, should demonstrably achieve this effect, thus: HCRS.dereg(a) HCS.dereg(a) a Ï cod(cod(acl))

4.4.

One may deregister only those professionals who no longer have access to any patient's record.

Proving the Model Consistent

The model contains two separate sets of constraints: the invariant, which limits the valid state space, and the pre- and post-conditions, which constrain the enabling and termination of events. It is possible to construct a model in which these sets of constraints conflict, that is in which ¥

the invariant is so strong that the system has no valid states, or

¥

the precondition of an event is so strong that it is not enabled in any valid state, or

¥

the postcondition of some event is not strong enough to prevent it from terminating in a state that violates the invariant.

A model that suffers from any of these errors is logically inconsistent. We seek to avoid the construction of inconsistent models for two reasons: ¥

they cannot be models of any systems in the world, which demonstrably do have valid states (in that they exist), or non-occurring events (in that they behave); and

¥

since any logically inconsistent formal system admits the inference of every consequence and its negation, we cannot use the theorems of an inconsistent model as a basis for its validation (see 4D below).

The constructor of a formal model therefore has an obligation to prove its internal consistency (prior to, and independently of, its empirical validity). The consistency of set-theoretic models of the type used here can be proved by the discharge of a finite and well-defined collection of proof obligations (see Appendix 3), all of which require only first order proof techniques. However, no proofs are presented here, because our model is merely a prototype, a 'proof of concept' constructed in the absence of consultation with the stakeholders, and no proofs have yet been conducted for it. Furthermore, proofs are boring things to read; it is more important to know that the consistency proof obligations have been discharged than to inspect the proofs. Proofs is also notoriously prone to human error [Lipton], so the sceptic is entitled to ask what has been gained by formalisation [Fetzer] . Fortunately, first order proof is mechanically supportable: several computerbased proof assistants and fully mechanised proof checkers have been available for many years. These powerful tools take the boredom out of the proof process and admit third party verification of its


Version 2

ÓB Cohen 1996

9

quality. Governments and industries rely heavily on them in their development and certification of high security products. On the other hand, the modelling strategy is deeply affected by the possibility, and eventually the necessity, of consistency proof, as follows: (a) Every expression in the model should be manually 'typechecked' as it is constructed. This discipline encourages elegance and simplicity in the state space structure. (b) The consistency proof guarantees that the invariant will be maintained by any implementation that respects the events' pre- and postconditions. The modeler should therefore seek to strengthen invariants and weaken postconditions. This discipline minimises restrictions on the implementor and makes the case for compliance easier to construct. It also eases validation by making essential structure manifest.

5.

How To Present a Formal Model

Although the mathematical content of the formal healthcare security policy model outlined above is essential to its purposes of definition and verification, it makes the model unintelligible to most of its stakeholders. A number of possible ways out of this impasse have been considered (for an anecdotal survey, see [Cohen94]). One might: A.

teach the stakeholders enough (elementary) set theory to enable them to read and understand

(but not to construct) the model. The Princeton Institute of Advanced Studies is alleged to have taken this approach in the early '50s with a US submarine manufacturer, and it was extremely successful in an Irish insurance company in the '70s. B.

extract only the (informal) comments accompanying each class and event definition, to

which reference is made only to resolve ambiguity. This approach has also had some success, but it relies on a very high quality of prose in the comments, which tend to be dry and boring as a text. C.

project the model into a representation that is weaker in semantic content but easier for the

mathematically challenged to read. This has been done frequently, both in classical engineering (most computer-aided-design systems rely on exactly this approach) and in information systems (e.g. the 'projections' offered by Higher Order Software's CASE tools). As with extraction, any ambiguities in the legible form can be resolved by reference to the formal model when necessary. The set-theoretic modelling technique that we have used lends itself to projection into several more familiar, and less formal, frameworks, including entity-relation, object-oriented, dataflow and rule-based. D.

derive from the model some of the infinity of its formal consequences (theorems) which offer

ready interpretation as statements about the system's behaviour. The selected theorems should be universally quantified , that is, proved to hold for all states, or valid sequences of events, etc., in contrast to those traditionally used for testing , which relate to a single state-of-affairs or sequence of events. They should also be contentious when interpreted Ñthat is, they should say something about the system (as modelled) which is not trivially obvious, and preferably counterintuitive, as these are most likely to reveal the inevitable misconceptions, ambiguities, differences of opinion, etc. which it is the purpose of analysis to identify and resolve.


Version 2

ÓB Cohen 1996

10

E.

animate the model, for example by executing it as a program on a suitable interpreter. This

is actually a variety of derivation, where the proofs of the theorems are 'constructive', that is, generate executable algorithms. This has also been achieved in the past, for example in the University of Surrey's SUZAN tool, which 'animates' set-theoretic models by converting them to (very slow) Prolog programs. However, it suffers from similar drawbacks to 'testing', since executing the model explores the infinite space of its possible behaviours one at a time.

6.

How to Explain a Formal HSP Model to its Stakeholders

Each group of stakeholders in a Healthcare Security Policy has different needs, skills and priorities. Explaining to them the content and implications of a formal HSP model will require the exercise of at least the modes of presentation listed above. We will consider each class of stakeholder in turn and recommend one or more appropriate modes of explanation. 6.1.

Patients

The patient needs to feel confident that the benefits of every aspect of the healthcare system far outweigh its risks. The public perception of the security and safety of critical systems, such as nuclear power stations, automatic teller machines and fly-by-wire aircraft, is a notoriously fickle commodity, easily disturbed by a small number of spectacular, and well-publicised, violations and tolerant of level of risk which is often so low as to be technically unachievable. Ultimately, the level of patient confidence in a healthcare security policy will rest on some unquantifiable 'feel-good factor' which will be strongly influenced by factual evidence that breaches of confidentiality have been difficult to achieve and that any that have occurred have detected and have attracted appropriate sanctions and compensation. No explanation of the HSP model is likely to have any effect on this factor, but it might help to build an educational advertising campaign around scenarios based on the animation of the model. Mode E 6.2.

Professionals

Clinical and administrative professionals have notoriously different attitudes to many aspects of the healthcare system, including its security. However, they do share the concern that their obligations and responsibilities, as defined by the model, be fair to them, i.e. that standards of professional practice should not be undermined or made infeasible by the security policy. This kind of professional acceptability is often difficult to isolate from the cognitive mechanisms that an implemented system provides for access control Ñ the so-called 'human computer interface' Ñ since all professionals find it difficult to reflect on their practice sufficiently to articulate it in the abstract. However, any proposed HSP would have to be professionally validated well before compliant systems had been developed. HCI issues should therefore be avoided when validating an HSP. One possible strategy is to explicate the 'business rules' that the policy enforces by the use of scenarios and interpreted theorems, derived from the model, that illustrate the rules in use.


Mode D

Version 2

ÓB Cohen 1996

11

In the medium term, it would seem highly advisable to include introductions to HSP and its modelling in educational programmes for healthcare professionals, both clinicians and administrators so that they might read, understand, and even help to reconstruct, formal models of their own enterprise. Modes A, B 6 . 2 . 1 . Clinicians The special security concerns of clinical professionals include their need to access patient records in an emergency, and for the purposes of research, without running foul of sanctions. This immediately indicates the fundamental conflict between the patient's rights to privacy and the information requirements of clinical practice, that is, between the confidential and fiduciary natures of the clinical relationship. A suitable short term strategy here might be to include dataflow, or flowchart, diagrams, projected from a formal HSP model, in the ever-growing collection of Clinical Practice Guidelines .

Mode C

6 . 2 . 2 . Administrators The healthcare system is enormously complex. The NHS itself is the world's largest single enterprise. Its administrators require access to information in the patient record in order to manage resources (planned and actual), costs (revenue and expenditure) and manpower (organisation and performance), and to perform audits (statutory and fraud prevention). At the same time, they have to understand the potential conflicts between such access requirements and the HSP. Their management r™le demands that they have a depth of understanding of the HSP and its implications that can be achieved only at close proximity to the formal model itself. 6.3.

Modes B, C

Systems Suppliers

The supplier of a 'secure' system needs to know what security criteria have to be satisfied by any implementation, and what evidence of compliance is required in the presentation of a 'security case'. In the military security domain, the formal security model is crucial to both factors, as it defines the compliance criteria, formally and unambiguously, and it invites formal proof that they have been satisfied by any system that claims to implement the model. Note that such a model does not stand as a 'software requirement specification'; it is expressed at a level of abstraction much higher than that required by a programmer. For example, the formal model need not, and should not, make any reference to any particular class of 'platform' Ñ be it Operating System (e.g. Unix, Windows), Database Management System (e.g. Oracle, Informix) or Network Management System (e.g. Internet, Novell, Lotus).

Although (or perhaps because) the mathematics of formal models is similar to that of

computation, there has been confusion for many years over what qualifies as a 'formal model' of an information system. The 'methodologies' of information systems development have concentrated on the means of representing the client's apparent requirement in forms (entity-relation, object-oriented, etc.) that admit the rapid implementation of software on specific types of platform, but that offer little, if any, analytical power. The result is that the 'models' expressed in these forms cannot be validated other than by executing the code eventually generated on a platform of the appropriate type.


Version 2

ÓB Cohen 1996

12

The recent advent of highly 'integrated' systems, extending over whole corporations, or nations, or even continents, coupled with the increasing demand for 'open' systems, in which the software products of different manufacturers, running on a variety of platforms, can freely, effectively and transparently interoperate, has necessitated a radical review of software engineering practices and methodologies [Cohen]. The classical design approaches ('top-down', 'refinement', etc.) and their corresponding modelling frameworks (dataflow, entity-relation, object-oriented, etc.) may no longer be adequate. The 'interaction model' [Holland] Ñ a composition of the formal models of a domain and a platform Ñ offers an alternative approach to design and verification that might be particularly suitable for expressing safety and security cases. The outstanding problem in many application domains, such as telecommunications [Cameron], is the integration of our 'legacy' of billions of lines of existing code with new services in open systems. Thus, presenting a formal HSP model to information systems suppliers is much harder than it should be. In the short term, the best strategy is likely to be to project the model into forms familiar to them. But even that is fraught with difficulty, since different suppliers have become committed to different modelling frameworks; O-O people will not countenance E-R models, and vice versa. Ultimately, the supplier community will have to face up to its own professional responsibilities and learn to cope with the mathematics. 6.4.

Modes A, B, C

Governmental and Standards Bodies

The pressure for integration and harmonisation of healthcare service and systems has come largely from national and international government, who perceive advantages for the 'health of the nation', for the cost-effectiveness of maintaining it, and for the international competitiveness of suppliers who conform to the 'standards'. As with all technological developments, however, there is a natural political tendency to gloss over technical difficulties that lie in the way of 'progress'. In the presence of technological and intellectual complexity, self-interested lobbying tends to hold sway over informed debate. Somehow, the content and implications of an HSP model, and of models of the whole healthcare enterprise, must be validated and communicated to governments, preferably before being passed to the standards-making bodies. Fortunately, there exist government agencies with the skills and expertise necessary to comprehend and evaluate formal models, although they have not been deployed in the healthcare arena. It is for the national and supranational Departments of Health to seek out and exploit this expertise.


Modes A, D

Version 2

ÓB Cohen 1996

13

Appendix 1: Set Theoretic Operations We have used only the following small number of well known set theoretic operators in this model, although set theory allows for the definition of structures and operators of arbitrary complexity. In the informal definitions below: a, b, c are elements; W, X, Y and Z are sets, R: X « Y, S: X « Z, and T: Z « X are relations. Symbol

Meaning

Example

Interpretation

Î

set membership

a ÎX

predicate: element a is a member of the set X

Ï

non-membership

a ÏX

predicate: element a is not a member of the set X

{_}

singleton set

{a}

set: containing only the element a

Æ

the empty set

´

Cartesian product

set: containing no elements X ´Y

set: of all ordered pairs of elements, the first of which is in X and the second in Y

Í

subset

X ÍY

predicate: every element of X is an element of Y

set (or P)

powerset

set X

set: of all subsets of X

«

relation

X «Y

set: the powerset of the Cartesian product of (i.e. the set of all relations between) X and Y

®

(total) function

X®Y

set: the set of all total functions from X to Y (a subset of X « Y)

dom

domain

dom R

set: all the first elements of the ordered pairs in R (a subset of X if R: X « Y)

cod

codomain

cod R

set: the second elements of the ordered pairs in R (a subset of Y if R: X « Y)

_-1

inverse

R-1

set: all pairs (b,a) such that (a,b) Î R

_ -_

domain restriction

R-W

set: all pairs (a,b) Î R such that a Î W (where W Í X)

_[_]

image

R[X]

set: the second elements of the ordered pairs in R whose first elements are in X

°

composition

R°T

an a Î X for which (b,a) Î T and (a,c) Î R

(of relations) &

join (of relations)

set: all pairs (b,c)Î (Z ´ Y) such that there exists

R&S

set: all triples (a, (b,c))Î (X ´ (Y ´ Z)) such that (a,b) Î R and (a,c) Î S


Version 2

ÓB Cohen 1996

14

Appendix 2: The Calendar Class The Calendar class is defined in order to model the passage and measurement of time. The ÔunitsÕ of time may be construed as intervals, rather than instants. There is no implied granularity; we may be measuring in seconds, days or any other period deemed suitable. CAL now refers to 'today', say.

now: T before, after: T « T past, future: set T before = after-1

before and after are partial order relations, equivalent to £ and ³ respectively on the integers, and mutually inverse.

past ´ {now) Í (before )

past is the set of intervals before (and

future ´ {now) Í (after )

including) now; the future is from now on. The system is initially at day 1.

now' = 1 The passing of a unit of time Ñ the tick of a CAL.tick

'clock'. There is no precondition (the march of

now' = now + 1

Appendix 3:

time is inexorable).

Consistency Proof Obligations

A class definition in the above notation is internally consistent if: (a) There is at least one value for every state component, which are of the same types as the components' declarations, and which collectively satisfy the invariant. If this were not the case, then no object of the class could exist in any valid state. (b) For every event, there is at least one value for each state component and for each parameter, which are of the same types as their declarations, and which collectively satisfy the invariant and the precondition. If this were not the case for some event, then that event would never be enabled in any object of the class. (c) For every event, and for every set of values of the state components and parameters which are of the right type and satisfy the invariant and the event's precondition, there must be at least one value of each of the state components (primed) which are of the right type and which satisfy the invariant and the postcondition. If this were not the case for some event, then it could be enabled but could, on termination, leave the object in an invalid state. If in a given class definition, condition (a) is proved for the 'state space', and conditions (b) and (c) are proved for each event, this constitutes a proof by induction that no sequence of events, starting in a valid initial state, can ever reach an invalid state. [Note that this is a theorem about all the behaviours of the model, even if they are infinite in number!]


Version 2

ÓB Cohen 1996

15

Consistency therefore requires the discharge of exactly 2n+1 proof obligations for every model with n events, all these obligations being well-formed-formulae in the first order predicate calculus that are mechanically derivable from the presentation of the model itself. Obligations (a) and (b) are existential, that is, they require only the demonstration of the existence of values of certain sets that meet certain constraints. Such proofs are discharged merely be exhibiting one suitable collection of values, which is usually a trivial task. Obligation (c) is a universally quantified predicate in first order logic, which requires more sophisticated proof techniques. However, they are well within the capabilities of modern computerbased proof assistants and the proofs themselves are readily mechanically checkable.

References Anderson, R. A. Security in Clinical Information Systems, BMA Jan 1996. NHSE-IMG NHS_wide Networking Service, ref IMG E5216, 1995. Cameron, E. J. and Velthuijsen, H: Feature Interactions in Telecommunications Systems, IEEE Communications Magazine, August 1993. Cohen, B. A Brief History of Formal Methods, FACS Europe, BCS FACS/FME Newsletter, Vol. 1, No. 3, Winter 1994. Cohen, B. The Description and Analysis of Services as Required and Provided by their Agents, http//:www.soi.city.ac.uk/finger/bernie/services.html, 1995 Doyle, P. Every Object is a System, Doyle, Duncannon, New Ross, Co Wexford, 1978 Fetzer J. H. Program Verification: the Very Idea, CACM Vol. 31, No 9, Sep 1988 Holland, J The Requirements Analysis and Design for a Clinical Information System: A Formal Approach, PhD thesis, City Univ., 1995 Lipton R. A., de Millo R. J. and Perlis A. J., Social Processes and Proofs of Theorems and Programs, CACM Vol. 22, No 5, May 1979. Schuman, S. A., Pitt D. H. and Byers P.Object Oriented Process Specification, Univ. of Surrey, 1989.


Version 2

ÓB Cohen 1996

16