Access report final iso format 29 mar 2000

© ISO 1999 – All rights reserved

Reference number of working document: ISO/TC 215/WG1 000
Date: 2000-.03-15

Reference number of document: ISO/WD nnn-n

Committee identification: ISO/TC 215/WG 1

Secretariat: XXXX

Access to Electronic Health Records

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to
change without notice and may not be referred to as an International Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.

Document type: Technical Report
Document stage: (20) Preparation
Document language: E

/home/pptfactory/temp/20110102092331/accessreportfinalisoformat29mar2000-110102032329-phpapp01.doc
Basic template BASICEN2 1999-02-12

ISO/WD nnn-n
Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the
reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards
development process is permitted without prior permission from ISO, neither this document nor any extract
from it may be reproduced, stored or transmitted in any form for any other purpose without prior written
permission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed as
shown below or to ISO’s member body in the country of the requester:

the full address
telephone number
fax number
telex number
and electronic mail address

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

II

ISO/WD nnn-n

Contents

Foreword...........................................................................................................................................................v
Introduction: ...................................................................................................................................................vi
0.1 Executive Summary..................................................................................................................................vi
0.2 History of New Zealand’s involvement....................................................................................................vi
0.3 Scope Statement of the ISO/TC215 committee.....................................................................................vii
1.0 Scope and Aims.........................................................................................................................................1
1.1 Specifically excluded from the scope......................................................................................................1
1.2Specific Aims..............................................................................................................................................1
2 Terms and definitions...................................................................................................................................1
3 Review concepts and literature on access to health records...................................................................2
3.1 Cultural concepts about rights and obligations which pertain to access to personal health
information..........................................................................................................................................2
3.1.1 The definition of social man ..................................................................................................................2
3.1.2 Pakeha and Maori concepts in New Zealand........................................................................................2
3.1.3 National and Jurisdictional Differences................................................................................................2
3.1.4 The Concept of Ownership....................................................................................................................2
3.2 Review of international literature on access to health records.............................................................3
3.2.1 Background: The Ethics of Privacy.......................................................................................................3
3.2.2 Overview of national standards and procedures.................................................................................3
3.2.3 Data Collection........................................................................................................................................3
3.2.4 Storage and Security..............................................................................................................................3
3.2.5 Access and Corrections.........................................................................................................................4
3.2.6 Access 4
3.2.7 Unique Identifiers....................................................................................................................................5
3.2.8 Recommendations for international consistency................................................................................5
3.2.9 Problems with inconsistencies across jurisdictions...........................................................................5
3.2.10 Possible solutions................................................................................................................................5
4 Relevance to EHR of access control in electronic commerce..................................................................6
4.1 Levels of Access control...........................................................................................................................6
4.2 Types of access control............................................................................................................................6
4.2.1 Client hostname and IP address restrictions.......................................................................................6
4.2.2 Password protected access control lists .............................................................................................6
4.2.3 Role Based Access Control (RBAC)......................................................................................................7
4.2.4 Strong Authentication Techniques........................................................................................................7
4.2.5 Intellectual Property Rights...................................................................................................................7
4.2.6 The Platform for Privacy Preferences...................................................................................................7
5 Concepts relevant to EHR access...............................................................................................................8
5.1 Developing operational concepts and their interrelationships relevant to EHR access ....................8
5.1.1 Roles and Rules......................................................................................................................................8
5.1.2 Self–defining systems............................................................................................................................8
5.1.3 The Role concept in Messaging.............................................................................................................8
5.1.4 The Role concept in Security processes..............................................................................................8
5.2 Minimum concepts that could be implemented in a global system......................................................9
5.2.1 Four related concepts.............................................................................................................................9
5.2.2 Three irreducible outcomes...................................................................................................................9
5.2.3 The Access Control Matrix.....................................................................................................................9
6 EHR access control across jurisdictional and national boundaries......................................................10
6.1 Jurisdictional boundaries.......................................................................................................................10
6.2 Requirements ..........................................................................................................................................10
6.2.1 Availability ............................................................................................................................................10
6.2.2 Data Integrity.........................................................................................................................................10
6.2.3 Auditability............................................................................................................................................10

© ISO 1999 – All rights reserved III

ISO/WD nnn-n
6.2.4 Confidentiality.......................................................................................................................................11
6.2.5 Interoperability......................................................................................................................................11
6.2.6 Accessibility .........................................................................................................................................11
6.3 The Access Object Model........................................................................................................................11
6.3.1 Attestation.............................................................................................................................................11
6.3.2 The Security WG4 contribution............................................................................................................12
6.4 Access Objects.......................................................................................................................................12
6.5 Model of Access Control Mechanism.....................................................................................................12
6.5.1 Use Case Diagram of Access Control Mechanism.............................................................................13
6.5.2 Access Lock Objects............................................................................................................................14
6.5.3 Class Diagram of Architecture of Patient Information ......................................................................15
6.5.4 Class Diagram of Access Control Mechanism...................................................................................16
6.5.5Sequence Diagram of the Request Patient Information Usecase......................................................17
6.5.6 Sequence Diagram of the Request De-identified Information Usecase...........................................17
7 Discussion...................................................................................................................................................18
8 Recommendation .......................................................................................................................................18
Annex A: Terms and Definitions...................................................................................................................20
Annex B - Part 1: National policies regarding access to health records.................................................26
Annex B - Part 2: Legislation relevant to privacy in various countries....................................................28
Annex C: UML Models from Russia and Sweden........................................................................................33
Bibliography...................................................................................................................................................44

IV © ISO 1999 – All rights reserved

ISO/WD nnn-n

Foreword

ISO (the International Standards Organization) is a worldwide federation of national standards bodies (ISO member
bodies). The work of preparing International Standards is normally carried out through ISO technical committees.
Each member body interested in a subject for which a technical committee has been established has the right to be
represented on that committee. International organizations, governmental and non-governmental, in liaison with
ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC)
on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.

Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.

International Standard ISO nnn-n was prepared by Technical Committee ISO/TC 215, WG1, Modelling.

ISO nnn consists of the following parts, under the general title Access to Electronic Health Records (EHR):

© ISO 1999 – All rights reserved V

ISO/WD nnn-n

Introduction:

0.1 Executive Summary

The ISO/TC215 process aims to deliver an interoperability standard for healthcare computer systems. Access
control interoperability would be a crucial feature of the standard, but this is challenging because of the diversity of
access control policies and procedures current in different countries, jurisdictions and institutions. This report
explores these issues, and concludes with some specific models using Unified Modelling Language notation (UML).
We argue the case for developing a shared global technique for regulating access to electronic health records
(EHR). Such a technique, if widely accepted, might also have application beyond health care.

The design for the global EHR standard that emerges should be accessible to clinical practice at all levels of
technological sophistication and complexity. The ISO process could be used to facilitate the ‘business plan’ for
global health care that Peter Treseder mentioned in his first address to the inaugural TC/215 meeting in Orlando,
August 1998. In this report, we explore ways that this might be done. The Access Object concept that we develop
could be used as a 'universal currency' for healthcare information. Although Access Objects would need to be
customisable to any configuration required by national or jurisdictional policy, basic default settings could be taken
from international conventions. The ‘Universal Declaration of Human Rights’ is an appropriate reference document.

