national ehr environment - newcastle university€¦ · web viewnational environment for ehr...

National Environment for EHR (deliverable 4.3)

+

NATIONAL ENVIRONMENT FOR EHR (DELIVERABLE 4.3)

Status: Final Version

Author: Mike Martin & Stephen Smith

Issue Date: October 2002

Final Version - October 2002


TABLE OF CONTENTS

SECTION Page

1. Executive Summary..........................................................................................1

2. Architectural Models........................................................................................3

3. Enterprise models: Defining the ‘Problem’......................................................6

4. Solution Models: Framing the ‘Answers’.......................................................12

5. EHR Enterprise Models..................................................................................18

6. EHR Solution Models.....................................................................................36

7. ‘Ownership’ and Governance.........................................................................52

8. Locating the EHR: Options and Issues...........................................................56

Appendix 1: The simulator....................................................................................62



1 EXECUTIVE SUMMARY

2 This document is designed to inform thinking, discussion, decision making and implementation of EHR in the NHS and in, eventually, in aspects of social care. In particular, it defines a national architecture for the delivery of an electronic health record service. It defines two broad areas for development of an architectural approach:

The problem domain, expressed as a set of enterprise models to represent the contexts in which clinical information is generated and interpreted, based on a range of theoretical analysis and observations of practice.

A generic solution, expressed terms of functionality, the way systems resources can be deployed and the technologies required to deliver the service.

3 The architecture and its components are not novel. They build on and correspond to the way information and communications infrastructures have evolved in many sectors in recent years around the world.

4 Furthermore, the architecture is not prescriptive of a particular policy of centralisation or devolution of control. It can be configured to a highly monolithic and centralist approach and, equally, can be configured to a highly distributed and devolved approach. These are political decisions, not technical ones. Hence, the deliverable also sets out the issues and options for a framework for governance of EHR by health and social care organisations.

5 The architecture is the result of examining the ‘big picture’, considering the contexts and environments of health care, rather than taking the narrow view that EHR is simply another clinical application and data service. The approach presented here would represent a radical change in the way the National Health Service conceives of, procures and operates its information and communications infrastructure. It has implications for the way it treats all aspects of communications and transactions in the delivery of care pathways which span different health enterprises.

6 The document is structured in three parts, designed to allow readers and users to start at a point in line with their own knowledge and experience:

Part 1 introduces the idea of an architectural approach to the design and implementation of information systems in a health care context.

Part 2 describes and explains the set of architectural models developed to express the EHR ‘problem’ or need, and the set of models developed as a framework for designing and assessing EHR solutions.

1



Part 3 sets out key concepts and issues of governance concerned with ensuring that EHR can be safely, legally and coherently designed, procured and provided for the user communities concerned.

PART 1: OVERVIEW OF THE ARCHITECTURAL MODELSThe models are presented in a particular order which is based on the logical priority of the concepts they contain, e.g. problem first, solution second. This is not necessarily the best order for understanding and this document is inevitably a difficult on to come to grips with.

The reader should be familiar with the material in the technical animator: this material represents the theoretical underpinning of that material.

2



7 ARCHITECTURAL MODELS

INTRODUCTION8 There are four sources which provide the background and input to the

architectural models which we introduce here:

The aspirations and policies expressed in Information for Health and the associated documents which were the basis for the ERDIP Programme.

The practical experience and needs of the Health Care Community in Durham and Darlington.

Early contacts with the other EHR projects within the ERDIP programme.

Commercial and technical practice in the delivery of information and communications infrastructure and facilities to large organisations

9 All of these confirmed the initial belief that electronic health records, as they were being discussed, were really a consequence of a much deeper set of issues about the nature of health care and how it is delivered by a National Health Service made up of many different organisations with complex and dynamic relationships.

10 This led to the conclusion that EHR cannot be treated as just another clinical record system. Rather, a much more fundamental approach to examining the scope and context of the problem has been needed. The purpose of the first part of this deliverable is to explain is meant by ‘architecture’, and to introduce the various parts of the proposed national architecture for EHR which has emerged.

DEFINING “ARCHITECTURE”11 An architecture is a set of resources - languages, models and definitions -

which allows representation and analysis of a particular problem domain, along with exploration, specification and configuration of a range of possible solutions. The ‘users’ of an architecture will eventually select a specific solution (such as a system or service, or a collection of these) to meet specific needs and conditions. An architecture must allow them to express their assessment of their problems and needs, and to compare proffered solutions against this assessment; it must therefore provide a high degree of flexibility. It is most important to understand that architectures are not designed from scratch but emerge from practice. The problem we face in this attempt to represent an architecture for EHR is that we are must to import aspects of external practice into clinical settings. Commerce is not the same as care and we have had to pay particular attention to identifying the special features of the transactions and relationships of care to validate the redeployment of technologies and systems to meet the new demands being placed on the health service.

3



12 Selection of a specific configuration could be exercised centrally and imposed at a national level, or could be exercised more locally. Whether EHR is introduced locally and federated into an national solution, or is mandated at a national level and based on a centralised approach represent a range of policies which the architecture must accommodate. Many approaches would, in fact, involve a combination of these approaches. Defining a national environment does not mean prejudging such decisions but defines the range of options and the consequences in terms of economies, externalities and the consequent distribution of control and responsibility.

13 The sorts of problem domains to be considered are not static. Health service provision is subject to constant development and reorganisation, and ideas about IM&T support develop in the light of thinking, experience, and solution development. The introduction of EHR is itself an example of such change, and within the short lifetime of the ERDIP EHR Programme there have been several significant NHS reorganisations and reconfigurations. This demonstrates the need for a flexible and highly configurable approach.

WHAT THE ARCHITECTURE CONTAINS14 An architecture comprises a set of models which represent different aspects of

a complex problem. In the following sections of Part 1, each of the models developed in the project is introduced and its purpose explained, covering:

Enterprise models, which are used to explore the nature of the problems presented by EHR through ‘unpacking’ and making explicit the functions, roles, responsibilities, and so on.

Solution models, which are used to define the elements needed to build an EHR, and how they relate to each other.

15 Part 2 then describes how these models have been developed and refined in the specific circumstances of Durham and Darlington.

4



16 ENTERPRISE MODELS: DEFINING THE ‘PROBLEM’

17 Enterprise models aim to explore the problem presented by EHR. This material is complex because it deals with complex problems. The models are an attempt to make explicit issues and concerns that are often assumed to be understood and left implicit. Where changes of the significance of EHR are being proposed, some of these assumptions are called into question and need to be discussed and reappraised. In the first instance, the models were based on an analysis of a wide range of policy documents and discussions of current theory and practice in health care. Through the life of the project they have been tested and refined through the many interactions with interested and informed parties and through their embodiment in more accessible deliverables such as the animator and simulator.

18 The purpose of enterprise models is to raise questions and to clarify meanings – to improve the quality of the discourse between users, managers and designers. They provide new concepts and analogies to discuss some of the issues of EHR, and they provide a means of representing and sharing some of the insights which have emerged in the wide ranging consultations we have undertaken.

19 The enterprise models are now introduced and discussed in turn as follows:

Encyclopaedic models, which serve to define and explain the concepts needed to discuss what a health record is for, along with intentions of its users, covering:

1. Clinical communication and record keeping.2. Contexts of clinical communication.3. Provenance of clinical data.

Structural models of health enterprise and its environment of other health and non health enterprises, covering:

1. Clinical enterprise.2. Transactions between health enterprises.

Infrastructure models: the services which create an information economy and ecology1.

1 An economy because clinical information has value and is transacted in the delivery of care, the management and development of the service and in the development of clinical capabilities and practice. A ecology because, if the conditions are not maintained and appropriate, then the quality of information is compromised and it dies.

5



CLINICAL COMMUNICATION AND RECORD KEEPING20 The first enterprise model is concerned with the nature of clinical

communications. It represents the abstract roles of the generator, interpreter and subject of clinical information, and shows how the duty to maintain a record produces the additional role of custodian.

21 One of the important jobs of this model is to provide an comparison between the primary and secondary health care sectors. The usual configuration of responsibilities in primary care is that GPs reserve to themselves the roles of generator and custodian of records in the context of a continuing, open ended care relationship with the subject. In the acute context, custodianship is devolved to the medical records department, and the care relationship is regarded as episodic and having a clear closure. EHR means that records must be shared between these two domains, as well as with others. Building this model has shown that these different attitudes must be understood and taken into account in any proposed EHR solution.

22 This model also raises the issue of the nature of subjecthood: information generated in the delivery of care to one individual, at a particular point in time, may be of material interest to other individuals either immediately or at some time in the future. This is explored further in the second enterprise model.

CONTEXTS OF CLINICAL COMMUNICATION23 Two sets of issues are represented in the model of clinical communications

contexts:

The subject of a clinical communication is represented in terms of a hierarchy of relationships which span genetic kin, family, contacts, diagnostic group and finally, the population in general. These are the concepts required to justify certain acts of communication of clinical information beyond the immediate context of care delivery.

The nature of the relationship between the generator and interpreter of the information, spanning the following types of communication from a clinician:

1. To another clinician for the purposes of care.2. To clinical management for the purposes of governance.3. To service management for purposes such as accounting and payments.4. To the domains of public health and health service development5. To an academic researcher in the context of non-commercial research.6. To a student in the context of medial education and training.7. To a researcher in the context of commercial research.8. To social services in the context of care coordination.9. To legal authorities in the context of litigation.10. To the civil authorities in the context of policing.11. To non health entities in the context of the provision of infrastructural

and other supporting services.

6



In each of these cases, the basic clinical communication model can be composed with a specific instance of a generator–interpreter relationship. This allows reasoning about the nature of the justification and of the records which are maintained on each side of the conversation.

24 Note that it is not the purpose of these models to represent a solution. Their purpose is to provide a framework for representing and analysing the problem of tracing the responsibilities for clinical information and the justifications for sharing it.

THE PROVENANCE OF CLINICAL DATA25 The third model stems from the observation that clinicians pay particular

attention to the origin and source of any item of clinical information in order to decide how useful and reliable it is to them. This is clearly an important factor in creating a shared electronic health record. The provenance model attempts to identify the factors which could be represented and, in theory, have an impact on the quality of an item of clinical data appearing in a clinical communication or record.

26 This model should not be interpreted as a statement of requirement to maintain all of this information and include it in an EHR service. The information represented in the provenance model appears somewhere in the infrastructure. Some of it may never be recorded, but the wider requirements of governance, planning, assessment and investigation in the delivery of health care require different subsets to be assembled at different times.

CLINICAL ENTERPRISE27 There are two ways of looking at a clinical message:

As a ‘container’ of clinical information.

As the means or instrument of a (clinical) transaction in which responsibility for the delivery of care is created, passed on or shared between clinical enterprises and with clinical support services.

28 Both views are necessary. However, the latter view is the focus of the next models.

29 The first of these is based on a very generic concept of a service provision enterprise which comprises funding, resourcing and delivering responsibilities. The ‘client’ is composed of two roles:

Civil person (or citizen) who has a relationship with the funding role in which the right to and consent for the service is established.

Recipient role (the patient) which is the locus of the rights to benefit from the service.

