Access to the health record Draft report ISO/TC215/WG1

Prepared by the New Zealand Delegation

Wednesday 21 June 2000

Vancouver

Canada

something we could achieve ...

From the TC215 Scope Statement

“Standardization in the field of information for health, and Health Information and Communications Technology, to achieve compatibility and interoperability between independent systems.”

From the WG1 scope statement

The scope of WG1 is to develop standards for the trusted management of information concerning health and the healthcare process.

WG1 will address health record standards that are independent of setting and technology. The standards will enable the availability of the appropriate information at the place and time of decision.

From the WG1 scope statement ‘Terms of Reference’create a framework of standards that enables health

information to be created, used and shared across any and all boundaries including systems, jurisdictions, disciplines and professions

adopt a consistent modelling approach across all health informatics standardization activities, based on an existing modelling notation.

include, but not be limited to, the content, structure and documentation of the health record, integration of patient information, interoperability and decision support

From the resolutions of the WG1 meeting, Tokyo, Nov.’99

The agreed title of the Work Item is “Access to the Health Record”

The objectives of this Work Item are to define concepts for modelling access, not to determine a set of rules for access

A further recommendation was that the work item should lead to a 'technical report', not a 'specification’, and that it should be done in collaboration with WG4.

Role of WG1 within ISO/TC215WG1 is the ‘pilot’ committee which should

integrate the work of all working groupsInteroperability is a key goal of the TC215

process, and of the access item in particular. In our view, this will demand solutions which are both simple and flexible

Mention of a ‘shared notation’ indicates we should be developing ‘concepts for modelling access’, ie Models

UML was identified as an appropriate notation

OverviewThe ISO/TC215 process has a strictly

defined time spanthere is an urgent need for an accepted

access model, and for its implementationWe discuss policy issues and propose a

model of/for EHR access An agreed access model would be of

relevance to all WGs in the TC215 process

WG4 defined the task• 'To define the essential elements of a health care public key infrastructure to support

the secure transmission of health care information across national boundaries.

• The specification must be Internet based if it is to work across national boundaries.’ from the Technical Specification Draft for Secure Exchange of Health Information, February 2000

It seems likely that the public key infrastructure proposed by WG4 will provide the basis for implementation of a global system.

The concept of ‘attribute certificates’ would seem to be crucial to the implementation of access control by ‘role’, and

our task is to develop a model of the ‘access’ process which will enable that synthesis.

Beyond reviewing current concepts and practices, the ‘access control’ task for WG1 can thus be re-stated:

To propose a global policy to both accommodate jurisdictional and national differences in access control and facilitate cross border access

To marry these concepts with the evolving work from WG4 (including the Technical Specification Draft for Secure Exchange of Health Information, February 2000)

(a brief anthropological detour…)

The Definition of Social Man

Different cultures have distinct views of social responsibility and distributive justice

Western industrialised societies tend to emphasise individual autonomy

Many others regard the concept of 'self' as more socially constituted

In order to be truly international, an Access Standard would need to accommodate diverse definitions of self and society

The ISO Access Standard -

must contain a framework which permits diverse solutions to the age-old questions of self and society

should facilitate exchange of health information between systems with different 'set up' configurations in the networks of rights, obligations, access, and privacy considerations that surround health records

The Concept of Ownership

The concept of ‘ownership’, which can be deconstructed into rights and reciprocal obligations, is problematic when viewed cross-culturally

A decision was taken by WG1 members at the Tokyo meeting November 1999 to delete the ownership concept from the title of the work item

Review of international literature on access to health records

We presented a critical overview of national standards and procedures, including assessment of the extent of international consensus on principles relevant to access(please refer to this in the document on the WG1 web site)

www.health.nsw.gov.au/iasd/imcs/iso-215/

many OECD countries have broadly similar rules and restrictions regarding access, but:

details vary considerably, and relatively little information is available about

practices and procedures in other countries

Types of Access Control

Client hostname and IP address restrictions

User and password authentication

Role based Access Control

Strong authentication techniques

Digital and Attribute Certificates

Public-Private key encryption (eg PGP)

Role Based Access Control (RBAC)

The decision to allow access to objects is based on the role of the user, rather than on permission based on another user.

The determination of the role membership and the allocation of each role's capabilities are determined by the organisation's security policies.

Developing operational concepts and their interrelationships

• Roles and Rules

• Self–defining systems of roles

• The Role concept in Messaging

• The Role concept in Security processes

Rules and RolesCultural concepts regulating access can be

considered as sets of ‘roles’, and ‘rules’ relating those roles.