This report explores a variety of access policies which presently apply to personal health information, and points
out the diversity of cultural concepts and definitions relevant to EHR access. It outlines how these might be
expressed through a generic access control matrix. The outcome of match and mismatch between request and
data access criteria is expressed in the simple outcomes of access and denial of access, the latter further divisible
into privacy (data located but not viewable) and secrecy (data not located).

A technique by which this might be done is described: the 'access object' technique would permit de-identified data
to be available from participating systems, including across jurisdictional and national boundaries. The technique
could also allow cross-boundary access to personally identifiable data in emergency situations. More detailed
negotiations between jurisdictions on the attributes of Access Objects would facilitate full interoperability.

A process is described whereby the authentication techniques of digital signatures and attribute certificates could
be incorporated in the process of requesting and obtaining EHR. The concept of 'role' is explored with reference to
Work Groups Four and Two, and mention made of Work Group Three in content definitions. The technique is thus
a synthesis of all the work groups, and the Access Object concept might be implemented on 'smart cards' (Work
Group Five).

We advocate that an agreed international EHR standard be freely available to those with suitable credentials, and
that the standard itself should not be ‘owned’, unless by an accredited international body such as ISO or the UN.
Health Workers should be able to freely obtain ISO accredited 'access objects' which they could then customise to
their own jurisdictions (or use with default pre set access definitions). This could make the simplest documents
(such as word processed files) into ISO accredited records, which would also be valid within (and compatible with)
complex and sophisticated systems. Access Objects could thus become a global 'currency' for healthcare, and
might have a function in protecting access to other sorts of confidential information as well.

This report is a 'working draft' of a work item that might, ultimately, lead to an implementable standard. There is no
sense in which it is complete. It is offered as 'work in progress', in the hope that it contributes to discussion in this
area.

0.2 History of New Zealand’s involvement

The history of this project on Access Rights to the EHR goes back to the inaugural meeting of the committee in
August 1998. At this meeting the domain of Health Informatics was divided into four work groups.

WG1 Modelling

WG2 Messaging

WG3 Content

VI © ISO 1999 – All rights reserved

ISO/WD nnn-n
WG4 Security

After the Berlin meeting in April 1999, a fifth work group was added:

WG5 Health Cards

The New Zealand delegation volunteered for WG1 at this meeting. At the subsequent meeting of WG1 in Sydney
(January 1999) Dr Mair contributed to the discussion of the proposed work group item on ‘Ownership and Access’
to the global health record by suggesting that the ‘ownership’ concept could be deconstructed into rights and
obligations surrounding health records.

WG1 delegated the responsibility of developing this work item to New Zealand. This was presented to the ISO
committee first as a completed ‘Form 4’ with attachments ‘A’ and ‘B’, prior to the Berlin ISO/TC215 WG1 and
plenary session in April 1999. It was then amended as a result of discussions there to reflect that our involvement
was to be with an ISO ‘Technical Report’. An updated and expanded attachment including many of the ideas from
attachments ‘A’ and ‘B’ was included with an amended Form 4, and submitted to ISO for vote (see ISO document
NP17128). These documents are to be found on: http://www.hl7.org/special/committees/tc215/

The acceptance of the work item was confirmed unanimously by vote in September 1999, and ten of the fourteen
‘P’ (voting) members of the committee offered to help with the report. However there were some constructive
critical comments made which were returned to ISO from member countries at the time of the vote. There was a
comment from Germany that the ‘attachment’ was not in the required format, and one from the UK that it was an
outline document only and did not address ‘conformance issues’. The US and the UK also emphasized that the
report should not be a specification, whereas the Japanese comment was that it should be a specification not a
report. There was a further WG1 meeting in London in September 1999, which requested a succinct statement on
the scope of the project, which would clarify its significance to Working Group 1 and distinguish it from security
mechanisms, which are the responsibility of Working Group 4.

With these injunctions, and with the collaboration of David Menkes and Lindsay Stewart, we developed a statement
of ‘Scope’ and ‘Aims’ for the report. The ‘Aims’ were intended as content list. These were submitted before the
Tokyo meeting of WG1 and the plenary TC/215 committee in November 1999, with David Menkes representing
New Zealand.

In discussions at the meeting, and with the encouragement of members from Australia, Japan, Sweden, amongst
others, the concept of ‘ownership’ was dropped from the title of the work item, and relegated to the status of a
‘cultural’ concept. One of the resolutions from the WG1 meeting was about the work item. It said that:

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'.

0.3 Scope Statement of the ISO/TC215 committee

The TC215 Scope Statement reads:

“Standardisation in the field of information for health, and Health Information and Communications Technology
(ICT), to achieve compatibility and interoperability between independent systems. Also to ensure compatibility of
data for comparative and statistical purposes (e.g. classifications), and to reduce duplication of effort and
redundancies.”

The ISO/TC215 committee has a brief to deliver a working standard for global interoperability in health care within a
defined time span. Interoperability is an urgent need for healthcare systems. The proliferation and provenance of
information technology in Health Care cannot realize its full potential without it. The new technologies developing
around the World Wide Web are delivering an entirely new environment for electronic data exchange of all sorts.
The ISO process in its founding assumptions looks for international standards separate from de facto proprietary
standards.

© ISO 1999 – All rights reserved VII

WORKING DRAFT ISO/WD nnn-n

1.0 Scope and Aims

To prepare a report, in collaboration with WG4, on workable definitions and models relevant to EHR access. This
will include definition of the operations to be performed by an ethical framework for facilitating global, authorised
access to EHR.

1.1 Specifically excluded from the scope

Channel related security issues, authentication techniques, encryption algorithms, and other technical
matters which belong specifically within the scope of WG4.

1.2 Specific Aims

1. To retrieve and review the available international literature on access to health records

• Consider cultural concepts about rights and obligations which pertain to access to personal health
information

• Gather from different nations standards and documents that currently purport to regulate access to
health information (e.g. New Zealand ‘Health Information Privacy Code’)

2. To consider the relevance to EHR of access control in electronic commerce

• Consider current developments for access control in e-commerce

• Identify common ground with access control processes which might be of use in e-health

3. To explore and define concepts relevant to EHR access

• Develop operational concepts and their interrelationships relevant to EHR access

• Identify an underlying minimum set of concepts that could be implemented in a global system

4. To develop concepts and models of EHR access control across jurisdictional and national
boundaries

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

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

5. In light of the above, and in collaboration with WG4, to develop policies regarding appropriate
EHR access:

6. To advocate that an agreed global access mechanism be freely available to all credentialled
healthcare workers and free from commercial control

2 Terms and definitions

Terms and definitions used in this technical report are to be found in Annex A.

© ISO 1999 – All rights reserved 1

ISO/WD nnn-n

3 Review concepts and literature on access to health records

3.1 Cultural concepts about rights and obligations which pertain to access to personal health
information.

There is a diversity of views and practices surrounding the definition of personal information. This diversity is
apparent both between and within nations.

3.1.1 The definition of social man

The definition of social man can vary markedly between cultures, and with it are defined differing views of sociall
responsibility and distributive justice. Within the Western Tradition, some presuppose a definition of individual
autonomy that places care of others in the context of enlightened self-interest. More fundamentally, the concept of
'self' is seen as socially constituted (see Mulhall and Swift, 1996). There is a diversity of views in the area of rights
and obligations, definitions of the self, and relationships between the individual and society.