30 In the case of a health care service, there are two different ways of representing the structure of clinical responsibilities:

7



In terms of diagnosing, prescribing, dispensing and administering, placing the emphasis on the responsibility for process and the concept of a sequence of interdependent stages.

In terms of the responsibility in clinical practice to:

o Gather sufficient relevant information

o Make appropriate assessments and decisions

o Carry out the requisite interventions.

These are seen as ‘co-responsibilities’. They cannot be separated and allocated to different individuals -although they can be delivered by teams -, as it is essential to the clinical role that all three are exercised.

31 These models are not mutually exclusive, since each has a distinct ‘job’ within architectural discourse. In considering accident and emergency services, for example, the second model has proved more expressive of the concerns and issues of clinicians. It also makes the structure and context of medical records explicit and allows clinical and clerical support roles to be represented.

32 Both of the models of clinical process represent the responsibility for informing the civil person for the purposes of consent.

TRANSACTIONS BETWEEN HEALTH ENTERPRISES33 Returning to the more abstract model of health enterprise in terms of funding,

resourcing and delivery, the next model represents transactions between health enterprises. Referrals and discharges, requests for clinical services, and requests for records all fall into this category of clinical transaction. They provide a context for the justification for sharing clinical information in the interests of both patients, clinicians and the service.

34 While the basic model is simple and apparently unproblematic, it must also be capable of representing more complex situations. The project has, for example, used the model to represent the process of ‘disposition’ of a patient admitted to a self damage unit. This complex transaction provides a difficult test case for the evaluation of the completeness of the problem oriented models and the appropriateness of proposed solutions. It raises questions about the interests of the patients and of the different health enterprises.

INFORMATION SERVICE35 The general concept of infrastructure relates to resources that are shared, used

and reused in different contexts. In the enterprise models, there is an additional idea associated with infrastructuralisation, whereby a particular responsibility is devolved by a set of role holders to a third party. One example of this is the comparison of medical record custodianship in acute settings compared with general practice.

8



36 The earlier models have shown that medical records represent a one-to-many communication, distributed over time and space. Information is put into an EHR where it may be read by a number of different individuals at some time in the future. This pattern may be seen as corresponding to an information service based on acts of publication.

37 A patient-based health record will contain elements from a number of different sources. The information service must include responsibility for coordination across these sources, and this function characterises a brokered information service. This concept has been analysed in great detail in other contexts. A model of the information service value chain has been imported and applied to the delivery of an electronic health record service. Since this is an imported model, it raises issues about the appropriateness and detailed mapping of concepts. The most important and informative of these has been to apply the concept of ‘publication’ to EHR.

38 The information service model is based round three provider responsibilities: publication, brokerage and delivery. The first of these faces the sources of information, while the second two face the enquirer and user of information. Each of the responsibilities is decomposed to a more detailed level. This allows consideration of key questions for constructing an EHR service:

What sort of organisation or individual can be entrusted with each of these responsibilities?

Where, both organisationally and physically, will these responsibilities be discharged?

39 The detailed description of the roles and responsibilities of an information service value chain is presented in Part 2. However, some of the more significant conclusions which have been arrived at in applying this model to EHR are as follows.

EHR implies a new responsibility which is added to custodianship. Any holder of a medical record will also have a responsibility for the appropriate publication of content into an EHR domain.

Considerations of individual rights and governance have led to the conclusion that the only acceptable and sustainable basis for this is that the clinician and the patient jointly publish EHR information.

The tripartite structure of the information service value chain indicates a similar structuring in the infrastructural resources required to deliver it. This results in the EHR systems view being divided into publication, portal and gateway systems. This reflects current commercial and technological practice where the Internet has created an environment and infrastructure for e-Business in which markets and communities configure themselves into value chains and networks.

9



ENTERPRISE MODELS: CONCLUSION40 The enterprise models say nothing about the content of EHR. They are

concerned only with defining the contexts in which clinical information is generated and interpreted, and in which clinical communications processes are supported. Clinical vocabulary and record structure models are, of course essential to an EHR, but we have considered them to be outside the scope of this project.

41 Specific data sets must also be agreed, but, in these architectural views, these are seen as a product of a continuing negotiation and re-negotiation process. They evolve in response to clinical and service management requirements. It is therefore a requirement of the architecture that it supports and sustains these management processes, rather than attempting to ‘freeze’ any local, current approach.

42 From a methodological point of view, the enterprise models contain only two sorts of concepts:

Roles, as the locus of responsibility and the nodes of relationships such as doctor-patient.

Instruments, defined as types of information and communicative resource, such as a ‘consent’ or a ‘consultation’, through which roles and relationships are exercised.

43 Both of these ideas are intentional in nature. For example, in some circumstances, a doctor may (appropriately or inappropriately) take the absence of an objection as an implicit instrument of consent. In other cases, a doctor may refuse to accept that a consultation can be conducted, i.e. instrumentalised, over the telephone (or believe that other clinicians or investigators will not accept it as such). Both of these cases compare a real world event, activity or object, and ask whether it represents an acceptable way of instrumentalising a particular aspect of a relationship located in an enterprise model.

44 These models are, necessarily, abstract in nature, because they are trying to be generic in the sense of accommodating all potential instances. In addition, because they attempt to represent things that are usually implicit and taken to be obvious, they can appear abstruse, difficult to understand or unnecessary. In this Part 1, the aim has been to introduce the models and to show that they do essential work within an architectural discourse. They provide a manageable way of exploring important aspects of the ‘big picture’, helping to create a new definition of the space within which EHR can be defined.

10



45 SOLUTION MODELS: FRAMING THE ‘ANSWERS’

INTRODUCTION46 This section introduces three quite different sorts of model, providing a way of

defining a ‘solution space’. This should not be regarded as a high level design, but as a framework within which such designs can be defined and evaluated.

47 There are some general requirements at the architectural level regarding the scalability of the solution. For example, the aim is to consider an EHR with national coverage. Within this constraint, the architecture must be configurable. If it presented a monolithic structure, it could not claim to support a federated national solution, only a centralised one. In contrast, a scalable and federable approach, as presented here, can be configured to a range of different policies from the highly centralised to the highly distributed.

48 Technical architectures are sometimes used as tools to enforce particular organisational structures and conditions. This, however, seldom proves efficient or effective in the short term, and has never been sustained in the long term. The architecture presented here is an attempt to be as ‘policy neutral’ and generic as possible, with the following objectives:

To maximise the configurability of the approach to reflect the wide range of local conditions found in different health care networks and communities.

To maximise the federability of the approach so that different implementations of the EHR infrastructure created at the local or regional levels to meet the needs of care communities and networks are able to interconnect and cooperate effectively. This is not merely a matter of technical or data modelling standards, but one of coordinating working practices and supporting the implementation of care plans and pathways across organisational and care network boundaries.

To identify the minimum centralised components, limiting them to elements of shared resource which are necessary and sufficient for coherence at the national level. Additional resources and capabilities may be placed at the centre in the planning of a national service, but this is understood as an act of policy or of economy, rather than an architectural necessity.

49 There are three sorts of model presented within the solution space: a functional model, a resource model and a technology model. Each of these can be thought of as a ‘projection’ on a system. Each is complete, in that it represents all of the system from a particular perspective,, and each has a particular job to do and set of answers to deliver. In this part of the deliverable we will introduce them, while Part 2 provides detailed descriptions and explanations.

11



THE FUNCTIONAL MODEL50 The functional model is derived from a survey of the projects in the ERDIP

programme. A simple (even simplistic) functional approach is chosen rather than producing an object model, because it remains more easily accessible to a non-technical audience. A box in this model names some functionality – something that has to be done. A line indicates a flow of information. The principle of parsimony in systems design states that a particular sort of efficiency is achieved when information flow is organised so that each part of the system maximises internal information flows and minimises external ones.

51 The functional model is a tool for exploring and comparing the scope of different approaches to EHR. Any EHR project can draw a line on this model and state that it is implementing the functionality within the area indicated (and is not implementing functionality outside the area). If a project identifies an area of functionality which it is implementing which is not represented in this model, this raises a question of scope: should the model, and the functional definition of EHR, be extended, or should the functionality be declared not part of EHR? The model has been subjected to this process in the context of the current projects (both in DuDEHR and elsewhere). It therefore represents an aspect of the state of current thinking about EHR within the ERDIP programme2.

THE SYSTEMS MODEL52 Each function in an EHR must be mapped onto a physical resource – machine

or a person - which will perform it. So, in the first place, the relationship between the functional model and the systems model is one of grouping and mapping. But the relationship is more subtle than that:

The systems have to be procured and operated by some organisation.

The functions correspond to implementations of relationships represented in enterprise models, and the interfaces between the systems correspond to the relationships in the model of the information service value chain.

53 Hence, the first operation is to group the functions in the functional model into the following categories:

Those functions which are by definition external but connected to EHR.

Those functions which are concerned with the handling of information.

Those functions concerned with integration and presentation of information from multiple sources.

2 In the “complete” architecture of a health infrastructure, other areas of functionality can be represented such as the national booking service, the prescription massaging and management service, or a clinical governance service. In the approach to architecture we are presenting here, each of these models would be mapped onto the same resource model and in this sense “integrated”. This differs from the idea that each of these sets of functionality has to be procured individually and then they have to be made to “interwork” – an approach which we would regard as defective and highly failure prone.

12



Those functions concerned with access to and delivery of information.

Those functions concerned with the relationship between EHR communities.

Management functions.

54 The correspondence between publication, portal and gateway systems and the structure of the information service value chain is obvious. The publication systems which provide information to the portal network on behalf of the host systems may be constructed at a number of different levels of aggregation. This could belong to individual trust systems at both primary and secondary levels, or could be provided at an intermediate level (such as a Strategic Health Authority). The important consideration is that these systems do not connect to each other but are connected to EHR source systems and to portals.

55 Portals reflect natural care communities and networks. The physical portal network may be implemented at a number of levels of granularity: sub-regional (e.g. SHA), regional or a centralised national approach. Within this physical network there is likely to be a more fluid and flexible logical network of virtual portals which correspond to a wide range of natural care communities:

Some may be specialty- and condition-based, linking tertiary, secondary and primary communities.

Others may be geographical, spilling over administrative boundaries to reflect the realities of local referral patterns.

There may be networks of virtual EHR portals reflecting interests such as public health and research.

56 The protocols, rules and conventions, referred to as ‘usage control’ and reflecting the agreements and networks of trust within and between these communities of users, will be inscribed at the portal level. The proposed framework of governance and consultation provides the means for appropriate monitoring and management of this network. In particular, it will be at this level that:

Cross organisational audit trails will be maintained.

Information governance will be exercised.

New relationships and protocols in shared and coordinated care will be negotiated and implemented.

13



57 Finally, the gateway network reflects the requirements and responsibilities for custodianship of EHR data, and provides access control. This systems level combines requirements for access to resources which are essentially local, such as the identities of current staff on shift, locums and appointments. At the same time, however, there is a need for gateways to access national resources such as the register of NHS numbers and the search services. This represents a third independent domain of distribution which, as seen in the technology view, may itself be split between local resources and others which are infrastructuralised at regional and national levels.