Operationalizing is challenging and will show up redundancies, inconsistencies (eg David Jones’ UK scenarios, see Form 4 attachment)

Systems of roles and rules are mutually defining. Our task is not to try to evolve some sort of ‘definitive set’ but rather to develop a model that can accommodate different sets of rules and roles yet remain globally interoperable

Self–defining systemsThe concept of ‘self defining system’ comes

from linguistics, cybernetics etc.

The game of chess is an example.

The concept of ‘roles’ has its own extensive literature in sociology

a truly international standard must accommodate and express cultural variation in such systems of roles

Maori concepts in Aotearoa/New Zealand

the notion of an extended family group (whanau) helps to explain the Maori’s greater collective interest/input bearing on access to personal information

infirm or incompetent individuals often have a 'minder' (Kai Awhina) consensually assigned by the whanau, who is then responsible for decisions relating to, the individual's health care

whanau in practice may overrule the decision of an individual to undergo a medical procedure (e.g., abortion) based on cultural values and extensive social supports.

The Role concept in Messaging

the concept of role is defined (Hinchley CEN "A role of a healthcare agent is undertaken in the context of their relationship with another agent".

the ‘messaging’ standard role appears to comprise an agent, a context and an action.

Thus a role can be considered a simple syntactic structure

The Role concept in WG4The WG4 paper uses the concept of ‘role’ in

relation to ‘attribute certificates’. control decisions about request and

disclosure can be rule-based, role-based and rank based .

‘attribute certificate’ supply role information bound to a health professional’s public key. a health professional may have many of

these, which reflect multiple roles. attribute certificates are typically more short

lived than the identity certificates

Minimum ‘Access’ Concept Set

Four Related Concepts Access Failure of Access Rights Obligations

Three irreducible outcomesAccess - Access Criteria Matched,

information identified and and availableFailure of Access - information identified,

access denied - PRIVACYFailure of Access - information not identified

to requester - SECRECYFailure of Access may also occur because of

system failure or because the information simply does not exist

The Access Control Matrix

The level of rules and roles can be modelled at a higher level, and triggering one of three outcomes

This would depend on the match between the reasons for access offered by the request and the criteria required to access the target data.

The computations involved can be modelled with an Access Control Matrix (ACM). This can have as many dimensions or variables as are found necessary.

The Generic ACM

A generic ACM would specify the dimensionality of the variable space on which roles can be defined.

It would not specify any particular role or rule set.

Each jurisdiction would need to define this, although much is shared, eg OECD

The generic ACM is EMPTY.

Jurisdictional boundariesPart of the scope is to develop concepts and

models of EHR access control across jurisdictional and national boundaries.

. Differences in access control policies are one of the defining parameters separating jurisdictions.

. A jurisdictional boundary is not necessarily the same as a national boundary, and could be as small as a single provider

Some big companies ignore present jurisdictional boundaries, or want to!

Requirements for EHR Access

• Availability

• Data Integrity

• Auditablility

• Confidentiality

• Accessibility

Availability

• What: there should some indexing system for classification and retrieval. (It is the task of WG3 to determine this)

When: a method should be defined for regulating access to health information with respect to time.

Who: personal identity information, regulating ‘who’ can access a demarcated segment of information, based on their role and the situation (e.g., urgent medical need for records).

Where: there should be a location of source identifying system applied to health information, which determines where information can be accessed

Why: there should be a ‘reason for obtaining’ information applied to demarcated segments of health information

Auditablility

EHR should be auditable, with regard to content and

by an ‘audit trail’ of access (an ‘access history’ for health information should be traceable)

It should be possible to discern modification/updating of EHR using version control

Data Integrity

There should be processes which verify data as unchanged when communicated

Confidentiality Procedures should be in place which restrict

access to health information by defined criteria (e.g. the ‘what’ ‘when’ ‘who’ ‘where’ and ‘why’ list above)

The criteria, which may be culture- or jurisdiction-specific, must be able to be locally defined according to ethical precepts current in that jurisdiction. These may or may not include individual consent, depending on the situation

Interoperability

There should be a process or processes mediating the exchange of health information at jurisdictional boundaries

This should allow EHR to interoperate in a way that is truly global yet respects local customs and culture. It follows that the process should be both simple and be amenable to customisation in different jurisdictions

Accessibility There should be open access to

a EHR standard for suitably credentialled workers.

Like a currency, the interoperable standard should not be owned or privately controlled

ISO-compatible records should be able to be ‘open source’ in principle (if only because some record systems are!)

Policy or Model?Should this draft technical report on Access

proceed further?Was the ‘Technical Report’ to be limited to

WG1?We understood that it was to be

collaborative with WG4In the absence of their input, we developed

the matter further ourselvesWe believe that further progress depends on

active collaboration

The Access Object Model

• Axiom 1: Data collection in medical practice occurs at the clinical interview and other clinical encounters.

• Axiom 2: Access to EHR and other health resources will be significant determinants of how medical and personal narratives develop.

• Axiom 3: There is a need for a generic technique to de-identify data. This facility must be built in to any global system.

Access Objects 1

We propose a class of metadata (data about data) objects, which are created alongside health data at the clinical encounter or interview

These contain the referent to the data. They are “proxy” data objects

Access to data is through them, employing public/private key encryption

The audit trail is kept with the data.

Access Objects 2

Access Objects could serve different schemata for data structure and architecture. (USAM, CEN,GEHR etc)

They would also be functional for linkage to data objects with little formal structure, e.g. word processed documents,

this would serve technologically unsophisticated environments

Access Object attributes

Patient IDContent definition / indexAccess Rules and Roles (ACM)Reference (address) to dataEncryption keys

Request Object attributes

Patient IDRequest content templateUser IDUser RoleReason for AccessConsent (if applicable)

To Summarise the process

The collection of clinical objects formed at the clinical encounter has an access object assigned to it.

These contain a key to the data contained –(patient ID), a content definition, indicating the type of information contained in the object, the ACM applicable to the object, a reference by which the data can be located, encryption keys

The definition and grain of the clinical objects is not defined by the access system

Summary 2

The Request Object made by the request manager would also contain encryption keys verifying ID and role of requesting agency, and the access rules for that role (what classes of data can be accessed, as well as a content template, and a statement of ‘reasons for request’).

If the ACM of the access object, and the roles and reason for request as well as the content search criteria from the request object are met, the requesting agency gets access to the referent in the access object

Summary 3

There is a final verification stage for the source of the requested data using the encryption key which is part of the access object, and then a ‘secure socket’ connection is established which permits exchange of data.

This concept might bridge the work of WG1,2 and 4, but WG3 would need to address content coding.

The access objects might be web-based, stored on smart cards or other mobile media (WG5)

Integration with WG4 model

The proposed model would work by authentication of identities and roles occurring like 'welds' or 'rivets' in the ongoing process of medical work.

In UML models of the access process, we can now identify where these ‘rivets occur’.

The ‘Access Object’ model in UML notation

These diagrams use this notation to express the concepts, and are not intended to specify an implementation

the diagrams are incomplete because they do not specify the cardinality and multiplicity of the classes displayed

this is corrected in the latest version (19 June 2000

6.5.4 Class Diagram of Access Control Mechanism

request manager

access request

patient idrequest templateuser iduser rolereason for access

access controller

access lock

patient idcontent definitionaccess rulesreference to dataencryption keys

demographic data

audit trail

clinical objects

attestable unit

financial objects

6.5.5 Sequence Diagram of the Request Patient Information Usecase.

: Data User

: request manager

: access controller

: demographic data

: attestable unit

: audit trail : access request

: access lock

1:

14:

2:

3:

4:

12:

13:

11:

5: 6: 7:

8: 9:

10:

ConclusionOur legitimate task is modelling the Access

Process for the ISO standardFair concordance is found in some models

of the process, enough to start from.We have suggested a particular model, but

it is not a specification, and the policy part of our document can be considered a ‘stand alone’

We advocate that the matter be explored further with WG2,3,4, and 5.

Policy or ImplementationThe comment has been made that we have presented an

implementation rather than a policy statement. We remain convinced that a report which did not point

the way toward an implementable standard would be a waste of time.

Our work in pursuing the standard is preliminary, and is more in the domain of proposed policy than technical detail.

Our hoped for collaboration with WG4 is thus a logical necessity

Dangers of ‘de facto’ standards

Small players excludedCulturally insensitiveInteroperability problematicInefficient use of resources (human, time)

The reality of cultural differences

there is broad sympathy among Western industrialised nations in access policies but..

many cultures including some with ISO representation and others not well represented in TC215 see things differently.

We require a solution which is flexible enough to allow for these cultural differences in roles and rules for ‘access’

Global interoperability is the goal. What would it be like?

It should be possible for health care workers, with the minimum of resources or technical sophistication other than their skills in health care to create and use ISO compatible and conformant records.

The standard should not be a barrier to healthcare, but should facilitate it.

The simple process model described is argued to be in some sense to be necessary.

We should work to facilitate global healthcare

But it will not happen of itself, we would need to decide to do it...