In order to be truly international, the Access Standard thus needs to be compatible with diverse definitions of self
and society and should have the flexibility to reflect cultural differences. It must therefore contain a framework,
which permits diverse solutions to these age-old questions. It 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.

3.1.2 Pakeha and Maori concepts in New Zealand

In New Zealand, the indigenous Polynesians (the Maori) have rather different concepts of family and community
compared to the now numerically dominant European (the Pakeha). Because New Zealand is bicultural, European
and Maori concepts of access and access control can be compared within the same country. Preliminary
discussions with Maori health professionals have emphasised the communal focus of Maori values, which contrasts
rather with the more individualistic Western tradition. For example, the notion of an extended family group (whanau)
helps to explain the Maori’s greater collective interest/input bearing on access to personal information.

Similarly, infirm or incompetent individuals often have a 'minder' (Kia Awhina) consensually assigned by the
whanau, who is then responsible for decisions relating to, the individual's health care. Similarly, 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. These and other examples challenge the supremacy of the individual enshrined in
Western privacy laws, based on the OECD guidelines (see Introduction).

It might be possible within New Zealand to have a 'Maori values' option for the individual to select how the rights
and obligations surrounding EHR access are specified. This has a precedent in the choice that individuals of Maori
descent have in their political (electoral) role. Quite possibly, the option of 'Maori values' as a customisation choice
in EHR access control would be open to all New Zealanders.

3.1.3 National and Jurisdictional Differences

Access to EHR will need to be customised to respect these cultural differences within one country, and it can be
confidently predicted that national differences will, in many cases, be greater than those discussed above.
Moreover, access control will need to be applied in military and other institutional environments (e.g. jails) where
quite other than conventional Western concepts of individual autonomy and sovereignty may prevail.

In this report, we will not grapple further with cultural concepts. As indicated in the Introduction, our brief is to
develop models of access, rather than sets of rules. We propose that national, cultural and institutional differences
in EHR access control should be achievable by customisation of access parameters.

3.1.4 The Concept of Ownership

This concept is commonly employed in access regulation processes at present. The concept of ‘Ownership’ can
however be deconstructed into rights and their reciprocal obligations. 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.

2 © ISO 1999 – All rights reserved

ISO/WD nnn-n
3.2 Review of international literature on access to health records

This section includes:

• Background on ethics of privacy and autonomy

• Critical overview of national standards and procedures, including assessment of the extent of international
consensus on principles relevant to access

• Assessment of the extent to which nations endorse the concept that access is justified in some circumstances
and not in others

• Assessment of the implied requirements for ethical access, and comparison with our 'requirements list' (see
below)

• Synthetic overview, conclusions and recommendations

3.2.1 Background: The Ethics of Privacy

An important cornerstone of medical ethics in the Western world is the notion of autonomy (Beauchamp 1994). As
rational decision makers we are obliged to give others the freedom to make and carry out their own decisions
regarding their ‘life plans’, this freedom and the corresponding responsibility for these decisions are considered to
be “fundamental to human flourishing” (Gillett 1989, page 35). Privacy interacts with other social conditions to
create an environment in which a person is able to make and execute rational decisions, that is, exercise their
autonomy (Friedlander 1982). In this way privacy is not something that needs to be justified in its own right, but is
rather a means towards an already justified and important end, autonomy.

3.2.2 Overview of national standards and procedures

A review of various national and other documents is summarized in the Table (Annex Two). In 1980 the OECD
issued guidelines for privacy policy in order to facilitate the development of compatible legislation. These guidelines
have been influential, and consequently there is a reasonable degree of concordance in policy internationally.
However, this concordance can be seen to relate mainly to principles rather than to specific rules or procedures
relating to access. In particular, laws and policies regarding personally identifiable data often do not explicitly relate
to health information (e.g., United Kingdom Data Protection Act, see European Commission Report 1999).

Despite a variety of approaches to regulation of access, there is a general harmony of underlying principles which
should facilitate the development of a global standard. The following is a summary of what would be needed in a
privacy policy in order to satisfy the requirements of the documents reviewed in Annex Two.

3.2.3 Data Collection

There is widespread agreement that at the time of collection of data consent must be obtained for its storage and
for the intended uses. There is some variation in policy as to whether consent should be written, and whether the
terms can be changed later by either party (see Table, Annex Two).

Some countries require that the data be collected from the individual where possible. This is not universal but it is
logically consistent with the principle of gaining an individual’s consent for the collection of data. Although not
openly stated in all documents, data collection should also be by means which are legal, fair and not unduly
intrusive.

The data that are collected and stored should be limited to those which are necessary for the purpose for which
they are being collected. In addition, this purpose ought to be a legitimate one. These principles correspond to
those governing legitimate access, in the sense that access should be limited to data which are necessary for the
purpose at hand (e.g., clinical care, funding or research).

3.2.4 Storage and Security

The agency which stores the data is generally held to be responsible for taking reasonable steps to ensure the
security of the data. Although the term reasonable is widely used, its interpretation may vary. In the case of health
records it would be reasonable to expect a high standard of security. The data ought to be protected from loss,
unauthorised use, modification, or disclosure, or other use. As part of this protection some countries expect that


ISO/WD nnn-n
the agency holding the data ought to be able to account for all accesses to an individual’s data. Thus, with regard
to EHR, provision for an access audit trail would be important to include.

Mechanisms of security, though not part of this report, also have pervasive ethical and legal implications. These
will be specifically addressed by WG4.

3.2.5 Access and Corrections

There is also widespread agreement internationally (Annex Two) that individuals have the right to access any data
held about them, and request changes be made if necessary. The strongest right is to know that information is
being held. Following this, the right to access the information. There are a number of exceptions to this principle:

If disclosure of information would breach another’s confidentiality. This would be avoided by only storing
information gathered from or known by the individual, but there will be instances when such an approach is not
practicable

If disclosure of the data could compromise the individual’s mental or physical health. Such clauses seem to be
included in order to assuage concerns of doctors, although actual cases where such concerns are justified are
likely to be rare

Court orders or proceedings can also be used as a reason to refuse access in various jurisdictions, although there
is considerable national variation in how this is done

There are other reasons stated also, for example if the request is ‘frivolous or vexatious” (New Zealand Health
Information Privacy Code, 1994)

Of note is that if one of these exceptions pertain, this should be indicated to the individual, and reasons for denial of
access explained in full. In addition all other data must still be made available with the relevant/sensitive items
removed.

In terms of requesting changes, it is generally agreed that all reasonable requests must be complied with. If the
agency is to refuse a request it must explain why. An individual may then request that a note is made that a certain
request for change was made. Again there are varying degrees of detail regarding this issue from country to
country.

The USA document recommends that, if necessary, individual institutions develop and document policies regarding
rights to access and corrections. In New Zealand there are very detailed policies in the Privacy Code which are
intended to apply across the whole country. Other nations fall between.

New Zealand and the USA which have explicitly required that each agency that holds health information to have a
Privacy Officer/Official who is responsible for handling such requests and complaints and would then report to a
statutory authority, such as the Privacy Commissioner in New Zealand (see Annex Two).

3.2.6 Access

In the documents reviewed in Annex Two, the concept of access was referred to in terms of legitimate uses and
disclosures of health information. There is considerable variation in how access is sought and achieved in various
countries. France and Canada, for example, have proposed information systems which include access control.
Most other countries (e.g., New Zealand, USA) have concerned themselves more with privacy protection legislation
in advance of such anticipated developments in technological mechanisms of access.