58 The systems resource view also includes a management domain. This reflects the fact that EHR represents and implements networks of care pathway coordination and cooperation across organisational boundaries. Hence, it will necessarily evolve, with new approaches emerging in response to improving clinical capabilities and practice and to changing political priorities and targets.

THE TECHNOLOGY MODEL59 A technology projection is concerned with representing and analysing the

constraints on implementation and distribution of functionality within an architecture. It is concerned with issues of capacity, performance and dependability – including security.

60 At its first level, the technology projection of EHR provides a framework for positioning the following types of capability within the systems resource model:

Presentation, interaction and mobility/portability.

Information processing, aggregation and analysis.

Data storage and warehousing.

Security.

Communication.

Transaction.

61 Any technology view of a modern information and communications infrastructure must take into account that two forms of integration take place:

Data integration, where data is removed from local applications and placed in a centralised data warehouse, and

Message and transaction integration, where domains which each hold their own data are connected by a structured message and transaction system to achieve integration and maintain coherence at a wider scale.

14



62 Data integration does not scale beyond the boundaries of an enterprise and attempts to exploit it across organisational boundaries corresponds to merging rather than federation or cooperation. The integration it delivers is the integration of internalisation. Applied to a national EHR, a data integration approach would represent an attempt to make the NHS a single enterprise and create a national electronic patient record.

63 Message and transaction integration coordinates between domains while maintaining their separate identities. This represents integration through federation. The EHR technology model shows how domains of data integration are themselves integrated through a message and transaction infrastructure. It shows that the security and communications technologies must be deployed at two levels: (1) the local system and gateway, corresponding to such items as fire walls and encryption engines, and (2) the shared infrastructure level, corresponding to the trusted third party services required for scalable operation.

64 Finally, the technology model indicates that there is a minimum set of information which must be deployed at a national level. The purpose of this is to provide a coherent name and address space for an EHR federation of systems.

CONCLUSION65 The solution models presented here are not particularly novel. They are a

representation of current practice in the provision of information and communications infrastructures in dynamic and unpredictable environments. They represent little more than the definition of a national intranet. There are many examples of such intranets, at different scales and with different levels of connection (and virtuality) to the Internet in public and commercial domains. The roots of this technology are complex, but its current shape is a result of the requirements of commercial sectors to configure and reconfigure themselves and the value chains in which they operate in response to the dynamics of modern economy, technologies and society.

66 If it is to create a national EHR, the NHS has no option but to construct it with the technologies that are on offer shaped in the products that are available. The NHS has the option of recasting these technologies into a range of solutions: it is possible to create highly monolithic and inflexible solutions out of them, and it is also possible to exploit the flexibility and configurability of current products and technologies to create an infrastructure which is much more responsive to needs at local as well as national levels. Perhaps even more importantly, the latter is significantly more responsive to the ever-changing priorities and opportunities for health care delivery.

15



67 This section has tried to show – in theoretical terms – how structures and technologies developed in the commercial world map onto the more complex, multi-valued world of health care, and the particular problems of electronic health records. Other areas of work within the DuDEHR project have attempted to validate this on the ground, and have demonstrated that the architectural approach presented here can be translated into concrete proposals and plans for the governance, procurement and operation of an EHR.

16



PART 2: MODELLING THE ARCHITECTURE OF EHRThis part of the deliverable presents the set of models which have been introduced in part 1. As previously stressed, these models are architectural. They do not define a specific solution but provide the means of configuring a range of solutions according to overall policy.

The models comprise:

EHR enterprise models, covering:

o The purposes and nature of clinical communications.

o The nature of ‘health enterprises’ which provide the context for clinical communications, based on models of healthcare planning, delivery and monitoring.

o The characteristics of an information service to support health enterprises.

EHR solution models, covering:

o The functional view: which defines what an EHR infrastructure does.

o The systems resource view: which identifies the sorts of systems required to deliver EHR and how they can be distributed and interconnected.

o The EHR technology view which represents the options and constraints on the construction and delivery of EHR.

17



68 EHR ENTERPRISE MODELS

Figure 5.1 clinical communication and record keeping.CLINICAL COMMUNICATIONS69 Policies about data protection and the confidentiality of clinical information

are expressed in terms of intentions. It is a principle of governance that clinical information may be used only for purposes for which it was generated. The patient – the subject in relation to clinical information - must have their privacy protected, and any use made of the information should be with their informed consent.

70 Figure 5.1 is an attempt to represent clinical communication. In this style of model:

Roles and responsibilities are represented as boxes. The particular roles indicated are, of course, very generic. A ‘generator’, for example, corresponds to the responsibility for creating and communicating a new item of clinical information, which could be undertaken by the patient themselves or by a clinician.

Relationships between the roles/responsibilities, referred to as ‘conversations’ as they consist in mutual exchanges of information, are represented as lines joining the boxes.

The lozenges represent instruments, the logical resources created and exchanged in the exercise of roles and relationships – the means of embodying and passing on the information.

18



71 These models allow consideration of the nature of the problem, rather than what the solution might be. It allows discussion of these concepts without any commitment as to who the role holders are, how the communication is going to be done in practice, or the media, channels or technologies which will be used to implement the instruments.

72 There are two types of instrument in figure 5.1:

Clinical communications which may ultimately be implemented as such real world objects as a referral letter, a prescription or even a consultation; in these cases some form of decision or action is expected as a result.

Clinical records; the information contained is expected to be interpreted at some time in the future.

73 The act of making a clinical record creates the new role and responsibility of custodian. This is concerned with preserving the record and ensuring that only the intended interpreters are able to access them.

74 Where a clinical communication passes from one health enterprise to another (shown by the grey line in figure 5.1), then the possibility of two sets of records of the same clinical information arises, introducing the concept of an original and a copy. As long as paper is the main technology for implementing instruments, the issue of who holds the original is (thought to be) fairly straightforward. In electronic messaging and storage, things can be more problematic.

75 Figure 5.1 represents the intended purposes of clinical information in terms of the nature of the relationship between the generator and interpreter and between each of them and the patient/subject. This relationship may not be a direct one, however, and exploring the concept of ‘subjecthood’ in the context of clinical information requires closer examination of these contexts of interpretation.

Figure 5.2: the clinical subject in context 19



76 In the interaction between a patient and a health care enterprise, information is generated which is obviously of material interest to the patient (subject) herself. However, other parties may also have an interest in the information and its implications, as Figure 5.2 suggests, at varying levels of connection to the subject:

Blood relatives who share aspects of the patient’s genetic makeup are the closest connections. This relevance may be the basis for a justification of sharing information with third parties. Consent would be discussed in the context of the rights and duties of the subject in relation to her kin, etc.

At the next level, the information may be relevant to the subject’s partner and family because of issues of care and dependency, for example, or to her contacts because of issues of contagion.

At a further level, information may be generated which would benefit fellow sufferers within her diagnostic group.

Finally, the clinical information may have relevance to the subject’s demographic population, and other users of an health service.

77 Figure 5.2 represents conversations between different health enterprises, such as referral, where the purpose of the exchange of clinical information is the co-ordination of care provision. They are thus concerned with the services provided for care of the patient, and information flows are justified on these terms. There are also potential flows of information which are justified in terms of the management of the service rather than the care of the patient. This justification may take one of three forms:

An efficient and effective service is ultimately in the patient’s interest; or

The provision of care may have some commercial third party relationship, e.g. private care under an insurance scheme; or

It supports the management of service delivery at a detailed level, for example, as the basis for payments to the provider under contract with a commissioner of health care services.

78 Policy in such cases is intended to ensure that actual uses of information about a subject are explicit and are judged by the subject as acceptable.

20



Figure 5.3: Contexts for clinical information flows 79 Figure 5.3 is an attempt to represent the possible flow of clinical information

from within a health care delivery context to another type of context. In each of these cases there is a relationship (a conversation) between the generator and the interpreter and a relationship between the interpreter and the subject (in the more general sense that we have described) which justifies the interpretation. These are shown in Figure 5.3 as follows:

The relationship between the generator and subject is almost always that of health care delivery, concerned either with decisions about the provision of healthcare services or with the consequences of those decisions (such as complaints).

Public health and service planning: the use of clinical data in an aggregated and appropriately anonymised form as an input into public health and service planning and evaluation is routine and justified on a similar basis as its use in service management. There is, however, an extra layer of complexity caused by the frequent requirement to track a subject’s clinical history over time, without breaking privacy. Indeed the identity of providers of services to such subjects may also similarly and justifiably be both tracked and protected.

Academic research: this also represents a routine external context for interpreting clinical information and has similar public good justifications. In this context, however, as well as the benefit of the general population, there may be a direct relationship between the research activities and the subject. Well-defined protocols are used in the composition of the doctor-patient conversation and the experimenter–subject conversation. These are often subjected to ethical committee scrutiny.

21



Medical education and clinical training: this case shares many characteristics with the research case. In terms of the enterprise model, two sets of roles and their associated conversations are being composed together and this can create different conflicts and synergies of interest for all the parties. The challenge in the formulation of protocols for permission, supervision and governance is significantly increased when the modalities and media of communication and of record are being changed from concrete and explicit paper-based approaches to more abstracted and ‘virtualised’ implementation of electronic records. Hence, a more rigorous representation of contexts and purposes is needed.

Social care: provides a yet more problematic context for the exchange of sensitive patient information. The clinical and social domains may operate on the basis of possibly different professional principles and concepts of responsibility; for example, clinical governance in the former and best value in the latter. It is widely believed that there are many different sorts of information which could flow between clinical and social service contexts and which would be of material benefit to the patient/client. Recent research3 tends to confirm this, and also indicates that this does not necessarily require the sharing of information which either side considers part of its core and inalienable responsibility. In these emerging service models, information about qualification for services and scheduling of services, for example, may be shared and can be the basis for the construction of co-ordinated care paths without the need for core clinical records or social case notes to be shared. The conclusion emerging from this work is that the exploration of service integration in social and health domains should not initially focus on the issue of exchanging and sharing records but should take a broader view of service, care and client-hood. The contexts and the confidence to begin sharing core data may then grow out of closer co-ordination at other levels.

Legal contexts for the interpretation of clinical information may be initiated from the health care side or from the subject side and arise in several distinct forms:

1. The context is about the care process itself: for example, the subject is suing the health care enterprise in which the record was generated and it is thus part of the evidence. Here there is a conflict of interest between custodian and the interpreter because the outcome may be regarded as detrimental to the health enterprise.

2. The subject is suing a third party (possibly another health enterprise) and the records are used as evidence in the interests of the subject. This raises problems about whether the health care enterprise is independent and neutral, or indeed supportive of the subject in an adversarial process (for example where the third party is part of the medical profession or another organisation in the NHS).

3. The subject of the record is the focus of the legal process. 3

22



4. The health enterprise is the subject of a legal process initiated by a third party and the subject is a ‘fourth party’. Here the records are used by the subject in defence, implying that they must also be revealed to the prosecution. The records are being used in support of the legal process itself, raising difficult issues of jurisdiction and rights.

Civil authority use of medical records for purposes of policing and detection may be construed as an ‘attack intrusion’. This may be justified on the basis of the common good, but this raises issues of civil liberties and human rights. These problems become more acute as the capabilities for executing automated search and surveillance become greater.

Medical research and development, in the commercial domain, is a context where clinical records have commercial value as a research resource. Since the purpose of these interpretations may not be the care of the subject but the business interests of the interpreter, such activities are interpreted as theft if undertaken without informed consent and appropriate compensation.

External parties represent the final, ‘catch-all’ category of interpretation of clinical data. As with medical research, this category locates the possibility of commercial transactions in which medical records figure. In the case of electronic records, selling access or purchasing a custodian service which is separate and possibly independent of the health care enterprise have been proposed.

THE PROVENANCE OF CLINICAL INFORMATION80 Figure 5.4 is a generic representation of the context of generation of an item of

clinical information. Any such context is informed by a set of different sorts of background information, on the basis of which the validity and effectiveness of the information can be evaluated and an assessment made of the quality of the discharge of responsibility in the conversation under consideration. This ‘background’ or ‘contextual’ information is referred to as the provenance of an item of clinical information.

23



Figure 5.4: The provenance of an item of clinical information4

81 Considering Figure 5.4 in more detail, the provenance of an item of clinical information may include such elements as:

The presentations of a patient who is the subject of the information (clinical scenarios).

Data produced by some equipment or clinical service, e.g. a scan or other image, the results of laboratory tests, blood pressure readings or other physiological information.

The qualification and training of the operator of the equipment or performer of the service; the level of experience and the relationship between the operator and the present interpreter may also have a bearing on the latter’s interpretation (e.g. how long a radiologist has been working with a particular radiographer).

The calibration, maintenance and certification of the equipment and the accreditation of its supplier, all of which may have a bearing on the validity and reliability of the information.

The record of clinical information generated in the current encounter.

The clinical history of the subject.

Clinical research and evidence pertaining to the subject and their presenting condition(s) and history.

4 This diagram is an instrumental view; it represents the instruments that are generated and interpreted by role holders. The arrows show the responsibilities for generation and interpretation.

24



Information recording the qualification and appointment of the holder of the generating and interpretation roles.

The clinical and other policies in force at the time of generation.

82 In any particular instance, these instruments:

may or may not exist;

may or may not have been accessible to the ‘generating’ individual;

if available, may or may not actually have been accessed and used.

83 They all may, however, contain evidence regarding the validity and effectiveness of the generated instrument. This itself will become part of the context for subsequent conversations and acts of generation in the clinical encounter, the episode and patient history.

84 In addition, the provenance of an item of clinical information may include not only the above elements, concerned with the immediate contexts in which the item is generated. It may also include previous interpretations of the item or its significance by other professionals.

THE NATURE OF HEALTH ENTERPRISE85 The next stage in the problem modelling process involves looking inside the

health enterprise and analysing the structure of responsibilities of health care delivery. This is the doctor-patient conversation and models clinical practice.

86 Two models of clinical roles have been developed. The first represents responsibilities for clinical processes. This model proved useful and acceptable in some discussions, but also generated a level of dissatisfaction that it does not express certain important aspects of clinical practice. Exploring this dissatisfaction further resulted in a second model.

Clinical Practice: Model 187 The context of clinical encounters can be analysed, for example, in terms of

the responsibilities of a presenting patient and a diagnosing clinician and between the clinical roles of diagnosing and prescribing, prescribing and dispensing and dispensing and administering. This formulation presents the units of success and failure of a clinical encounter and locates the contexts in which medical information is generated and interpreted. (At this stage no account is taken of the differences between an intervention such as surgery, the use of therapies delivered by a practitioner and the use of medication which become important at a more detailed level of distinction between primary, secondary, tertiary and community services.) The health care delivery conversations are represented in Figure 5.5.

25



Figure 5.5: clinical responsibilities - model 188 Each of these ‘conversations’ should be conducted under a principle of

informed consent, so each is composed with a counsellor-client relationship. Each of the relationships represented in a prescriptive account such as this may be mapped onto different professional roles and organisational units in different contexts. This model moves away from the generic concept of clinical information to more explicitly distinguished concepts such as presentations, diagnoses and prescriptions on the basis of the specific conversation being instrumentalised.

89 Where these roles are composed together on to a single individual, for example where a general practitioner is a diagnosing and prescribing agent, the conversation may not be instrumentalised at all – it takes place in the clinician’s head. Because there is an explicit communication (currently invariably a written or printed script) between the practitioner and the pharmacist or dispenser, the prescription is always instrumentalised.

Clinical Practice: Model 290 This model needs a concept of responsibilities which are conceptually distinct

but which, by their nature, cannot be allocated to different individuals or mapped onto distinct action. Thus, it is taken to be constitutive of the role of a clinician that sufficient, relevant information must be gathered, that appropriate evaluations are made and that requisite interventions are delivered. Any particular activity undertaken by the clinician can be justified as relating to one or more of these responsibilities5.

91 In addition to the core responsibilities there are also responsibilities to inform the patient for the purposes of consent, and to record all the relevant information generated in the clinical process.

5 Administering a GTN spray is an intervention and is diagnostic: if the pain is alleviated then an evaluation indicating angina is appropriate.

26



92 Because the actual activities of a clinical encounter vary so widely and are so complex, clinicians are, in general, unhappy with the idea that they can be formularised into a process definition. Thus, the role is represented in terms of co-responsibilities which interact constantly rather than proceed sequentially as was the case in the last model. Figure 5.6 illustrates this.

Figure 5.6: Clinical responsibilities - model 293 Setting this model of clinical responsibility into a context introduces the

following external roles:

Patient who is the subject of the clinical care and the initiating agent who is responsible for establishing the need for a clinical encounter in the first place.

The accepting carer indicates the fact that clinical responsibilities, in this model, exhibit closure. This is clearly the case in accident and emergency at one extreme but is less clear in the case of primary care.

94 While this model asserts that the co-responsibilities of the clinician are not amenable to formalisation, there are aspects of care that can be rationalised and specified. These can be allocated to third parties, such as nurses, creating clinical support roles. Similarly, aspects of the recording responsibilities can be allocated to clerical support roles. These allocations are the responsibility of the clinical facilities provider.

95 Finally, the clinical encounter is part of a service relationship which implies evaluation. All of the parties share in this responsibility as well as independent clinical governance agents.

27



STRUCTURE AND INFRASTRUCTURE 96 The views of the problem which have been presented so far are structural as

opposed to infrastructural: that is, concerned with the specific information associated with specific encounters. When a relationship and the associated resources are ‘infrastructuralised’, it is ‘outsourced’: entrusted to a third party, mapped onto shared resources, with adoption of standard policies and procedures (which may be automated or ‘mechanised’) for handling the instruments.

97 An example is the handling of clinical records, referred to earlier. There may be a different attitude to the ‘infrastructuralisation’ of custodianship in primary and secondary care. In general practice, a GP will see him or herself as the custodian of the records created in consultations. In the hospital setting, clinicians may seem more ready to devolve responsibility for records to ‘the organisation’ (typically the NHS trust), or to administrative staff in the records department, with ultimate responsibility vested in the head of IM&T and the Caldicott guardian. These two possible configurations of responsibility – the latter showing a higher degree of ‘infrastructuralisation’ than the former’ - are depicted in Figure 5.7.

Figure 5.7: Two views of custodianship98 Clearly, the concept of an EHR implies a shared service ‘infrastructure’ of

some sort. If these differences of attitude between primary and secondary clinicians are real, a higher level of acceptance of the concept can be expected among secondary care circles than in primary care.

28



INFORMATION SERVICES99 ‘Infrastructuralising’ the relationships and resources deployed in health and

social care contexts means, in effect, designing a ‘service’ that can be provided to various users. Specifically, the concept of an ‘information service’ is being developed. This information service can be modelled in terms of a value chain, i.e. a set of roles and relationships which work together to create and deliver a service, each element with its distinctive contribution or ‘value’ to add for the benefit of users. Figure 5.8 shows an overview of an information service, broken down into the components that make up the ‘information value chain’.

Figure 5.8: the basic information service value chain100 The information service value chain is represented at the highest level by a

threefold division of value-adding which correspond to publishing, information broking and information delivery. Outside the chain, but interacting with it, are ‘informing agents’; in the health and social care context these are the ‘generators’ of clinical information. They have the requirement or obligation to inform and the duty to record.

101 In a clinical information service, a clinician is, first an inquirer, seeking to find information, then a user of that information in the process of generating new information. This generation makes the user an informing agent to future users because the clinical information which is generated is incorporated in the records.

102 One of the objectives of these models of information services is to illustrate the range of possible configurations of basic roles by abstracting away from the boundaries and structure of specific types of enterprise. They thus attempt to ‘unbundle’ value-adding relationships in information service provision. This enables us to propose a flexible representation of relationships, which should be resilient in the face of perpetual changes in organisational structure.

29



103 This is important in exploring the possible configurations of the EHR service. The allocation of roles between the health enterprise itself and the infrastructural service provider(s) represents a key set of decisions. It must be clear who is doing what, for what purposes, and what is being provided or ‘added’.

Informing Agents104 Informing agency is associated with the requirements, rights and duties to

provide information. An agency named ‘subject’ is represented in this part of the model as the locus of the rights to privacy and good name6 which apply in a regulated information economy particularly one of health care.

Information Using Roles105 The information user is represented as three component roles which

correspond to three epochs or phases of information service usage (shown in Figure 5.9):

1. The enquiring agent has some information need which is matched to a current offer in the conversation with the information broking enterprise.

2. The information user accesses and acquires information through the conversation with the information service provider.

3. Finally, the utility and effectiveness of the information may be communicated back to the information broker by the evaluating agent.

Figure 5.9: Publishing roles

6 This refers to ‘good name’ as used in the legal sense, that is, concerned with the public reputation and standing of a subject.

30



106 While these are usually combined into a single person or enterprise, they are distinct roles. The following paragraphs consider the three different groupings of responsibility within the information service value chain.

Information Publishing Roles107 Four roles are the components of information publishing enterprise:

Publishing agent.

Authoring agent.

Designing agent.

Editorial agent.

108 The publishing agent is the locus of responsibility for the content that is published and for the intended and actual benefit or harm that is caused by its interpretation and use. The units of publication may vary from an individual data item in a database service to a complete work corresponding to an article or book. This, and the other responsibilities in publishing enterprise, are presented here at a completely generic level. They generate questions about haw and whether the concept of publication applies to clinical records.

109 The publishing agent interacts with the other three roles, which are usually considered as part of a publishing enterprise. It is worth noting that the most usual context for these roles has corresponded to paper based publishing. However, the underlying division of responsibility is independent of medium. The outcome of the conversation between the informing agent and the publishing agent is a publishing brief.

110 The authoring agent is concerned with generating and assembling content to meet the communications objective in the publication brief. This takes the form of copy. In some cases the informing agent may generate the copy.

111 The designing agent is concerned with the organisation and presentation of the copy into a draft in a way that will meet the intended information users’ needs.

112 The editorial agent is responsible for the formal aspects of the draft and applies sets of editorial rules which have been defined by the publishing enterprise. The scope of editorial responsibility may extend to ensuring that new material is coherent and compatible with other sources and policies.

31