There is also some inconsistency in terms of uses of health information. There is widespread agreement that there
should be consent at the time of collection for the use of the data (see above). Development of a robust consent
procedure is the most reasonable way that an internationally compatible system can be produced. Canada in
particular proposes a fairly detailed consent procedure that includes any future possible research. The proposed
rules for the USA state that the agency that holds the data must have documented policy regarding data use, but
allows for agencies to change this policy at any time. This may not be acceptable internationally. In general most
types of data use can be predicted. In addition to personal health care, these further uses might include public
health measures and epidemiological or other biomedical research. It should be possible to obtain consent from the
individual at the time of data collection for these various uses in general terms. For example identifiable, non-
identifiable, identifiable but reported in a non-identifiable way.

There are some compulsory uses of the data, such as notifiable disease reporting, etc. Whilst consent cannot be


ISO/WD nnn-n
withheld for these required uses, the individual ought to be informed of the possibility of these uses.

In terms of access and disclosure there is inconsistency in how detailed the various documents are (see Annex
Two) but the underlying principle seems uniform. Although in general terms disclosure is very limited there will be a
number of exceptions required. These will be in order to conform with other laws. Different countries will have
various laws regarding compulsory disclosures under court order, to facilitate investigations, to report crimes, or for
quality assurance or peer review, to name a few. In general these are important and necessary to the functioning of
that society. However, international inconsistency could be a real problem in this regard. If something is recorded in
confidence in one jurisdiction, but requires reporting in another, where does responsibility lie?

3.2.7 Unique Identifiers

Involved in the issue of unique identifiers is the question of cross referencing health information with other
personally identifiable information. Although unique identifiers can enhance privacy in some situations when they
are used too widely they may endanger privacy. For this reason it would be unacceptable to use a unique identifier
for the health information database that was also used for some other purpose, e.g., electoral roll, welfare benefit,
vehicle licensing, etc. This obviously would not include using name, birthdate or address.

3.2.8 Recommendations for international consistency

At the time of collection written consent should be obtained for the storage of the data. In addition the potential
further uses for public health and research should be consented for in general terms. This consent should not be
conditional, ie. failure to consent to all or part of this should not affect the patient’s care in any way.

Data should be collected by legal, fair and non-intrusive means, and where possible from the individual concerned.
Data should be limited to what is, or is likely to become, necessary.

The organisation that controls the EHR would be responsible for ensuring a reasonable level of security.

An individual is entitled to know that data are being held about them. They have a right to access but this right is
not absolute. They also have the right to request changes, if this request is refused they may reasonably ask that a
record of their request be added to the EHR.

Uses should be restricted to those consented for at the time of collection. Disclosure should only be with the
consent of the individual. There will have to be exceptions to these two points in order to comply with other
legislation.

Any unique identifiers would have to be unique to the EHR. Cross referencing to other databases would be
problematic because of risks to privacy.

3.2.9 Problems with inconsistencies across jurisdictions

Differences between states/provinces/counties in some countries add to the total differences worldwide being
many. The positive side of this is that by the time federal governments have sorted things so that states have
compatible laws they will probably be so generic as to also be compatible with most other countries.

Non-OECD countries may present a problem as they are less likely to have privacy laws compatible with the
guidelines. In this case it would be up to local case law and possibly the strength of local contract law regarding
rules of access to the database in order to protect privacy. This might not be acceptable for OECD countries. The
origin of the OECD guidelines was from reluctance to exchange information with countries with less stringent or
absent privacy laws. This reluctance may continue to inhibit exchange of health information today.

An extension of this inconstancy is the difference between punitive measures for breaches of privacy between
nations. Most of the policies reviewed agree that there must be significant penalties for breaches of privacy but the
exact meaning or degree of significance varies and is often not specified. Differences in this and all the other
complications of international law may complicate enforcement or punishment following a breach. The nature of
these complications is outside the scope of this report.

3.2.10 Possible solutions

For Western nations, from an ethical point of view it is not acceptable to allow potential breaches of a person’s
privacy to occur through data sharing with a country with poor privacy protection. A “lowest common denominator”
approach may not be satisfactory, neither would a “when in Rome” approach. The OECD viewpoint suggests that


ISO/WD nnn-n
any person is entitled to enjoy the level of privacy protection described in the above recommendations. If this level
is not provided in a given country, some would argue that the international community (UN and other) should
facilitate development of such privacy protection, and not condone breaches of an individual’s privacy whilst they
are in such a jurisdiction.

As a means of augmenting protection, civil contracts relating to data access might be useful in countries with few
privacy laws in order to provide more protection than provided by current law.

As a means of reaching international standardization with respect to EHR access, a set of principles might include
the above headings, as well as provision for specification of national and cultural differences. However an ISO
standard cannot be prescriptive in this regard.

Based on the foregoing, we suggest that interoperability across jurisdictional and national boundaries can only be
served by a basic shared technique for performing the requirements for EHR Access. The differences in access
requirements between different jurisdictions can be expressed as customisation of elements within such a shared
technique

4 Relevance to EHR of access control in electronic commerce

4.1 Levels of Access control

Access control in electronic commerce can be considered to have the same levels as in the EHR,

• application

• computing hardware

• physical (e.g., site security, locks on doors).

Only the first of these is of relevance to this report.

4.2 Types of access control

Three types of access control mechanisms are generally available for protecting confidential documents through
Web access:

• Client hostname and IP address restrictions

• User and password authentication

• Strong authentication techniques

4.2.1 Client hostname and IP address restrictions

The simplest technique is that of the access control list. The first method cannot be considered secure enough for
EHR. This is because the server implicitly trusts the information sent by the client request in order to make its
access decision, and this can be easily 'spoofed' or fabricated.

4.2.2 Password protected access control lists

These can be centralised or distributed. The distributed scheme creates an access control file in the directories of
the protected resources. This has the advantage that every time access to a protected resource is requested, the
corresponding ACL file is reread and re-evaluated. However, it is more of a problem for the system administrator
than the centralised scheme. He or she must maintain distributed access control files. When the distributed system
has large numbers of users working under different access control regimes (as would be the case with a global
healthcare standard), the logistic problems are multiplied (Ghosh 1998).


ISO/WD nnn-n
4.2.3 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.

There is some work reported by DSTC, one commercial concern specialising in interoperability between computer
applications. Details are available at: http://security.dstc.qut.edu.au/projects/access/RBAC.html

DSTC suggests that the greatest advantage of RBAC is its flexibility and low management overhead. In a large
organisation or distributed system, a RBAC framework can also establish such that the administrative task can be
decentralised. Thus it can naturally reflect the organisational structure. This work might be adapted for use in e-
health but it does not appear to be highly developed as yet.

4.2.4 Strong Authentication Techniques

E-commerce makes use of the strong forms of authentication supplied by digital signatures and certificates.
Discussion of these is beyond the scope of this paper. Clearly the concept of Attribute Certificates as mentioned in
the Draft Technical Specification by WG4 (see below) is very relevant for e-health. It does appear that roles and
their validation can be identified and confirmed as securely as digital certificates. It is with this exciting concept that
some proposal are made below for collaboration between WG1 and 4 on EHR Access.

The challenge of EHR transmission may result in new techniques for RABC that could contribute to role based
access control in e-commerce generally.