The application of these external concepts of responsibility to EHR and to clinical practice may, at first sight, seem problematic. However, our experience within the projects demonstrates that they are highly relevant. EHR screens are “designed”, for example, and their design can have a material impact on their acceptability, utility and safety. The creation of an EHR infrastructure produces an environment where, within the limitations of consent and ethics, value can be added to and extracted from clinical information for the benefit of the patient, the population and the service. These are the concepts required to understand and shape such an information economy and ecology.

Information Broking Roles113 Figure 5.10 decomposes the information broking roles in the value chain.

Figure 5.10. Information broking roles

114 In the context of EHR, an information broking enterprise will usually serve many publishing enterprises (i.e. health enterprises which generate and keep records). The first stage in the conversation between a publishing enterprise and an information broking enterprise is the submission of information for registration.

115 Registering agency exercises the following responsibilities:

Assessment of the registrability of the submitted information. Each broking domain will have a set of criteria of eligibility and relevance of information for the client/user groups served.

32



Registration (i.e. acquisition and reliable storage) of data to support access and delivery transactions on accepted information. This includes the record of ownership and conditions of use. In some circumstances, the register may be a set of pointers to information located elsewhere.

One of the consequences of the work we have undertaken in the area of governance indicates that these responsibilities must be exercised by the stake holders through the process of defining and negotiating the multi-disciplinary and multi-agency care pathways within which they will agree to operate.

116 In the strict definition, a register provides the information resources required by the transaction managing agent but does not contain information to support searching or discovery. The organisation of register entries and the provision of supporting resources is the responsibility of the classifying agent. This value may be delivered via three different means:

1. Organisation and provision of key word and content search mechanisms.

2. Provision of classification and categorisation schemes.

3. Labelling, linking and ordering (the most obvious one being the EHR).

117 In each case, there may be multiple schemas implemented over the same register of information offers, and of content, to meet the needs of different user groups.

118 The advertising agent is responsible for publicising information services and is taken to be acting on behalf of the publisher and informing agents. This information is distinct from content and from independent evaluations of the provenance, relevance and value of information. This is the responsibility of accrediting agents.

119 The interactions between the publishing agent and the registering, classifying, advertising and accrediting agents results in an update of a catalogue which here takes on a very wide meaning. We consider it to correspond to any resources provided in an information service environment to assist the user to satisfy an information need by searching or discovering and selecting an appropriate source. Whatever forms the catalogue takes, responsibility for the information embodied in it can be ascribed to one or other of the agents we have identified so far in the information broking enterprise.

120 When an enquiring agent has located a source and an item of information within a catalogue environment, a transition takes place from what we term the rendezvous phase to the transaction phase of information service. The enquiring agent becomes a user and the corresponding agent in the information broking environment is the transaction management agent. The responsibilities of this agent are:

1. To check that all the preconditions for the information transaction are met.

33



2. To record the instance of usage. This may include noting the appropriate access to an investigation result (with implicit transfer of responsibility that this implies) and will often also include the capture of information required for management purposes and to resolve any post-transaction enquiry (e.g. a complaint or valuation).

3. To provide or mediate access capability between the user and the information service enterprise.

Service Delivery Roles121 Figure 5.11 decomposes the service delivery roles in the value chain.

Figure 5.11: Service delivery.122 The access controlling agent is responsible for ensuring that only users with

the appropriate rights and consents access information appropriate to them.

123 The medium handling agent is responsible for the organisation and holding of information for the purposes of delivery to the user. This includes the configuration and management of information servers in the case of network based services and would correspond to stock holding of copies in the case of physical media. In both cases, there is a responsibility to ensure sufficient capacity to meet expected demand.

124 The delivery agent is responsible for the timely and appropriate delivery of requested content (and media) to the designated user. In the case of electronic information services, this agency is usually split into communications access provision and data transport provision.

34



125 The presentation agent is responsible for rendering the delivered information in a way that conforms to the presentation conventions of the information environment. Note that the presentation agent is indicated as distributed between the service delivery enterprise and the user enterprise which corresponds, for example, to the ownership and configuration of a browser by the user.

CONCLUSIONS126 As stated in the introduction, the models have been the subject of a process of

refinement, extension and validation through interaction with policy makers and stakeholders. The conventions under which they have been constructed and the conceptual formalisms that underlie them are part of a projection oriented approach to describing complex socio-technical systems. They represent enterprise and instrumental projections.

127 The following section explores functional, resource and technology distribution projections of what is intended as a comprehensive architecture for the communication and recording of clinical information. The concept of an Electronic Health Record must be positioned within this architectural framework.

128 This is not to say that EHR corresponds to the whole architecture. Rather, it is a claim that EHR is a consequence of developing and deploying and architecture such as this. It is also important to recognise that the architectural approach presented here represents a blueprint for a technical and organisational strategy within which short term, pragmatic developments can be positioned and justified in terms of a long-term strategy.

35



129 EHR SOLUTION MODELS

INTRODUCTION130 This section describes the range of configurations that could be adopted in the

creation of an EHR service. The form that such configurations take depends upon three sets of factors:

The selection and grouping of the functions which are implemented and the way they are distributed onto real systems.

The ownership of these systems by health service actors and the consequent allocation of responsibility for, and control of, the service.

The technological constraints which must be accounted for if the capacity and performance requirements of the service are to be met.

DEFINING EHR IMPLEMENTATION OPTIONS131 This project aims to produce a set of architectural pictures of EHR with the

following properties:

That they represent the generic solution so the range of possible national approaches can be explored and evaluated

That they must help to position the EHR in the wider context of clinical information and messaging services, booking and health service planning and management systems. They must show the boundary and relationship between EHR and the wider set of NHS and other agency systems and infrastructure.

That they must indicate the range of possible evolution paths for EHR and, in particular, show the extent to which different approaches to EHR could interwork and evolve into national solutions.

132 A number of ‘pictures’ are needed to represent different aspects of the architecture. This section considers three ‘systems orientated’ views.

133 The first identifies the functions that are required to deliver an EHR service. In words, this description takes the form of a set of assertions such as: “The EHR system must be able to identify users and verify the rôles they claim.” In pictures, a functional model represents functions as boxes and information flows between functions as lines joining them. This model defines what an EHR system does.

36



134 The second picture identifies the physical resources – sorts of computers and communications services – that deliver EHR functions. The importance of this representation is that it can be used to show who owns what resources, and who is responsible for delivering which of the EHR functions. (EHR may be delivered by a complex chain of NHS and infrastructural service providers. One of the factors which distinguishes different approaches is the assumptions made regarding the configuration of this value chain or mesh).

135 The third projection which, in a final, fully developed architecture, would include a great deal of technical detail, is the technology model.

136 At this stage, it is important to keep functional and resource distribution models distinct, even though the pilot projects quite appropriately mix functional and resource concepts into rich pictures to serve their local purposes. The reason to keep them distinct in this exercise is the need to be clear and rigorous about comparing and contrasting proposed solutions. Two sorts of questions need to be considered:

Which functionality is implemented in a proposed solution and which is not?

What are the assumptions about the distribution of responsibilities and control which are implied by a proposed solution?

SORTS OF INFORMATION IN AN EHR137 Before considering the functions, it is useful to categorise the different sorts of

information which may be considered to be part of an EHR service. This is not considered from the data modelling point of view – this is a big question which must be dealt with in a different sort of model from the ones considered here. Information is being considered in relation to the responsibilities associated with acquiring, maintaining and distributing or using it.

Information Model138 Five classes of information have been identified which may be relevant to a

proposed EHR implementation:

1. Demographic information which is the basis for the identification of a patient as well as being significant in aggregation processes for both epidemiological as well as service planning purposes.

2. Original clinical information; the data in the EHR service system is the master or may be the only instance of this clinical data about a patient.

3. Mirrored clinical information; the data in the EHR service system is a copy of data held in an external clinical system and is maintained by an automatic updating service.

4. Pointers and URLs which provide links to clinical data which is accessible to the EHR service system from external systems.

37



5. Archival information which is no longer significant in its original clinical context but which is maintained for possible future use.

139 Proposed EHR solutions take different views about which of these sorts of data are regarded as internal and which are regarded as external and may include combinations of several different types. For example, demographic data may be considered to be part of a national index and external to an EHR. Alternatively, a regional EHR solution may maintain its own demographics which are supplemented and cross checked with other indices at national level.

140 The information classes considered so far are primary in the sense that they contain or point to EHR content. Three other classes of information have been identified which are relevant to the service:

EHR register data: There are three registers required to inform access control functions; the register of patients, the register of users and the register of systems and channels through which EHR may be accessed.

EHR access rules: In any proposed EHR implementation, this information may be implicit or explicit, ‘hard wired’ or the subject of continuing redefinition, negotiation and management.

Provenance information: This is ‘meta-data’, i.e. data about data. In EHR it includes any information which records the context, purpose and antecedents of an item of data. This may take the form of a link to a particular step in a care path, a reference to a national service framework or a link to a particular piece of clinical evidence which was consulted at the time of generation of the item.

141 This categorisation may well evolve as exploration of the different aspects of EHR proceeds in the NHS.

38



EHR CORE FUNCTIONS

Figure 6.1: EHR Functions142 Figure 6.1 shows a functional reference model, covering the following:

1: Operational functions1.1: Data acquisition and publication functions

1.1.1: Updating Functions1.1.2: Data mirroring Functions,1.1.3: Notification functions1.1.4: Data repository functions

1.2: Portal functions1.2.1: Data integration Functions1.2.2: Data presentation functions1.1.3: Usage control Functions1.1.4: Usage auditing functions

1.3: Access control functions1.3.1: Patient identity verification functions1.3.2: User identity verification functions1.3.3: System and channel verification functions

2: Management functions2.1: Data management functions

2.2: Workflow management functions2.3: Register management functions

3: EHR federation support functions3.1: External data provision functions3.2: External data acquisition functions

4: Universal functions4.1: National naming and location service4.2: National infrastructural services

39



143 These are discussed in the following paragraphs.

Operational Functions144 It is assumed that there are existing systems which contain live, changing

clinical information about patients and which support the exchange of clinical messages and the execution of transactions between care delivering organisations, for instance practices, hospitals, community services. These existing systems (patient record systems, primary care records, social care records together with messaging systems to support referral, prescription, and bookings, etc) were not and are not being designed to support secure external access from an EHR service or to generate data and notifications to populate and maintain such a service. These systems are not considered to be within the EHR system but to be connected to it. The first EHR functionality is, therefore:

[1.1] Data acquisition and publication functions are concerned with the acquisition, maintenance and organisation of agreed sets of clinical information for external access by EHR users.

There are three sorts of relationships possible between an EHR system and the external systems which are the sources of the information it contains. They implement different distributions of responsibility for EHR data between the EHR system itself and the system in which the data originates.

[1.1.1] Update functions assume that the information in the EHR is the master copy and that the external system is originating or issuing an update. This function will normally be implemented as push, where the process is initiated by the external system.

[1.1.2] Mirroring functions may be push or pull but here the master copy of the information is regarded as being in the external system and the EHR is holding a copy. The quality of the mirroring service defines how up to date information is.

[1.1.3] Notification functions respond to messages from external systems which indicate that certain events have taken place. These are interpreted in the EHR system and the data content or access permissions are modified accordingly. An example would be a notification of the issue of a referral from a primary to a secondary context. This could result in the granting of access rights to certain patient data to an appropriate clinician in the secondary unit.

[1.1.4] Data repository functions combine the results of these three sources; these functions correspond to the delivery of database capabilities for the information which is maintained within EHR.

145 The external data functions raise a number of issues of the following type:

Can patients have multiple EHR in different domains or even within a single one? (see below for the definition of an EHR domain.)

40



What is the scope of the agreement on standard demographics, national, local, sectoral? Can there be universal core demographic data and local variant data?

What is the mechanism for registration of new data and links and how is this mechanism assessed for timeliness, accuracy, relevance and patient consent. (Mirroring and notification services.)

[1.2] EHR Portal functions deliver an information service which assembles and presents clinical data sets about particular patients, or classes of patients, to support defined clinical and other contexts and processes. (Data may be individual or may be aggregated, identified or anonymised depending on the type of use.)

[1.2.1] Data integration functions combine data from within the EHR with data from external sources and demographic data.

[1.2.2] Presentation functions select and represent EHR information in ways that are appropriate for the class of use and for the channels of access.

[1.2.3] Usage control functions maintain and apply a set of rules about who (identity + role/accreditation + relationship with subject) can access what data for what purpose via which channels. (This implies that the EHR system has clinical workflows and care paths explicitly inscribed within it.)

[1.2.4] Usage auditing functions maintain an audit trail of who has accessed what data for what claimed purpose.

[1.3] Access control functions represent the gateway and sentry mechanisms which check claims against registers

[1.3.1] Patient identity verification functions make use of demographic data which may in internal, external or both, to verify the identity of a patient and to check their status with respect to the care paths that they are currently engaged in.

[1.3.2] User identity verification functions uses registers of practitioners and appointments to check the identities of users of EHR and their relationship with the patient.

[1.3.3] System and channel verification functions. A third level of gate keeping is concerned with the verification of the points of access to EHR.

Management Functions[2.1] Data management functions support the redefinition and re-negotiation of EHR datasets and the means by which EHR content and pointers are maintained.

[2.2] Workflow management functions support the redefinition the rules for access to EHR and also of the workflows and usage contexts.

41



[2.3] Register management functions support the processes of registration and de-registration patients, users and access channels.

EHR Federation Support Functions146 The above functionality applies to a particular population of patients usually,

but not necessarily, defined in geographical terms: such a population is termed an EHR domain. Each EHR domain is required to interwork with other, peer domains by means of the following functions:

[3.1] External data provision functions provide clinical information in response to requests originating from external EHR domains.

[3.2] External data acquisition functions issue requests in response to local queries requiring remote data.

147 There is a major issue of trust in the federation of EHR domains, concerning whether the credentials of external requests are to be accepted by the receiving domain and, if not, they how can be verified remotely. These functions imply agreements between domains regarding the rules of access and use.

EHR Universal Functions148 Since the EHR, at the level of the national NHS, is a federation of EHR

domains, there are certain functions which must be logically centralised and universal. These are:

[4.1] National naming and locating services provide a naming and locating service which ensures that entities have a single, unique name. This service must span;

Systems.

Patients.

Users and their roles.

[4.2] National infrastructural functions provide a common communications, messaging and transaction platform. (This is the NHS and public service intra/internet)

42



SORTS OF SYSTEMS149 This sub-section identifies a small set of system types, defined in terms of the

sorts of functions they deliver and the way they can be replicated and distributed within an EHR domain and within the EHR federation. The terminology seeks to be as neutral as possible, drawn from the Durham architecture model (not the implementation model):

Access systems and channels.

Gateway systems.

EHR portal systems.

EHR content systems.

Message notification systems.

Registration systems.

Workflow negotiation and audit systems.

150 Figure 6.2 represents these system types and the relationships between them

Figure 6.2: EHR Resource Model

Access Systems and Channels 151 These are the resources which users have to access EHR services and include:

43



Browsers on the public Internet.

Clinical systems on NHSnet in primary and secondary care.

Research networks.

Service planning and management networks.

Intranets within secured environments, e.g. NHS-direct call centres.

Mobile networks supporting paramedical, emergency and community services.

EHR Gateway Systems152 These are systems which deliver EHR security functions. They verify claimed

identities and rôles and identify the accessing system and channel. To be able to deliver this function, they must have access to three sorts of registration information:

The patient register - to identify the subject of the EHR request.

The user register - this includes the clinical register which links accredited practitioners and carers to their current roles and institutions.

The EHR systems register.

EHR Portal Systems 153 These systems contain clinical information integration functions. It is at this

level that multiple source data is assembled and combined into presentations for specific types of users in EHR requests.

154 The portals may rely on the fact that the identities and purposes claimed by users may be believed. The responsibility for ensuring that the requested access and use is allowed is located within the portal. Thus, the portal may receive a request from Mr. J (consultant at hospital H), treating patient Y in the context of a referral from Dr. Z. Since this request has come via a recognised EHR gateway, these claimed identities and rôles will be accepted. A rule that mental health notes and family circumstances will not be routinely included in the consultants view, and would require an explicit request to the GP and the patient for them to be included, would be held and implemented at the portal level because it is directly concerned with the selection and presentation of data.

155 It is important to note that there may be several different types of portal distributed within several different sorts of network. For example, there could be a network of specialised emergency care portals, specific patient access portals and research portals, as well as those dedicated to care delivery.

156 There are two different sorts of design principle at work here:

44



Firstly, if the rules were held and actioned at the gateway level, there would be a higher level of information flow required between them and the portals, because the portal would need to be informed exactly which information is to be included in each request. This is the principle of minimising information flows (parsimonious design).

Secondly, the division and allocation of responsibilities. Determining whether a request for EHR access is allowed by the rules is different from determining whether the request is from the individual who claims to be making it. They require different sorts of techniques and technologies to implement and, therefore, may – perhaps should – be segregated and handled separately. When things go wrong, unique points of failure can be located.

EHR Content Systems 157 These systems are the repositories of clinical data for the EHR. Given legacy

issues, and the fact that EHR must be introduced into a live environment, the EHR information systems fall into two categories:

EHR clinical content servers which contain core demographic data, locally held clinical data, ‘mirrored’ data from external systems, and pointers to external data in other EHR domains. The EHR service is considered to be the custodian responsible for holding this data.

External systems which host ‘EHR-accessible’ clinical content. These systems may also serve as patient records systems for their ‘home’ healthcare institution. This data may be accessible through the EHR service, but its custodian is considered to be the owner and operator of the external system.

158 Initial implementations of EHR will have few, if any, external content systems on-line: such systems do not yet exist. However, in the future, it is likely that hospital and primary care records systems will evolve to provide external access to the EHR network. The EHR may be seen as evolving from existing patient record and messaging systems, and reflecting new ways of managing information and communications, rather than as a new, additional system and service.

Registration Systems 159 These systems maintain the registers of clinicians, patients and access systems

and channels for one or more gateways. This is how the ‘access rights’ of a clinician or other user are established and verified.

45



Workflow Negotiation And Audit Systems 160 These provide the current set of access and transaction rules for one or more

portals. The term ‘workflow’ refers to a means of representing and supporting, or enforcing, a set of procedural rules regarding transactions and information flows. Thus, a care pathway or a national service framework could be represented, in computational terms, as a workflow. This implies that it will have embedded in it information about rôles and purposes as well as processes and events. It is clear that the realities of clinical practice and the aspirations for ‘joined-up’ service delivery imply the need for a particularly powerful workflow language which is able to handle exceptions and accommodate breakdown. It is in this area that the concepts and requirements of EHR are most challenging to the state of the art in distributed information systems engineering.

Distribution And Federation161 Each of the core functions defined for the EHR has an appropriate home in

one or other of the types of EHR component systems. These systems may be configured in a number of different ways. For example:

A highly centralised approach would bring the information system, the portal and the gateway into a single unit which would deliver all the required functionality within an EHR domain or context of use.

Alternatively, there could be gateway systems for each of several hospitals and PCTs, with a single logical portal, providing a regional service which is in fact triplicated for resilience and capacity management purposes.

162 Either of these implementations would make use of national naming and identification services.

163 An extreme form of distribution of EHR data might involve the use of patient held media, such as data-cards, providing mirrored as well as master data. Clearly, such an approach could not be applied universally: there are many classes of patient who could not be relied upon to take responsibility for custodianship of their data. However, one purpose of taking a more abstract architectural approach is to explore the extent to which different approaches could co-exist and interwork to meet a wide range of needs and levels of patient participation.

164 One reason for proposing the structuring of systems resources into content, portal, gateway and access is that each type of EHR system represents a potentially independent domain of distribution within EHR domains, and also provides the structuring of the interfaces between domains for the provision of a scalable federated service. Thus, EHR content and notification systems are connected only to portals. (Concepts such as an ‘EHR standard API’ signify the means by which data is acquired from existing information and messaging systems and services and placed within an EHR information system.)

46



165 The distribution of portals and the way they interwork may vary in response to a number of different factors. Where patient data is distributed among different EHR domains, the portals will contain the functionality to locate and integrate it on demand. There may be distinct portals dedicated to certain contexts of use: for example, emergency portals may be distinct from those which support routine care, while epidemiology portals provide a specialised front end to data aggregation functions. Whether these portals are merely logically distinct or represent separate systems depends on a range of clinical, technical and organisational factors. It is a requirement of an architectural approach that the EHR environment is configurable to meet these different needs, which will themselves evolve in the context of a national service.

166 Gateways connect to each other and may be distributed to ensure that claimed identities are checked and that access control responsibilities are exercised as close to the points of access as possible.

167 Any attempt to connect a highly centralised implementation to a more distributed one would require an interface reflecting the distinction between portal functionality and gateway functionality. The architectural model does not imply one way of doing things, but allows a wide range of distribution policies to suit local conditions.

Simulating the Resource Model: See Appendix 1EHR TECHNOLOGY MODELAn Outline Technology Projection For EHR168 The technology projection comprises a number of quite conventional

constructs. The base component is an application, implying an association of interactional, computational and data management resources dedicated to a purpose. An application may be distributed in a number of ways: it may be mapped onto a set of local or remote resources.

169 An enterprise contains a number of distinct applications, and these may be jointly distributed in a number of ways. Assuming that these applications share and exchange data, there are two extremes of integration possible:

1. The data centred approach where all the data management resources are pooled into a data warehouse and the individual computational and interactional resources are local to their users.

2. The message exchange approach where each application maintains its own data and sharing is a result of message passing and transactions through a common message hub.

170 These two approaches are represented in Figure 6.3.

47



Figure 6.3: Two approaches to integrating applications171 These positions are, of course, based entirely on the technological options

available. In the past, technological limitations have been the major determining factors in selecting an approach. The storage capacities and bandwidths now available mean that choices are based more on enterprise and political issues such as the ‘ownership’ and control of data.

172 Real systems often exhibit a hybrid distribution, relying on elements of database integration along with elements of common message and transaction management. They are further complicated by the fact that the data warehousing and the message/transaction management systems can themselves be logical rather than physical, and may be replicated and distributed to meet independent systems objectives such as performance, resilience or survivability.