4.2.5 Intellectual Property Rights

A related field is that of ‘intellectual property’ rights, and these have a large legal literature. There is overlap
between rights in intellectual property, and rights in medical data, and both might be validly argued to be part of any
global EHR structure.

However, it appears that there is already a global standard in evolution for the electronic management of
intellectual property. Such a standard is the ‘INDECS’ project (Interoperability of data in e-commerce systems
generic metadata model. See www.indecs.org/ ). This aims to provide a standard semantic framework for an XML
(Extensible Mark Up Language)-based infrastructure for integrating metadata (data about data) in the World Wide
Web. The very existence of such a product for e-commerce will influence our attempts to gain global consensus
(or alignment) for the EHR. The concept has architectural features. The generic concepts of ‘People’, ‘Stuff’, and
‘Deals’ and the relationships between them could also be made to apply to the EHR. To quote from the ‘INDECS’
document: “Not only can metadata be precise and all-embracing, but in the distributed digital environment now
dominating the future of intellectual property management, it has (sic) to be”.

The INDECS generic model will be expressed as a technical data model using the W3C standard RDF (Resource
Description Framework) based in XML www.W3org/RDF/. This is intended to integrate a variety of web-based
metadata activities.

The model that we develop below separates demographic and ID data (people), clinical data (stuff) and financial
data (deals), and might be compatible with the INDECS scheme. The INDECS project as yet lacks an access
control technique. The approaches from intellectual property and e-health might be complementary.

4.2.6 The Platform for Privacy Preferences

The World Wide Web Consortium also has developed a Privacy Preferences Protocol, which can mediate between
the privacy practices in different web sites, to come to an agreement about the release of information
(http://www.w3org/TR/2000/WD-P3-P0000211). However this is limited to regulating information that web sites
collect on clients, and does not regulate access to data themselves.


ISO/WD nnn-n
5 Concepts relevant to EHR access

5.1 Developing operational concepts and their interrelationships relevant to EHR access

5.1.1 Roles and Rules

We suggest that cultural concepts regulating access can be considered as sets of ‘roles’, and ‘rules’ relating those
roles. Operationalizing them comprehensively for any one culture or jurisdiction will be a challenging exercise and
may well show up redundancies, inconsistencies and gaps in sets of concepts.

Systems of roles and rules are mutually defining. Our task is not to try to evolve some sort of ‘definitive set’. Rather
it is to develop a model or models that can implement different sets of rules and roles for specified nations or
jurisdictions, yet remain globally interoperable.

5.1.2 Self–defining systems

The concept of self-defining systems has its origin in theoretical linguistics (de Saussure, 1899). The 'values' or
'meaning' of individual roles can only be discovered in relation to the whole set. The game of chess is an example.
The concept of ‘roles’ has its own extensive literature in sociology (cf. Cicourel 1973).

In healthcare, we suggest that any role definition will comprise relationships to other roles relevant to that setting.
Considerable overlap in definitions is likely between related jurisdictions. As mentioned above, the OECD work
preceded many Western national efforts to regulate access, and has imparted many common elements to such
efforts. These are likely to flavour the ultimate standard. However it is not the concern of a standard for
interoperability to argue for any particular ‘solution’ or group of related solutions.

5.1.3 The Role concept in Messaging

In Annex C: of the CEN TC251 'Short Strategic Study on Message Alignment', there are proposals for
implementation of the "revised structure for the representation of Healthcare Agents". This same document was
included in minutes for distribution after a recent ISO/TC215 WG2 meeting.

With this concept, we find that WG2 is already considering the tools needed for modelling roles and rules
generically. In the CEN scheme, (Markwell 1999, section 3.3) the concept of role is defined, "A role of a healthcare
agent is undertaken in the context of their relationship with another agent". This concept is further illustrated by the
statement, "A healthcare agent in the context of a specified relationship with another healthcare agent (a
healthcare agent in context) may perform a role”. Thus the ‘messaging’ standard role comprises an agent, a
context and an action. Thus a role can be considered a simple syntactic structure (Subject, Noun, Verb).

The CEN document referred to above is under consideration for adoption as the ISO standard. This would include
a synthesis of HL7 and CEN proposals. Markwell indicates, from the CEN perspective, that the technique of
defining roles is an attempt to be generic. We suggest that this is an area where WG1, 2, and 4 need to
collaborate.

Markwell also suggests that the 'message' could be a direct transcription of UML to XML. If the role and rule sets
were locally defined, there could be a local document type definition set for the XML expression of the local rules
and roles. The 'standard' would be concerned with the way this was done, not the concepts used within any one
user group or jurisdiction.

5.1.4 The Role concept in Security processes

The ISO/TC215 WG4 paper ‘Technical Specification Public Key Infrastructure for Secure Exchange of Health
Information Across National Boundaries’ (February 2000) uses the concept of ‘role’ in relation to ‘attribute
certificates’. They point out that control decisions about request and disclosure can be rule-based, role-based and
rank based . They suggest that such information should be supplied by using an ‘attribute certificate’ that is bound
to a health professional’s public key. A health professional may have many of these, which reflect multiple roles.
Such attribute certificates are typically more short lived than the identity certificates.

When these processes have authenticated and verified the identity and role of the healthcare agent who makes a
request, some kind of matching process must occur to establish the rights and obligations that the requester has to
data. The WG4 work does not define a complete access-regulating process, but will be essential to such a process.
The model below suggests how identity and attribute verification might be built in to a generic process of access


ISO/WD nnn-n
control.

5.2 Minimum concepts that could be implemented in a global system

5.2.1 Four related concepts

The concept of ‘Access’ to the EHR has a reciprocal, 'Failure of Access' or which is further separable into Privacy,
Secrecy, and Data Not Found. The concepts of Rights, Obligations, Access and Failure of Access are interrelated
concepts which define each other, and can be considered together both theoretically and practically.

Rights

Access Failure of Access

Obligations

5.2.2 Three irreducible outcomes

We have identified a minimum set of possible outcomes from requests for information subject to access control.

Access access criteria matched, information identified and available

Failure of Access information identified, access denied (Privacy)

information identified by receiver, not identified to requester (Secrecy)

information not identified by receiver (Data Not Found)

N.B. From the requester’s (but not the receiver’s) perspective, the latter two outcomes are indistinguishable.

Thus, the receiver would be aware of four, and the requester three, basic outcomes.

Hirose (1998) has provided an elegant simplification of access errors which cuts across the above outcomes:

Case 1 "Could not access, although the information was necessary for clinical use" (inappropriate access failure)

Case 2 "was able to access, without valid reasons for patient care or management"(inappropriate access)

These similarly reduce down the multitude of different errors to two simple categories, and encourage us to think
that the same basic logical model of access is global in its relevance.

This simple triplet of possible outcomes for access requests is 'Boolean' in its derivation. An access request can
either find matches, or not find matches. Once found, a data object can either be opened, or it cannot be opened.
That simple reality models our three basic conditions of access, privacy, and secrecy.

5.2.3 The Access Control Matrix

The level of rules and roles can be modelled as existing above and triggering one of three outcomes depending 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. Hirose (1998) has demonstrated a graphic representation of such
an ‘n’ dimensional ACM. This might also be modelled in the form of a tree diagram.

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. The outcome of the match between request ACM and the ACM protecting
identified target data would supply the data if an appropriate match were made. Different request objects might
allow different levels or ranges of access, depending on their request template and ACM. Such is the complexity
and sophistication of contemporary computer game technology that the above concept should be readily