173 This is illustrated in Figure 6.4, where several of the applications integrated through the common messaging and transaction services could themselves be data warehoused enterprise systems. It is not a question of choosing a single configuration, but of meeting a range of local information governance, management, performance and cost requirements which may vary among the enterprises which are co-ordinating their activities across networks.

48



mobi

le

I nf rastructuralised security technologies.

Common distributed messaging and transaction inf rastructure.

Local and national systems and applications integrated through data warehousing.

Locally deployed security technologies.

National services and data repositories.

fi xed terminalsimage

PDA

voice

wearable Human – computer interaction technologies

Figure 6.4: Framework for the technology projection of the EHR architecture

Deploying Security Technologies174 At this stage, the security technologies are represented simply as an element

which sits between the user technologies and the data managing technologies:

In the case of the data oriented integration, it corresponds to access control to the warehouse.

In the case of the message and transaction oriented system, it represents a mechanism which is interposed between each data holding domain and the shared message and transaction domain.

175 In each case, the security technologies are seen as encapsulating and protecting the data repositories. However, the second case generates some specific requirements if the economies and externalities of this approach are to be realised.

176 Clearly, if each of the applications has to maintain its own rules and mechanisms for exchanges with any other application that it might need to interact with, there is scope for considerable incoherence and inertia as well as combinatorial and performance problems. On the other hand, if all of these rules and mechanisms are ‘infrastructuralised’ in the message and transaction system, there is considerable loss of autonomy and local control, necessarily changing the local responsibilities for custodianship.

49



177 Thus, from a logical point of view, the security architecture is concerned with the balance between local capabilities and shared capabilities. This corresponds to the options for sharing of custodianship responsibilities. These translate into a distribution policy represented in figure 6.4.

178 Any actual implementation of EHR (including that in Durham) must extend and detail the technology projection of the EHR architecture based on this initial framework.

Security Framework6.50. In an architectural approach, such as the one we have been pursuing here,

issues of security – which is one of a set of concerns including fault tolerance, recoverability and self healing and ergodicity which we refer to as dependabilities – must be treated at the systemic level. These are not characteristics that are added to a system they must emerge from its structure and organisation.

6.51. Our explorations of policy, clinical practice and technological capabilities in this project have led us to the following conclusions:

Since the fundamental ethical principle is that clinical information should only be used for the purposes intended at its generation and with the informed consent of the subject, any approach to implementation in systems terms requires these intentions to be represented or inscribed in some way.

The concepts and language of differential access, which classifies data items and assigns access rights to role holders, while a necessary part of any implementation, is not, on its own, sufficient.

A general approach to security and consent in health requires an integration of message and transaction management, concerned with the co-ordination of care pathways and containing the contextual information associated with any item of data, with the means for recording and retrieving information from publication systems.

6.52. It is these ideas which have led to the concept of the Health Community “Portal” as the locus for services which:

Integrate data from different sources into a coherent presentation according to a set of rules and agreements at three levels: national, local community and individual preferences.

Provides the transaction management for complex and flexible sequences of care transactions.

Delivers a structured message management service which takes account not only of the source and destination but also of the significance of a message within a pathway.

50



Coordinates a set of security services which combine to provide not only confidentiality and consent management but also other characteristics such as identification, auditability, notorisation, non-repudiation, etc.

6.52. The portal represents what we have called “usage control” which is distince form the access control which is delivered by the gateways whos’ responsibility is to ensure that claims of identity and location associated with every request for access to EHR are reliable and can be trusted.

6.53. The systemic approach is clearly demonstrated in the technical animator where, for example, digital certificates based on a key infrastructure deliver transaction co-ordination in an emergency setting which involves multiple parties in different locations including mobile units. The delivery of confidentiality is, in this case, a side effect of the encryption approach not its purpose and the security is systemic not imposed.

PRESENTATION AND INTERACTION6.54. The technology framework also positions the human – computer interaction

technologies. In many of the contexts in which ICT technologies and products are defined and developed, this aspect of architecture tends to be rather marginalised, issues of mobility, transportability and miniaturisation of information tools tends to be driven by fashion and differentiation rather than by real user need. Our examination of information use in clinical practice is that it is highly situated. Many of the barriers to the uptake and use of these technologies in care delivery can be traced to the fact that many current offerings do not respond to this sort of requirement and seem to be based on the idea that the support of clinical practice and health care delivery can be mediated through work stations.

6.55. The fact that an information artefact can be hung at the end of a bed, stacked up and physically handed over is often a key factor in its utility. It is for these reasons that interaction technologies and mobility must be made architecturally visible in the EHR architecture from the outset.

51



PART 3: EHR GOVERNANCE

52



179 ‘OWNERSHIP’ AND GOVERNANCE

180 A national solution for EHR must include a framework for governance and service delivery with the same degree of scaling and federability as the technical architecture. An outline structure has been developed which allows consultation and participation of stakeholders, along with the creation of legal entities competent to procure EHR services, to supervise service level agreements, and to coordinate EHR service delivery. This approach does not predefine which organisation should be made responsible for procuring and operating EHR portals in any particular context, but it does define the responsibilities and relationships to be exercised by any such organisation.

181 The governance framework identifies three levels of interest: stakeholder, service commissioner and service deliverer(s). It seems likely that the appropriate level for commissioning of the EHR service will correspond to the area covered by Strategic Health Authorities. However, there is a range of possible legal frameworks in which new collective legal entities are created, or authority is delegated to an existing Trust to act as service commissioner.

182 At the national level, there is a need for a forum for such agencies to coordinate and supervise the elements of EHR which have been infrastructuralised at the national level. It is likely that, under the aegis of this national EHR body, a national stakeholder forum would be required and also a national forum for suppliers of technologies, systems and services.

183 This section presents a brief overview of the proposed EHR governance framework in order to identify the governance, supervision and planning components required at national level. Figure 7.1 shows the key elements.

Figure 7.1: Ownership, Control and Governance of EHR

53



184 This, very brief description of the governance options is expanded in other deliverable of the project. It is introduced here because there are national implications for a national service.

OWNERSHIP AND GOVERNANCE OF EHR185 The EHR architecture identifies a set of systems resources and the services

they deliver. It shows that there is a wide range of configurations possible, representing different levels of aggregation and distribution, from highly centralised approaches to ones where EHR is delivered by many local systems. However, each of these systems must be procured, owned and operated by some organisation.

186 Current practice in the NHS is as follows:

Hospital systems are owned and operated at individual trusts or, in some cases, a number of trusts have aggregated their requirements and procured a common service.

Primary systems provision is more fluid, with ownership and demarcation of functionality between practice and PCT systems under discussion.

There are nationally procured shared services, such as NHSNet and the National Strategic Tracing Service.

187 The concept of an EHR is based on ideas of health care communities which are groups of trusts and other organisations. This implies the need for collective procurement at levels which do not currently exist.

188 The architecture requires that EHR publication systems provide a service to the EPR host systems to deliver continuous access to information that has been published into the EHR domain. These may be part of the enterprise systems of the host organisation, either individually, or collectively at sub regional or regional levels. Alternatively, the EHR may be supplied as an application service by third parties.

189 The EHR portal, however, presents an interesting problem. It is not simply a shared resource: it implements policies and requirements which are negotiated between a range of different sorts of user organisation who form a multi agency care delivery network. Each member of this community, and the clinicians and managers who are part of it, have an important stake in the way the EHR is operated, and have rights and responsibilities associated with the data it contains. A framework of governance is needed which allows these responsibilities to be exercised.

190 This framework has three layers:

A service commissioning, procuring and supervising entity.

54



A stakeholder forum which includes representation from all the interests who have a stake in the clinical information governance of a health care network.

Service delivering entities who operate the EHR infrastructure.

Commissioning, Procuring And Supervising191 There must be some appropriately constituted entity which is legally and

technically competent to procure an EHR portal service from suppliers. This procurement is of an infrastructural service, and the provider of this service will operate and probably own the physical assets which deliver the service functions.

192 The principles for a framework of governance must be federable and scaleable, just as the technical architecture is. The main practical conclusion from this is that, if the general architectural principles are adopted, then an EHR procurement would most likely be initiated at the Strategic Health Authority level. The required steps would be:

Formation and operation of a stakeholder forum.

Decision as to whether a new legal entity is formed to undertake the collective procurement, or the task is delegated to some existing legal entity would be made.

Initiation of an EHR service, to proceed on the basis of a preliminary information notice (PIN) followed by a European Journal tender (OJEC).

193 The federability of the governance framework has to deliver local and national structures. At the local level, it is clear that natural health care communities are not necessarily co-terminous with Strategic Health Authorities. It will therefore be necessary to invite participation from representatives of neighbouring EHR domains where appropriate. The stakeholder forums (see below) must ensure that such participation is achieved.

Stakeholder Forum194 The stakeholder forum has the purpose of enabling stakeholder involvement in

the governance of EHR. This must take the form of some collective or association. There are a range of possibilities for the nature of the relationship between this stakeholder forum and the EHR procurer:

At one extreme, the procurer could be the Strategic Health Authority, or, indeed, the NHS centrally, and the stakeholder forum could be a representative committee that is set up under its aegis. This delivers only indirect control to stake holders and represents the centralist and authoritarian approach.

55



At the other extreme, the stakeholder forum could constitute itself as the shareholder(s) of a non-profit distributing company limited by guarantee, appoint the directors and set the policy, with this company becoming the vehicle for procurement, licensing and operation of EHR services and infrastructure.

195 There may be an option of a third approach, where the stakeholder forum delegates the provision of the EHR service directly to a supplier. This has the advantage of simplicity and direct control, but the disadvantage of creating a supplier of an important service who would be difficult to remove in the case of unacceptable service. There may also be legal issues raised by this approach from a public procurement point of view and supervision of the service would need to be exercised through direct management channels.

196 A national stakeholder forum is required to provide coordination and to supervise the national EHR service components. It is also clear that national technical coordination must be provided to maintain the architecture and to plan service evolution.

56



197 LOCATING THE EHR: OPTIONS AND ISSUES

INTRODUCTION198 This section examines some of the issues surrounding the initiation of EHR. In

particular, it considerers whether a national EHR could emerge through the federation of local solutions or has to be initiated in a top down fashion. As stressed throughout this deliverable, this is not a technically determined decision but a political one. An architecture such as the one presented here is capable of sustaining either approach.

199 The ERDIP programme is supporting a number of pilot implementations. Each has been initiated independently and responds to local conditions and requirements. Each involves co-operation between a number of health care organisations, where the specific grouping is a result of local conditions and history. The technical solutions emerging from this diversity show some variation but, nevertheless, are surprisingly similar:

They have all suggested some sort of portal.

The majority identify some data repositories which are initially populated with basic EHR data.

There is some form of update mechanism through connections with existing patient record systems.

200 This is not surprising, since all the projects are inevitably faced with the same set of technologies and product architectures from the suppliers. The principal area of variation between approaches is that:

In some cases, all the data is considered as external and the portal delivers an entirely ‘virtual’ service.

In others, the data is all regarded as internal and held within a specific EHR data repository.

201 A third option is to mix both internal and external data.

202 Where the approaches differ more fundamentally, however, is in the assumptions made about who owns and operates the portal, and therefore controls and delivers the service. Choices here reflect the initial configuration of the group involved in the development of the EHR and their relationship to the local health care community. There are three broad classes of approach which correspond to a primary-based, secondary-based, or third party approach to the provision of an EHR service.

203 These are discussed briefly in the rest of this section.

57



PCT Based Approaches204 Here, the introduction of Trust status to PCGs and the shift of the locus of

responsibilities for clinical governance and service commissioning in the primary sector generate a need to review the provision of information systems support. A series of responses is being developed which vary from minimalist approaches that do not disturb the existing practice systems, to a complete reconfiguration of the provision of primary care patient records and care management systems onto a central trust server, with only basic access functionality at the individual practice level. Various intermediate distributions of functionality between the practices and the Trust are also possible. Evaluation of these options appears to be relatively fragmentary and preliminary at present.

205 It is clear that data which originates in primary care will have an important role in any EHR, emergency or otherwise. This implies that the primary systems must act either as source systems issuing updates to an EHR publishing system, or as feeder systems which make use of an automatic mirroring service. A large number of individual practices will never have the resource or the technical capability to operate as highly available data sources to a emergency service. The standard practice system is unlikely to become an EHR publishing system, and some aggregation will be required. This leads to the obvious solution of providing data mirroring services at the PCT level, together with the functionality to support other Trust operations and responsibilities.

206 While this approach does not imply that the EHR portal is also located at the Trust level, local scope and participation may promote this approach. If a consortium is dominated by primary care interests, the locus of control and management of the proposed EHR service will, naturally, be allocated to that sector of the NHS.

207 As new types of organisation, PCTs do not necessarily have a well developed IT department, or the skills and resources to put together the technical and operational plans required to set up a complex service. In the ERDIP projects there are examples of PCTs developing relationships with the IT department of the Health Authority and third parties capable of providing a facilities service. In this scenario, large PCTs will operate EHR portals and deliver an EHR service to their local health community, including the hospitals to which most of their referrals go and to the community health services of their area. Smaller PCTs will join together to produce a shared service. The systems and human resources required to manage and deliver the service may be derived from some evolution of the Health Authority IT department or from the service supplier who provides this facility. Equally, it may be based within the PCT.

58



Secondary Care Based EHR208 The initiative within a local community may come from the IM&T

departments of hospital trusts. They are often experienced in procurement and delivery of complex technical services and, particularly where alliances between trusts within a locality (or Region) have developed, have provided a natural base for responding to the ERDIP initiative. In this approach, EHR grows out of hospital EPR systems; the EHR portal is co-located with the hospital system and is operated by an individual or a federation of hospital trust IT departments.

Third Party Approaches209 One of the significant themes which has been part of the development of the

concept of an EHR is that of patient empowerment and participation. In this view, the EHR information is seen primarily as the property of the subject. Historically, both the practice and the hospital have regarded the records they keep as their responsibility, even if they are prepared to share them with the patient. The creation of a truly patient oriented EHR implies that, while both primary and secondary records are integrated into the concept, the core is independent of either of them. This leads to the concept of a third party provision of the EHR portal delivering a patient oriented service.

EHR EVOLUTION210 Each of the three approaches which have emerged face a challenge when

presenting themselves to the wider local health care community. Primary based systems need to ‘recruit’ the hospital IM&T services, while the secondary systems need to offer a service to the primary sector in a way that is sensitive to their culture and practice. This is not a simple matter - cultural differences between primary and secondary clinical practice, particularly in their attitudes to the custodianship of medical records, are considerable. The third party solutions may be interpreted as threatening to both sectors.

211 In ERDIP projects, these explorations and negotiations of organisational options have made and are making varying levels of progress. One way of interpreting these activities is that, in response to policy and the stimulation of funding, local health communities are reconfiguring themselves and their relationships. In particular, they are re-mapping their communications and information resources into a new level of local infrastructure which makes use of the services of the national networks and provides services and resources which are shared across organisational boundaries of a sub-regional health care community. The approaches being taken depend upon the specific composition of the Trusts and Authority organisations that have chosen to develop a co-ordinated response in each of the areas in which the projects are situated.

59



SIMPLIFICATIONS IN CURRENT SOLUTIONS212 Because they are new developments and are dominated by local issues and

configurations, the EHR configurations currently being generated implement a selection of the core functions identified in the functional model. A number of simplifying assumptions are inevitably made at the systems level. These assumptions and simplifications include the following:

Access control can often be assumed to be external to the implemented system, with reliance placed on the security measures within NHS buildings and organisations, and also on the mechanisms built into NHSnet.

Usage control can be simplified in initial implementations. For example, an emergency EHR delivers a particular, fixed data set to any request from designated sources such as an A&E department.

The portal and the base data repository can be closely coupled to the extent that they are regarded as one system: information integration and information holding are the same thing.

The initial data set will be relatively unproblematic as far as the maintenance of quality and timeliness is concerned.

213 There are two stages in the initial evolution of EHR where these simplifications will require re-examination. The first of these is fairly immediate, and occurs when a proposed solution is expanded within the local health community to recruit organisations and interests who have not been part of the initial core team who defined and developed it. Here, it may be necessary to show that more sophisticated access and usage control can be exercised to meet the expanded set of usage contexts. It may also be necessary to show that the ownership and control of the portal can be compatible with the location of responsibility for information integration and presentation, and with the interests and sensitivities of all the suppliers and users of EHR data.

214 The second stage, which may not be long delayed, concerns the negotiation of federation agreements between different EHR domains and between clinical domains and others such as social care and research.

215 Both the functional model and the resource model distinguish between:

The relationships which are concerned with the supply and integration of clinical information.

The responsibilities for ensuring that it is used only in appropriate circumstances.

The responsibilities for maintenance and checking of user credentials.

60



216 If the demarcation of these functions has been respected in the design and implementation of the initial systems, then these systems will be open to reconfigurations at each of these levels. This allows for the structuring of the negotiation between federal parties. They are able to deal separately with issues of, on the one hand, what data can be shared and for which purposes and, on the other, the operational procedures and trust mechanisms required for maintenance of the responsibilities of information custodians under operational conditions.

217 These considerations apply in the case where two or more EHR implementations are linked, and also to the extension of EHR within a local community beyond the bounds of clinical care to social care and to research. In all these cases, there is a process of establishing and building trust which, if it is to be successful, will require two conditions to be met:

Implementation must be progressive: it is likely that the first stages of basic information sharing will not be ideal or that, if successful, will then result in changes of culture which will open the possibilities for further developments.

Implementations must deliver the configurability and transparency implied by the proposed architecture; a requirement for fundamental re-engineering of the solution would be an insuperable barrier to progress.

218 The discussion of EHR introduction and evolution which has been presented here draws on a survey of the current ERDIP projects. At the overall programme level, there is some discussion as to whether EHR could be defined and introduced as a ‘big bang’ national solution, introduced progressively but on the basis of a unified, mandated approach defined at, say, the regional level, or whether it will have multiple, heterogeneous starting points and develop through federation and expansion, both in terms of geographic coverage and areas of utilisation.

219 National policy is clearly predicated on the concept of a ‘National Emergency EHR’, while the ERDIP projects are inherently inclined towards the ‘multiple sources’ approach. Adoption of either broad approach depends partly on whether the emerging EHR architecture is powerful and flexible enough to respond to these two apparently divergent sets of drivers and issues.

AN INTERCEPT STRATEGY FOR PROCURMENT8.23. EHR presents a particular challenge for the coordination of procurement: we

have an idea of where we want to be but this will take several years to fully emerge and clarify and we have to continue to procure systems and services and to run the service.

61



8.24 This leads to the following recommendations for an “intercept strategy” an approach which has been adopted in the telecommunications industry at several points in the past when new technologies and commercial conditions have indicated that the architecture of the telecommunication service network or management environment was going to need to change radically. Applied to health, the approach could be as follows:

1. The full definition and implementation of the first generation of systems and services in response to ICRS will take 24 months at least.

2. Subsequent generations of systems which are conformant to the emerging architecture will be procured over a considerably longer period.

3. In the mean while, individual Trusts will need to procure internal systems to meet ongoing development commitments.

4. This calls for a set of procurement guidelines which will ensure that

a. Newly procured systems are specified in a way that maximised their convergence with the emerging standards and practices of ICRS.

b. That the return on investment in legacy systems is maximised.

5. The procurement guidelines should therefore, include the following elements:

a. A mandatory statement of commitment to the emerging standards as part of all relevant NHS systems procurement. Initially, this will be couched in general terms of a statement of intent to migrate products to the standard. This would be progressively tightened and made more specific to address issues such as EHR national service compatibility, the inclusion of EHR publication and message protocols to full federability standards.

b. The participation of suppliers who are making such commitments and delivering interim systems to the NHS in and architecture and standards forum which will advise and comment on the emerging standards.

c. A set of specific, pilot procurements of the fist generation ICRS systems, services and components which will have special requirements to make their experience available to the pre-competitive architecture and standards forum.

6. The objective would be that the outcome of the first set of ICRS procurements would not only be a number of working system at the health community/network level which use common national services and demonstrate federability across their boundaries but also a set of systems and service level specifications to inform the next wave of procurement.

7. Such an approach presents several challenges in terms of sharing of commercial information, supplier negotiation and the application of procurement rules, but these problems are unavoidable in the procurement of a complex infrastructure.

62



APPENDIX 1: THE SIMULATOR

The EHR simulator which has been produced in the project demonstrates that a clinically relevant record can be constructed as a result of the management of structured messages rather than as a result of updates to a database.

It is based on our CHD scenario and is defined in terms of:

A set of clinical messages which have been defined in XML using current and proposed standards where possible.

An imagined local configuration of host systems, publication and portal systems together with a gateway and trusted third party server.

The tool allows the series of messages to be “played through” and, at each stage, in a separate browser window, the resulting state of Mr Edward Jones’ record can be examined.

User (H)

Gateway

User (GP)

GatewayGateway services

ConsentRegister

UserRegister

Trusted Third Party Server

Hospital Clinical System

EHR Publication

System

EPR

Practice System

EPR

Call Handling & Triage

Gateway

User (E)

EHR Portal

Rules

Pharmacy SystemGateway

Remote EHR Portal

Publication Systems

Remote User

Gateway

Gateway

Clinical Service System Gateway

EHR Publication

SystemGateway

User (P)Gateway

PCT SystemGateway

AV

AV

AV

Figure A1: The local systems context for the EHR simulator.

The systems context is comprised of an example practice system and an associated PCT system. There is also an example of a publication system which provides the EHR publication service to the particular practice we represent.

The Hospital clinical systems are also represented together with their own publication system. The clinical service systems associated with, say, pathology are shown as distinct systems here which can be the destination and origin of messages.

63



All of these systems are interconnected via a gateway network to the community portal or hub which will be connected to other hubs. The gateways are supported by a trusted third party certificate service and a set of gateway services in the form of user and consent registers.

64


national ehr environment - newcastle university€¦ · web viewnational environment for ehr...

Documents