ISO/WD nnn-n
implementable.

6 EHR access control across jurisdictional and national boundaries

6.1 Jurisdictional boundaries

The purpose of this section is to develop concepts and models of EHR access control across jurisdictional and
national boundaries. The goal of the ISO/TC215 process will include this among its requirements. 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 in some instances a jurisdiction might be as small as a single
provider organisation or even provider. We need to:

• 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)

6.2 Requirements

In 'Requirements' lists for components of an EHR, the elements are arbitrarily demarcated from each other. In a
functioning EHR, all the elements are part of all the other ones. For example, a separate listing for ‘medico-legal’,
ethical, ‘privacy and security’ and ‘exchange and sharing’ requirements is misleading, since each is part of the
others.

We recognise that 'Communication' security services and 'Application 'security services need to be distinguished.
(see discussion of electronic commerce, above).

We assume that we are dealing with the latter, which will involve the ethical and privacy aspects, although the
implications for 'security' again emphasise the overlap between categories. This is why our report needs to be in
collaboration with WG4. Our 'requirement' list includes:

6.2.1 Availability

Involved in this concept are the ‘what’ ‘when’ ‘who’ ‘where’ and ‘why’ of access to health information

• 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: there should be some system in place for defining personal identity information, regulating ‘who’ can
access a demarcated segment of information, based on their role with the individual (e.g., as their doctor)
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

6.2.2 Data Integrity

• Participating systems should have procedures which authenticate the source of health information and
which verify it as unchanged when communicated

6.2.3 Auditability

• EHR should be auditable, both with regard to content and by an ‘audit trail’ of access (an ‘access history’


ISO/WD nnn-n
for health information should be traceable) It should be possible to discern modification/updating of EHR
using version control.

6.2.4 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 culture or jurisdiction.

6.2.5 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

6.2.6 Accessibility

• There should be open access for suitably credentialled workers

6.3 The Access Object Model

'Ordinary life fits the absolute as a box and its lid'

from: 'Sandokai' ('Identity of Relative and Absolute') Shih-tou 700-790 CE

In pursuit of a universal solution for an interoperable 'access' technique, we propose the following axioms:

Axiom 1: The boundaries of what can be accessed in EHR should be configured around the subject of care.

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

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

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

Our model links the 'action' of 'attestation' to the assignment of culturally sanctioned access rules at the time of the
creation of data objects (or object clusters) which occurs in the clinical encounter. The assignment of access
controls is not seen as a separate process to data collection, but to occur at the time of collection, as part of
'attestation'.

6.3.1 Attestation

This a concept with practical, medical, and medico-legal implications. For a practising doctor in the pre-electronic
era, attestation could be considered to occur constantly, in the recording on paper. The undertaking not to alter or
modify records except explicitly has been a fundamental medical-legal assumption of medical practice. More
fundamentally, a surgeon can be thought of as continually 'attesting' his or her work on the patient.

This 'automatic' nature of attestation must be transferred to the electronic record making medium in a way that
does not delay or embarrass the process of medical care. However, attestation remains the ‘action’ of medico legal
significance in medical record keeping.


ISO/WD nnn-n
6.3.2 The Security WG4 contribution

The mechanisms of digital certificates and signatures are the closest that we have to any concept of 'the absolute'
on the web. If we can find a way of allowing the relativity of cultural concepts and practices to be grounded in this
absolute universal technology, we will have achieved the desired fit of the relative and absolute for this process.

It seems likely that the global 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 models of the ‘access’ process which will enable that synthesis.

The Technical Specification that WG4 has developed is remarkable for its detail about Certifying Authorities,
Registering Authorities, Public Key Infrastructure, and Attribute Certificates. WG4 are in no doubt that the
specification must be internet-based.

'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.'

The ISO/TC 215 WG4 specification suggests that interoperability across national boundaries be achieved by a
series of bilateral and multinational agreements between registration authorities. They point out that the
infrastructure for this does not yet exist, but suggest that it should. Until it does, they recognise that there is some
risk in the transfer of confidential information.

The solution we propose will be based on the PKI and Attribute Certificate Infrastructure proposed by WG4. The
security techniques now appear available for authentication, non-repudiation, and for ensuring integrity and
confidentiality of transmitted health data. However, they are insufficient in themselves to constitute a global access
regulating technique.

6.4 Access Objects

• We propose a class of metadata (data about data) objects, which are created alongside health data at the
clinical encounter or interview. They could also be used to protect data objects created in other kinds of
transactions.

• These metadata objects are linked to clinical data in a standard (ISO certified) way, but are themselves not
prescriptive of the form or grain of those data.

Access Objects could thus serve different schemata for data structure and architecture. They would also be
functional for linkage to data objects with little formal structure, e.g. word processed documents, as might be
predominant in technologically unsophisticated environments.

The proposed model would work by authentication of identities and roles occurring like 'welds' or 'rivets' in the
ongoing process of medical work. We have modelled this process using the Unified Modelling Language (UML).

6.5 Model of Access Control Mechanism.

The following section contains a UML model that outlines the basic processes of accessing patient information.
The section also gives a brief overview of a model for an implementation. The focus in on a high level conceptual
model of the process of accessing patient information; underlying issues such as techniques for authentication and
security are assumed to be dealt with elsewhere.

The Use Case Diagram below illustrates the scope of the system under consideration.. It shows the actors who will
interact with the system and the way that the system will be used.

Data providers create information. The model assumes that default sets of access rules can be established
according to the local customs and legislation. These are automatically associated to the different categories of
data when the data are created or collected.

One role of the patient is to define or modify, as necessary, the access rules that are applied to their information.

Two types of actors generate requests for access to information:


ISO/WD nnn-n
1. Data Users, are people who generate requests for specific information about a patient.

2. Researchers, who request de-identified information about groups of patients.

The supervision of the system and the establishment of access rules is under the control of the security manager.

6.5.1 Use Case Diagram of Access Control Mechanism

Data User
Data provider

create patient information

request patient information

define access rights
patient

monitor access to information
security manager

request de-identified information
researcher

The behaviour of the system can be realised by the activities of a number of objects that are represented in the
Class Diagram, given below.

The implementation of the class diagram has some major assumptions. Firstly, there are issues relating to the
structure and mechanisms associated with the storage of the patient information:

1. A patient record consists of some fairly constant data (here called demographic data) plus a number of
attestable units that are created during consultations, examinations, laboratory procedures, etc. The
“demographic data” may in fact be broken down into smaller units under separate control, but this is not shown
here for the sake of clarity.

2. Attestable units consist of multiple clinical objects which may be built from other clinical objects.

3. Attestable units may also contain financial information under separate control.

4. The audit trail is associated with the object. (in order to record access to the data).

5. Access permissions may operate at any level, with the option of access being increasingly restricted at the
attestable unit level, clinical object level or financial object level.


ISO/WD nnn-n
6.5.2 Access Lock Objects

Access to data is afforded via the Access Lock objects that contain:

• a (data base) key to the data contained –(patient ID),

• a content definition, indicating the type of information contained in the object,

• the access control rules applicable to the object,

• a reference by which the data can be located,

• encryption keys

Access locks are replicable objects which may be stored in various locations, such as servers or smart cards, and
provide the link between a request and a data object.

All these assumptions could require extensive debate, for example:

• Record structure could be different

• audit and control might be applied at either a higher or a lower level

• relationships may be associations rather than aggregations. Aggregation has been used because
access keys and audit trails are essentially part of’ the data and there is no logical reason for them to
have a separate existence from the data to which they relate.

The following diagram illustrates the Class Structure of the Architecture of a Patient Record


ISO/WD nnn-n
6.5.3 Class Diagram of Architecture of Patient Information

demographic data

access lock
patient id
content definition attestable unit audit trail
access rules
reference to data
encryption keys

financial objects clinical objects

The handling of a request for information is implemented by 4 major components:

1. The Request Manager object handles the interface between the user and the data storage and retrieval
system. It is which is responsible for formulating a valid request with parameters and ranges, it is also
responsible for authentication of the user, user’s role, reason for access etc. It produces an Access Request
object.

2. The Access Request object (analogous to the codon in the immune system) is replicated and distributed to
Access Controller objects located at various data repositories for processing.

3. Access Controller objects serve as interface objects whose role is to handle the information contained within
their local repository. They receive Access Requests which they match against their known Access Lock
objects for matching data.

4. Access Controllers are also responsible for translating some aspects of Access Requests into the local format
between systems and jurisdictions. For example they may be responsible for translating roles or relationships.

5. When the Access Request has located a matching Access Lock, the Access Lock enforces access controls,
updates the audit trail and returns the requested information via the Access Request.

The overall class diagram illustrating the structure of the system is given below. Notice the symmetrical
relationship between the Access Request and the Access Lock. Access is granted when the request matches the
patient identifier and content definition and also when the user, role and reason for access meet the criterion
expressed in the access rules.


ISO/WD nnn-n
6.5.4 Class Diagram of Access Control Mechanism

request manager access controller

demographic data

access request access lock
patient id patient id
request template content definition attestable unit audit trail
user id access rules
user role reference to data
reason for access encryption keys

financial objects clinical objects

The processes involved in handling requests for information are explained in the sequence diagrams given below.
These are used to define the sequences of actions of the system.

The first figure illustrates the request patient information usecase, for the case where a successful match is found
for some demographic data and on some information held within an attestable unit.

The second figure illustrates the request de-identified information usecase, for the case where a successful match
is found on some information held within an attestable unit, but no information is returned from the demographic
data.


ISO/WD nnn-n
6.5.5 Sequence Diagram of the Request Patient Information Usecase.

: request : access : access : access lock : demographi c : attestabl e : audit trail
manager request control ler data uni t

: Data User
1:

2:

3:

4:

5:
6: 7:

8: 9:
10:

11:

12:

13:

14:

6.5.6 Sequence Diagram of the Request De-identified Information Usecase.

: request : access : access : access lock : demographic : attestable : audit trail
manager request controller data unit
: researcher
1:

2:

3:

4:

5: 6:
7:

8:

9:

10:

11:

The philosophy behind the model is that it is to be built on multi-level architecture, with the user’s workstation being
attached to a local server and then widely connected via a network.


ISO/WD nnn-n
Patients may also carry smartcards, which interface to the workstation.

With this architecture, the actual data are under the control of the local access controllers.

The access lock objects may be replicated and stored at any level: smartcard, workstation or server.

This facilitates the matching of an access request that is generated on the workstation with an appropriate access
lock, which will eventually lead to the retrieval and delivery of the data.

smart
card workstation
Server network

7 Discussion

Access objects, which could be stored on smart cards or identified by search could constitute a currency for the
exchange of health information around the world. However, without detailed alignment of attribute definitions in the
access objects and their matching request objects, the access objects would not constitute interoperable currency.
Therefore, without a previous treaty that permits the access object to be recognized in a new (host) jurisdiction, the
‘currency’ would not be accepted and interoperability would fail.

However since the technique for accessing (or failing to access) data would be shared, alignment negotiations
would be greatly simplified and might be expected to occur in a similar way for each pair of countries or
jurisdictions. With basic research justification, and without further negotiation, ISO compliant systems could share
de-identified data. The advantages for epidemiological research would be profound.

To summarise the process:

• Attestation occurs at the clinical encounter

• The collection of clinical objects thus formed has, by the same act, an access object assigned to it.

• These contain a (data base) 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 Request Object made by the request manager also contains 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

• 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’ 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.

8 Recommendation

That the possibility of such a synthesis between requirements and implementation is further explored, along with
any other options offered by other members of WG1 and WG4.


ISO/WD nnn-n
If a shared technique were developed which facilitated interoperability, it itself should not be ‘owned’ by any
individual or organization, except possibly ISO or the UN. This would safeguard flexibility in innovation and delivery
of healthcare for the future, and allow for the emergence of possibilities as yet undreamed, or as the classic and
ubiquitous Latin medical acronym states, ‘for that yet to be born’, or pro res nata (PRN).


ISO/WD nnn-n
Annex A: Terms and Definitions

Terms and definitions are from diverse sources, including Standards Australia 'National Requirements for the EHR,
and Markwell (1999).

Access

Right, opportunity, or means of finding, using, or retrieving information

Access Control Rule

A constraint on the action of a health care agent in a particular context to access health information

Accountability

The property that ensures the actions of an entity can be traced uniquely to the entity (Ref : ISO 7498–2)

Authentication

The process of reliably identifying security subjects by securely associating an identifier and its
authenticator (Ref : ISO 7498-2)

Authorise

Granting of rights, which includes granting of access based on access rights (Ref : ISO 7498-2)

Availability

The property of being accessible and useable upon demand by an authorised entity (Ref : ISO 7498-2)

Classification

Systematic idenitication and arrangement of business activities and/or records into categories according to
logically structured conventions, methods, and procedural rules represented in a classification scheme

Clinical information

Information about a subject of care, relevant to the health or treatment of that subject of care, that is
recorded by or on behalf of a healthcare person

NOTE: Clinical information about a subject of care may include information about the subject of
care’s environment or about related people where this is relevant (Ref : ENV 1613)

Confidentiality

The characteristic of data and information being disclosed only to authorised persons, entities and processes at
authorised times and in the authorised manner (Ref : AS4400). Alternatively, the policy and procedures used by an
organization or individual given access for a particular purpose.

Conversion

Process of changing records from one medium to another or from one format to another.


ISO/WD nnn-n
Data

Representation of facts, concepts or instructions in a formalised manner suitable for communication, interpretation
or processing by human beings or by automatic means (Ref : OECD Security Guidelines)

Data integrity

Property that data has not been altered or destroyed in an unauthorised manner (Ref : ISO 7498-2)

Document

Structured units of recorded information, logical or physical, not fixed as records

Electronic health record

(1) A collection of data and information gathered or generated to record clinical care rendered to an
individual. It is to be noted that the EHR is a virtual entity where the actual physical information may
be distributed across various systems and geographies.

(2) A comprehensive, structured set of clinical, demographic, environmental, social, and financial data
and information in electronic form, documenting the health care given to a single individual. (Ref :
ASTM 1769)

The EHR is the structured record of an individual’s complete health status and health care. It is a comprehensive,
structured set of clinical, demographic, environmental, social, and financial data and information in electronic form,
documenting the health care given to a single individual and extends from pre-birth to post-death and must meet all
record keeping requirements.’ It may be a ‘virtual entity where the actual physical information may be distributed
across various systems and geographies.’

Electronic patient record

The EPR describes the record of the periodic care provided mainly by one institution or provider. It generally exists
in one place or on one system, and therefore is seldom virtual. An EHR is made up of EPRs. The fact that EPRs
can come from diverse sources where different Access criteria may apply is one of the reasons we need to develop
a Standard to facilitate interoperability.

Electronic record

Record on electronic storage media, produced, communicated, maintained and/or accessed by means of
electronic equipment

Electronic health record system

An Electronic Health Record system forms the mechanism by which patient records are created, used,
stored, and retrieved. It includes people, data, rules and procedures, processing and storage devices, and
communication and support facilities. (Ref : CBPR)

healthcare agent

Healthcare person, healthcare organisation, healthcare device or healthcare software component that performs a
role in a healthcare activity.

healthcare agent in context

One or more healthcare agents related together in a specified manner for the purposes of performing a particular
role in a healthcare activity.


ISO/WD nnn-n
healthcare agent in context reference

Reference to a healthcare agent in context, which uniquely identifies that healthcare agent in context in the context
within which it is used.

NOTE: Use of healthcare agent in context reference depends on the existence of shared information describing the
healthcare agent in context to which it refers.

healthcare agent role

A role played by a healthcare agent (or by a healthcare agent in context) in a healthcare activity.

EXAMPLE: Originator/author of a record entry, Requester of a service, Provider of a service, Sender of a message,
Recipient of a message, Person signing a message or record entry.

healthcare agent reference

Reference to a healthcare agent, which uniquely identifies that healthcare agent in the context within which it is
used.

NOTE: Use of healthcare agent reference depends on the existence of shared information describing the
healthcare agent to which it refers.

healthcare agent relationship

A relationship between two healthcare agents.

NOTE 1: A healthcare agent relationship may apply for a specified period of time.

EXAMPLE 1: Employee / employer

NOTE 2: A healthcare agent relationship may be specific to a particular healthcare agent role.

EXAMPLE 2: On behalf of / responsible for.

healthcare device

Device or equipment involved in the direct or indirect provision of healthcare services to an individual or to a
population.

EXAMPLE: ECG machine, auto-analyser, syringe pump.

healthcare organisation

Organisation involved in the direct or indirect provision of healthcare services to an individual or to a population.

NOTE: Groupings or subdivisions of an organisation, such as departments or sub-departments, may also be
considered as organisations where there is need to identify them.

healthcare party

Organisation or person involved in the direct or indirect provision of healthcare services to an individual or to a
population.

healthcare person

Person involved in the direct or indirect provision of healthcare services to an individual or to a population.

EXAMPLE: Primary care physician, dentist, nurse, social worker, pharmacist, medical secretary.

healthcare software


ISO/WD nnn-n
Software component involved in the direct or indirect provision of healthcare services to an individual or to a
population.

EXAMPLE: EHCR system, decision support software, viewing tools.

Healthcare data

Data which are input, stored, processed or output by the automated information system which support the
business functions of a the Healthcare organisation. These data may relate to person identifiable records or
may be part of an administrative system where persons are not identified (Ref : HL7)

Health information

• The determinants of the population’s health, including those in the external environment (physical, biological,
social, cultural and economic) and those internal to individuals (for example, knowledge, behaviour, disease
risk factors, and physiological, biochemical and anatomical variables which might be measured or imaged);

• Health interventions or health services, including those which have been provided directly to individuals and
those provided to communities, and covering information on the nature of interventions, management, resource
allocation, accessibility, use and effectiveness; and

• The relationships among these elements

Information

The meaning assigned to data by means of conventions applied to those data (Ref : OECD Security Guidelines)

Longitudinal/lifetime patient record

A permanent, coordinated record of significant information, in chronological sequence. It may include all historical
data collected or be retrieved as a user designated synopsis of significant demographic, genetic, clinical, and
environmental facts and events maintained within an automated system. (Ref : ASTM 1384)

Metadata

Data describing data

Migration

Moving records, while maintaining authenticity, from one electronic system to another without major conversion or
inputting of data

Originating organisation

Corporate body or organisational unit in which records are created or received and accumulated in the conduct of
its business

Privacy

The legal right a person has to determine what information is accessed by whom and to what purpose

Preservation

The processes and operations involved in the stabilisation and protection of records

Records

Data created, received, and maintained as evidence and information by an agency, organisation, or person, in
pursuance of legal obligations or in the transaction of business


ISO/WD nnn-n
Records capture

Recognition of a record resulting in its inclusion in a system that manages records operations

Records management

The discipline and organisational function of managing records to meet operational business needs, accountability
requirements and community expectations

Records management plays many roles within an organisation and in the organisation’s relationships with the
world. Thus records management is concerned with the following :

Managing the records continuum, from the design of a recordkeeping system to the end of the records’ existence.

Providing a service to meet the needs, and protect the interests, of the organisation and its clients.

Capturing complete, accurate, reliable and useable documentation of organisational activity to meet legal,
evidential and accountability requirements.

Managing records as an asset and information resource, rather than as a liability.

Promoting efficiency and economy, both in the management of records and in organisational activity as a whole,
through sound recordkeeping practices.

(Ref : AS 4390.1)

Records systems

Information systems which capture, maintain and provide access to records over time

Registration

A method for giving a record a unique identifier

Retention period

The time period records are kept according to requirements including operational, legal, regulatory and fiscal

Records Retrieval

Process of recalling specific records from storage

Request

Attempt to access health information, whether personal, pedigree/group, or anomymised

Security copy

Copy of a record made in order to preserve the evidence and information it contains in case the original is lost,
damaged or destroyed

SNOMED

The Systematized Nomenclature of Human and Veterinary Medicine is a comprehensive, multiaxial nomenclature
classification work created for the indexing of the entire medical record, including signs and symptoms, diagnoses,
and procedures (Ref : NHS IFH)

Standard

Document, established by consensus and approved by a recognised body, that provides, for common and repeated
use, rules, guidelines, or characteristics for activities or their results, aimed at the achievement of the optimum
degree of order in a given context


ISO/WD nnn-n
Note: Standards should be based on the consolidated results of science, technology and experience, and aimed at
the promotion of optimum community benefits

(Ref : ISO/IEC Guide 2:1996)

Storage

Measures for keeping records under defined conditions and permitting their retrieval

Storage medium

Physical base on which information may be recorded

Subject of care

Person or defined groups of persons receiving or registered as eligible to receive healthcare services or having
received healthcare services [Example: patient]

(Ref : CEN ENV 12443:1996)

Tracking

Capturing and maintaining information about the movement and use of records

Trust

Reliance on the integrity, justice etc of a person, or on some quality or attribute of a thing

Universal identifier

A means to provide positive recognition of a particular individual for all people in a population. A universal health
care or patient identifier provides the identifier for use in health care transactions. (Ref : ASTM 1714)

User

A person or other entity authorised by a provider to use some or all of the services provided by the provider (Ref :
COACH)


Access report final iso format 29 mar 2000

Access report final iso format 29 mar 2000

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Similar to Access report final iso format 29 mar 2000

Similar to Access report final iso format 29 mar 2000 (20)

More from eyetech

More from eyetech (6)

Access report final iso format 29 mar 2000