HealthConnect
Business Architecture version 1.9
November 2004
Foreword
We have already seen one revolution in health, as computers have become used in all
areas of healthcare. We are now on the verge of a second revolution, as improved
communication technology makes it possible to share data between computer systems.
Information vital to a patient’s care can now be made available when and where it is
needed.
HealthConnect is a cooperative venture between the Australian, state and territory
governments. The core of HealthConnect is a national system of sharable electronic
health records, established to collect, store and exchange consumer health information.
Information will be transferred using a secure network with strict privacy safeguards.
Summaries of health events such as community consultations, hospital interventions,
prescribing history and recent test results can be made available when and where they
are needed – to the advantage of both consumers and health professionals.
For the past three years HealthConnect has conducted research, trials and extensive
community consultations. The business architecture is based on that work; it defines a
workable and achievable solution for stage 1 of HealthConnect and provides a
framework for future development, implementation and operational activities.
HealthConnect is moving closer to becoming a national reality with whole of state
implementations underway in Tasmania and South Australia. Significant development
projects are underway in several states. The business architecture and other technical
documents to be released shortly are providing the basis for this work to proceed.
Another important development is the establishment of the National e-Health Transition
Authority (NEHTA) to drive the national IM&ICT strategic priorities such as clinical
data standards, identification standards and provider directories. These will provide
important national components to HealthConnect.
This draft business architecture is being made available to provide the basis for
comment. Feedback from consumers and the broader health community will guide the
preparation of version 2.0 of the business architecture and also guide its ongoing
development.
There are important new elements of this version of the business architecture that are
designed to support the everyday operation of HealthConnect such as the introduction of
the eHealth Message Bank service for communication of referrals, prescriptions and
diagnostic tests between providers.
Nowhere else in the world has an extensive, truly national electronic health record
system been established. We are embarking on a long journey that we know will be
complex and challenging. HealthConnect will evolve substantially during this journey,
but we are confident the destination will provide significant benefits in improved health
care and health status for all Australians.
On behalf of the HealthConnect Board, I look forward to receiving your comments.
Dr Robert Wooding
Chair, HealthConnect Board
22 October 2004
i
Contacts and Further Information
If you require further information, or wish to comment on this document or any other
aspect of HealthConnect, please contact the HealthConnect Program Office at:
The HealthConnect Program Office
Australian Government Department of Health and Ageing
MDP 25
GPO Box 9848
CANBERRA ACT 2601
Fax: (02) 6289 8295
Email: healthconnect@health.gov.au
Alternatively, please contact your nearest interstate HealthConnect office, as follows:
Joanna Kelly
New South Wales
Ph: (02) 9391 9090
Fax: (02) 9391 9015
Ernest Higgs
Victoria
Ph: (03) 9616 2083
Fax: (03) 9616 8559
Karen Gibson
Queensland
Ph: (07) 3131 1679
Fax: (07) 3131 1687
Alan Nankivell
South Australia
Ph: (08) 8237 8276
Fax: (08) 8237 8070
Des Hutchinson
Western Australia
Ph: (08) 9222 4379
Fax: (08) 9222 2449
Garry Hulme
Tasmania
Ph: (03) 6233 2483
Fax: (03) 6233 2899
Gloria Baillee
Northern Territory
Ph: (08) 8999 2629
Fax: (08) 8999 2419
Wendy Mossman
Australian Capital Territory
Ph: (02) 6244 3870
Fax: (02) 6285 2099
ii
Business Architecture V1.9 - Table of Contents
Business Architecture V1.9 - Table of Contents ............................................................. iii
HealthConnect Business Architecture version 1.9 - An Overview .................................. 1
Part A – Introduction to the HealthConnect Business Architecture version 1.9 .............. 9
1. Introduction ............................................................................................................ 11
1.1
The HealthConnect Project............................................................................. 11
1.2
Phase 1 & 2 Achievements ............................................................................. 12
1.3
HealthConnect Business Architecture ............................................................ 14
1.4
Finding Your Way around the Business Architecture .................................... 15
Part B – HealthConnect Business Context ..................................................................... 19
2. The HealthConnect Business Drivers ..................................................................... 21
2.1
The Business Need ......................................................................................... 21
2.2
HealthConnect Objectives .............................................................................. 22
2.3
The HealthConnect Concept........................................................................... 23
2.4
The Business Case .......................................................................................... 26
3. HealthConnect Principles ....................................................................................... 29
3.1
Scope of HealthConnect ................................................................................. 29
3.2
Participation in HealthConnect ....................................................................... 30
3.3
Information Management Principles .............................................................. 33
3.4
Technology Principles .................................................................................... 34
4. The HealthConnect Solution .................................................................................. 37
4.1
HealthConnect Context .................................................................................. 37
4.1.1
HealthConnect Scope ............................................................................. 37
4.1.2
The HealthConnect Participants ............................................................. 38
4.1.3
HealthConnect Service Roles and Services ............................................ 39
4.2
HealthConnect System ................................................................................... 40
4.2.1
The HealthConnect EHR ........................................................................ 41
4.2.2
The HealthConnect EHR Repository ..................................................... 41
4.2.3
Core HealthConnect EHR Functionality ................................................ 42
Part C – HealthConnect Participant Involvement .......................................................... 49
5. Consumer Participation .......................................................................................... 51
5.1
Benefits of HealthConnect to Consumers ...................................................... 51
5.2
Consumer Consent to Participate ................................................................... 52
5.2.1
Consent Principles .................................................................................. 52
5.2.2
Current Consent Model .......................................................................... 52
5.2.3
Access Control Arrangements ................................................................ 56
5.2.4
Privacy of Consumer Records ................................................................ 57
5.2.5
Consumer Responsibilities ..................................................................... 57
5.3
Consumer Registration ................................................................................... 58
5.3.1
Identification of Consumers ................................................................... 58
5.3.2
Initial Registration Process ..................................................................... 58
5.3.3
Establishing the Initial Health Profile .................................................... 59
5.3.4
Ongoing Identification ............................................................................ 60
5.3.5
Cancelling Registrations ......................................................................... 61
5.4
Consumer Interaction with HealthConnect .................................................... 61
5.4.1
HealthConnect Consumer Access Services ............................................ 61
5.4.2
Consumer Access to their Health Record ............................................... 62
5.4.3
Consumer Direct Interaction .................................................................. 62
iii
5.5
HealthConnect Consumer Access Portal ........................................................ 63
5.6
Consumer Value Added eHealth Services ..................................................... 65
5.7
Consumer Scenarios ....................................................................................... 67
Scenario 1. HealthConnect – Value Add for Accident Victims. ............................ 67
Scenario 2. HealthConnect – Value Add for the Young Family. ........................... 68
Scenario 3. HealthConnect – Value Add for those with Chronic Disease. ............ 69
6. Healthcare Provider/Organisation Participation ..................................................... 72
6.1
Benefits of HealthConnect to Provider/ Organisations .................................. 72
6.2
Provider Participation Boundaries .................................................................. 73
6.2.1
Scope of Provider Participation .............................................................. 73
6.2.2
Provider Organisations and Individual Providers ................................... 73
6.2.3
Provider Identification ............................................................................ 75
6.2.4
Provider Registration .............................................................................. 75
6.2.5
Authorisation of Providers...................................................................... 76
6.2.6
Provider Authentication .......................................................................... 76
6.2.7
Provider Responsibilities ........................................................................ 77
6.2.8
Privacy and Confidentiality .................................................................... 77
6.3
Provider Interaction with HealthConnect ....................................................... 78
6.3.1
Provider eHealth Access Services .......................................................... 78
6.3.2
Provider Clinical Information System Interfaces ................................... 79
6.3.3
HealthConnect Provider Access Portal................................................... 80
6.3.4
Value Added eHealth Services ............................................................... 81
6.3.5
eHealth Message Bank Service .............................................................. 81
6.4
Key Work Practice Implications..................................................................... 82
6.4.1
Creating Event Summaries ..................................................................... 82
6.4.2
Retrieving EHR information .................................................................. 83
6.4.3
Authorising Diagnostic Test Results ...................................................... 83
6.4.4
Maintaining EHR Lists ........................................................................... 84
6.4.5
Receiving Notifications .......................................................................... 85
6.4.6
Creating the Initial Health Profile .......................................................... 85
6.4.7
First Presentation at Healthcare Setting ................................................. 86
6.4.8
Managing Emergency Access ................................................................ 87
6.5
Provider Scenarios .......................................................................................... 87
Scenario 1 – HealthConnect – Value Add for the GP ............................................ 87
Scenario 2 HealthConnect – Value Add for the Busy Specialist ........................... 88
Scenario 3 – HealthConnect – Value Add for the Ancillary Health Workers ........ 89
Scenario 4 – HealthConnect – Value Add for the Community Health Nurse ........ 90
7. Secondary Users Participation ................................................................................ 92
7.1
Scope of Secondary Uses ............................................................................... 92
7.1.1
Secondary Users ..................................................................................... 92
7.1.2
Areas Secondary Uses will Support ....................................................... 92
7.1.3
Examples of Secondary Uses ................................................................. 93
7.2
Benefits of Secondary Uses ............................................................................ 94
7.3
Consent and Responsibilities .......................................................................... 95
7.3.1
Consent for Secondary Uses ................................................................... 95
7.3.2
Responsibilities of Secondary Users ...................................................... 95
7.4
Governance of Secondary Uses ...................................................................... 96
7.4.1
Governance Structure ............................................................................. 96
7.4.2
Secondary Uses Approval Process ......................................................... 97
7.4.3
Information Access Process.................................................................... 98
7.5
Secondary User Scenario ................................................................................ 98
iv
Scenario – HealthConnect – Value Add for the Population ................................... 98
Part D – Description of HealthConnect Components................................................... 101
8. HealthConnect Context and Roles........................................................................ 103
HealthConnect Participants .......................................................................................... 105
8.1
Consumers .................................................................................................... 105
8.2
Providers ....................................................................................................... 105
8.2.1
Types of HealthConnect Provider ........................................................ 105
8.2.2
Provider Access to HealthConnect ....................................................... 106
8.2.3
Provider Processes ................................................................................ 107
8.3
Secondary Users ........................................................................................... 107
Core HealthConnect Roles ........................................................................................... 108
8.4
HealthConnect Governance .......................................................................... 108
8.4.1
HealthConnect Governance - Functions and Processes ....................... 108
8.5
HealthConnect EHR Repository................................................................... 110
8.5.1
The Federated Model for HealthConnect Delivery .............................. 110
8.5.2
HealthConnect Records System (HRS) ................................................ 111
8.5.3
Approved EHR Manager (AEM) ......................................................... 111
8.5.4
HRS/AEM – Processes ......................................................................... 112
8.6
National Data Store ...................................................................................... 113
8.7
HealthConnect Metadata Repository ............................................................ 113
8.8
Consumer Registration and Management..................................................... 114
8.9
HealthConnect Consumer Index ................................................................... 116
8.10 HealthConnect Consumer Access Services .................................................. 117
8.11 Provider Registration and Management ....................................................... 118
8.12 Provider eHealth Access Services ................................................................ 120
8.13 eHealth Message Bank Service .................................................................... 122
8.14 Value Added eHealth Services ..................................................................... 122
8.15 National Health InfoStructure ...................................................................... 123
8.15.1
National Health Identifier ..................................................................... 123
8.15.2
National Health Provider Directory...................................................... 124
8.15.3
National Health Metadata Repositories ................................................ 124
8.15.4
Health Information Standards, Terminologies and Data Sets .............. 125
8.16 Supporting ICT Infrastructure ...................................................................... 126
9. Information Components ...................................................................................... 128
9.1
Introduction .................................................................................................. 128
9.2
HealthConnect EHR Repository................................................................... 129
9.3
HealthConnect Electronic Health Record (EHR) ......................................... 129
9.4
The CEN EHR Reference Information Model ............................................. 130
9.5
HealthConnect National Data Store ............................................................. 131
9.6
HealthConnect Event Summary ................................................................... 132
9.7
EHR Views ................................................................................................... 135
9.8
EHR Lists ..................................................................................................... 136
9.9
EHR Query/Response ................................................................................... 137
9.10 HealthConnect Notifications ........................................................................ 139
9.11 Consumer Details ......................................................................................... 139
9.12 Access Control List ...................................................................................... 141
9.13 EHR Access Logs and Audit Trails.............................................................. 141
9.14 HealthConnect Reports ................................................................................. 142
9.15 HealthConnect Consumers and Providers .................................................... 143
9.15.1
HealthConnect Consumer Index ........................................................... 143
9.15.2
HealthConnect Provider Directory ....................................................... 144
v
9.16 HealthConnect Metadata .............................................................................. 144
9.17 HealthConnect Registration Objects ............................................................ 146
9.18 National Information Repositories ............................................................... 146
9.19 eHealth Communication Messages .............................................................. 147
10.
HealthConnect Business Processes .................................................................. 148
10.1 High Level Business Process Context .......................................................... 148
10.2 Major Business Processes............................................................................. 150
11.
Technology Components .................................................................................. 154
11.1 Systems Overview ........................................................................................ 154
Part E – Managing and Implementing HealthConnect ................................................. 159
12.
Managing HealthConnect ................................................................................. 161
12.1 HealthConnect Governance Structure .......................................................... 161
12.1.1
The Governance Approach ................................................................... 161
12.1.2
Ongoing Management Governance Structure ...................................... 162
12.1.3
Project Implementation Governance Structure .................................... 163
12.1.4
National eHealth Transition Authority ................................................. 165
12.2 HealthConnect Privacy Issues ...................................................................... 165
12.2.1
Need for Strict Privacy Control ............................................................ 165
12.2.2
Existing Privacy Frameworks............................................................... 166
12.2.3
HealthConnect Privacy Framework...................................................... 167
12.3 HealthConnect Legal Issues ......................................................................... 168
13.
Implementing HealthConnect ........................................................................... 169
13.1 HealthConnect Implementation Approach ................................................... 169
13.1.1
Implementation Drivers ........................................................................ 169
13.1.2
Provider and Consumer Take-up .......................................................... 170
13.1.3
HealthConnect Capabilities Compliance .............................................. 171
13.2 Current Implementation Activities ............................................................... 172
13.2.1
HealthConnect Version 1 ..................................................................... 172
13.2.2
Stage 1 HealthConnect Implementations ............................................. 172
13.2.3
Current HealthConnect Trials............................................................... 173
Glossary of Terms ........................................................................................................ 175
HealthConnect Business Architecture – Glossary of Terms ....................................... 176
vi
HealthConnect
Business Architecture v1.9
HealthConnect Business Architecture version 1.9 - An
Overview
HealthConnect
Business Architecture v1.9
HealthConnect
Business Architecture v1.9
Overview of the HealthConnect Business Architecture
What is the HealthConnect Vision?
Healthcare services in Australia are provided by a wide range of government and
non-government organisations. A key theme that has emerged in healthcare reform
over the last decade is the need to integrate and better coordinate the delivery of care
across the full range of healthcare settings.
HealthConnect is being developed as Australia’s national health information network.
It is a cooperative venture between the Australian, State and Territory Governments. It
involves the collection, storage and exchange of consumer health information via a
secure network and within strict privacy safeguards, to facilitate better integration of
care and to improve outcomes across the health care system. HealthConnect will help
make Australia a world leader in what many experts believe is currently the most
significant contributor to health care reform – better, more timely health information.
The first phases of HealthConnect involved intensive research, design and development,
including HealthConnect trials, to define the policies, technologies, infrastructure and
management structure needed to underpin the nation-wide implementation of
HealthConnect. These activities have delivered significant findings that are enabling
the HealthConnect concept to be distilled into practical reality.
Why develop a Business Architecture?
The HealthConnect Business Architecture is the means of communicating the scope and
longer term vision of a workable national solution for HealthConnect. It provides a
compliance framework for initial HealthConnect implementations, identifies
requirements for further research and provides a vehicle for stakeholder review and
participation in refining the HealthConnect solution.
The current version of the Business Architecture differs significantly from the earlier
version published in 2002. Since then, there has been extensive consultation with
stakeholders throughout Australia and HealthConnect trials in a number of States - these
activities have significantly refined the HealthConnect concept and have provided
valuable input to the development of the current Business Architecture. The Business
Architecture is now able to explain in much more detail how HealthConnect is to work.
What is the HealthConnect model?
The core of HealthConnect is a national system of sharable electronic health records,
which will be established to receive, store, retrieve and deliver consumers’ electronic
health record (EHR) information via secure eHealth communications with strict privacy
safeguards for use in the delivery of health care.
A consumer’s EHR will consist of a series of event summaries, each containing key
information about a specific health care event such as a general practitioner consultation,
hospital admission or discharge, community health centre visit, pathology test or a
pharmacy dispensing a prescription.
1
HealthConnect
Business Architecture v1.9
The figure below illustrates the components considered fundamental to the development
of HealthConnect, namely: HealthConnect Participants, HealthConnect Event
Summaries, EHR Repository, EHR Lists, EHR Views and EHR Reports.
HealthConnect
Participants
For example:
· Consumers
·
·
·
·
·
·
·
Event Summaries
HealthConnect Repository
General Practitioners, Specialists
Community nurses
Event Summaries including:
· Healthcare consultations
Private allied health care providers
eg. physiotherapists, podiatrists,
optometrists
Community pharmacists
EHR Views
Hospital clinicians
·
·
·
Diagnostic test results
Hospital discharge information
Immunisation information
Emergency department clinicians
Aged care workers
EHR Lists including:
· Current medications
Secondary Users
· Researchers
· Managers//Planners
· Evaluators
·
·
Principal diagnoses
Allergies and alerts
EHR Reports
Figure 1 – Key Components of HealthConnect
Once a consumer has given consent to participate in HealthConnect, each time the
consumer has contact with the health system, an event summary may be created and
sent electronically by the consumer’s health service provider for inclusion in the
consumer’s HealthConnect EHR. These event summaries will then be available to
those users of HealthConnect that the consumer has authorised access to the EHR.
With the consumer’s authorisation, access to the HealthConnect EHR will be available
to registered provider organisations at the time health services are delivered to the
consumer. The availability of EHR information is to assist clinical decision making
with a view to improving both quality of care and consumer safety.
HealthConnect will not replace providers’ own clinical records or clinical information
systems. Providers will continue to maintain their own consumer health records but
may choose to incorporate selected HealthConnect EHR information in their records or
clinical information systems.
HealthConnect will support secondary use of HealthConnect EHR information for
research and planning of health service delivery, in line with strict privacy policies,
appropriate legislative requirements and monitoring of such use.
What other services will HealthConnect provide/support?
For HealthConnect to work, there will need to be considerable investment in the
establishment of national health messaging services and communications networks with
2
HealthConnect
Business Architecture v1.9
high levels of security and capacity. Building on this requirement provides the
opportunity for HealthConnect to support wider eHealth communications including the
transmission of messages between participating providers. This service is referred to as
the eHealth Message Bank service and might be used for delivery of referrals,
prescription processing, diagnostic test requests and results. Being a separate support
service rather than an integral part of HealthConnect, the eHealth Message Bank can be
used for more efficient clinical communication about any Australian health care
consumer, not just HealthConnect participants.
HealthConnect will also encourage development of new value-added services by the
health sector and will enhance the decision-support ability of provider clinical
information systems by ensuring that the information about the consumer being treated
is more complete than otherwise possible.
HealthConnect implementations will support, use, and facilitate the development of
health infostructure such as the national provider directory, national health identifier,
health metadata repositories, health information standards, approved terminologies and
health data sets. While this infostructure may not be available for the early
implementations, HealthConnect will need to be able to accommodate and use these
infostructure components as they become available.
Who will participate in HealthConnect?
HealthConnect’s primary users will be consumers and those seeking consumer health
record information to assist in decision making related to the provision of health
services - specifically: health service providers (including doctors, nurses, pharmacists,
allied health, community health, Aboriginal and Torres Strait Islander health and public
health practitioners); and consumers reviewing and adding to their own health records.
There will also be a range of secondary users including researchers, planners and
managers, and evaluators.
How will consumer participation be managed?
Enrolment in HealthConnect will be available to all Australian citizens and residents of
Australia. Early implementation will focus on those consumers with ongoing health
care needs – those suffering chronic diseases, populations with high morbidity and
infants. Consumer participation in HealthConnect will be voluntary and nondiscriminatory.
The consumer must have given informed consent before their EHR and other personal
information can be collected, accessed, used or disclosed by HealthConnect. Consumer
consent arrangements and practical measures for managing consent have proven some
of the most difficult and sensitive aspects of HealthConnect to date and are some of the
most heavily researched. The proposed consent model covers: consent for
establishment and use of the consumer’s HealthConnect EHR, the nomination of agents
and legal representatives to act on behalf of the consumer, amendment, correction and
withdrawal of information, deregistering from HealthConnect and the complaints
process.
A key aspect of the consent process is the creation and maintenance of a list of provider
organisations authorised to access the consumer’s HealthConnect record. Organisations
not identified on the consumer’s access list will not be able to access the consumer’s
3
HealthConnect
Business Architecture v1.9
EHR, unless using the emergency override facility. At any time, the consumer will be
able to nominate or change the provider organisations that may access their EHR. In the
future, there may also be the opportunity to control access through features such as
restriction by provider type and the ‘secure envelope’ concept which allows more
restricted access for sensitive information, although these are subject to the findings of
further research.
How will consumers use HealthConnect?
HealthConnect Consumer Access Services (HCCAS) will be established to assist and
support customer interaction with HealthConnect. These may also offer additional
services of interest to consumers.
Consumers will have access to HealthConnect to view their EHR information. A web
browser facility will be created for this purpose. Future implementations of
HealthConnect are expected to include consumer contribution to their records,
following resolution of medico-legal and workflow concerns.
How will provider participation be managed?
Provider participation in HealthConnect will be voluntary and available to all providers
and provider organisations involved in the chain of health care delivery. While the
initial focus is likely to include medical practices, pharmacies, hospitals, diagnostic
services, health and aged care facilities and those practitioners currently participating in
HealthConnect initiatives, this scope will be extended through arrangements with
representatives of each provider group.
Participation in HealthConnect occurs at the level of individual providers (for example,
medical practitioners, diagnostic specialists, community clinicians, pharmacists) who
may be contributing to HealthConnect and provider organisations accessing
HealthConnect. Both will need to register with HealthConnect.
As part of registration with HealthConnect, providers will be required to sign an
agreement that includes an acknowledgement that their access to consumer information
through HealthConnect will be only for the purpose of delivering health services to the
consumer.
How will providers use HealthConnect?
Provider eHealth Access Services (PeHAS) will be available to providers and provider
organisations as the means of accessing HealthConnect services, via a message handling
and transport system and for obtaining front line support to assist them in using
HealthConnect.
Providers will interact with HealthConnect primarily through their clinical information
systems. In the initial stages, a web portal will be available for providers who do not
have clinical information systems able to create event summaries. This will allow them
to enter event summary data directly; however, this is not seen as the preferred method
of event summary entry for the long term.
HealthConnect information will be available to providers via specially designed views
that bring together key aspects of a consumer’s health record, such as medications,
4
HealthConnect
Business Architecture v1.9
allergies and alerts, problems and diagnoses. Providers will send requests for
information to HealthConnect and will be able to use the resulting information as part of
their local decision making processes.
Though it is recognised that access to HealthConnect entails additional processes, a high
priority will be placed on effective integration with provider systems in order to
streamline the process and minimise the impact on provider work practices.
How will secondary user participation be managed?
HealthConnect will support secondary uses of HealthConnect information for
improvement of health service delivery and for research purposes, in line with national
privacy legislation, the research and ethics best practice guidelines of the National
Health and Medical Research Council (NHMRC) and with transparent monitoring of
use.
A key role in HealthConnect will be to manage the process of granting access to
HealthConnect information for agreed secondary purposes. HealthConnect’s
governance structures will contain arrangements for the independent and transparent
monitoring of the role of HealthConnect in authorising and managing access to
information for secondary uses.
How will privacy be managed?
The success of HealthConnect will depend on individual providers, health service
organisations and consumers having confidence and trust that their health information is
kept confidential and secure. To this end, a robust privacy framework, together with the
strongest available security measures, is required.
Providers participating in HealthConnect will be obliged to abide by existing privacy
legislation and by specific HealthConnect privacy protocols, covering access and use of
information from consumers’ HealthConnect records, and contributing information to
these records.
What functions will be needed to deliver HealthConnect?
There are many roles and functions associated with the delivery of HealthConnect
services including both roles performed within HealthConnect itself and roles
performed within associated entities (such as providers and consumers). The figure
overleaf presents the major roles; the core HealthConnect roles are shaded.
These core HealthConnect roles include those for registration of consumers and
providers, maintaining the HealthConnect EHR repository, managing the structure and
content of EHR information, and for governance of HealthConnect.
The ICT infrastructure necessary for the operation of HealthConnect includes secure
networks, IT processing platforms, clinical applications and the organisations that
support these services.
Ministers have endorsed the establishment of the National eHealth Transition Authority
(NEHTA) to drive the national IM&ICT priorities to June 2005, at which stage a longer
term strategy will be determined. NEHTA has established a work program focussing on
5
HealthConnect
Business Architecture v1.9
the areas of clinical data standards, identification standards, directories, supply chain
procurement standards, consent models, secure messaging and information transfer, and
technical integration standards. These initiatives will be critical to supporting the future
development and implementation of HealthConnect.
National Health InfoStructure
National Health
Identifier Service
(Consumers)
Health Information
Standards, Terminologies
and Data Sets
National Health Metadata
Repositories
National Health
Provider
Directory
Secondary
User
HealthConnect Governance
HealthConnect
Metadata
Repository
HealthConnect
EHR Repository
National Data Store
Consumer
Consumer
Registration &
Management
HealthConnect
Consumer
Access
Services
HRS/
AEM
...
HRS/
AEM
Provider
Registration &
Management
Provider
Health
Connect
Provider
Directory
HealthConnect Consumer Index
Provider eHealth
Access
Services
Value Added eHealth Services
Health Registries
eHealth Message Bank Service
Supporting ICT Infrastructure
Processing Platforms
Clinical Information
System Support
Clinical Applications
Secure Communications
Networks
Figure 2 – Role Map for Delivery of HealthConnect Services
How will the EHR information be structured?
Each HealthConnect EHR will comprise a collection of ‘event summaries’ that contain
a summary of information about healthcare events related to the ongoing care of a
consumer in a standardised, machine readable form. Separate event summaries can be
submitted for each healthcare event or one event summary may cover a number of
related treatments. Different types of event summaries will be developed over time in
line with business needs.
The information within the event summaries will be structured as data groups. Some
key data groups will be stored as EHR ‘lists’ which are collections of similar EHR items
describing key aspects of a consumer’s health, formed to serve a specific purpose.
Examples of EHR lists which HealthConnect will automatically derive from event
summary information are prescribing/dispensing history, procedure/treatment history,
and recent health services. Examples of EHR lists which need to be maintained by a
6
HealthConnect
Business Architecture v1.9
provider are current medications, active problems/diagnoses, adverse reactions and
warnings.
Users of HealthConnect will access data using pre-defined ‘views’ suited to the specific
needs of consumers and providers. The priority views identified to date are the primary
(or ‘critical’) view; and the health profile view. Secondary users will access data
through ‘reports’ that are extracts of EHR information that have been predefined as part
of the HealthConnect secondary use approval process.
What are the key technology components?
HealthConnect will establish an EHR repository based on a national network of
HealthConnect Records Systems (HRS). Each HRS will hold and manage the shared
electronic health records (EHR) for many consumers. Whilst the HealthConnect EHR
repository may be distributed across a number of federated elements, it is intended that
it be available as a single national resource from the viewpoint of access,
interoperability, reporting and inquiry. Hence each HRS service must support a
common interoperability framework that enables standard HealthConnect interactions
with provider systems, national HealthConnect infrastructure and health infostructure
components.
A copy of the EHR material will to be transmitted to the National Data Store (NDS) for
archiving and long-term retention. This National Data Store will be used to support all
secondary use of HealthConnect EHR data for research and planning purposes, while all
operational interaction with a consumer’s EHR will occur through the HRS. Access to
the NDS will be tightly controlled.
HealthConnect will complement rather than replace providers’ systems. The focus will
be on sourcing event summaries from these systems and providing information required
for the selected views.
All communications between an HRS and user applications are conveyed as messages
via the message handling and transport system that manages communications between
HealthConnect participants and other individuals and organisations. The message
handling and transport system and HRS services will rely on the HealthConnect
consumer index and HealthConnect provider directory for information needed to
identify HealthConnect participants and to route messages to and from the appropriate
HRS and other application components in the federated HealthConnect environment.
For consumers, and providers whose clinical information systems cannot interact with
HealthConnect, web-based portals will be developed for entry of event summaries,
viewing of EHR information and maintenance of registration information.
How will HealthConnect be implemented?
The procurement, development and implementation of a complete, sustainable solution
as a long-term platform for HealthConnect will be based on version 2 of the
HealthConnect Business Architecture. Given that some of the longer term requirements
are still being finalised, it is likely to be several years before this solution is
implemented.
7
HealthConnect
Business Architecture v1.9
There is an immediate need to make progress and to build on the successes and the
momentum of the first HealthConnect trials. HealthConnect is therefore undertaking a
staged approach to implementations. The Stage 1 implementations will not be
extensions of the trials, though they will make use of components and lessons from the
trials.
There are also significant development projects underway in other states as part of the
HealthConnect trial program, some of which are intended to become part of the
longer-term HealthConnect program.
Implementation is therefore three pronged, with: stage 1 implementations in three
jurisdictions; continuation of trials still under development in some other states and the
development and implementation of a complete, sustainable HealthConnect solution for
the longer-term.
How will HealthConnect be managed?
It is proposed that the ongoing management of the HealthConnect program at the
national level be vested in a dedicated organisational entity on behalf of all the
participating governments and other stakeholders. This organisational entity is
commonly referred to as the HealthConnect governing body.
The functions which this governing body would be expected to cover include:
overseeing the implementation and operation of HealthConnect, providing clinical
governance, maintaining approval mechanisms to assess requests for secondary uses of
HealthConnect data, overseeing registration process for both consumers and providers,
determining the rules and standards applicable to HealthConnect activities, establishing
contractual and licensing arrangements with various HealthConnect participants and
suppliers, and monitoring of compliance throughout the network.
In the short term, the governance arrangements for project implementation activities
will be based on the current HealthConnect Board, Steering Committee and Advisory
Group arrangements. HealthConnect is also being progressed regionally through
HealthConnect state/territory implementations and the ongoing HealthConnect trials.
8
HealthConnect
Business Architecture v1.9
Part A – Introduction to the HealthConnect Business
Architecture version 1.9
HealthConnect
1.
Business Architecture v1.9
Introduction
1.1 The HealthConnect Project
Australian health ministers are committed to improving the delivery of health services
and achieving better health care outcomes through the use of information and
communications technologies. To this end, health ministers established the National
Health Information Management Advisory Council (NHIMAC) in July 1998 to develop
a national action plan for information management in the health sector.
In turn, NHIMAC established the National Electronic Health Records Taskforce in 1999
to develop a coordinated approach to electronic health records in Australia. In July
2000, the taskforce presented its report, A Health Information Network for Australia,1 to
the health ministers. They endorsed its recommendation to create a national health
information network supporting electronic health records (EHR) - now known as
HealthConnect.
HealthConnect will, with consumer consent, allow the electronic exchange of clinical
information between health care providers. HealthConnect is a cooperative venture
between the Australian, State and Territory governments. The Taskforce proposed that
HealthConnect be developed in three phases over a six to ten year period, as follows:
·
Phase 1 & 2: Research and development work (years 1-4);
·
Phase 3: Construction and initial operation (years 3-6); and
·
Phase 4: Subsequent growth and expansion (years 6+).
Phase 1 of HealthConnect commenced in July 2001 with a mix of research,
development and design activities and in July 2003 was extended for a further two years
to enable the conduct of further trials and for the results of these activities to be assessed
and incorporated into the design of HealthConnect.
In March 2004, the Australian government announced the national implementation of
HealthConnect, providing $128 million over the next four years towards the
implementation, which will commence in Tasmania, South Australia and the Northern
Territory.
The Australian Health Information Council (AHIC) and the National Health
Information Group (NHIG), to which the HealthConnect Board reports, are jointly
developing a national IM&ICT strategy due to be completed at the end of 2004.
Ministers have endorsed the establishment of the National eHealth Transition Authority
(NEHTA) to drive the national priorities over the next 12 months. The longer term
strategy will then be determined, potentially including the establishment of an
independent legal entity. The directories and standards work to be conducted by
NEHTA will be critical to supporting the future development and implementation of
HealthConnect.
1
A Health Information Network for Australia, National Electronic Health Records Taskforce, July 2000
11
HealthConnect
Business Architecture v1.9
1.2 Phase 1 & 2 Achievements
The first phases of HealthConnect involved extensive research, design and development,
including a program of HealthConnect trials and accelerated programs of work to define
the policies, technologies and infrastructure, and management structure needed to
underpin the national implementation of HealthConnect. Many of the preliminary
outcomes were presented in the HealthConnect Interim Research Report2, published in
August 2003. Significant outcomes have been derived from the HealthConnect Trials,
MediConnect Field Test and research deliverables. Each of these is discussed below.
HealthConnect Trials
The HealthConnect trials are a significant achievement for the project and have been the
principal mechanism for testing the HealthConnect concept. Each of the trial sites
focuses on a particular health issue or population group where HealthConnect
arrangements might reasonably be expected to, in the future, yield some benefit to both
consumers and providers.
In October 2002, ‘fast track’ trials commenced in Clarence municipality near Hobart in
Tasmania and in the Katherine region of the Northern Territory. The Tasmanian trial,
subsequently extended to cover Southern Tasmania and now nearing completion,
focuses on adults with diabetes and involves health care providers from general practice,
pathology and the Royal Hobart Hospital, as well as a range of diabetes specialists and
educators. The Northern Territory trial has expanded to become a full implementation
covering services to indigenous and remote communities across the Katherine region,
with a view to further expansion across the Territory in the future.
Two longer-term HealthConnect trials have been established in Queensland in the
second half of 2003. The North Queensland HealthConnect trial, which went live in
December 2003, focuses on the peri-operative assessment and preparation of consumers
travelling to undergo elective surgery at Townsville Hospital. This trial has now been
extended for a further 12 months. The Brisbane Southside HealthConnect trial,
commenced in late 2004, focuses on testing new openEHR software technology for
managing health records for consumers with diabetes.
The New South Wales Health-e-Link initiative currently under development is also
considered a HealthConnect trial. The project will test HealthConnect infrastructure in
two pilot sites. The Child Health Information Network (CHIN) will operate in Greater
Western Sydney and includes the Children’s Hospital at Westmead. The Chronic
Disease Management System project will operate in the Hunter Valley and includes the
John Hunter Hospital in Newcastle. These two pilots are expected to go live in mid2005.
MediConnect Field Test
MediConnect, formerly known as the Better Medication Management System (BMMS),
has been combined with HealthConnect and now forms the medications component of
HealthConnect.
2
The HealthConnect Interim Research Report, August 2003.
12
HealthConnect
Business Architecture v1.9
A field test has been conducted at two locations, Ballarat and Launceston, as part of the
MediConnect program. MediConnect was aimed at improving quality and safety in
prescribing, dispensing and managing medication by using online technology to enable
prescribers, dispensers and the consumer to have more timely access to more complete
information about the consumers’ medication.
The HealthConnect trials and MediConnect field test are providing first-hand
experience that has proven valuable to HealthConnect in understanding the practical
application of EHR concepts, their impacts on clinical workflow and the challenges of
sharing EHR information between different clinical settings.
Research Deliverables
Phase 1 of HealthConnect addressed the key HealthConnect research questions and
commenced important technical design work, much of which has resulted in the
production of substantial research reports and planning documents. The key reference
documents are:
·
HealthConnect Interim Research Report3, which included version 1 of the
HealthConnect Business Architecture, following its refinement through
widespread public consultation;
·
Outputs of the HealthConnect systems architecture project, including: the
HealthConnect Architecture Overview and the HealthConnect Systems
Architecture v0.94;
·
Reports of the Clinical Information Project (CIP)5 which specify the information
content and structure of HealthConnect health event summaries, lists and views;
·
A series of discussion papers on HealthConnect business requirements. These
papers were circulated to the HealthConnect Board, Program Office and Trial
Managers and address: privacy; consent; registration and identification of
HealthConnect participants; processing and storage of health information;
security and access control; and user interfaces, messaging and transport;
·
HealthConnect Indicative Benefits Report6;
·
A proposed National Health Privacy Code and accompanying discussion paper,
which was developed by the AHMAC Privacy Working Group and has now
been forwarded to Health Ministers for their consideration;
·
Work by National InfoStructure Development Section facilitating the
development of Australian Standards and International Standards on healthcare
messaging, EHR architecture, terminologies, discharge summaries and referrals,
patient (consumer) identification, provider identification and other areas that will
benefit both HealthConnect and the health sector generally; and
3
The HealthConnect Interim Research Report, August 2003.
HealthConnect Draft Systems Architecture v0.9, July 2003.
5
www.health.gov.au/healthconnect/building_blocks/cip.html
6
Indicative Benefits Report, Fujitsu Consulting, February 2004
4
13
HealthConnect
·
Business Architecture v1.9
Research and evaluation studies of HealthConnect trials in Tasmania and
Northern Territory and preparation for trials in New South Wales and
Queensland.
These documents, together with feedback from the trial and evaluation documents, have
been instrumental in shaping the HealthConnect solution described in this Business
Architecture.
1.3 HealthConnect Business Architecture
In 2002 the HealthConnect Business Architecture version 1 was issued. While an
effective communication tool, it was not possible to resolve all the business issues at
that time. Since the initial version, the lessons learned from the trials and research and
the development of the draft systems architecture have informed the requirements.
Hence a review of the Business Architecture and the development of an update were
required. This document, version 1.9 of the HealthConnect Business Architecture,
represents the results of the review.
The purpose of this version of the HealthConnect Business Architecture is to:
·
Communicate HealthConnect in a way that is understandable to a range of
different audiences;
·
Identify the scope of the longer-term HealthConnect solution, based on the
findings of HealthConnect research and development work and extensive
consultation;
·
Determine a workable, achievable and cost-effective scope for stage 1
HealthConnect implementations, recognising current technical, legal and
environmental considerations;
·
Provide the framework to which the stage 1 implementations will need to
comply;
·
Identify potential business requirements for further research, and possible
inclusion in later versions, of HealthConnect; and
·
Provide a suitable vehicle for stakeholder review and acceptance of the initial
and longer-term HealthConnect solution.
This version of the HealthConnect Business Architecture seeks to address and reconcile
the many different positions on HealthConnect held by Australian, state and territory
health jurisdictions, consumer and privacy advocates, health service delivery
organisations, healthcare providers and the health software industry.
As such, the Business Architecture seeks to define the requirements for the end-point to
which those currently proposing to provide EHR solutions need to aspire for Australia
to succeed in its endeavour of having a single national system of health records, albeit
composed of many disparate, interoperating parts.
14
HealthConnect
Business Architecture v1.9
Approach to Developing the Business Architecture
As indicated the HealthConnect Business Architecture is based on extensive clinical and
consumer consultation, research and trial lessons. Preparation of this version of the
Business Architecture (version 1.9) was also based on a staged program of activities that
involved:
·
Reviewing existing HealthConnect work programs, including the HealthConnect
trials, MediConnect field test, HealthConnect architectures, HealthConnect
business requirements and the work of the Clinical Information Project;
·
The development and circulation of a range of position papers to the Program
Office and recognised experts. These papers addressed topics such as: eHealth
communications; clinical decision support; the nature of the summary record;
HealthConnect front-end processing; the passive store paradigm; secondary uses
of HealthConnect data; the federation paradigm, EHR architectures for
HealthConnect and the use of EHR standards;
·
Widespread consultation on HealthConnect business requirements and matters
raised in the position papers - including conduct of two national workshops;
·
Discussions at HealthConnect Trial Manager Forums, HealthConnect
Stakeholder Reference Group and HealthConnect Board meetings and
consultation with state and territory health jurisdictions, and the HealthConnect
Program Office;
·
Consultation with consultants and project managers reviewing other aspects of
HealthConnect, specifically, benefits realisation, implementation and legal
issues; and
·
Contact with the broader health informatics community and industry experts,
and obtaining updates on relevant developments in the eHealth environment and
the activities of government and non-government organisations.
Following broad consultation and feedback on version 1.9, it is proposed that an
updated final version 2.0 of the Business Architecture will be released following
approval by the HealthConnect Board.
As implementations proceed, it is proposed that the HealthConnect business architecture
will continue to be developed in line with the changing business requirements, under the
guidance of the body responsible for on-going management of HealthConnect.
1.4 Finding Your Way around the Business
Architecture
Structure of the Business Architecture
The main content of the Business Architecture is divided into five parts as follows:
·
Part A - Provides background on the HealthConnect project and the
development of this business architecture.
15
HealthConnect
Business Architecture v1.9
·
Part B - Develops the HealthConnect concept – the business drivers for
undertaking HealthConnect, the key principles on which HealthConnect
implementation is based;
·
Part C – Discusses the operation of HealthConnect from the viewpoints of
different types of participants – consumers, providers and secondary users;
·
Part D – Provides a structured description of the business and systems
components that make up HealthConnect and how they interoperate – based on
considerations raised by the Federal Enterprise Architecture Framework (FEAF);
and
·
Part E – Provides detail on governance, legal and implementation issues
associated with realising HealthConnect.
Using the Business Architecture
The HealthConnect Business Architecture contains a variety of material intended for a
broad audience including: Australian, state and territory health jurisdictions; consumer
representatives; peak bodies and professional associations representing healthcare
providers and the health IT industry; health ministers, their advisers and other policy
makers; those working on implementation of HealthConnect; other involved agencies;
and interested stakeholders.
Where more selected reading is required, the following guidance may be helpful in
finding the most appropriate material:
7
·
Those with no prior knowledge of HealthConnect may find it helpful to refer
first to some of the introductory HealthConnect materials (including the most
recent HealthConnect overview7) that are available from HealthConnect offices,
or HealthConnect staff in each state and territory or to view the HealthConnect
website at www.healthconnect.gov.au
·
Those seeking a general overview of HealthConnect and its specific scope
should refer to Parts A and B of this document.
·
Those primarily interested in the impact of HealthConnect from a consumer
perspective should refer to Section 5 in Part C of this document.
·
Those primarily interested in the impact of HealthConnect from the perspective
of a healthcare provider or provider organisation should refer to Section 6 in Part
C of this document.
·
Those interested in access to HealthConnect information for research, health
planning or policy development, should refer to Section 7 in Part C of this
document.
·
Those seeking more detailed information on HealthConnect requirements and
proposed functions should refer to Part D of this document.
HealthConnect – An Overview, May 2004, Australian Department of Health and Ageing.
16
HealthConnect
Business Architecture v1.9
·
Those seeking information on HealthConnect implementation issues including
governance and stakeholder engagement arrangements should refer to Part E of
this document.
·
A glossary of terms is provided to assist understanding.
17
HealthConnect
Business Architecture v1.9
Part B – HealthConnect Business Context
19
HealthConnect
2.
Business Architecture v1.9
The HealthConnect Business Drivers
This section addresses the business drivers associated with the exchange of health
information and a proposed solution based on a national system of shared electronic
health records.
The Business Drivers are discussed below in relationship to the:
·
Business need, a statement of the background to the business drivers and a
statement of the primary and secondary business problems;
·
Business objectives, a statement of the business goals, purposes, outcomes of the
system;
·
System concept, a statement of the concept of what the system is; and
·
Business case, a high level statement of the HealthConnect business case.
2.1 The Business Need
A key theme that has emerged in healthcare reform in Australia over the last decade is
the need to integrate and better coordinate the delivery of care across the full range of
healthcare settings.
Achieving such integration, where healthcare services are provided by a wide range of
government and non-government organisations, depends upon relevant information
about individual consumers being more readily available at every point of care.
Currently, health records are kept in a variety of formats at different locations across the
system – i.e. in ‘information silos’. The situation is further compounded by existing
organisational and professional boundaries that impede information sharing.
Lack of ready access to critical information can result in:
·
adverse events, including drug interactions, duplicated medications and
inappropriate therapy based on less complete information;
·
diagnostic tests being undertaken unnecessarily due to previous results not being
available and there being insufficient information to assist diagnosis;
·
consumers and providers spending additional time retrieving information that
could be readily available at the point of care; and
·
individuals falling through ‘cracks’ in the system and not receiving appropriate
health care due to information not being effectively communicated.
Clearly, inadequate sharing of information is a quality and safety issue that needs to be
addressed through a system-wide approach. Technologies, such as an electronic health
records network, offer unprecedented opportunities to improve the flow of information
across the health system. If successfully implemented, such systems have the potential
to ensure that the consumers and providers have access to the information they need for
better decision making.
21
HealthConnect
Business Architecture v1.9
As stated in version 1 of the Business Architecture:
The primary business problem that HealthConnect aims to address is to facilitate access
by consumers and providers to timely, relevant, summary information relating to the
health status, treatment and events of consumers, at the time of care, to assist decision
making. This has the potential to enable consumers to take an increasing role in self
management.
The secondary problems that HealthConnect is intended to assist with resolving include:
·
creating a best practice, evidence-based health system through generation of new
knowledge and better education and professional development of healthcare
providers, planners and policy makers;
·
improving utilisation of health resources and access to health services through
implementation of better, more targeted health initiatives and better planning;
·
improving safety of healthcare services through activities such as enabling rapid
response to treatment and device failures;
·
supporting research and education; and
·
detecting outbreaks of disease.
2.2 HealthConnect Objectives
In 1999, the Australian Health Ministers endorsed Health Online: A Health Information
Action Plan for Australia and a national strategy was developed which included a key
recommendation to develop a national framework for the use of electronic health
records. The Australian Health Ministers subsequently endorsed the recommendations
of the National Electronic Health Records Taskforce to establish HealthConnect - a
health information network overseeing the development of a national electronic health
record.
In its July 2000 report to Health Ministers8, the National Electronic Health Records
Taskforce outlined the following objectives for achieving this national EHR network,
namely:
"Improved delivery of healthcare and better continuity and quality of care, consumer
safety and health outcomes for all Australians while enhancing the privacy and
respecting the dignity of health consumers by:
·
empowering consumers to be able to take a greater responsibility for their own
healthcare and be better informed about the choices available to them in respect
of their healthcare;
·
ensuring better decision-making which is shared by both consumers and health
providers at the point of care;
8 A Health Information Network for Australia, National Electronic Health Records Taskforce, July 2000
22
HealthConnect
Business Architecture v1.9
·
providing a flexible, seamless and integrated process of care through the
improved delivery of healthcare and better continuity and quality of care,
consumer safety and sharing and better exchange of information;
·
providing better access to healthcare, particularly in rural and remote areas;
·
building a best-practice, evidence based health system;
·
encouraging better, more targeted health initiatives; and
·
informing research, learning and training;
through developing a nationally coordinated and distributed system of electronic health
records, which is based on the greater use of online technologies."
Building on the Taskforce’s objectives for a national EHR network, a HealthConnect
Project Proposal was developed and endorsed by the HealthConnect Board in
September 2001. This project proposal identified the specific goals, purposes and
objectives of HealthConnect to be:
Goal(s)
Improved health outcomes.
(ie the higher order
objective(s) to which
the project contributes)
Improved healthcare delivery.
Purpose(s)
Improved knowledge creation and employment of same.
(ie the direct effect(s) or
impact(s) of the project)
More informed consumers.
Improved participant (consumer and sectoral stakeholders) satisfaction with the health
system.
Less time and resource wastage, including reduction in duplication of information/tests.
More appropriate healthcare delivery and decision making.
Better informed, planned and coordinated care.
More empowered providers, consumers and planners.
More effective targeting of resources (people, services, dollars etc).
Outcome(s)
A national system of EHR available to authorised consumers and providers.
(the deliverables of the
project)
Availability of the best health information (clinical, evidence and service) to the right
people, at the right time and place, and in appropriate forms – targeting the needs of
a range of end-users ie consumers, healthcare providers, managers.
Confidence in a national health information network in Australia (privacy, information
storage and retrieval, governance etc).
Improved quality (scope and nature) of health data holdings.
A sustainable business model (eg incentives framework).
Better equipped health workforce – ie information use, decision making etc.
2.3 The HealthConnect Concept
In 2000, the National Electronic Records Taskforce defined an EHR (Electronic Heath
Record) as:
“An electronic, longitudinal collection of personal health information, usually
based on the individual, entered or accepted by health care providers, which can
23
HealthConnect
Business Architecture v1.9
be distributed over a number of sites or aggregated at a particular source. The
information is organised primarily to support continuing, efficient and quality
health care. The record is under the control of the consumer and is stored and
transmitted securely.”
In the context of HealthConnect, a consumer’s EHR will consist of a series of event
summaries (subsets of the complete information recorded by providers for a given
health event and not aimed at replacing local health records). The event summary is
analogous to a document containing key information for a specific health care event
such as general practitioner consultation, hospital admission or discharge, pathology test
or a pharmacy dispensing a prescription.
HealthConnect is a cooperative venture between the Australian, State and Territory
Governments to implement a national EHR solution which will operate seamlessly and
consistently across Australia, with the same rules for privacy, identification, registration
and consent applying everywhere. Each time a consumer has contact with the health
system (including at a general practitioner’s surgery, specialist rooms, hospital,
community health centre, pharmacy), a standard event summary will be created and sent,
subject to consent arrangements, electronically to a HealthConnect repository. These
event summaries form a summary health record for the consumer which will then be
available when it is required to help with making decisions about the consumer’s
healthcare.
HealthConnect’s primary focus is to improve the availability of relevant consumer
information in the delivery of healthcare so as to achieve better continuity and quality of
care, consumer safety and health outcomes.
HealthConnect’s primary function is to receive, store, retrieve and deliver electronic
health record (EHR) information for use in the delivery of health care. HealthConnect
will also provide simple notifications. HealthConnect will provide the information
needed to support other functions, such as clinical decision support, but will not itself
provide these functions.
HealthConnect will support secondary use of EHR information for improvement of
health service delivery and research purposes, in line with strict policies, appropriate
legislative requirements and monitoring of such use.
A number of components are considered fundamental to the development of
HealthConnect, namely:
·
HealthConnect Participants
·
HealthConnect Event Summaries
·
EHR Repository
·
EHR Lists
·
EHR Views
·
EHR Reports
These components are illustrated in the figure below.
24
HealthConnect
Business Architecture v1.9
HealthConnect
Participants
For example:
·
·
·
·
Event Summaries
Consumers
HealthConnect Repository
General Practitioners, Specialists
Community nurses
Event Summaries including:
· Healthcare consultations
Private allied health care providers
eg. physiotherapists, podiatrists,
optometrists
Community pharmacists
·
·
·
·
EHR Views
Hospital clinicians
·
·
·
Diagnostic test results
Hospital discharge information
Immunisation information
Emergency department clinicians
Aged care workers
EHR Lists including:
· Current medications
Secondary Users
· Researchers
· Managers//Planners
· Evaluators
·
·
Principal diagnoses
Allergies and alerts
EHR Reports
Figure 2.1 Key Components of HealthConnect
·
Consumer participation in HealthConnect will be voluntary and nondiscriminatory. Non-participation must not limit the availability of any health
service to the consumer.
·
Enrolment in HealthConnect is available to all Australian citizens and residents
of Australia. While HealthConnect is for all Australians, early implementation
will focus on those likely to get greatest long-term benefit – those suffering
chronic diseases, populations with high morbidity and infants.
·
Provider participation in HealthConnect will be encouraged and will be made
available to all providers involved in the chain of health care delivery. While
the initial focus is likely to include medical practices, pharmacies, hospitals,
diagnostic services, health and aged care facilities and those practitioners
currently participating in HealthConnect initiatives, this scope will be extended
through arrangements with representatives of each provider group.
·
Each consumer EHR will comprise a collection of ‘event summaries’ which
provide summarised information about healthcare events that are relevant to the
ongoing care of a consumer. These event summaries will be produced according
to defined metadata covering format, data items and allowable code sets.
·
The HealthConnect EHR repository is expected to comprise multiple health
record systems (HRS). The EHR of each registered consumer will reside on one
HRS.
·
HealthConnect will include the maintenance of EHR lists of critical information
such as current medications, diagnoses and alerts.
25
HealthConnect
Business Architecture v1.9
·
Users will access data from the stored event summaries for an individual
consumer through a series of pre-defined EHR views. Views will be developed
to address specific needs of consumers and providers taking into account
specific practice areas, conditions and treatment regimes.
·
Users will access data from event summaries across consumers, i.e. relating to
populations, through EHR reports which will be extracted from the EHR
databases in line with predefined requirements and strict approval processes;
The underlying principles of HealthConnect are discussed more extensively in Section 3
HealthConnect Principles and the scope and functionality of the HealthConnect solution
is detailed in Section 4 HealthConnect Solution.
HealthConnect support for the Business Need
HealthConnect, as a national EHR network, will address and support the business
problems described above by:
·
The provision of timely information about consumers, available at the point of
care, including emergency situations;
·
The provision of information that supports safer healthcare delivery, such as
improved medication information during prescribing;
·
The provision of information supporting coordinated and shared care through
increased recognition of the involvement of multi disciplinary healthcare
providers and the availability of information at key transition points in service
provision, such as during care handover between participating healthcare
services; and
·
The provision of information for research, education, service planning and
policy development.
2.4 The Business Case
Extensive research and consultation has shown that, while there are significant costs
associated with HealthConnect, there are considerable benefits to be realised and that, to
the extent that quantifiable information is available, a sufficiently strong business case
exists for proceeding with HealthConnect as the national EHR solution.
The key benefits and costs are summarised below.
Benefits of HealthConnect
According to the draft HealthConnect Benefits Realisation Framework9, the
implementation of HealthConnect in Australia is expected to deliver benefits that will
accrue to consumers, providers and to the Australian health sector more generally. By
improving access to a consumer’s health information across health care settings,
HealthConnect would deliver benefits though increased coordination of care, enabling
healthcare providers to provide a better quality of care to their consumers, and even a
reduced number of adverse reactions, which would lead to improved health outcomes.
9
HealthConnect Benefits Realisation Framework V1.0 October 2004
26
HealthConnect
Business Architecture v1.9
Moreover, the availability of HealthConnect records should reduce the amount of time
providers spend chasing patient information, enabling their business to become more
efficient.
Financial Benefits of HealthConnect
The HealthConnect Indicative Benefits Report (February 2004)10 analysed potential
financial benefits attributable to HealthConnect. The report took a conservative
approach to estimating benefits. After removing potential areas of double counting, the
cost offsets from the implementation of HealthConnect were estimated to be in the order
of $396m per annum should there be a 100% take up by consumers and providers.
While it is recognised that a near 100% take up is not likely to happen for many years if
ever, the analysis provides an indication of the level of benefits that could be achieved.
The report also concluded that when fully deployed additional direct financial benefits
could accrue giving a total indicative benefits range of $554m to $604m per annum.
Cost of HealthConnect
An analysis of the cost of HealthConnect was conducted as part of the research
activities and summarised in the HealthConnect Interim Research Report (2003)11.
The cost modelling of HealthConnect demonstrates that the overall cost is highly
dependent on the registration process and to a lesser extent on the technical solution
adopted. The one-off establishment costs are highly dependent on the approach to
registration employed by HealthConnect. An intensive registration would require
hundreds of millions of dollars, but a self-managed approach is expected to become the
standard if HealthConnect were offered as a mainstream service.
The major establishment components outside registration are expected to be:
infrastructure deployment ($140 million); the change management program ($90
million, including training, support, and the organisational change studies); and system
integration ($60 million). These establishment costs would be spread out over a number
of years and therefore would be in the order of $30 million per annum over 10 years.
Within this there would be an initial loading in years 0–5.
It is anticipated that annual recurrent costs, including registration, would be in the order
of $160 million. The major components of the ongoing cost are information technology
operations ($100 million), information technology infrastructure replacement and
application development ($35 million), registration ($5 million) and governance and
management ($20 million). This would be a shared cost among all jurisdictions and,
potentially, private sector partners.
Indirect Costs of HealthConnect
There are also indirect costs that are necessary to provide the underpinning structure of
HealthConnect. The indirect costs of HealthConnect include development and
implementation of: privacy, security and identification arrangements; information
technology and data standards; computing infrastructure within participating
10
The HealthConnect Indicative Benefits Report was prepared by Fujitsu (formerly DMR Consulting) for
the HealthConnect Program Office in February 2004.
11
The HealthConnect Interim Research Report, August 2003.
27
HealthConnect
Business Architecture v1.9
organisations; workflow changes; and telecommunications infrastructure. These costs
are substantial, (in the order of $2–3b). However, these costs will be incurred/are
already being incurred with, or without, HealthConnect.
Funding HealthConnect
Based on the research undertaken, it is has been stated that it cannot be assumed that the
private information technology industry sector will take on a substantial role as an
investor/funder in the first few years of implementing HealthConnect, notwithstanding
the substantial role of the private health care sector in providing the source systems
feeding into HealthConnect.
As evidenced by experiences with other e-government projects, the private sector is
likely to invest in HealthConnect only after a proven business case for the private sector
has emerged. And, as evidenced by overseas experiences, government needs to take a
leadership role for implementation on a national scale, particularly with respect to
standards and infrastructure development.
The assumption at this point in time is that the majority of funding support in the early
years would be provided by the public sector. Notwithstanding this, the implementation
plan needs to allow for subsequent private sector involvement possibly through public
private partnership models.
There is also a major funding issue with private sector providers, many of which do not
have the infrastructure and resources required for them to participate in HealthConnect.
The need to encourage investment in areas such as infrastructure for general
practitioners, specialists and private hospitals, will be addressed as part of
implementations.
28
HealthConnect
3.
Business Architecture v1.9
HealthConnect Principles
This section presents high level principles which encapsulate the intent of
HealthConnect, guide the development of its processes and systems and inform
proposed implementation activities. These high-level guiding principles are grouped
according to whether they relate to:
·
The Scope of HealthConnect;
·
Participation in HealthConnect;
·
HealthConnect Information Management; and
·
HealthConnect Technology Principles
These high-level guiding principles have been adopted in the contemporary conceptual
design of HealthConnect and are reflected, to the maximum extent reasonably possible,
in the more detailed material presented in the various parts of this business architecture.
3.1 Scope of HealthConnect
·
HealthConnect’s primary focus is to improve the availability of relevant
consumer information in the delivery of healthcare so as to achieve better
continuity and quality of care, consumer safety and health outcomes.
·
HealthConnect will support a whole-of-health perspective encompassing
private and public providers and continuity of care across primary, secondary
and tertiary care settings including preventive health.
·
HealthConnect’s primary function is to receive, store, retrieve and deliver
electronic health record (EHR) information for use in the delivery of health
care and to support rather than provide additional functions, such as clinical
decision support, other than simple notifications.
·
HealthConnect will not replace providers’ own clinical records or clinical
information systems. Providers will continue to maintain their own consumer
health records but may choose to incorporate selected HealthConnect EHR
information in their records or clinical information systems.
·
HealthConnect will encourage development of value-added services.
HealthConnect’s contribution to improving health outcomes can be greatly
enhanced by stimulating development of other complementary systems and
services such as clinical decision support and health call centres.
·
HealthConnect will support secondary use of HealthConnect EHR
information for improvement of health service delivery and research
purposes, in line with strict privacy and ethical protocols, appropriate legislative
requirements and monitoring of such use.
29
HealthConnect
Business Architecture v1.9
·
To the maximum extent possible, HealthConnect implementations will
support, use, and facilitate the development of national health infostructure
and work closely with the National eHealth Transition Authority (NEHTA) and
the longer term entity. Key infostructure areas include the national provider
directory, national health consumer identifier, health metadata repositories,
health information standards, approved terminologies and health data sets such
as the Australian Catalogue of Medicines.
·
From stage 1 onwards, the scope of HealthConnect will expand to
encompass new types of providers and information. Core HealthConnect
systems and services for receiving, storing, retrieving and delivering EHR
information must be able to accommodate this expansion with minimal
redevelopment or replacement.
·
HealthConnect will potentially support registers through the provision of
information such as diagnosis and treatment information on which specialist
registries may be built. In the future it may also support registers such as
notifiable diseases databases.
·
Any changes to the business boundaries of HealthConnect, required over
time, will be controlled and be on a national basis. This would potentially
include changes to the definition of core services to reflect evolving business
requirements. A number of issues requiring future decisions have already been
identified; these include the scope of consumer contributions to their health
record.
·
Ongoing management of the HealthConnect program at the national level
will be vested in a dedicated organisational entity on behalf of all the
participating governments and other stakeholders. This organisational entity
is commonly referred to as the HealthConnect governing body.
3.2 Participation in HealthConnect
Consumer Participation
·
Enrolment in HealthConnect is available to all Australian citizens and
residents of Australia. While HealthConnect is for all Australians, early
implementation will focus on those likely to get greatest long-term benefit –
those suffering chronic diseases, populations with high morbidity and infants.
·
Each consumer and their EHR information will be uniquely identified
within HealthConnect by use of a single unique identifier able to be linked to
any future National Health Identifier. This is currently being researched by the
National eHealth Transition Authority (NEHTA).
·
Consumer participation in HealthConnect will be voluntary and nondiscriminatory. Non-participation must not limit the availability of any health
service to the consumer.
·
The consumer must have given informed consent before their EHR and
other personal information can be collected, accessed, used or disclosed by
HealthConnect. This will form part of the initial consumer consent process.
30
HealthConnect
Business Architecture v1.9
·
Consumers will be free to deregister from HealthConnect at any time,
without suffering discrimination in terms of access to healthcare.
·
Consumer consent for participation in HealthConnect remains valid until
deregistration.
·
Consumers will have control over who may access their HealthConnect
EHR. At any time, the consumer will be able to nominate (and to vary or
revoke the nomination of) provider organisations that may access their EHR.
·
Consumers will have access to HealthConnect to view and, in the future,
contribute to their EHR information and, also, to review the access log for
their EHR and to set preferences that control access to the EHR. To do this,
the consumer must be identified to HealthConnect – usually by giving their
unique HealthConnect identifier and another form of identification (eg a PIN).
·
Each consumer will be able to nominate (and vary or revoke the nomination
of) one or more agents capable of accessing HealthConnect on behalf of the
consumer. An agent may be any person formally nominated by the consumer
and capable of being identified to HealthConnect. Other persons able to access
the EHR on behalf of a consumer include legal representatives such as parents
(for a child), a legal guardian or person with power of attorney over the
consumer’s health care.
·
Consumers will, as part of the sign up process, consent to an “emergency
access override” facility. This would entail their EHR being accessed by any
provider delivering clinical care in an emergency, where the consumer is not in a
position to otherwise give their consent e.g. where consumer is unconscious or
otherwise unable to provide immediate consent at the time of service. This type
of access be tightly controlled, and will be closely monitored with audit trails
and follow up processes being maintained.
·
Consumers, at the time of a consultation, may require personal information
to be withheld from HealthConnect. The provider will, on request, not send
the event summary or delete the information prior to sending the event summary.
Provider Participation
·
Provider participation in HealthConnect will be encouraged and will be
made available to all providers involved in the chain of health care delivery.
While the initial focus is likely to include medical practices, pharmacies,
hospitals, diagnostic services, health and aged care facilities and those
practitioners currently participating in HealthConnect initiatives, this scope will
be extended through arrangements with representatives of each provider group.
·
A person practising as a health service provider who is recognised for
professional registration in an Australian jurisdiction will be eligible to
register with HealthConnect as an individual provider. This will require their
professional registration body to have been previously recognised and registered
with HealthConnect.
·
A registered business (including a sole trader) that delivers health services
using the services of one or more individual providers will be eligible to
register with HealthConnect as a “provider organisation”. This could range
31
HealthConnect
Business Architecture v1.9
from small general practitioner practices to major hospitals and area health
services.
·
Provider participation in HealthConnect will be voluntary and will remain
active until the provider gives HealthConnect a request to deregister or the
provider is no longer eligible to participate in HealthConnect (as determined
by the rules governing the operation of HealthConnect).
·
Individual providers and provider organisations will be required to sign
HealthConnect agreements outlining their responsibilities at time of
registration.
·
Each provider (individual or organisation) will be uniquely identified
within HealthConnect by use of a single unique identifier linked, in the future,
to the National Provider Directory.
·
HealthConnect will allow any registered individual provider acting on
behalf of a provider organisation that has been authorised by the consumer
to access the consumer’s EHR for the purpose of providing health services
to the consumer.
·
A provider’s organisation must have the consumer’s consent prior to an
individual provider accessing a consumer’s HealthConnect EHR. This
consent would typically be set up at registration or the first time the consumer
presents at the provider organisation’s premises.
·
Provider access to view a consumer’s HealthConnect EHR implies that the
provider requires access to the information for clinical purposes. All access
will be audited and providers may be requested to provide reasons for an access
event.
·
Each provider organisation will be responsible for controlling its
personnel’s use of HealthConnect information and for ensuring that the
individual provider (or any other person) accessing the consumer’s EHR on
behalf of the provider organisation does so for valid clinical reasons, and
that the provider/person is identified to HealthConnect.
·
Providers once authorised will be able to access all parts of the consumer’s
HealthConnect EHR. HealthConnect will not determine which parts of the
EHR are relevant to any individual health encounter and therefore not restrict
access. As the range of providers widens there will need to be a review of this
principle; this will be based on additional research and policy work to be
undertaken as part of the implementation phase.
·
All access to a consumer EHR will be logged and able to be tracked back to
individual - provider, consumer or other authorised person.
·
HealthConnect participants will be obliged to abide by privacy legislation
and by specific HealthConnect privacy rules. The National Health Privacy
Code will be used when it has been implemented, until then privacy
arrangements will be tailored to suit each jurisdiction for each implementation,
with a view to progressing towards a single national solution.
32
HealthConnect
·
Business Architecture v1.9
Providers are responsible for the security of any EHR information
integrated into their clinical information systems. Once HealthConnect EHR
information has been entered into a local system, the owner of that system has
responsibility for the security of the information.
3.3 Information Management Principles
·
Each HealthConnect EHR will comprise a collection of ‘event summaries’
which provide a subset of information about healthcare events that are
relevant to the ongoing care of a consumer. These event summaries will be
produced according to defined metadata covering format, data items and
allowable code sets as developed by the Clinical Information Project.
·
Separate event summaries will be submitted for each healthcare event e.g. a
hospital stay, an emergency department presentation, a community nurse visit,
pathology test(s). An event may cover a number of treatments e.g. a series of
chemotherapy treatment events may be represented by an admission summary
and a discharge summary. Different types of event summaries will be developed
over time in line with business needs.
·
Event summaries should be available as soon as possible after a health event
and hence, as far as practicable, should be submitted directly following the
completion of an event. Failure to do so may adversely impact on some of the
functions of HealthConnect such as the provision of script information to
pharmacists at the time of dispense.
·
Users will access data from the stored event summaries for an individual
consumer through a series of pre-defined ‘views’. Views will be developed
to address specific needs of consumers and providers taking into account
specific practice areas, conditions and treatment regimes.
·
Users will access data from event summaries across consumers, i.e. relating
to populations, through ‘reports’ which will be extracted from the EHR
databases in line with predefined requirements and appropriate approval;
·
HealthConnect will not perform any clinical validation of the data in the
event summary. It will take reasonable steps to ensure that any personal health
information held is accurate, up to date and relevant to the HealthConnect
functions and activities by validating the type of information contained in the
event summaries, but not assessing the clinical content.
·
HealthConnect will promote a focus on data quality checking in source
systems. Improving the quality of data at the time of entry is critical to ensuring
that the HealthConnect EHR information is meaningful and useful in assisting
healthcare delivery.
·
HealthConnect will include the maintenance of ‘lists’ of critical information
such as current medications, diagnoses and alerts.
·
Information, once submitted to HealthConnect, may not be deleted or
altered; however corrections or amended information may be included in the
EHR by issuing revised versions of the information which will be used in place
of the earlier versions with appropriate annotations. Access to view an event
33
HealthConnect
Business Architecture v1.9
summary can be removed. Operational based changes to maintain database
integrity will be closely managed and controlled.
·
Each entry in a consumer’s HealthConnect EHR must be attributed to an
individual provider, on behalf of an authorised provider organisation, the
consumer or another person authorised to add information to the EHR.
The event summary formats will control the type of information which can be
added. Requests for information from the EHR will also be attributable to an
individual.
·
The EHR data will be permanently recorded and preserved subject to legal
constraints. Upon a consumer’s death, processes will be put in place to limit
access to those with a need eg for activities in relation to death certificate issue,
autopsy or coroner investigation and for secondary uses. Rules controlling these
processes will be established by HealthConnect in line with privacy legislation.
·
If a consumer deregisters from HealthConnect, the information in their
HealthConnect record will be withdrawn from view, but will not be deleted.
It will continue to be available for de-identified secondary reporting uses.
·
Each implementation of HealthConnect must fully support:
(a)
use of the HealthConnect consumer identifier to identify consumers
and their EHR information; and
(b)
use of the HealthConnect provider identifier for authentication of
event summaries and control of access to EHR information.
·
All implementations of HealthConnect HRS services must support
interoperability. This requires that all implementations must be able to perform
the core functions of HealthConnect, and be able to handle standard
HealthConnect interactions with provider systems and national HealthConnect
infrastructure throughout Australia. Any implementations not able to achieve
full interoperability in the short term must have clearly defined migration paths
aimed at achieving the required level of interoperability.
·
The use of standard terminologies in the provider source systems will be
heavily promoted. This will be critical to the grouping of key data into
meaningful lists and for the provision of appropriate information to support
clinical decision making.
·
The HealthConnect data model must be extensible to accommodate evolution
of the content and format of EHR information over time.
3.4 Technology Principles
Integration with clinical systems
·
Providers will interact with HealthConnect primarily through their clinical
information systems. A standard web-browser interface to HealthConnect will
be available for consumers. A provider web-browser interface will also be
available for providers whose systems do not have the capacity to interact with
HealthConnect. This will be phased out over time.
34
HealthConnect
·
Business Architecture v1.9
HealthConnect will aim for access to HealthConnect to be integrated into
the providers’ clinical information systems and as far as practicable
streamline access and keep to a minimum impact on provider work practices.
Standards and conformance
·
HealthConnect will use existing health informatics standards and seek to
cater for emerging standards to support local and national perspectives, and in
the future the potential sharing of EHR data on a global scale.
·
HealthConnect will support standards proven and supported by industry.
·
The structure of messages must conform to Australian standards accepted
for use within HealthConnect and these standards must be supported by all
systems participating in HealthConnect.
·
Participating organisational systems and personal provider IT devices must
be demonstrably compliant with appropriate published security policies
and standards that have been endorsed by HealthConnect.
·
Software developed to interact with HealthConnect records systems will be
tested and accredited to the standard endorsed by HealthConnect.
Storage and Access
·
The entire EHR of each registered consumer will reside on one and only one
HRS.
·
HealthConnect will receive EHR information sent by providers and
consumers and provide information in response to requests from users.
Providers and consumers will initiate and control their interactions with
HealthConnect; however standing requests for notifications related to specified
consumer EHRs will be supported where the provider organisation has access to
the EHR.
·
For participation in HealthConnect, a HRS must allow any provider
registered with HealthConnect acting on behalf of a provider organisation
that has authority to access the consumer’s EHR information stored on that
HRS. This includes access both for viewing and update of the EHR.
·
Each HealthConnect Records System will aim for continuous availability. A
target of 99.9% availability is being sought.
·
Systems and services for receiving, storing, retrieving and delivering
HealthConnect EHR information should be extensible i.e. designed to adapt
to the growth of HealthConnect in terms of provider types and clinical
information content. The capacity and capability of HealthConnect will grow
in terms of provider types, event summaries, views and lists and facilities must
be flexible enough to cater for this change without replacement.
·
HealthConnect data structure, systems and processes must be designed to
maintain backward compatibility and integrity of the stored data so that
information may be reproduced through time.
35
HealthConnect
Business Architecture v1.9
Other Initiatives
·
Implementations of value added services are outside core HealthConnect
functionality. Individual implementations of HealthConnect may include
optional value added functionality to address local requirements. While these
will be encouraged, they are related systems and must be implemented such that
they do not affect the compatibility of the HealthConnect implementation with
the national standards.
·
Implementations of HealthConnect are likely to build on the messaging
service it requires and conduct, as an adjunct to the core service, an
implementation of a wider eHealth message bank service to support other
health communications.
36
HealthConnect
Business Architecture v1.9
The HealthConnect Solution
4.
This section presents the HealthConnect solution from a business perspective. It
addresses the:
·
Broad scope of HealthConnect;
·
Context of HealthConnect in terms of participants and roles;
·
National network of EHR repositories known as HealthConnect Records
Systems (HRS); and
·
Key functions of the HealthConnect system and the associated information flows.
Topics such as who uses the services, who provides the services or where the systems
and services reside, will be discussed later in the document in Part C Participant
Involvement and Part D Description of HealthConnect Components.
4.1 HealthConnect Context
4.1.1
HealthConnect Scope
Over the last three years considerable effort has been focussed into research aimed at
scoping HealthConnect. This research has concluded that HealthConnect should be
kept relatively simple – focusing on the acceptance, validation and management of
event summaries to construct an EHR for each consumer, and the use of EHR
information to create views. Summarising the HealthConnect Principles, the scope of
HealthConnect can be encapsulated in the statement:
“HealthConnect will be a repository service for consumers’ lifetime health
records.”
HealthConnect will complement rather than replace providers’ systems. The focus will
be on sourcing event summaries from these systems and providing information required
for the selected views. HealthConnect will enhance the decision-support ability of
provider clinical information systems by ensuring that the information about the
consumer being treated is more complete than otherwise possible.
At least in the initial stages of HealthConnect, for providers who do not have clinical
information systems able to create event summaries, a web portal will be available for
direct entry of event summary data; however, this is not seen as the preferred method of
event summary entry for the long term.
For consumers, a web based front end will be developed for ongoing use.
HealthConnect, through the supply of EHR information, will act as an enabler to the
development of other complementary systems and services such as clinical decision
support and health call centres.
HealthConnect implementations will support, use, and facilitate the development of
national health infostructure such as the national provider directory, national health
identifier, health metadata repositories, health information standards, approved
terminologies and health data sets. It is recognised that this infostructure may not be
37
HealthConnect
Business Architecture v1.9
available for the early implementations. HealthConnect will need the capability to link
to them as they become available.
HealthConnect will potentially support registers, such as the Australian Childhood
Immunisation Register, through the provision of information, but will not of itself
provide full registry functionality.
4.1.2
The HealthConnect Participants
HealthConnect’s primary users will be those users seeking consumer health record
information to assist in decision making related to the provision of health services,
namely:
·
Providers (including doctors, nurses, pharmacists, allied health, community
health, Aboriginal and Torres Strait Islander health and public health
practitioners) and public and private provider organisations seeking information
about the consumer they are treating; and
·
Consumers reviewing and adding to their own health records.
There will also be a range of secondary users including:
·
Researchers seeking information to conduct research needed for improving
health care and its delivery;
·
Planners and Managers (including administrators, strategic planners, policy
makers, funding bodies) seeking information to assist management decision
making; and
·
Evaluators seeking information directly related to monitoring the effectiveness
of HealthConnect.
The provision of data for secondary uses will only be allowed under strict privacy and
ethical protocols, appropriate legislative requirements and monitoring of such use.
Stakeholders
In addition to these five broad groups of participant stakeholders, there is a sixth group
which is key to the success of HealthConnect but will not generally be made up of direct
users of the system. Members of this group include:
·
Consumer representative groups (eg Consumers’ Health Forum, National
Aboriginal Community Controlled Health Organisations, Health Consumers of
Rural and Remote Australia);
·
Provider representative groups (eg Australian Medical Association, Royal
College of Nursing Australia, Australian Nursing Federation, Pharmacy Guild of
Australia, Pharmaceutical Society of Australia, Society of Hospital Pharmacists
of Australia, Australian Divisions of General Practice, Australian
Physiotherapists Association, Medical Colleges including specialist colleges and
the Royal Australian College of General Practice, Australian College of Rural
and Remote Medicine);
38
HealthConnect
Business Architecture v1.9
·
The health IT industry, who will provide the applications, systems, services and
staff to deliver HealthConnect functionality and support infrastructure
(represented by groups such as the Medical Software Industry Association
(MSIA) and Australian Information Industry Association(AIIA));
·
Healthcare-related organisations such as the Australian, state and territory
departments of health and/or human services, the Health Insurance Commission;
and
·
Health information providers, academics, publishers and health libraries.
4.1.3
HealthConnect Service Roles and Services
Figure 4.1 below illustrates the major roles/services associated with the delivery of
HealthConnect services. This role map includes both roles performed within
HealthConnect itself, roles performed by the associated national bodies and roles
performed within associated participant entities. Those roles contained within the
dotted lines are considered core HealthConnect roles.
National Health InfoStructure
Secondary
User
Consumer
Consumer
Registration &
Management
HealthConnect
EHR Repository
Provider
Registration &
Management
HealthConnect
Consumer
Access
Services
Provider
Provider eHealth
Access
Services
Value Added eHealth Services
eHealth Message Bank Service
Supporting ICT Infrastructure
Figure 4.1 Key HealthConnect Roles and Services
Ongoing management of the HealthConnect program at the national level will be vested
in a dedicated organisational entity, the HealthConnect governing body, acting on
behalf of all the participating governments and other stakeholders.
39
HealthConnect
Business Architecture v1.9
The roles/services associated with the delivery of HealthConnect may be grouped as
follows:
1.
HealthConnect participants - consumers, providers and secondary users.
2.
Core HealthConnect roles, including those for:
-
registration and management of consumer and provider participation;
-
maintaining the HealthConnect EHR repository; including the individual
Health Record Systems and the National Data Store ,
-
managing the structure and content of EHR information, including the
HealthConnect Metadata repository;
-
evaluating program performance; and
-
governing the interaction with HealthConnect.
3.
HealthConnect Consumer Access Services that support customer interaction
with HealthConnect and may also offer additional services of interest to
consumers.
4.
Provider eHealth Access Services that support providers interacting with
HealthConnect.
5.
eHealth Message Bank Services, an adjunct to the core services, to facilitate
electronic information interchange for both HealthConnect and other purposes,
such as electronic retrieval of prescriptions, referrals and notifications.
6.
Supporting HealthConnect ICT infrastructure, which includes secure networks,
IT processing platforms, clinical applications and the organisations that provide
and support these services.
7.
National Health Infostructure, which provides national repositories and
information definitions that underpin the operation of HealthConnect. This
includes the proposed National Health Identification Service (Consumers) and,
national Provider Directory/Index; the National Health Metadata Repository and
terminologies and data sets, such as the Australian Catalogue of Medicines.
8.
Other contributors and recipients of information – specifically value-added
eHealth services and (potentially) health registries.
These roles are discussed in more detail in Part D Description of HealthConnect
Components.
4.2 HealthConnect System
Having discussed the context and scope of HealthConnect above, this section presents a
high-level discussion of the HealthConnect EHR, the key functions of the
HealthConnect system and the associated information flows from a business perspective.
More detailed descriptions of HealthConnect components can also be found in Part D
Description of the HealthConnect Components.
40
HealthConnect
4.2.1
Business Architecture v1.9
The HealthConnect EHR
HealthConnect intends to complement the provider’s records by facilitating the sharing
of summary healthcare information, in the form of standardised event summaries and
composite views of information in event summaries, between providers that are
involved in the care of a consumer. The EHR will also be accessible to the consumer,
other people nominated by the consumer and those with a legal responsibility for the
consumer’s health care. The HealthConnect EHR is not intended to replace the
provider’s own detailed consumer records and health record systems, but should be able
to supply information that can be stored and used by such systems to better support
health care delivery.
The EHR will contain clinical information that is of relevance to other providers. It is
proposed that the EHR will be comprised of a series of event summaries, each of which
will contain summary information relating to the services provided at a given healthcare
event. Users will access data from multiple event summaries through a series of predefined views (relating to individuals) and reports (relating to populations). It is
expected that views and reports will be developed for specific practice areas, conditions
and treatment regimes. The Clinical Information Project, a major project contributing to
HealthConnect, is developing the initial set of event summaries and views in
consultation with consumer and provider representatives.
HealthConnect will also send users notifications based on analysis of the type of event
summary or the information contained in the event summary. Notifications based upon
clinical content will not be supported initially.
4.2.2
The HealthConnect EHR Repository
HealthConnect will establish a shared electronic health record (EHR) for consumers and
a national network of secure EHR repositories known as HealthConnect Records
Systems (HRS).
HealthConnect is to be implemented as a federation of HealthConnect Records Systems
(HRS) supported by common services at a national level, with each consumer’s EHR
being stored in a single HRS. A copy of the EHR material is to be transmitted to the
National Data Store for archiving and long-term retention. Together, the EHR
information held in each HRS and the National Data Store will comprise the
HealthConnect EHR repository.
Whilst the HealthConnect EHR repository may be distributed across a number of
federated elements, it is intended that it be available as a single national resource from
the viewpoint of access, interoperability, reporting and inquiry. Within this framework,
it is proposed that the National Data Store be used to support all secondary use of
HealthConnect EHR data for research and planning purposes, while all operational
interaction with a consumer’s EHR will occur through the HRS. Access to the National
Data Store will be limited and will generally be for de-identified record analysis. This
will be tightly controlled.
Each HRS is a system that provides EHR storage services. The HRS will act as a
library of EHRs, storing event summaries on behalf of the consumer and ensuring that
the entire record is accessible 24 hours a day in accordance with the consumer’s privacy
41
HealthConnect
Business Architecture v1.9
rights and the nationally-agreed security and access control policies. The primary
functions of the HRS are:
·
to store event summaries that are contributed to the EHR by participating
consumers and providers;
·
to maintain the confidentiality, integrity, availability and non-repudiation of an
individual consumer’s EHR;
·
to present views of the EHR in response to requests by participating consumers
and providers, subject to the consumer’s consent and the privacy, security and
access control policies established by HealthConnect.
For participation in HealthConnect, an HRS must allow any provider registered with
HealthConnect acting on behalf of a provider organisation that has authority to access
the consumer’s EHR information stored on that HRS. This includes access both for
viewing and update of the EHR.
It is envisaged that there will be a limited number of HRS implemented across Australia
each of which may be operated by public or possibly private organisations referred to as
“Approved EHR Managers” (AEMs).
Further details of the system environment are presented in Part D Description of
HealthConnect Components.
4.2.3
Core HealthConnect EHR Functionality
The focus of HealthConnect is to be kept relatively simple – focusing on the acceptance,
validation and management of event summaries, the maintenance of the consumer’s
EHR and the use of EHR information to create views and reports. HealthConnect will
provide information in standardised electronic formats that may be more readily used by
clinical information systems and newer applications external to HealthConnect such as
expert clinical decision support systems.
The figure below illustrates the boundaries of the key HealthConnect functions
(contained within the dotted line) and relationships to the receipt and provision of EHR
information, followed by brief descriptions. The main functions discussed in this
section are:
A. Create Event Summaries
B. Manage access to EHR Information
C. Incorporate into Local Records
D. HealthConnect Notifications
E. Secondary Uses
F. eHealth Value Added Services
G. eHealth Message Bank Services
42
HealthConnect
Business Architecture v1.9
As indicated in Figure 4.2 the main function of HealthConnect, apart from maintaining
the EHR repository, is receiving and sending messages. The specific functions of
creating event summaries, views, conducting clinical analysis etc are conducted by end
user tools such as:
·
Provider clinical information systems, consumer access tools and registers;
·
Specialist clinical and consumer health tools; and
·
Research and planning tools
The functions associated with the registration of consumers, providers and other users
are discussed in Part C Participant Involvement.
Via Provider systems,
consumer tools
A. Event Summaries
Provider:
· Hospital Discharge
· Emergency Discharge
· Pharmacy
· GP Consultation
· Specialist Consultation
· Diagnostic tests
(pathology, imaging etc)
· Allied Health
· Community Health etc
Consumer (future):
· Diary
· Event summary
Research/planning tools
E. Secondary Uses
· Clinical research
· Health policy
HealthConnect
EHR
Repository
Provider
eHealth
Access
Services
D. Notifications
Examples:
· Admission/discharge
· Registers
Specialist clinical &
consumer health tools
F. eHealth Value Added
Services
Examples:
· Medication management
· Evidence based analysis
G. eHealth Message
Bank Services
(related initiative)
Eg: Referrals, results,
prescriptions
Via Provider systems,
consumer tools
B. EHR Views/Lists
Examples:
· Critical View
(Composite)
· Individual Event Views
· List Views
C. Incorporation into
local health record
Examples:
· Script details
· Event summary
· Medications list
· Allergies, alerts etc.
Figure 4.2 Key HealthConnect Functions and Interactions
A. Create Event Summaries
Event summaries will typically be created in the providers’ clinical information system
and then transmitted to HealthConnect, which will receive and store the event
summaries in the consumer’s EHR. HealthConnect will not proactively extract data
from operational systems but will receive event summaries sent by the operational
systems at the discretion of the consumer and system user.
HealthConnect will work with the vendors of the provider systems to investigate ways
of integrating the process of creating and sending event summaries into their systems.
From the research and trials conducted it is apparent that not all providers have clinical
information systems and that many of the systems that are in use may not be able to
create the required event summary messages in the short term.
43
HealthConnect
Business Architecture v1.9
Stage 1 of HealthConnect will therefore include a web based access portal tool to enable
providers without an appropriate clinical information system to create event summaries
online. The preferred solution for the longer term is for commercial vendors to address
this requirement for all providers.
There is also a future requirement for consumers to be able to create and maintain health
diaries, create and send event summaries and add comments to their EHR. A web based
access portal tool will be provided for this purpose. In the future, HealthConnect
compliant Consumer Health Tools are expected to become available as commercially
viable products. However the HealthConnect provided consumer tool will still be
available to consumers that require it.
B. Manage Access to EHR Information
Retrieval of consumers’ EHR information will be through the provision of EHR views.
An EHR view is a subset of a consumer’s EHR information and may consist of one or
more complete event summaries or a collection of lists of specific items derived from
one or more event summaries.
Users, in addition to being able to access individual event summaries, will be able to
select from a range of predefined summary views or lists. The types of views of an
EHR to be provided by the HRS will include a ‘critical’ view containing information
such as basic demographic data, diagnoses, alerts, allergies, adverse reactions and
current medications, and recent history.
HealthConnect will be responsible for providing the requested EHR information to the
user’s clinical information system. HealthConnect will need to be able to receive and
interpret a request for information, and retrieve and send the information.
HealthConnect will only send the information as a result of a request for the information.
The composition of the information in some views will be targeted to a specific type of
user.
A key aspect of the definition of views will be the maintenance of the integrity of the
information presented in the view and ensuring that important components of an EHR
are always included so that information cannot be misinterpreted by being seen out of
context.
There will be a requirement to interface to a wide range of consumer and provider
systems including:
·
clinical information systems – hospital, specialist, general practitioner systems;
·
provider group tools eg shared care, health call centre systems; and
·
consumer health tools eg consumer diary, self monitoring, and care management
advice tools.
As with the event summary creation, it is acknowledged that not all provider systems
will be in a position to provide this functionality in the short term and that initially a
web based ‘viewing’ tool will be provided as part of services available through the
access portal.
44
HealthConnect
Business Architecture v1.9
Within this model there are still opportunities for a level of integration with the clinical
information system such as automatic initiation of a HealthConnect session upon
opening a consumer record locally and transmission of clinical context information.
The web-based HealthConnect consumer access tool will include development of
‘consumer-friendly’ viewing functions.
Generalised ad-hoc query of information within a HealthConnect EHR will not be
available from HealthConnect; (however, secondary uses will be facilitated through the
provision of ‘reports’ – discussed below). The use of predefined EHR views (some of
which are expected to include search parameters) will ensure that the results of requests
represent clinically valid data and that the processing workload which would be
required to service queries do not adversely impact performance of the overall
HealthConnect system.
C. Incorporation into Local Record
Once the EHR view information has been delivered to a provider system, this may be
stored temporarily and used when displaying the data. A user may wish to browse
extensively through the available views of the EHR data, and possibly print out selected
views, or even store a full copy in the same way they would store any externally
supplied report, such as a referral.
Alternatively, the user may wish to incorporate specific data into their local clinical
information system, particularly for use in decision support systems for activities such
as interaction checking. The type of information to be incorporated might be:
·
Individual event summaries stored as a report attached to the local record; or
·
Selected lists eg medications, diagnoses, allergies, alerts, adverse reactions
incorporated into the appropriate part of the local database.
This incorporation facility will depend on the capabilities of the clinical information
system and may be set up within the system to take place automatically or as a result of
a user initiated request. HealthConnect will encourage and support this functionality as
it is seen to be important for realising key safety benefits.
D. HealthConnect Notifications
HealthConnect will support simple notifications relating to time, events and data codes,
for example, admission notice, discharge notice or overdue notice. Notifications based
upon interpreting the clinical content of an EHR will not be supported.
Notifications can be sent to the provider organisations nominated in the consumer’s
access control list. This list will be established and maintained as part of the consumer’s
consent process. Organisations receiving these notifications will be responsible for
actioning the notifications.
The notification function could, if the business need is identified, also be extended to
consumers; for example, to provide a Consumer Reminder Service for overdue
appointments.
45
HealthConnect
Business Architecture v1.9
HealthConnect could be developed to have the facility, should it be required, to provide
a mechanism for facilitating the notification of notifiable events to national health
registers. This would be particularly important for registers which require timely
reporting, such as notification of infectious diseases. It should also improve collection
of data for voluntary registers. Registers might include: disease specific eg cancer,
implantable and other devices, organs, treatments, immunisations, births, deaths,
research cohorts.
While HealthConnect may provide limited support for some notifiable registers, it will
not seek to replace any registers or become a registry service. This position will be
reviewed in later years particularly if participation reaches very high proportions of the
Australian population.
HealthConnect will send all notifications on encountering the appropriate trigger
without reference to any other notification that might have been sent. Any filtering to
avoid double counting etc would need to be managed by the access service or the
recipient (eg. a provider or register).
E. Secondary Uses
The HealthConnect repository will provide a valuable source of information which,
under appropriate privacy and ethical protocols, can also be used for clinical research,
policy making, planning and health outcome evaluation - collectively referred to as
secondary uses.
The provision of access to data for secondary uses will only be allowed under strict
protocols. These will include information being aggregated or de-identified and
ensuring authorisation has been given for the requested use. The focus of the secondary
uses will be on analysis of de-identified data.
Any research projects requiring access to identified information will only be allowed in
accordance with current legislation detailed in the National Health and Medical
Research Council (NHMRC) section 95 and 95A guidelines. These requests which may
include epidemiological research, environmental research, and clinical research will be
limited to special circumstances and subjected to stringent requirements, including
assessment by appropriate ethics committees.
Given the significant investment in the HealthConnect system, there will also be a need
to monitor and evaluate the success of the system and seek ways to improve the quality
of the service. As a minimum, this will require analysis of usage and outcomes to assess
whether the overall objectives of HealthConnect are being met.
The focus of the HealthConnect functionality will be on extracting the required
information or ‘reports’ such that the analysis can be performed.
Specialist research and planning tools used to analyse the data are outside the scope of
HealthConnect.
46
HealthConnect
Business Architecture v1.9
F. eHealth Value Added Services
The functionality of the eHealth Value Added Services such as clinical decision support
is outside the core HealthConnect functionality; however, interfacing to these systems
and providing them with EHR data will be part of HealthConnect.
Specifically HealthConnect will maintain lists such as current medications, prescribed
medication, dispensed medication, current diagnoses and alerts and be able to provide
these to provider clinical information systems to support clinical practice such as
interaction checking and script processing functions.
While not directly within scope, HealthConnect will be actively promoting the
development and use of a range of eHealth value added services.
G. eHealth Message Bank Service
For HealthConnect to work, there will need to be considerable investment in the
establishment of national health messaging services and communications networks with
high levels of security and capacity. There has been extensive discussion about whether
HealthConnect should build on this requirement to incorporate within its scope the
provision of an eHealth Message Bank Service. This would particularly facilitate the
provision of prescription details to pharmacies; a high-benefit service identified from
the MediConnect field tests.
If this requirement were to be addressed by means of an eHealth Message Bank Service
developed in close association with HealthConnect, it would provide an opportunity for
HealthConnect to support wider eHealth communications. Such a service could support
transmission of messages between participating providers for services such as delivery
of discharge summaries, prescription processing, referrals, diagnostic test requests and
results. Being a service rather than an integral part of HealthConnect, it could also be
extended to include all consumers of health care services and not just HealthConnect
participants.
Given the philosophy of containing the scope of HealthConnect, the HealthConnect
business architecture does not include this wider eHealth Message Bank Service as part
of the core functions to be provided by HealthConnect. It is however considered a
critical adjunct service and the actual implementations of HealthConnect are expected to
include coordinated implementation of these two major initiatives.
47
HealthConnect
Business Architecture v1.9
Part C – HealthConnect Participant Involvement
49
HealthConnect
5.
Business Architecture v1.9
Consumer Participation
HealthConnect’s primary focus, as stated in the HealthConnect Principles, is to improve
the availability of relevant consumer information in the delivery of healthcare so as to
achieve better continuity and quality of care, consumer safety and health outcomes.
To achieve this goal, a high level of consumer participation is required and considerable
analysis into what being involved in HealthConnect will mean to consumers has been
conducted. This section outlines the key elements of consumer involvement including:
·
Benefits of participation in HealthConnect;
·
Consumer consent arrangements for the stage 1 implementations of
HealthConnect;
·
The process of consumer identification and registration;
·
Subsequent consumer interaction with HealthConnect;
·
Features of the HealthConnect Consumer Access Portal; and
·
Potential for value added eHealth services to consumers.
5.1 Benefits of HealthConnect to Consumers
Analysis of consumer benefits have been conducted throughout the HealthConnect
research and development activities, drawing on the experiences of the HealthConnect
trials. A full analysis of the potential HealthConnect benefits is presented in the Benefits
Realisation Framework12.
In summary, the key benefits of HealthConnect specific to participating consumers
include:
12
·
the availability of critical consumer health information during a healthcare
emergency;
·
facilitation of freedom of choice and freedom of movement, with the consumer’s
heath record “following” the consumer;
·
the ability for a consumer’s health information to be brought together when it is
needed – at the point of care;
·
the availability of consumer health information where consumers are not known
to the provider, including first-time consultations and when working and
travelling away from home;
·
more complete consumer medication records available to prescribers and
dispensers, supporting greater medication interaction checking and fewer
medication errors and associated adverse events;
HealthConnect Benefits Realisation Framework V1.0 October 2004
51
HealthConnect
Business Architecture v1.9
·
reduced need for consumers to repeat their medical history to different care
providers;
·
decreased incidence of unnecessary services;
·
better consumer care-coordination and care integration across providers,
including more effective and efficient care transfer between care settings,
through the availability of timely and accurate health information from
participating providers;
·
decreased patient waiting and travelling time and fewer cancelled operations
leading to increased patient satisfaction and increased health sector efficiency;
and
·
gains from improvement in the provision of health services from the creation of
new knowledge, more effective planning and allocation of resources.
5.2 Consumer Consent to Participate
5.2.1
Consent Principles
A fundamental principle of HealthConnect is that consumers should give informed
consent to participate in HealthConnect. This includes communicating clearly to
consumers what HealthConnect is and what agreeing to participate means in practical
terms.
The key HealthConnect Principles relating to consumer consent are:
·
Consumer participation in HealthConnect will be voluntary and nondiscriminatory. Non-participation must not limit the availability of any health
service to the consumer.
·
The consumer must have given informed consent before their EHR and other
personal information can be collected, accessed, used or disclosed by
HealthConnect.
·
Consumers will be free to deregister from HealthConnect at any time, without
suffering discrimination in terms of access to any health service.
·
Consumer consent for participation in HealthConnect remains valid until the
consumer deregisters.
5.2.2
Current Consent Model
The following consent model, extracted from information provided in the consent
business requirements, describes the arrangements to be implemented as part of the
stage 1 HealthConnect implementation.
Consumer consent arrangements, and how consent is managed, are probably the most
sensitive aspects of HealthConnect. As such consent arrangements may evolve over
time, though within the framework of the underlying principles. Considerable research
has gone into the development of the consent model; any changes to the model that
would require consumer re-consent would be prohibitively expensive.
52
HealthConnect
Business Architecture v1.9
1. Consumer Registration
Should a consumer choose to participate in HealthConnect they will need to register.
As part of this process the consumer will need to sign a consent form specifically
consenting to:
(i) Conditions of participation
Consumers will be given information about HealthConnect, how it will operate
and how they can deregister at any time.
(ii) Collection of initial health profile (optional)
Consumer consent will be sought to gather background information about their
health status in order to establish their HealthConnect record. Some of this
information will be collected by directly asking the consumer questions (eg.
social and lifestyle information) and some through retrieving information from
their nominated provider’s electronic health systems.
(iii) Nominate provider organisations
Consumers will nominate service provider organisations who can access their
HealthConnect records. Consent is at the provider organisation level, not the
individual provider. Consumer nominations may be changed at any stage to
reflect consumer choices.
(iv) Emergency override
Participation in HealthConnect includes allowing providers to have access to
consumer HealthConnect records in an emergency situation where (a) consent
has not previously been given, (b) the consumer is unable to consent and (c) no
one else available to give consent. Where emergency override occurs, details of
the access will be recorded in the access log and consumers will subsequently be
advised of the emergency override.
(v) Consent to secondary uses of data
Consumers will be advised that consent to participate in HealthConnect will
include consent for HealthConnect information to be used for approved
secondary uses. For the majority of secondary uses de-identified data will be
used; identified data may be used for limited research purposes, subject to
independent scrutiny and National Health and Medical Research Council
Guidelines.
2. Agents and legal representatives
Each consumer will be able to nominate (and vary or revoke the nomination of) one or
more agents capable of accessing HealthConnect on behalf of the consumer. An agent
may be any person formally nominated by the consumer and capable of being identified
to HealthConnect, including carers and family members.
Other persons able to access the EHR on behalf of a consumer include legal
representatives such as parents (for a child), a legal guardian or person with power of
attorney over the consumer’s health care.
53
HealthConnect
Business Architecture v1.9
Where the consumer is not able to sign the consent form or nominate their agents, the
consent form can be signed on their behalf by a legal representative such as parent,
guardian or someone who has power of attorney that extends to the right to make
decisions about the consumer’s health care. Appropriate documentation will be
required.
Children will be able to consent on their own behalf if their medical practitioner
provides a statement that the child has the requisite capacity to understand and make
their own health decisions.
Any nominated agent has the same access rights as the consumer themselves. Changes
to a nominated and legal agent might occur at any stage.
Policies and processes will be put in place to manage the potentially changing status of
children’s consent. These are currently being investigated and are not yet finalised but
might include: when a child reaches maturity giving them the option to withdraw from
HealthConnect, and the option of making their parents/guardians their registered agents.
Processes might include activities such as: sending out letters to children approaching
maturity informing them of their rights; issue of separate cards, and expiry dates on
registration of parents as agents such that it requires active renewal to stay valid.
Policies and processes will be put in place to manage blocking of access for a parent or
guardian should HealthConnect be instructed to do so and presented with official
documentation such as a court order.
3. Subsequent episodes of care
Consumers will be informed that they have the right to withhold information from
HealthConnect at the time of the healthcare event.
After the initial registration to join HealthConnect, summaries of all events occurring at
registered provider organisations will be added to the consumer’s HealthConnect record
unless:
·
the consumer requests that the provider not send the particular event summary,
or request that part of the information be deleted before it is sent; and/or
·
the provider advises, and the consumer agrees, not to send the particular event
summary or that part of the information be deleted before it is sent.
An example might be a young teenager requesting that details of a particular
consultation not be sent to their HealthConnect EHR to which their parents have access.
Providers will need to assist the teenager in understanding the implications of sending
or not sending the event summary.
Hence, once a consumer has consented all event summaries generated by registered
provider organisations will be sent to HealthConnect unless the consumer actively
indicates otherwise.
There is concern that not having access to all the facts may impede a provider’s ability
to give appropriate care. It is assumed that the number of requests not to send
information will be small, but that this feature is required to address consumer control
and confidence issues. It will be provider’s responsibility to explain the implications to
54
HealthConnect
Business Architecture v1.9
the consumer. Providers viewing the HealthConnect EHR will need to take into
consideration that, as with manual records, the records cannot be considered 100%
complete, but that the HealthConnect EHR provides a more complete picture. Indeed
until HealthConnect is widely used there will be gaps in the record relating to providers
who have not yet registered with HealthConnect.
There have been discussions about the potential for establishing a ‘secret envelope’
section of the consumer’s EHR, where sensitive information can be placed with access
restricted to certain providers. This functionality is not part of the scope for version 1 of
HealthConnect. If further investigations identify that there is a strong business case for
this requirement, and technical challenges related to its implementation particularly
within provider organisations can be resolved, it will be considered for future
implementations.
4. Amendment, correction and withdrawal of information from view
Should clinical information on the record be considered incorrect, the consumer should
raise the issue with the provider, or another provider from the organisation which
submitted the original event summary. The provider may then if appropriate submit an
updated version of the event summary containing the corrected information. The
original and updated versions of the event summary will contain the identity of the
provider submitting the event summary.
Should factual information on the record be considered incorrect, the consumer will be
able to request, via their HealthConnect Consumer Access Service, that it be changed.
The rules determining whether a correction is made will be set out by the
HealthConnect governing body and will be developed in consultation with appropriate
organisations. A consumer will also be able to request that a comment be added to an
event summary.
The consumer may request that a particular event summary be withdrawn from view.
This will mean that the information contained in the event summary will not be used to
generate subsequent views of their HealthConnect information.
In all cases the original information will be kept for medico-legal and audit purposes,
but will no longer be disclosed by HealthConnect.
5. Deregistering from HealthConnect
Consumers will be free to deregister from HealthConnect at any time, without suffering
discrimination in terms of access to healthcare.
6. Complaints process
The complaints process will be based on current practices, with private sector privacy
complaints being directed to the Office of the Federal Privacy Commissioner and public
sector privacy complaints to the Health Care Complaints Commissioner or
state/territory body authorised to deal with privacy and health complaints in each
jurisdiction.
Health care related complaints will be referred to the relevant jurisdictional Health Care
Complaints Commission. The possibility of a memorandum of understanding (MOU)
with the Health Care Complaints Commissions is being investigated. If such an MOU
55
HealthConnect
Business Architecture v1.9
is established, Health Care Complaints Commissions could investigate privacy
complaints as well as health care complaints in the public and private sectors.
A process will also be established for managing complaints about the operation of
HealthConnect such as delays in registration processing.
5.2.3
Access Control Arrangements
A key aspect of the consent process is the establishment of a list of provider
organisations authorised to access the consumer’s HealthConnect record. It is expected
that these provider organisations would generally be those routinely or potentially
involved in the consumer’s care. Access control is at the provider organisation level,
not the individual provider. Organisations not identified on the consumer’s list will not
be able to access the consumer’s record, other than using the emergency override
facility.
Consumers will not be able, through HealthConnect, to deny access to an individual
provider within an authorised provider organisation, though it may be possible for the
consumer to address this requirement with the relevant provider organisation. It would
be misleading to consumers to claim that denying access to the individual providers
could be achieved unless organisational access control systems could also match the
requirement. Once a provider from an authorised provider organisation has accessed
the consumer’s record they may printout or download the information for incorporation
into the local record. After this it is the responsibility of the provider organisation to
control access.
Providers registered with HealthConnect will be required to sign an agreement
indicating that they will only access a consumer’s record as part of the process of
delivering health care to the consumer. Within HealthConnect, all access includes the
identity of the provider and provider organisation and the consumer will be able to
review access logs and check whether who has accessed their record.
Consumers will be able to change their HealthConnect access control arrangements in
line with their changing healthcare needs, for example, changing their general practice
or adding specialist groups to their list.
The access control arrangements are without time limit and will remain in force until
such time that the consumer changes them. Where access has been granted to cover
some temporary situation, eg while on holiday, it is the consumer’s responsibility to
remove the access rights when such access is no longer required. The potential for
introducing time-limited access will be explored further in future versions of
HealthConnect.
Access control arrangements may be established and changed in a number of ways,
including:
·
On enrolment in HealthConnect as part of the HealthConnect registration
process;
·
At reception areas on first presenting to a healthcare organisation;
·
By attendance at nominated HealthConnect agency;
56
HealthConnect
Business Architecture v1.9
·
Directly by the consumer accessing their HealthConnect record through the
HealthConnect web portal; and
·
By written instructions to HealthConnect.
5.2.4
Privacy of Consumer Records
The success of HealthConnect will depend on consumers, providers and provider
organisations having confidence and trust that health information is kept confidential
and secure. To this end, a robust privacy framework, together with strong security
measures, is required.
Providers participating in HealthConnect will be obliged to abide by existing privacy
legislation and by specific HealthConnect privacy protocols, covering access and use of
information from consumers’ HealthConnect records, and contributing information to
these records.
Although a national health privacy framework is not yet in place, the National Privacy
Principles and the proposed NHPC have informed the development of specific
HealthConnect privacy common service principles. More detailed information on the
privacy protocols is set out in Part E Implementing and Managing HealthConnect.
5.2.5
Consumer Responsibilities
Consumer participation in HealthConnect comes with certain consumer responsibilities
including:
·
making a decision whether to participate in HealthConnect;
·
maintaining consent arrangements so that providers from provider organisations
of their choice can access their HealthConnect record when required;
·
being aware of the HealthConnect protocols that will operate in an emergency
situation;
·
understanding the consequences of contributing to, or withholding information,
from their HealthConnect record. It is important that consumers are aware that
withholding information may directly impact the provision of healthcare
services;
·
being informed on how to obtain access to their HealthConnect record and
access log, including obtaining hard copies; how to complain or seek redress;
and how to obtain more information on HealthConnect and its governance
mechanisms; and
·
being responsible for the security and access control of any copies of their EHR
information they may store on a local system.
The consumer’s agents and legal representatives will have additional responsibilities in
protecting the privacy of the record on behalf of the consumer.
57
HealthConnect
Business Architecture v1.9
5.3 Consumer Registration
5.3.1
Identification of Consumers
HealthConnect Principles state that:
·
Enrolment in HealthConnect is available to all Australian citizens and residents
of Australia. While HealthConnect is for all Australians, early implementation
will focus on those likely to get greatest long-term benefit – likely to be those
suffering chronic diseases, populations with high morbidity and infants.
·
Each consumer and their EHR information will be uniquely identified within
HealthConnect by use of a single unique identifier able to be linked to any future
National Health Identifier.
It is important that each consumer has only one HealthConnect identifier so clinical
decisions can be made accurately and that information can be stored, retrieved and
exchanged efficiently. Consumers will need to provide evidence of identification for
registration to HealthConnect.
Consumers will have the ability to change their identities on HealthConnect (for
example, a change of name).
Initially the criteria used for Medicare eligibility will be used as the criteria for
consumers to participate in HealthConnect, though this will eventually be extended to
accommodate consumers who are not eligible for Medicare. The same proof of
eligibility documents accepted for Medicare registration will be used for HealthConnect
enrolment. Where consumers have previously registered for a Medicare smartcard, this
card will be sufficient evidence of both eligibility and identity for HealthConnect
registration.
5.3.2
Initial Registration Process
HealthConnect registration can occur in a number of ways, including:
·
registration at registration agencies acting on behalf of HealthConnect;
·
supported registrations, where additional time may be required for explaining
HealthConnect concepts, for example, for elderly consumers, consumers with
disabilities, or where registration occurs on behalf of another person; and
·
registration via a HealthConnect web based access tool (this would only be
possible where consumers have previously registered for the Medicare smartcard
and further identification is not required).
The registration process will involve the consumer:
·
providing the evidence required to uniquely identify themselves;
·
providing written agreement to participate in HealthConnect, indicating an
understanding of their rights as a consumer participating in HealthConnect,
including consent arrangements; and
58
HealthConnect
·
Business Architecture v1.9
optionally, providing consent to collect initial health profile information to
establish the health record.
The HealthConnect agency will then:
·
issue a unique HealthConnect identifier and assign to the consumer a personal
identification number (PIN), or equivalent, linked to the consumer’s
HealthConnect identification number. This PIN will also allow consumers
access to their HealthConnect records via web based systems;
·
set up the consumer’s HealthConnect record with consumer provided
information and initial population of the list of provider organisations authorised
to access the consumer record; and
·
initiate steps to collect the initial health profile information including obtaining
information from the consumer and sending requests for information to the
selected providers.
All registration processes will be developed to facilitate access by people from a nonEnglish speaking background. Registration processes will also be developed to
facilitate access by people with a disability.
5.3.3
Establishing the Initial Health Profile
The collection of initial health profile information is initiated at the time a consumer
registers with HealthConnect. This is an important part of establishing the record,
particularly for consumers with chronic and complex conditions and where consumers
have important allergies or alerts. For others, such as a predominantly healthy young
adult, it is likely that only a simple initial health profile will be collected.
All collection activities are subject to consumer consent with consumers being informed
about the types of information and sources of information being sought. Consumers
will subsequently be able to review the initial health profile and, if necessary, request
changes.
The initial health profile may comprise information from a number of sources such as:
·
family and social history information supplied by the consumer potentially
through an on-line registration system;
·
information on recent events taken from the Medical Benefits Scheme (MBS)
and Pharmaceutical Benefits Scheme (PBS) - what constitutes a recent event
will be determined as part of the process;
·
summary information such as current diagnoses, allergies and medications,
extracted from the systems of nominated providers, such as the consumer’s
general practitioner or specialist;
·
details of inpatient and emergency presentations and procedures from hospital
systems; and
·
selected records from registers such as the Australian Childhood Immunisation
Register.
59
HealthConnect
Business Architecture v1.9
While the information may come from multiple sources, only one source for each type
of information will be permitted; HealthConnect will not include the ability to
rationalise the data and resolve duplications and inconsistencies. The number and type
of sources from which the information is sought will vary depending on the health status
of the consumer.
5.3.4
Ongoing Identification
After the consumer is registered there will be an ongoing need to identify the consumer
to ensure appropriate and safe utilisation and management of their HealthConnect
record. The main circumstances in which consumer’s identity will need to be
authenticated are:
·
·
Consumer-initiated
-
when the consumer or their authorised representatives wish to change
registration and access control settings;
-
when the consumer or their authorised representatives wish to access
their record or add information to their record; and
Provider-initiated
-
when a provider organisation is requesting access to the record or
wishing to add an event summary to the record.
In the consumer-initiated situations the consumer will need to provide “two-tier”
authentication. The specific details of the requirement will vary depending upon the
setting and means of communication with HealthConnect. For example:
·
In a HealthConnect agency, through a kiosk, or at a provider organisation
location with a smartcard reader available, the Medicare smartcard and
consumer PIN will provide the required level of authentication; or
·
If accessing HealthConnect through a web browser the consumer’s
HealthConnect identifier combined with the consumer PIN will serve the same
purpose.
Where a provider organisation is requesting use of the record, there is a necessary precondition that will need to be satisfied. That is, the consumer, or their nominated
representatives, will need to have added the organisation to the consumer’s access
control list.
Upon the first presentation to the provider organisation, the consumer will inform the
provider of their HealthConnect identifier either verbally or by producing the card.
Where the smartcard and PIN are not used the provider organisation will need to follow
an identification process as determined by HealthConnect to confirm the identity of the
individual. The HealthConnect identifier can then be added to the consumer record in
the provider’s system. The processes will be established to reduce the chance of
incorrectly identifying the consumer or incorrectly entering the information.
Once the provider organisation has been added to the consumer’s access control list and
the consumer’s HealthConnect identifier is part of the consumer’s local record, the
provider organisation’s system can access the consumer’s HealthConnect record.
60
HealthConnect
Business Architecture v1.9
It will then be the organisation’s own identification processes which are relied upon to
authenticate the consumer’s identity for any particular healthcare event. In this situation,
the organisation is acting as a trusted agent of HealthConnect, with responsibilities set
out in the organisation’s HealthConnect participation agreement.
The HealthConnect Consumer Access Service will assist the consumer should they
forget their PIN. Standard identification processes involving asking the consumer a
series of questions including a ‘secret question’ will be used. These processes will also
be used where a consumer has forgotten their smartcard or PIN when presenting to a
provider organisation location for the first time to which they wish to give access.
In the future additional processes will need to be put in place to manage the provision of
access where the consumer is not present, and therefore not able to provide their
smartcard. Situations of this type may include calls by the consumer to Health Call
Centres.
5.3.5
Cancelling Registrations
A consumer can deregister from HealthConnect at any time by completing and
submitting the appropriate deregistration form.
For consumers who cancel their registrations, information in their HealthConnect record
will be withdrawn from view, but will not be deleted – this will be explained as part of
the informed consent process. Any future event summaries submitted to HealthConnect
will be rejected and providers will no longer be able to view the record.
This information remains available for medico-legal purposes and, should the consumer
wish to reinstate their HealthConnect participation at some stage in the future, the block
on viewing could be reversed. Information in a ‘withdrawn from view’ record will also
continue to be available for secondary reporting uses.
Upon notification of a consumer’s death, processes will be put in place to allow access
to those with a need eg for issue of death certificate, autopsy purposes or coroner
investigation and for secondary uses. Procedures will also be put in place to handle the
submission of any late and retrospective event summaries.
When children reach maturity they may choose to cancel their registration, or possibly
change their list of guardians and carers including to disable their parents’ access to
their record.
5.4 Consumer Interaction with HealthConnect
5.4.1
HealthConnect Consumer Access Services
HealthConnect Consumer Access Services (24x7) will be established to support
customer interaction with HealthConnect and these may offer additional services of
interest to consumers.
The primary role of the HealthConnect Consumer Access Services (HCCAS) is to
provide consumers with an effective means of accessing HealthConnect services and to
give them front line support for using HealthConnect. Processes identified as being
potentially associated with the HealthConnect Consumer Access Service role include:
61
HealthConnect
Business Architecture v1.9
(a)
Provide HealthConnect consumer access portal service (for consumers
accessing HealthConnect via a web browser and via consumer health
information systems)
(b)
Provide advice, assistance and training to consumers using or starting to
use HealthConnect;
(c)
Provide consumer support to resolve HealthConnect access and usage
problems;
(d)
Assisting to market HealthConnect to consumers and to facilitate
consumer registration; and
(e)
Provide consumer access to value added services, potentially including
supply of HealthConnect-compliant consumer health information
systems.
The key elements of the service – the HealthConnect Consumer Access Portal and the
link to Value Added eHealth Services - are discussed in subsequent sections.
5.4.2
Consumer Access to their Health Record
Consumers will have access to HealthConnect to view and, in the future, to contribute to
their EHR information and, also, to review the access log for their EHR and to set
preferences that control access to the EHR. This provision for consumers to access and
contribute to their own electronic health record is a fundamental principle of
HealthConnect. Empowering consumers and getting them more involved in the
management of their own healthcare is an important objective of HealthConnect.
There are a number of ways in which the consumer, or their nominated representative,
could access their record, these include:
·
Directly through a HealthConnect Consumer Access Portal, which will be web
based for version 1 of HealthConnect;
·
Via third party Value Added eHealth Services such as Consumer Health Tools
or Shared Care Program Tools;
·
At any HealthConnect agency for specific tasks such as the provision of an audit
trail report;
·
Using access points such as public kiosks, established at selected places such as
HealthConnect agencies, hospitals and major health centres; and
·
Via written instructions to HealthConnect for specific tasks such as requesting
the withdrawal from view of a particular event summary.
5.4.3
Consumer Direct Interaction
Consumers may participate in HealthConnect simply so that their healthcare providers
have access to their health information to assist in their treatment and management, and
have no other ongoing interaction. Alternatively they may select greater levels of
involvement, taking a more proactive role in HealthConnect and ultimately in their
healthcare.
62
HealthConnect
Business Architecture v1.9
Given that they have completed the registration process, signed the consent form,
indicated which providers may access their EHR and been given a card and PIN, the
type of interactions that consumers might have are:
·
(Necessary) Presenting their Medicare smartcard (or possibly in the future other
HealthConnect smartcards) at the first presentation at a healthcare
provider/organisation. The card will be read by the provider system and the PIN
entered so that the details of the consumer’s HealthConnect number can be
added to the local system and the consumer identified as a HealthConnect
participant. The consumer will not need to present their card at subsequent visits
to that particular health care provider organisation. Alternate processes will be
put in place in the absence of a smartcard.
·
(Optional) Requesting an event summary is not sent to HealthConnect. At any
stage a consumer may indicate to the provider they do not wish the details of the
consultation to be sent to HealthConnect. The provider’s system will have the
capability to accommodate this request.
·
(Optional) Updating access control preferences. This might be achieved by
visiting HealthConnect agencies, writing to HealthConnect, or via the web based
access portal provided by the HealthConnect Consumer Access Services.
·
(Optional) Using the web based access system, provided by a HealthConnect
Consumer Access Services, to view or in the future to add to their record.
·
(Optional) Using the HealthConnect Consumer Access Services if they have any
queries about HealthConnect operations. Consumers will need to take clinical
queries to the relevant provider.
·
(Optional) Lodging of formal complaints through the appropriate HealthConnect
complaints channels – a complaints procedure will be established.
5.5 HealthConnect Consumer Access Portal
From the time of registration, consumers will have the ability to use a HealthConnect
Consumer Access Portal to view and contribute to their HealthConnect record. This
will initially be via a web browser system requiring the consumer’s HealthConnect
identifier and PIN for access. The consumer’s nominated agents will also be able to use
a Consumer Access Portal to access the consumer’s EHR by identifying themselves as
an agent.
This Portal may be accessed from their home computer or personal digital assistant
(PDA), or possibly through third party systems such as information kiosks, work
computers, Internet cafes or a relative’s or friend’s computer or PDA. Consumers may
also download their record onto their computer and some consumers may purchase
consumer orientated health software that allows them to maintain a local copy of their
health record. Consumers will need to recognise that the local record will need to be
updated as new event summaries are submitted to HealthConnect.
The HealthConnect Consumer Access Portal will include the following functionality:
63
HealthConnect
Business Architecture v1.9
1. Viewing and printing of their HealthConnect records, including:
-
Composite views that bring together key aspects of the consumer’s
health information for ease of viewing. This might contain summary
health status information such as current medications, diagnoses and
alerts and recent investigation results; and
-
Individual event summaries, such as hospital discharge summaries,
emergency department presentations, provider consultations and
diagnostic results.
2. Consumer contributions to their HealthConnect records, which may in the future,
include:
-
Creation of a consumer event summary. This might include direct entry
of health information, for example self monitoring information such as
weight, blood sugar levels and peak flows;
-
Addition of a consumer comment related to a specific event summary;
and
-
Consumer diary functionality.
The scope of these consumer contributions is discussed in more detail below.
3. Maintenance of consumer demographic and social information, important in an
emergency situation, as well as for discharge planning following hospitalisation,
including:
-
Contact details, including next-of-kin information;
-
Social circumstances, for example, independent living arrangements,
family and work contacts; and
-
Social care agencies providing services to the consumer;
4. Maintenance of access control preferences that enable healthcare
providers/organisations access the consumer’s HealthConnect record;
5. Consumer access control i.e. maintenance of PIN details; and
6. Audit review of access to the consumer’s HealthConnect record. This will include
recording when and by whom information was viewed/printed.
Additional consumer facilities may be provided through third party value added eHealth
services as discussed below.
Consumer Contributions
The original HealthConnect business architecture suggests that consumers can submit
their own event summaries to HealthConnect. Possible examples cited in the literature
include consumer weight records, blood sugar readings, events such as “hypos”, pain
management, lifestyle issues (diet and exercise), feelings/emotions, self-medication
records and contributions to joint care-plans.
Consumer contributions to their records were not included in the scope of the early trials,
though the Tasmanian trial now allows consumers to submit event summaries.
Therefore the requirements and issues in this area have not yet been defined and
64
HealthConnect
Business Architecture v1.9
evaluated. Additionally, there are potential medico-legal issues with consumers
contributing to their heath records, not least because of the expectation by consumers
that their contributions will be reviewed, and acted upon by providers where necessary.
Hence consumer submission of event summaries which are accessible to providers will
not be included in the scope of the HealthConnect implementations at this stage. It is
recognised that overseas experiences have demonstrated some successes in this area,
and that it is likely that this type of functionality will evolve and become integrated into
HealthConnect as the surrounding issues are resolved. Hence:
·
For version 1 of HealthConnect consumer access will be limited to viewing their
EHR, and maintaining their personal details and access control list;
·
Subsequent implementations are likely to expand to include a consumer health
diary, with the information within the health diary being owned by the consumer
and intended to assist consumers in the management of their own healthcare.
The consumer health diary information will not be available to providers as part
of the consumer’s HealthConnect record, though mechanisms for access when
the consumer is present may be established; and
·
Future implementations are expected to include consumer contribution to their
records which can be accessed by providers; as the medico-legal and workflow
concerns are resolved.
The design of the health record systems should allow for this future requirement.
5.6 Consumer Value Added eHealth Services
The HealthConnect Consumer Access Services will also provide mechanisms for
linking to value added eHealth services which are outside the scope of HealthConnect.
For example it is not proposed that the core HealthConnect functions include the
provision of sophisticated consumer clinical decision making tools; though it is
recognised that many of the benefits of HealthConnect will be realised through these
systems/tools. Rather HealthConnect will promote the development of these tools by
commercial and not-for-profit organisations and support their use by providing the
required HealthConnect information on request and the promotion of the standards
necessary to enable these tools to work safely and effectively.
As in the US, these tools might be provided to consumers by private organisations to
promote self monitoring and improve consumer management of their own healthcare.
These facilities might be funded on a subscription basis or through reduced costs to
healthcare providers.
Consumer Health Tools
Examples of these tools might include:
·
Consumer health tools which facilitate self monitoring and the collection of
information such as weight, blood sugar levels and peak flows, access to
knowledge bases, decision support tools and care management advice. These
systems may also include facilities tailored to the specific needs of the consumer
with certain clinical conditions; and
65
HealthConnect
·
Business Architecture v1.9
Shared-care tools which encourage consumers to actively contribute to their
health records in conjunction with providers. A well-established shared-care
tool is the personal health record used in the monitoring of child health
developments from birth to five years.
These systems will need to have the capacity to download information from the
consumer’s HealthConnect record and the ability to create event summaries;
The Need for Clinical Interpretation
The information within a consumer’s HealthConnect record will primarily consist of
clinical information which is often highly technical in content. This is inevitable, as the
clinical information provided to HealthConnect is mainly generated by health providers
communicating with other health providers involved in the consumer’s care.
Consumer access to this information may require interpretation and possible representation in ways more meaningful to consumers.
As with the clinical tools this is not core HealthConnect functionality. However the
need of consumers to understand the technical content of their health records is an
important issue which HealthConnect needs to include in its design. For example
should a provider wish to include consumer friendly instructions in their event summary,
HealthConnect must be able to accommodate this.
The types of features to be addressed by consumer tools and services include:
·
Consumer-centric views of their health records, with a consumer look and feel,
including the use of online help and navigation guides;
·
Consumer management instructions within individual provider event
summaries that are written in plain English, to assist consumer compliance. This
might include the incorporation or reference to context sensitive, consumerfriendly material supporting consumer self management and compliance with
their healthcare regime;
·
Access to consumer-centric clinical guidelines and knowledge sources;
·
Clinical support services for consumers seeking clarification regarding the
content of their HealthConnect record, or consumer requests for additional
information. Such services could be operated by trained clinical staff capable of
providing consumer advice based upon the clinical content of the consumer’s
HealthConnect record.
The extent to which these consumer-centric facilities will be made available depends
upon how quickly commercial products and other initiatives such as health call centres
are established to address the requirements, and the extent to which providers are able to
incorporate consumer-centric elements within their event summaries.
66
HealthConnect
Business Architecture v1.9
5.7 Consumer Scenarios
Scenario 1. HealthConnect – Value Add for Accident Victims.
The year is 2010 and John and Emily Craig, having retired last year, are three months
into their planned twelve month motor home tour of Australia – having set out from
Brisbane and explored NSW and Victoria – they are on the road heading for Adelaide.
As part of their preparation for the trip they had been to see their GP for a thorough
check up and on his advice had registered for HealthConnect, and had arranged for all
their basic health information (past history, allergies, past illnesses and present diseases
and treatment) to be uploaded into HealthConnect so that wherever they were in
Australia this information could be retrieved if needed.
Early one evening, just before the Craigs were to stop and rest for the evening, a large
fuel tanker on its way from Adelaide to Melbourne jumped the median strip and sideswiped their oncoming motor home causing it to crash into a pole. In the accident, the
tanker driver was uninjured but unfortunately John and Emily both sustained significant
injuries. Using his mobile phone, the tanker driver informed rescue and ambulance
authorities of the accident and did what he could for the Craigs until help arrived. Once
the paramedics arrived at the accident scene they were able to access John’s
HealthConnect record remotely (his card was in his wallet) and discover that because of
his heart condition he needed to have the fluids given in transport carefully monitored.
John was the most severely injured and it was decided that he would be flown to the
Royal Adelaide Hospital (RAH). Besides a number of broken bones, John had suffered
a significant head injury which left him quite confused. Fortunately his HealthConnect
smartcard was passed on by the paramedics and using, the emergency override facilities
within HealthConnect, the RAH emergency team were able to access his medical
records swiftly and discover two key facts. Firstly, John had had severe allergic
reactions to intravenous dye in the past and so would need to have special cover to
prevent a recurrence during the urgent brain scan which he was about to undergo (where
dye would routinely be used). Secondly, John was on a regular heart medication that
needed to continue while he was treated for his head injury and other broken bones and
that the fluids started by the paramedics needed to be carefully monitored during his
further treatment. The record also showed that John had while travelling in remote
NSW had a check up at a nursing post for his heart condition, and that he had run out of
his heart medication.
Emily on the other hand was not too badly injured – having just a couple of fractured
ribs and a broken wrist. She was taken by road ambulance to a nearby district hospital
where she was given pain relief, relevant precautionary X-rays were taken and her wrist
was placed in plaster. The local hospital also contacted the Craig’s relatives and they
arranged to all meet in Adelaide after the motor home was salvaged and accommodation
close to the RAH was secured.
Emily was able visit John the next day in the RAH’s Intensive Care unit and was greatly
relieved to know that his brain scan had been completed quite safely – due mainly to the
warning derived from the information obtained from HealthConnect – and that there
was an excellent chance that both the head injury and the other injuries would heal
successfully and that any deterioration in his heart condition would be avoided thanks
again to HealthConnect.
67
HealthConnect
Business Architecture v1.9
John was eventually discharged from the RAH some two weeks later to the attached
rehabilitation unit – and it was really only then his local doctor in Brisbane discovered
how valuable the information he had placed on HealthConnect had been, although he
had been alerted of their admissions to the two different hospitals when they happened
via a HealthConnect notification. The news came via the RAH Discharge Summary
from HealthConnect - Dr Hall, not being on the RAH’s internal provider directory,
would not normally have received this electronically. Dr Hall subsequently received a
discharge summary from the rehabilitation unit.
The discharge summaries highlighted the successful extra precautions taken to ensure
John’s safety and what special care John needed once he returned home. The doctor
had, of course, been aware of Emily’s progress much earlier as the smaller district
hospital had transmitted a discharge summary with her treatment when she left the
hospital the day after the accident.
Once at home, John’s local physiotherapist was able to develop a targeted treatment
plan assisted by looking at the imaging reports and the Adelaide allied health team
reports on HealthConnect.
The pleasing news is that four months later John and Emily are about to set out again to
complete their trip – due in no small part to the help given by HealthConnect’s
capabilities to move critical health information to where it is needed nationwide.
Scenario 2. HealthConnect – Value Add for the Young Family.
It is 2009 and HealthConnect has now registered over 70% of the adult population to
have their health records managed and retrieved by HealthConnect - the Australian
national electronic health record program.
A few years ago in 2006, Amanda Duncan was an early registrant who decided to sign
up to have her records and those of her children transmitted to HealthConnect – after
she was thrilled to discover that she was pregnant with her daughter Emma who was
born some seven months later.
Amanda has been feeling a little ‘unusual’ for a couple of weeks and decides to arrange
an appointment with her usual GP (Dr Ellen Grant) suspecting it just could be that she is
pregnant a second time. On calling the surgery she is disappointed to find that Dr Grant
is not available – being herself on maternity leave – and that her locum (Dr Phoebe
Mills) is looking after the surgery. Amanda agrees to come and see Dr Mills who can as
she works in the same practice access Amanda’s and Emma’s HealthConnect records so
she can ‘get up to speed’ before they meet in a few days (when Dr Mills moves to work
as a locum at a practice without authorisation, she will no longer have access to
Amanda’s record). Had Amanda decided to go to a different practice she could have
used her HealthConnect smartcard to provide access to her records for the doctor she
was seeing if she so chose.
On the day of the appointment, Dr Mills opened her Clinical Information System,
requested Amanda’s and Emma’s HealthConnect records and downloaded them to her
system. Here an advanced rule-based decision support system assessed information
from each of the records. From this assessment it was identified that Amanda needed
the routine early pregnancy checks should she indeed to turn out be pregnant and Emma
was a couple of months overdue for her year three vaccinations. Dr Mills noted these
68
HealthConnect
Business Architecture v1.9
findings and found stocks of the required vaccines were low and arranged for a delivery
so she could be sure they were ready when her patients arrived. The only concern that
was raised in the review of the records was a report relating to the previous pregnancy
that Amanda had suffered from high blood pressure and it was important to ensure this
had been fully resolved. Amanda’s blood pressure would need to be carefully tracked
during this pregnancy.
Later that day Amanda and Emma arrived for their appointment. Forewarned, Dr Mills
had all the necessary vaccines ready for Emma (who was less than impressed at the
prospect of a needle) and had the pathology forms ready so Amanda could be quickly
checked for any unexpected complications in the event she was indeed pregnant. The
rapid pregnancy test confirmed the good news that Amanda’s instinct was proved
correct – blood was collected for the routine tests and after some general
congratulations all around Amanda said she was keen to use the same obstetrician
(whom she had previously authorised to access her HealthConnect record). An
appropriately timed appointment and referral was made electronically – from Dr Mills
computer to the appointment system of Dr Adrian (the obstetrician) making additional
use of the HealthConnect communications network. Printed confirmation of the
appointment was given to Amanda as she left, as well as another appointment with Dr
Mills for one week’s time to review the test results and to ensure Amanda was happy
will all the arrangements and had no pressing questions etc.
For the next seven months Dr Mills and later Dr Grant (Amanda’s usual GP) received
notifications and progress reports on her visits to the Obstetrician – along with some
pictures of the ultrasound which was done at 18 weeks to confirm the status of the
pregnancy and rule out major congenital deformities. Through HealthConnect these
were available the day after they were done. This meant that when Amanda developed
a nasty episode of the flu about 28 weeks into the pregnancy Dr Grant was on leave, but
the temporary locum was able to catch up with the progress of the pregnancy and could
give optimum care to both Mum and the expected baby.
Amanda delivered a few weeks earlier than expected and needed minor operative
intervention to ensure a healthy baby was delivered. On the day of the birth Dr Grant
received a progress report via HealthConnect and later, on the day of discharge, a
discharge summary from the Maternity Hospital. These enabled her to check and be
confident that, if Amanda had any complications, she could offer informed assistance.
As it turned out, Amanda and Troy (the new baby boy) had no problems but Amanda
was greatly reassured that all those involved in her care knew exactly what the other
was doing and could work in a co-ordinated effective way to ensure a healthy mother
and baby - due at least in part to the capabilities of HealthConnect.
Scenario 3. HealthConnect – Value Add for those with Chronic
Disease.
It is 2008 and HealthConnect has now become an important and accepted part of Jim
Boyle’s life. Jim is now just over 60 and had been forced by worsening health to ease up
on his previously very active life as a building tradesman and to devote a little more
time to looking after himself, and planning for a healthier retirement.
Jim’s health problems began in late 2004 when the combination of poor dietary habits,
maybe a few too many beers after work and a move to more office work led to less
69
HealthConnect
Business Architecture v1.9
exercise, weight gain, and eventually to a feeling of progressive tiredness and increasing
difficulty getting around due to a gradually worsening pain in his right hip.
It was thus, early in 2005, that Jim finally decided, with much prompting from his wife
to visit his local GP for the first time in living memory! At the end of the first visit the
GP (Dr Andrew Hall) had formed tentative diagnoses of Type II diabetes and slowly
progressive osteoarthritis of the right and probably left hip. Fortunately for Jim, Dr Hall
had recently signed up to HealthConnect as a provider and just before Jim left to have a
range of tests, Dr Hall had explained to him that his care over the next few months and
years could be streamlined should he decide to register as a consumer on the
HealthConnect system and use the system to keep track of progress getting his diabetes
under control and his weight down – to help lengthen his life and much improve the
pain in his hip – deferring perhaps for years the need for more serious intervention such
as surgery.
Dr Hall explained to Jim that once he agreed to join HealthConnect it would be possible
for Dr Hall to use HealthConnect to closely monitor the progress of Jim’s diabetes and
reduce the number of times he actually had to go and see the doctor (something Jim
hates). Dr Hall explained that he could use HealthConnect to keep an eye on how
things were progressing and additionally could schedule routine visits around important
scheduled checks of vision and foot health (which may deteriorate with diabetes). On Dr
Hall’s advice Jim registered and consented to be a participating HealthConnect
consumer at his local Medicare office.
The next visit to Dr Hall a week later confirmed the diabetes as well as osteoarthritis of
both hips (milder in the left) and, Dr Hall explained what Jim would now need to do in
order to track and manage his condition. Being a moderately skilled person with good
understanding of his situation Jim was given the option of piloting using HealthConnect
or attending the surgery several times a week to track his condition. Jim took home the
documentation from HealthConnect which explained how he and Dr Hall could use the
HealthConnect system to enter and then keep track of his blood sugars, his home
measured blood pressure and his weight between visits to the doctor. (This capacity to
make use of information recorded by a patient is still being piloted and evolved by
HealthConnect and presently needs Jim and Dr Hall to sign specific consents, but such
facilities are in increasingly wide use overseas). Dr Hall also started Jim on an oral
hypoglycaemic tablet (anti diabetic tablet) and pointed out to Jim that with weight
reduction and careful dietary control, it was possible that, over time, his need for the
tablet may be reduced or even cease.
Each fortnight Dr Hall was able to access the records Jim created and ensure all was
going to plan. When problems arose, and this was quite common in the early months,
Dr Hall was able to contact Jim by phone or e-mail and, when Dr Hall’s clinical
information system identified any additional tests or routine follow-up that was required.
This was arranged at the same time. In this way both Jim and Dr Hall were able to
ensure Jim’s health was improving and any required adjustments to Jim’s treatment
could be simply arranged. Indeed, with Jim’s weight having dropped by 15 kilos and
his HbA1C being within the normal range after six months, (demonstrating the overall
effectiveness of his blood sugar control), Dr Hall was able to reduce the tablet dosage
and reduce the frequency with which Jim needed to check his blood sugar – good news
all around – less pain for Jim (in both his hips and fingers not having to sample his
blood so often), less cost for medication and use of state-of-the art evidence-backed care
all co-ordinated by HealthConnect and allowing both Jim and Dr Hall to do a better job
70
HealthConnect
Business Architecture v1.9
more easily. In particular, through the use of HealthConnect, Jim was able to minimise
the impact of his treatment on his employment and family life.
Now in 2008, HealthConnect has been helping Jim live a longer and happier life for
over three years while reducing the risk of complications of his diabetes and maybe
even avoiding the need for hip surgery. No wonder Jim is a convert – convinced he
now has control of his health, in co-operation with his doctor, back again!
71
HealthConnect
6.
Business Architecture v1.9
Healthcare Provider/Organisation Participation
The provision of timely, accurate and clinically useful information to healthcare
providers at the point-of-care is one of the key objectives of HealthConnect. The
availability of HealthConnect information will assist providers in delivering safe and
effective healthcare, and the provision of HealthConnect event summaries by providers
will facilitate on-going care provision. The ability of HealthConnect to integrate
seamlessly within healthcare providers work practices will be critical in ensuring the
success of HealthConnect.
This section outlines what being involved in HealthConnect will mean to providers and
provider organisations including:
·
Benefits to providers and provider organisations;
·
The process of provider identification and registration;
·
Provider privacy and consent responsibilities;
·
The interaction providers will have with HealthConnect; and
·
Use of value added eHealth systems which will interface with HealthConnect.
6.1 Benefits of HealthConnect to Provider/
Organisations
Analysis of provider benefits have been conducted throughout the HealthConnect
research and development activities, drawing on the experiences of the HealthConnect
trials. In addition, a full analysis of the potential HealthConnect benefits is presented in
the Benefits Realisation Framework13.
The expected benefits of HealthConnect for participating providers include:
·
·
13
Support for Medication Management, including:
-
More informed medication management;
-
Fewer prescriptions written and dispensed;
-
Increased efficiency in dispensing prescriptions; and
-
Fewer dispensing errors.
Assisting Decision Making and Care Coordination, including:
-
Better informed clinical decision-making;
-
Enhanced management of complex and chronic disease;
-
Improved knowledge about the existence of patient co-morbidities;
-
Reduced incidence of unnecessary services;
-
Improved coordination of patient care; and
HealthConnect Benefits Realisation Framework V1.0 October 2004
72
HealthConnect
·
·
Business Architecture v1.9
Increased efficiency and effectiveness of transfer of patients between
care settings.
Enhancing Service Delivery Efficiency, including:
-
Increased efficiency of outpatient services;
-
Increased efficiency of peri-operative processes; and
-
Decreased length of stay.
Improved Information Management, including:
-
Increased efficiency of referrals from general practitioners to specialists;
-
Increased efficiency of information exchange between care providers;
-
Reduced time spent chasing paper-based records or dispersed electronic
records;
-
Reduced duplication of effort in updating records; and
-
Improved accuracy of information.
6.2 Provider Participation Boundaries
6.2.1
Scope of Provider Participation
The HealthConnect Principles relating to providers include:
·
Provider participation in HealthConnect will be voluntary and will remain
active until the provider gives HealthConnect a request to deregister or the
provider is no longer eligible to participate in HealthConnect (as determined by
the rules governing the operation of HealthConnect.)
·
HealthConnect will support a whole-of-health perspective encompassing private
and public providers and continuity of care across primary, secondary and
tertiary care settings including preventive health.
·
Provider participation in HealthConnect will be encouraged and will be made
available to all providers involved in the chain of health care delivery. While
the initial focus is likely to include medical practices, pharmacies, hospitals,
diagnostic services, health and aged care facilities and those practitioners
currently participating in HealthConnect initiatives, this scope will be extended
through arrangements with representatives of each provider group.
Considerable efforts will be made in the implementation of HealthConnect to streamline
the access process and keep to a minimum the impact on provider work practices and
focus on delivering value to the provider. It is assumed that this approach, together with
appropriate marketing and education, will result over time in a high participation rate.
6.2.2
Provider Organisations and Individual Providers
Provider participation in HealthConnect occurs at the level of both individual provider
and provider organisation. Provider organisations must be registered with
HealthConnect and work is progressing on the requirements for individual provider
participation. Hence:
73
HealthConnect
Business Architecture v1.9
·
A person practising as a health provider who is recognised for professional
registration in an Australian jurisdiction will be eligible to register with
HealthConnect as an individual provider. This will require their professional
registration body to have been previously recognised and registered with
HealthConnect.
·
A registered business (including a sole trader) that delivers health services
using the services of one or more individual providers will be eligible to register
with HealthConnect as a “provider organisation”.
Individual providers will include general practitioners, specialist medical practitioners,
diagnostic specialists including pathologists and radiologists, nurse practitioners and
community nurses, pharmacists etc.
Organisational providers potentially include any of the following: medical centres;
general and specialist hospitals; community health centres, Aboriginal medical services,
residential aged care facilities and nursing homes etc. Any individual provider
operating as a sole trader or as a business enterprise will also be registered separately
with HealthConnect as a provider organisation.
Consumers consenting to providers accessing their HealthConnect records do so at the
level of the provider organisation (for example, a hospital or a general practice).
Thereafter, all personnel authorised by the nominated provider organisation will be able
to access the consumer’s HealthConnect record.
There is a requirement for HealthConnect to provide consumers with access to an audit
trail detailing who has accessed which parts of their HealthConnect health information,
necessitating both individual providers and provider organisations to be uniquely
identifiable. The audit trail report will display the name of the organisation, the user
who has accessed the information and the various parts of the participant’s health
records that were accessed. The delivery of reports at this level of detail requires all
personnel accessing the consumer’s record and the health care organisation from which
access occurred to be uniquely identified.
All information submitted for inclusion in a HealthConnect EHR will be attributable to
an individual provider as well as to the provider organisation from which it originates.
To submit entries for inclusion in the EHR, individual providers must already have been
uniquely identified within the organisation so that they can be identified to
HealthConnect.
It is recognised that there are a group of clinical support staff who are not clinicians but
will require access to HealthConnect as part of their current work practices. These
clinical support staff include surgery receptionists, admissions and ward clerks, and
junior clinical personnel. This group of users will not be individually registered on
HealthConnect but will need to be identified to HealthConnect by the organisations to
fulfil monitoring and audit requirements in a manner acceptable to consumers.
Procedures to support this requirement are currently being developed.
74
HealthConnect
6.2.3
Business Architecture v1.9
Provider Identification
Provider registration and identification requirements are defined together with consumer
requirements in the Registration and Identification Business Requirements document14.
·
Each provider (individual or organisation) will be uniquely identified within
HealthConnect by use of a single unique identifier linked, in the future, to the
National Provider Directory.
The National eHealth Transition Authority (NEHTA) has, as one of its strategic
priorities, the development of a national solution for unambiguous identification of
providers, known as the national provider directory (previously ProviderConnect).
HealthConnect will, in due course, make use of the national provider directory in
identifying and referencing HealthConnect providers.
To provide interoperability, give longevity to the information being recorded in
HealthConnect and to ensure that the entities are correctly identified, the identifier
allocated to a provider or provider organisation will be compliant with all relevant
national and international standards for health provider identification (for example,
AS4846 - 2004 Australian Standard for Health Care Provider Identification).
6.2.4
Provider Registration
A provider’s participation in HealthConnect will be subject to the provider having
entered into a legal agreement with the HealthConnect governing body which will set
out the obligations of the provider and provide the basis both for the provider’s use of
HealthConnect and the protection of consumer privacy.
Registration of provider organisations
A health provider organisation employing individual health providers will be able to
enrol in HealthConnect. The provider organisation must be a legal entity able to enter
into an agreement with HealthConnect. Public and private hospitals, outpatient clinics,
general practices, community health centres, pharmacies, aged care facilities and other
non-government health agencies are examples of health provider organisations.
Healthcare organisations wishing to participate in HealthConnect would need to:
·
enrol in HealthConnect;
·
acknowledge and support consumer preferences for participation in
HealthConnect;
·
follow HealthConnect guidelines and procedures for the use of HealthConnect;
·
manage staff participation in HealthConnect; and
·
secure and authorise use of HealthConnect information within the organisation.
The organisation’s representative or agent will be required to complete and submit to
HealthConnect an assessment of the organisation’s eligibility as part of the enrolment
14
Registration and Identification Business Requirements V1.01 Aug 04
75
HealthConnect
Business Architecture v1.9
process. The organisation must meet HealthConnect requirements on privacy and
security in order to participate.
Registration of individual providers
Processes for individual provider enrolment with HealthConnect will be developed to
complement existing and future professional registration processes and will be designed
to have a minimal impact on the individual provider’s existing business processes.
Providers wishing to participate in HealthConnect would need to:
·
enrol in HealthConnect including signing a HealthConnect agreement;
·
acknowledge and support consumer preferences for participation in
HealthConnect; and
·
follow HealthConnect guidelines and procedures for the use of HealthConnect.
6.2.5
Authorisation of Providers
Providers will only be able to access, view and contribute to the records of consumers
for whom the provider organisation has been authorised. Provider organisation
nomination will mainly be established by consumers in advance of a consultation,
although the consumer may nominate provider organisation access at the time of the
consultation. HealthConnect will also support access using emergency override.
The HealthConnect Principles state that:
·
HealthConnect will allow any registered individual provider acting on behalf of
a provider organisation that has authority to access the consumer’s EHR for the
purpose of providing health services to the consumer.
·
A provider’s organisation must have the consumer’s consent prior to an
individual provider accessing a consumer’s HealthConnect EHR. This consent
would typically be set up at registration or the first time the consumer presents
at the provider organisation’s premises.
·
Providers once authorised will be able to access all parts of the consumer’s
HealthConnect EHR. HealthConnect will not determine which parts of the EHR
are relevant to any individual health encounter.
·
All access to a consumer EHR will be logged and able to be tracked back to an
individual provider or consumer.
6.2.6
Provider Authentication
Stringent security and authorisation mechanisms will be put in place to ensure that only
authorised providers can access consumer records. Different levels of authentication
will apply depending on the access scenario:
Where a provider wishes to access a consumer’s information using an endorsed
healthcare IT system operating within a facility that is managed by a registered
healthcare organisation, the provider’s identity shall be authenticated by the normal
76
HealthConnect
Business Architecture v1.9
means used by that healthcare system. The individual provider’s HealthConnect
identification will then be included in each access request.
Where a provider wishes to access a consumer’s record using another device such (eg a
PC, laptop or PDA) the provider’s identity shall be authenticated by at minimum of two
factor authentication, for example a user defined PIN or equivalent and a token
containing a personal digital certificate.
6.2.7
Provider Responsibilities
Individual providers and provider organisations will be required to sign HealthConnect
agreements outlining their responsibilities at time of registration. As participants of
HealthConnect, provider responsibilities include:
·
Commitment to providing accurate information to HealthConnect. Providers
will be able to review the event summary prior to it being submitted to
HealthConnect;
·
Recognition of consumers rights as participants in HealthConnect (eg not
sending an event summary to HealthConnect if requested not to do so). This
includes a duty to assist consumers understand the implications of withholding
information from their HealthConnect record or restricting access to their
HealthConnect record, which may impact the ability of providers to deliver safe
and effective healthcare;
·
Participation in line with the HealthConnect confidentiality and privacy
arrangements. Providers must abide by privacy legislation and by specific
HealthConnect privacy protocols;
·
Local procedures which comply with appropriate national standards, to meet
HealthConnect privacy and security requirements. These will include processes
to control access to, and audit the use of, the organisation’s information systems.
Provider organisations will be responsible for controlling its personnel’s use of
HealthConnect information and for ensuring that the individual provider (or any
other person) accessing the consumer’s EHR on behalf of the provider
organisation is identified to HealthConnect;
·
Using clinical information systems to access HealthConnect that comply with
the technical requirements of HealthConnect; and
·
Maintaining security of any EHR information integrated into their clinical
information systems. Once HealthConnect EHR information has been entered
into a local system, the owner of that system has responsibility for the security
of the information.
6.2.8
Privacy and Confidentiality
The success of HealthConnect will depend on consumers, providers and provider
organisations having confidence and trust that health information is kept confidential
and secure. To this end, a robust privacy framework, together with strong security
measures, is to be established as proposed in the HealthConnect Principles:
77
HealthConnect
·
Business Architecture v1.9
HealthConnect participants will be obligated to abide by privacy legislation and
by specific HealthConnect privacy rules. The National Health Privacy Code
will be used when it has been implemented, until then privacy arrangements will
be tailored to suit each jurisdiction for each implementation, with a view to
working towards a single national set of rules.
Provider organisations and individual providers participating in HealthConnect will be
obligated to abide by existing privacy legislation and by specific privacy protocols
developed for HealthConnect – including when providers seek health information from
HealthConnect, or when they add information to any HealthConnect record.
The privacy framework will ensure that both consumer and provider privacy interests
are managed.
6.3 Provider Interaction with HealthConnect
The key HealthConnect Principles relating to provider interaction are:
·
HealthConnect will not replace providers’ own clinical records or clinical
information systems. Providers will continue to maintain their own consumer
health records but may choose to incorporate selected HealthConnect EHR
information in their records or clinical information systems.
·
Providers will interact with HealthConnect primarily through their clinical
information systems. A standard web-browser interface to HealthConnect will
also be available for providers whose systems cannot initially link to
HealthConnect.
·
HealthConnect will aim for access to HealthConnect to be integrated into the
providers’ clinical information systems and as far as practicable streamline
access and keep to a minimum impact on provider work practices.
6.3.1
Provider eHealth Access Services
A central role in HealthConnect is that of provider eHealth access services (eHAS)
whose primary function is to give providers effective means of accessing
HealthConnect services and any front line support needed to help them in using
HealthConnect.
This role was highlighted in the HealthConnect Roles/Services diagram presented above
in Section 4 - The HealthConnect solution.
Functions identified as being potentially associated with delivery of provider eHealth
access services include:
(a)
providing HealthConnect access portal and connection to the core
HealthConnect message handling and transport system (for providers
accessing HealthConnect via both clinical information systems and web
browsers);
(b)
providing advice, assistance and training to HealthConnect providers
using or starting to use HealthConnect;
78
HealthConnect
Business Architecture v1.9
(c)
providing eHealth support service to resolve HealthConnect access and
usage problems;
(d)
providing access to eHealth message bank service and facilities that
support secure transmission of eHealth messages (including prescriptions,
referrals and notifications) between providers;
(e)
providing access to added-value services, potentially including supply of
health information and clinical decision support services, HealthConnectcompliant clinical information systems, and associated consulting and
advisory services; and
(f)
assisting to market HealthConnect to providers and facilitate provider
registration.
The functions of the Provider’s Clinical Information System, the Provider Access Portal,
the Value Added eHealth Services and the eHealth Message Bank Service are discussed
in the sections below.
6.3.2
Provider Clinical Information System Interfaces
The longer term goal is that providers will, for the main part, access HealthConnect
through their own clinical information systems, which will inter-operate with the
HealthConnect message handling and transport system through nationally defined
HealthConnect interfaces.
The provider systems will generate and supply event summaries to HealthConnect.
Providers will send provider-initiated requests for consumer health information views to
HealthConnect and utilise the resultant information retrieved from HealthConnect. The
HealthConnect information will be presented succinctly to providers via specially
tailored EHR views/lists that bring together key aspects of a consumer’s health
information, such as medications, allergies and alerts, problems and diagnoses.
These provider clinical information systems will provide all aspects of the provider’s
“user interface” to HealthConnect so that providers will not need to use HealthConnect
directly.
The HealthConnect interface to a provider’s clinical information system (CIS) will
include the following functionality:
1.
Provision of information to create views of consumer HealthConnect records
such that the provider’s CIS can create the view. This will be subject to the
provider’s organisation having been authorised as part of the consumer consent
process. Views include:
-
Composite EHR views and lists that bring together key aspects of the
consumer’s health information for ease of viewing. This might contain
summary health status information such as current medications,
diagnoses and alerts and recent investigation results; and
-
Individual event summaries, such as hospital discharge summaries,
emergency department presentations, provider consultations and
diagnostic results.
79
HealthConnect
Business Architecture v1.9
The provider may elect merely to view the information or to incorporate the
information into their local system.
Within this functionality there will be support for specific information
downloads, for example a pharmacist using the barcode on a printed script to
download the prescription details to assist the dispensing process.
2.
Receipt of the event summary containing predefined key aspects of the
consumer consultation to HealthConnect, again subject to authorisation via
consumer consent. This will be automatically generated and sent by the
providers system, though the provider may elect not to send or all part of it, on
request from the consumer.
3.
Provision of Notifications regarding key consumer healthcare events including
hospital admissions and discharges and emergency department presentations.
4.
Provision of consumer demographic and summary health information –
where a consumer presents for the first time and provides access using their
HealthConnect identifier, HealthConnect will provide consumer demographic
and summary health information which can be integrated into the provider’s
local system.
5.
Receipt of initial health profile information – provider systems may upon
request create and send a message containing parts of the consumer’s initial
health profile.
6.3.3
HealthConnect Provider Access Portal
Where there are no clinical information systems in place, the Provider Access Portal
will provide web based access to HealthConnect to providers to facilitate viewing
records and creating event summaries. These facilities will be limited to core
HealthConnect functions only (that is, there will be no “value-added” provider services
such as medication management and clinical decision support). This web based access
is considered an interim measure and not part of the core HealthConnect, and as such it
will be phased out over time.
The HealthConnect Provider Access Portal web-based access will include the following
functionality:
6.
7.
Viewing and printing of consumer HealthConnect records, subject to the
provider’s organisation having been authorised as part of the consumer consent
process, including:
-
Composite views and lists that bring together key aspects of the
consumer’s health information for ease of viewing. This might contain
summary health status information such as current medications,
diagnoses and alerts and recent investigation results; and
-
Individual event summaries, such as hospital discharge summaries,
emergency department presentations, provider consultations and
diagnostic results.
Creation and transmission of an event summary, according to a predefined
event summary format appropriate to the provider type.
80
HealthConnect
Business Architecture v1.9
8.
Receipt of Notifications regarding key consumer healthcare events including
hospital admissions and discharges and emergency department presentations.
9.
Maintenance of provider preferences – it is anticipated that there will be the
facility for providers to record and change preferences such as types of views
they prefer to access, types of notifications they want to receive.
10.
Provider logon access i.e. maintenance of security PIN or equivalent details.
For some providers it may be that a combination of the two solutions (i.e. messaging
access through their clinical information system and direct access using the access
portal) would be required.
For example, the provider’s system may be able to create and send event summaries but
not initially have the capability to receive the EHR information and create the required
views.
6.3.4
Value Added eHealth Services
HealthConnect will make available health record information which will support
clinical decision making. It will not itself perform clinical decision support; rather it
will support providers’ local systems in performing these functions which include:
·
Medication management (including support for prescribing, medication
interaction checking and dispensing);
·
Evidence based information; and
·
Sophisticated event notifications based on analysis of the clinical information
within the event summaries.
To support these value added services HealthConnect must be able to provide the
information in an appropriate computable and interpretable form.
The HealthConnect Principles state that:
·
6.3.5
Implementations of value added services are outside core HealthConnect
functionality. While individual implementations of HealthConnect may include
optional value add functionality to address local requirements, these are related
systems and must be implemented such that they do not affect the compatibility
of the HealthConnect implementation with the national standards.
eHealth Message Bank Service
Though the eHealth Message Bank Service support for operational communications
activities such as electronic referrals, investigation requests and investigation results is
not part of the core functions of HealthConnect, it is expected to be established as a
related service.
The role of the eHealth message bank service is to provide a facility for handling
eHealth messages between participating providers and relating to any health consumer
(not just those who consent to participate in HealthConnect).
81
HealthConnect
Business Architecture v1.9
Providers wishing to use this service will need to register with HealthConnect in order
to formalise agreements and establish a provider identifier. This does not necessarily
imply active use of the HealthConnect EHR.
In the absence of a national identifier for consumers, use of the eHealth message bank
service in stage 1 will be limited to HealthConnect consumer participants. Once a
mechanism has been established for unique identification of non HealthConnect
consumers, the service can be expanded.
The HealthConnect Principles state that:
·
Implementations of HealthConnect are likely to build on the messaging service it
requires and conduct, as an adjunt to the core service, an implementation of a
wider eHealth message bank service to support other health communications.
6.4 Key Work Practice Implications
For the main part, provider interaction with HealthConnect will comprise the creation of
event summaries for each healthcare event for HealthConnect consumers and the
retrieval of HealthConnect consumers’ EHR information via views.
In addition to these core functions there are a number of specific functions which will
impact provider work practices such as authorising diagnostic test results; maintaining
current medications lists; receiving notifications and creating initial health profiles.
These core and specific functions are discussed below.
6.4.1
Creating Event Summaries
A critical aspect of the creation of event summaries is the quality and completeness of
the information being entered into the provider’s clinical information system as part of
their normal work practices. A key aspect of HealthConnect implementations will need
to be focussed on change management activities to improve the quality of the data
available in the local clinical information systems.
Once the data has been entered into the provider’s system, the creation of event
summaries should fit in with provider work practices. For example:
·
The hospital event summary will be created in parallel with the standard hospital
discharge referral and sent to HealthConnect once authorised by the discharging
clinician;
·
A general practitioner consultation event summary will be created by the
doctor’s clinical information system based on information entered during the
consultation. The doctor will have the opportunity to review and edit the event
summary prior to its submission; and
·
A diagnostic test result event summary, or possibly a link to the result
information, will be a by product of the standard electronic result message.
In all cases providers will have the ability to, on request, not send the event summary or
delete selected information prior to sending the event summary. To be considered
HealthConnect compliant the providers’ clinical information systems will need to
provide this facility.
82
HealthConnect
Business Architecture v1.9
Where the provider uses the HealthConnect web based tool for event summary creation
(a short to medium term solution) there will be a greater manual effort to set up the
event summary.
Vendors of provider systems will be encouraged to support the collection and checking
of data required in the event summary. Similarly providers will be encouraged to enter
this information as part of their normal work practices and increase the focus at the time
of data entry on the quality and completeness of the information being collected. In this
way the creation of an event summary will become a seamless by product of standard
work practices.
6.4.2
Retrieving EHR information
The first step in a provider retrieving information from HealthConnect is for the
provider to access and open the relevant consumer’s EHR.
The presentation of information received and the navigation pathways provided will
depend on the provider’s own CIS functions (or on the Access Portal Application)
rather than on HealthConnect itself.
The starting point for most providers is expected to be the “primary/critical view” which
provides information such as identification of the consumer; alerts, allergy and adverse
reaction list; existing diagnosis/problems list; and latest medications. It will also
contain secure links to further information such as relevant medication list; laboratory
test results list; recent health events; and procedure/treatment history.
Technology for reducing the impact of EHR systems operation on users is still in the
early stages of development and refinement of these concepts is expected to be a major
focus of the implementation architecture and of development work for stage 1
implementations.
A potential mode of operation might be that when the CIS opens up with the
consumer’s local record, it automatically establishes a communication session with
HealthConnect and brings up the critical view in the background ready, should the
provider so wish, to be viewed. Technologies such as the HL7 Clinical Context Object
Workgroup (CCoW) initiative could be used to identify the consumer and provider to
HealthConnect so that consent checking and creation of the view can be achieved
without intervention from the provider.
It is also anticipated that the provider’s CIS will put mechanisms in place to ensure that
the provider does not spend time reviewing information already reviewed as part of a
previous consultation. The CIS might, for example, highlight information which has
changed since the provider last accessed the consumer’s EHR, and the provider may
choose just to review that information.
6.4.3
Authorising Diagnostic Test Results
There has been considerable debate about whether diagnostic test results should be
submitted directly to HealthConnect or to the requesting provider for review and
subsequent incorporation into an event summary. Diagnostic test results are critical
parts of the EHR especially in an emergency and there is concern about any potential
delays in their being available on the consumer’s record.
83
HealthConnect
Business Architecture v1.9
The proposed solution is that:
·
All diagnostic test results for participating consumers will be sent to
HealthConnect at the same time as being issued to the requesting provider, with
the exception of diagnostic tests for hospital inpatients.
·
For inpatients it is considered that the test results will already be available to
those involved with caring for the consumer during the hospital stay. Only at
discharge will those tests deemed appropriate by the discharging clinician be
sent to HealthConnect as part of the discharge summary referral.
·
Test results sent to HealthConnect directly will not be available for viewing until
the requesting provider has reviewed the result and confirmed its release to
HealthConnect (to allow providers the opportunity of discussing with consumers
prior to general availability). Message functions will be established for this
purpose. In the future a parameter may be established which sets a time period
after which the results will become available whether or not the provider has
released them. The latter is not the current model.
·
Emergency access to the record will include access to all results available in
HealthConnect at the time, including non released tests. This emergency access
includes emergency presentations where the consumer is able to give consent as
well as the emergency override facility.
6.4.4
Maintaining EHR Lists
An EHR list is a collection of similar EHR items describing a key aspect of a
consumer’s health, formed to serve a specific purpose. Two types of lists have been
identified - derived and maintained.
A derived list is a list that can be automatically generated as an EHR view across all
relevant health event summaries and requires no user intervention. Examples of derived
EHR lists are prescribing/dispensing history, procedure/treatment history, and recent
health services.
A maintained list is a list which requires clinical judgement to determine if and when
an entry should be removed from the list. This implies, in most cases, a need for some
review process. Examples of maintained lists are current medications, active
problems/diagnoses, adverse reactions and warnings.
The current medication list is one of the most important aspects of HealthConnect. It is
therefore important that mechanisms are set in place to ensure that this is accurate and
up to date.
Details of prescribed, dispensed and over the counter medications will be sent to
HealthConnect as part of a wide variety of event summaries. HealthConnect will upon
receipt of medication information add the details to relevant derived lists such as
prescribed medications list, dispensed medication list and the maintained list for current
medications. Through this process the current medication list will contain all newly
prescribed and dispensed medications.
The issue arises of how best to delete entries from the list either due to the medications
no longer being current or there being duplicates on the list.
84
HealthConnect
Business Architecture v1.9
The Tasmania HealthConnect trial takes the current medications list from the most
recent general practitioner consultation event summary. Recent phases of the trial allow
other clinicians to add to the current medications list. For ongoing maintenance, the
current medication list contained in the general practitioner’s clinical information
system is incorporated into the consultation event summary. Upon receipt
HealthConnect uses this version to replace older versions. The Brisbane Southside
HealthConnect trial operates in a similar manner except that the consumer’s nominated
general practitioner maintains the current medication list. These solutions are not viable
for the wider implementation of HealthConnect.
For version 1 of HealthConnect it is proposed that HealthConnect provides the
functionality for any clinician (such as general practitioners, specialists, hospital,
community nurse practitioners) to review and amend a view of the current medication
list as part of a health event. The resulting event summary will be structured to include
information to confirm, delete, and/or add medications to the list. Amending rather than
replacing the list will ensure that the integrity of the list is maintained, and that any
linkages to event summaries relating to entries which are still current are retained.
It is recognised that this review activity will need to be conducted consistently and
involves changes to work practices, but that the additional effort is worthwhile due to
the importance of these lists in the consumer’s healthcare activities. A possible
approach might be to integrate the review of these lists into assessment consultations
which are longer than standard consultations and where such matters are commonly
addressed.
It is also recognised that the introduction of a standard medication coding scheme will
be required for this information to effectively support local clinical decision making.
6.4.5
Receiving Notifications
HealthConnect will support simple notifications relating to time, events and data codes,
for example, admission notice, discharge notice, overdue notice. Notifications based
upon interpreting the clinical content of an EHR will not be supported.
Determining which providers will be sent a notification about a consumer will be
managed through the consumer access control parameters, set up as part of the consent
process, which nominate specific provider organisations. It is anticipated that only a
subset of the providers on the consumer’s access control list will be sent notifications.
This will vary depending on the type of notification and consumer preferences, for
example only the consumer’s nominated general practitioner might be sent a
notification of hospital presentation and discharge.
HealthConnect will send all notifications on encountering the appropriate trigger
without reference to any other notification that might have been sent. Any filtering to
avoid double counting would need to be managed by the recipient (eg. a provider or
registry).
6.4.6
Creating the Initial Health Profile
The process of the collection of initial health profile information is initiated at the time a
consumer registers with HealthConnect. This is an important part of establishing the
85
HealthConnect
Business Architecture v1.9
record, particularly for consumers with chronic and complex conditions and where
consumers have important allergies or alerts.
Subsequent to a consumer registering with HealthConnect, a provider may receive a
request from HealthConnect to supply part of the initial health profile for a consumer
they are treating. This might include summary information such as current diagnoses,
allergies and medications.
It is important to note that:
·
establishing an initial health profile is a one off activity conducted around the
time of registration;
·
establishing a consumer’s initial health profile will not always require
involvement from a provider;
·
where provider involvement is required, only one provider on the consumer’s
access control list will receive a request to supply a particular type of
information. HealthConnect will not include the ability to rationalise the data
and resolve duplications and inconsistencies. Multiple sources might be used for
different types of data; and
·
the initial health profile will be extracted from the provider’s CIS, presented for
review and update and sent to HealthConnect as a specific type of event
summary. Clinical validation of the data contained in the profile is particularly
important to ensure that the consumer’s EHR is meaningful and useful. If the
provider is regularly maintaining the type of information required in their CIS
this process will be straightforward.
In summary, the creation of the initial health profile is performed only once, for a subset
of HealthConnect consumers; and for a subset of the consumers the provider is treating;
and will be as automated as possible though clinical validation is required.
6.4.7
First Presentation at Healthcare Setting
When a consumer attends a provider’s premises for the first time, they may be able to
establish their record with the provider practice using their HealthConnect identifier.
This would include:
·
the consumer’s HealthConnect identifier and PIN being entered. If the
consumer has forgotten their HealthConnect identifier, a phone call to the
consumer’s registration agency will be required. Processes for identifying the
consumer including use of secret questions will be established;
·
having established the consumer’s identity, messages can be sent to
HealthConnect to add the provider organisation to the consumer’s access control
list. This is a one off activity and the access authorisation will remain valid until
the consumer changes it; and
·
at this stage HealthConnect may send a predefined view of the consumer’s EHR
containing consumer demographics and a health summary. This can, should the
provider CIS have the capability, be incorporated into the provider’s local record.
86
HealthConnect
Business Architecture v1.9
Hence HealthConnect can bring a direct benefit to providers when establishing records
for new consumers.
6.4.8
Managing Emergency Access
In the case of an emergency presentation where the consumer is unable to give consent
for the provider access, the emergency override feature can be used.
If the consumer has already included the provider organisation on their access control
list, the emergency override is not required and standard provider access will be
possible. This will be the case where the consumer has attended an emergency
department previously and set up access.
If the consumer is able to give consent to the provider, the smartcard and PIN can be
used to set up the access. Once again this is not an emergency override situation, albeit
that the provision of the healthcare services are considered an emergency.
Only in those few cases where the consumer, or their agent, is not able to give consent
and consent has not previously been given will the provider need to use the emergency
override facility. If the HealthConnect consumer identifier is known (eg the consumer’s
card is with them), the provider can enter the HealthConnect identifier and activate the
emergency override to gain access. This type of access will be closely monitored.
As with other non emergency access requirements, where the HealthConnect identifier
is not known, processes will be put in place to ensure that the consumer may be
correctly identified and the HealthConnect identifier and a temporary pass code given.
The processes will include the ability for a provider organisation to phone a consumer
registration agency or the HealthConnect registration service.
6.5 Provider Scenarios
Scenario 1 – HealthConnect – Value Add for the GP
In the five years since 2005 when the initial components of the HealthConnect project
began to be implemented in his area, Dr Andrew Fergus has seen very substantial
change in his work practices, greater use of computers to support his practice of
medicine and increasing confidence in the quality of care he is providing.
Prior to HealthConnect, Dr Fergus was like the vast majority of GP’s in the sense that
he had a computer at the surgery front desk which handled patient registration,
appointments and billing and, while he also had a computer screen in the consulting
room, this was essentially used to print prescriptions and maintain medication histories
on the patients under his care. In 2004 it was Dr Fergus’s view that further use of
computers would slow his practice down, thus reducing his income potential while not
making a positive difference to patient care.
However, with the advent of HealthConnect, the value provided by his computer
systems began to change and the effort involved in recoding patient details and
encounters electronically became more worthwhile.
One of the first benefits Dr Fergus began to greatly value was the access to event
summaries providing a record of his patient’s encounters with specialists. Quick and
87
HealthConnect
Business Architecture v1.9
easy online access to this information has made Dr Fergus’s role as the key co-ordinator
of his patients’ care a great deal easier and more comprehensive.
In parallel with this Dr Fergus has begun using information from HealthConnect and his
own records to create patient summaries for current medications, current diagnoses
allergies etc, especially for his more complex patients. He has found being able to send
these summaries with his referrals to specialists has saved time in referring and usually
improves the quality of the information coming back to him when the patient is seen.
The benefits of having the medication summary maintained in HealthConnect have also
risen as this summary can also be simply added to referral notes and of course
downloaded to his local prescribing system ensuring accurate prescribing as well as
effective local checking of drug interactions and so on. In addition, the medication
summary can be used by the patient’s pharmacist to advise the patient on appropriate
use of medication and the pharmacist can also see the reasons for a patient’s treatment
in context from the patient summary resulting in fewer but more relevant,
communications between the pharmacist and doctor over medication and better
outcomes for the patient. With all this support Dr Fergus is much more confident he is
less likely to make errors and he has no worries that the pharmacist can’t read his
writing on the printed script!
Enriched with information from HealthConnect, as well as being able to link to x-ray
images from the radiologists report, Dr Fergus is finding his local clinical information
system increasingly valuable as a tool in assisting his quality practice. The combination
of information from HealthConnect – specialist reports, pathology results, discharge
summaries, home nursing encounter reports and so on, when combined with the
powerful local decision support capabilities and patient reminder systems in his desktop
computer is just unbeatable and he now really wonders just how he managed to practice
so effectively and safely before HealthConnect became available.
Scenario 2 HealthConnect – Value Add for the Busy Specialist
Dr Ted Aziz really enjoys practice as a specialist anaesthetist in his large regional centre
serving patients from a wide area. The centre is large enough to mean there are 3
colleagues working at the same hospital which ensures a reasonable after hours roster
while at the same time there is a wide variety of acute and elective surgery to ensure he
has an interesting and fulfilling practice.
The one thing Ted (and all the surgeons he works for) find frustrating are patients who
are admitted for routine surgery and, when seen on the evening before the operation, are
clearly not medically optimised to withstand the planned surgery and therefore have to
be deferred or cancelled while their condition is improved and stabilised. This problem
is annoying for all concerned (especially the patient) when they have travelled for many
hours to be admitted and then have to go back home or find accommodation after being
deferred.
Enter HealthConnect and a dramatic improvement becomes possible. All the surgeons
at the regional hospital have agreed that for any significant planned surgery the patient
will be assessed in the first instance by their authorised GP who will send an event
summary regarding the patient’s clinical status (including medications, recent tests etc
as well as a specific pre-anaesthetic questionnaire) to the Hospital pre-admission clinic
via HealthConnect. These records will then be reviewed by one of the specialist
88
HealthConnect
Business Architecture v1.9
anaesthetists and, if necessary, treatment will be altered, referrals instigated and so on
until it is clear the patient is ready to be admitted for their operation.
The outcome of this pre-admission screening has been threefold. Unexpected last
minute cancellations due to pre-existing medical conditions have almost been
eliminated, patients have not had surgery unnecessarily delayed anywhere nearly as
often and the average quality of pre-operative work up has been dramatically enhanced
– due in large part to the improved clinical communication provided by HealthConnect.
Better still, at least one aspect of ‘regional disadvantage’ is overcome as communication
through HealthConnect leads to greater equality in the quality of care for patients in
both large centres and small rural towns.
Other benefits of HealthConnect for rural and regional patients flow directly from the
speed and efficiency of communication of clinical information – so, for example, the
distant local GP is alerted when his patient is discharged after surgery (at which time
they can check the discharge summary on HealthConnect ) so early follow-up is
possible and equally any changes made by the specialists to the patients medications
and other treatments can be seamlessly continued when the patient reaches home.
Scenario 3 – HealthConnect – Value Add for the Ancillary
Health Workers
HealthConnect has made a huge difference to the life of the consulting dietician over the
years since it was made operational. Indeed Jenny Osmond, who is in private dietetic
practice in the inner suburbs of Melbourne, suggests that the impact has been almost as
large as that of the ‘obesity epidemic’ itself.
Jenny says she remembers how things were back in 2003 when her practice was entirely
paper-based and the potential impact of obesity and its health consequences were really
only starting to be picked up by the public at large. Some five years later she finds her
practice better integrated with both the needs of her clients and also the referring doctors
as a result of HealthConnect.
For her clients she now uses a Dietetic Information System (DIS) which permits her to
undertake dietary assessments, set goals and provide the client with individualised
evidence-based advice. Jenny can also use HealthConnect to obtain records of patient
parameters which are important in her management of patients e.g. cholesterol levels,
other blood lipids, calcium and vitamin D levels and so on. Better still, her DIS is able
formulate an event summary for each patient and to send it to HealthConnect for those
who are registered HealthConnect participants, so that she can keep the client’s GP up
to date with both her initial assessment and ongoing progress reports. This service is
much appreciated by the GP and assists Jenny in building her practice. Indeed a
significant number of GPs are now using the closely related eHealth Message Bank to
refer their patients and to arrange appointments electronically with Jenny while the
patient is still in the doctor’s surgery.
A year ago, in 2006, Jenny started her own client web site where registered clients can
track their dietary intake and other relevant parameters like weight and general wellness.
(Of course the web site also provides dietary information and advice for a wide range of
dietary problems along with general recommendations as to how these problems should
be addressed. Jenny hopes that soon such web services will be provided by
HealthConnect to improve the integration and reliability of the patient provided
89
HealthConnect
Business Architecture v1.9
information). This information is then transferred into the DIS and after review a
summary of the client’s progress can be sent as an event summary when the patient is
next seen.
Jenny is now convinced she has, with the help of HealthConnect, reached a near ideal
state in the quality and accessibility of the services she can offer her clients – to say
nothing of the excellent service she offers her medical referrers and the satisfaction she
derives from offering well documented evidence based care.
Scenario 4 – HealthConnect – Value Add for the Community
Health Nurse
Nurse Jane Watson, an experienced community clinician, has seen many changes to the
way healthcare services are delivered to the community in the last few years; one being
the introduction of HealthConnect. These changes began in 2006 when it became
increasingly common for patients who required continuing community health care to be
registered with HealthConnect. This allowed the Community Nursing Service in the
southern suburbs of Adelaide, with the client’s consent, to access their health record
electronically, ensuring continuity and coordination of care across the inter-disciplinary
team and multiple agencies providing services.
These days Nursing Clinical Information Systems (NCIS) are used to provide client
information, decision support and workload scheduling. New referrals (from GP’s,
hospitals, and allied health services) predominately come via the eHealth Message Bank
– though there are still one or two agencies (out of over 300) who have not yet moved
with the times and telephone in with their requests for care.
Each day clients are allocated by the service’s manager via the NCIS to individual
clinicians for visits and care. When Jane arrives at work she logs onto her computer and
reviews the clinical notes of the clients allocated to her. She regularly accesses
HealthConnect to obtain the most recent clinical information and completes the
occasional missing record from paper referrals, sending off a referral to the clerical staff
to follow up these clients for information, consent and possible participation in
HealthConnect. Jane is pleased that the number of clients where this is needed is
dropping to the extent that by the end of 2007 she believes the need for manual entry of
client details, with the risk of error and delay, will have virtually disappeared.
As Jane is an endorsed Nurse Practitioner her clients tend to have more complex care
needs and clinical decision making is needed to maximise their independence and
ability to stay in community based care. Jane decides today because of her clients’
complexity levels that she will take her notebook computer with her rather than
download data to a PDA which some of the other community clinicians prefer to do.
With her notebook computer loaded with the necessary information Jane is able to plan
her workflows taking into account client care needs, client appointment time
preferences and the best route to minimise travel while seeing each patient. At each
client visit she reviews case notes including current medications and pathology results
and using her clinical judgement prescribes medication changes and orders pathology
tests online. Details of these and her clinical notes from the NCIS are uploaded to
HealthConnect as event summaries.
With this done, the client, their GP, other community clinicians, and other members of
the interdisciplinary team (who may have to, for example, treat Jane’s clients when she
90
HealthConnect
Business Architecture v1.9
is on leave) can review each client’s progress, and the client’s healthcare needs can be
integrated providing both more effective and safer care.
As she leaves work for the day Jane reflects just how much better the services and care
she can offer her clients is with continual interaction within the interdisciplinary team,
compared with the days before HealthConnect. With the time saved Jane is able to
comprehensively manage her complex client workload safety and is assisting more
clients to remain in community based care then was ever possible before. In the past a
hurried note or telephone call from a doctor, hospital or allied health professional was
typically the only information source, and contact between clinicians was minimal for
weeks at a time with little information sharing or care coordination except for the odd
rushed telephone call. Often clients ended up in crisis, with urgent calls between
clinicians, invariably resulting in her clients not being able to remain at home and
independent in the community!
91
HealthConnect
7.
Business Architecture v1.9
Secondary Users Participation
The primary focus of HealthConnect is on recording and storing information about
consumer heath care events, with this information being available to healthcare
providers supporting healthcare delivery, greater coordination of care, safer care, and
improved health outcomes for consumers.
Over time, the HealthConnect data repository will become a highly valuable national
information resource supporting important national initiatives and activities including
clinical research, policy making and planning and health outcome evaluation,
collectively referred to as secondary uses.
This section outlines what being involved in HealthConnect will mean for secondary
users such as researchers and planners. It includes:
·
Potential scope of secondary uses;
·
Benefits of participation in HealthConnect;
·
Consent arrangements and responsibilities of secondary users; and
·
Management and control of use of HealthConnect for secondary purposes.
7.1 Scope of Secondary Uses
7.1.1
Secondary Users
In addition to consumers and providers, there will be a range of secondary users of
HealthConnect. Secondary users are expected to include:
·
Researchers seeking information to conduct research needed for improving
health care and its delivery;
·
Planners and Managers (including administrators, strategic planners, policy
makers, funding bodies) seeking information to assist management decision
making; and
·
Evaluators seeking information directly related to monitoring the effectiveness
of HealthConnect.
7.1.2
Areas Secondary Uses will Support
The “secondary use” of a healthcare record has been defined by the Clinical Information
Project as:
“Any legitimate use of a healthcare record other than the purpose of supporting the
direct delivery of healthcare services to the subject of care. Examples of secondary
uses include applying the record for medico-legal, quality management, clinical
research, epidemiology, population health, health administration, financial, educational
or health service planning purposes”.
92
HealthConnect
Business Architecture v1.9
Specific areas for the secondary use of HealthConnect data could include support for:
·
clinical research;
·
analysis leading to improvements in clinical practice and health service delivery,
including development of evidence-based clinical protocols and guidelines,
evaluation of current clinical practice, and analysis of health outcomes.
·
health service delivery quality improvement mechanisms including clinical audit,
continuous quality improvement studies, outcome analysis, benchmarking,
resource utilisation reviews and accreditation;
·
provision of information for health policy development including performance
monitoring, demand for health services, resource allocation and trend analysis;
·
improving consumer safety through healthcare product recalls (as an option of
last resort, that is, where there are no other mechanisms available to identify atrisk consumers other than via HealthConnect);
·
detection of adverse clinical events dispersed in time and space;
·
clinical teaching; and
·
provision of information to national data collections where authorised.
There is also a significant activity relating to the evaluation of HealthConnect. An
ongoing program will be put in place to monitor and evaluate the success of the system
and seek ways to improve the service.
7.1.3
Examples of Secondary Uses
There are a wide range of reasons why secondary users may request access to
HealthConnect. Examples of these include:
Evaluation of HealthConnect
Given the significant investment in the HealthConnect system, there will be a need to
monitor and evaluate the success of the system and seek ways to improve the service.
As a minimum, this will require analysis of usage and outcomes to assess whether the
objectives of HealthConnect are being met.
Using identified unit records to enhance consumer safety
This includes developing reports listing consumers who fulfil certain criteria, for
example, occurrences of:
·
certain procedures being performed (potentially for follow up or infection
control);
·
certain prostheses or medication regimes (for safety recall purposes); or
·
given combination of medications and/or clinical conditions over a particular
period.
93
HealthConnect
Business Architecture v1.9
Reporting based on anonymised unit records
This includes developing reports containing anonymised unit records for review and
analysis such as:
·
occurrences of consumers that received a particular treatment regime
(potentially to evaluate effectiveness of the regime); or
·
clinical audit and benchmarking studies.
Statistical reporting of aggregated HealthConnect data
There is a requirement for HealthConnect information to be used to produce
performance and statistical reports on HealthConnect at regular intervals (monthly,
quarterly, annually) and upon request.
Subject to considerations relating to sample bias and population size, there is also
considerable potential to use HealthConnect for the production of:
·
Indicative health statistics in specific HealthConnect populations; and
·
Casemix analyses.
These types of uses, which are likely to be common, could be largely automated.
7.2 Benefits of Secondary Uses
The ability to use HealthConnect information to support secondary uses is seen as a key
benefit of HealthConnect by consumers, healthcare providers, clinical researchers and
Australian Government, State and Territory health jurisdictions.
A full analysis of the potential HealthConnect benefits is presented in the Benefits
Realisation Approach15.
While it is recognised that the benefits from secondary uses will be limited in the short
term, there is considerable potential as participation rates, volume and type of data
collected increases, to:
15
·
use the information held in HealthConnect to improve the quality, effectiveness
and efficiency of the Australian health care system;
·
establish a detailed picture of Australians’ health profile, leading to advances in
the treatment of illnesses and improvements in the day-to-day and long-term
care of all Australians; and
·
increase the amount of information available for research purposes to enable
Governments to make more informed decisions about health sectors that should
be targeted in the future. With better information, Governments can become
more responsive to the community’s needs.
HealthConnect Benefits Realisation Framework V1.0 October 2004
94
HealthConnect
Business Architecture v1.9
7.3 Consent and Responsibilities
7.3.1
Consent for Secondary Uses
The HealthConnect Principles state that:
·
HealthConnect will support secondary use of HealthConnect EHR information
for improvement of health service delivery and research purposes, in line with
strict privacy and ethical protocols, appropriate legislative requirements and
monitoring of such use.
·
The consumer must have given informed consent before their EHR and other
personal information can be collected, accessed, used or disclosed by
HealthConnect. This will form part of the initial consumer consent process.
Consumers and providers participating in HealthConnect will be informed that
information will only be used for approved secondary uses, and in accordance with best
practice guidelines and privacy protocols developed for HealthConnect, including being
subject to independent scrutiny. The use of identified data (ie personal health
information) will be in accordance with the Privacy Act and National Health and
Medical Research Council (NHMRC) guidelines. The use of de-identified data will
likewise be subject to approved guidelines, drawing on work underway at the national
level to develop best practice in this area.
At registration, consumers and providers will be informed:
·
that their information will be used for approved secondary purposes only, in
accordance with strict privacy protocols and ethics committee scrutiny;
·
about the range of uses to which the health information might be employed; and
·
how they can access information about the HealthConnect approval process for
secondary uses and the arrangements in place to safeguard consumer and
provider privacy.
7.3.2
Responsibilities of Secondary Users
The use of HealthConnect to support secondary uses will require high-levels of
consumer and provider support and confidence that their health information will only be
used in accordance with strict procedures including ethics approval.
HealthConnect participants, researchers, planners and evaluators will have to abide by
the privacy legislation and protocols. The HealthConnect Principles state that:
·
HealthConnect participants will be obliged to abide by privacy legislation and
by specific HealthConnect privacy rules. The National Health Privacy Code
will be used when it has been implemented, until then privacy arrangements will
be tailored to suit each jurisdiction for each implementation, with a view to
progressing towards a single national solution.
As participants of HealthConnect, secondary users’ responsibilities include:
95
HealthConnect
Business Architecture v1.9
·
commitment to using the information only for the purposes stated, including
commitment to take reasonable endeavours to ensure accurate interpretation of
the information provided;
·
participation in line with the HealthConnect confidentiality and privacy
arrangements;
·
commitment to abiding by HealthConnect processes for secondary uses
including rules relating to circulating and publishing information; and
·
provision of a secure environment for storage of HealthConnect supplied
information.
7.4 Governance of Secondary Uses
7.4.1
Governance Structure
The HealthConnect Principles state that:
·
HealthConnect will support secondary use of HealthConnect EHR information
for improvement of health service delivery and research purposes, in line with
strict privacy and ethical protocols, appropriate legislative requirements and
monitoring of such use.
Hence a key role in HealthConnect will be that of managing the process of granting
access to HealthConnect information for agreed purposes in line with national privacy
legislation and the research and ethics best practice guidelines of the NHMRC.
HealthConnect’s governance structures, yet to be finalised, will contain arrangements
for the independent and transparent monitoring of the role of HealthConnect in
authorising and managing access to information for secondary uses.
Types of representation to be included are likely to be:
·
Consumers;
·
Professional bodies representing healthcare providers;
·
Other national agencies involved in the provision and use of national data
collections (to ensure a consistent approach); and
·
National Health and Medical Research Council (NHMRC).
Assistance will be sought from the Australian Health Ethics Committee (AHEC),
established under the NHMRC Act 1992 to advise NHRMC on ethical issues relating to
health and developing guidelines for the conduct of medical research involving humans.
AHEC membership is specified in the Act and draws on experts in philosophy, the
ethics of medical research, public health and social science research, clinical medical
practice and nursing, disability, law, religion and health consumer issues.
96
HealthConnect
7.4.2
Business Architecture v1.9
Secondary Uses Approval Process
The provision of access to data for secondary uses will only be allowed under strict
protocols and subject to ethics committee approval. These will include ensuring
authorisation has been given for the requested use; extracting the information;
performing any aggregation and de-identification activities required.
The specific processes have not yet been defined. It is recognised that these processes
will need to be consistent for all requests for secondary uses with the associated
procedures for approval being dependent on the type of information (and extent to
which it might identify individuals or communities) and sensitivity issues of the
secondary use being proposed. There are also expected to be reasons for secondary uses
not yet envisaged and the process and procedures will need to be enhanced over time to
accommodate these. Hence proposals for secondary use of HealthConnect data should
be assessed against ethical and legal principles, which need to be established, rather
than by specifying categories of permissible use. At a minimum, all such secondary uses
will be subject to ethics committee assessment.
Generation of and use of published aggregated data would not require very tight
controls as long as it has been aggregated according to best practice processes (eg
Australian Bureau of Statistics and AIHW). Management of “small cell” inference is
one issue of particular concern. Ethics approval once given may be valid for ongoing
production and use of regular reports eg disease type by age and sex. For more
sensitive uses, HealthConnect may establish a process which includes:
·
a formal request to HealthConnect ;
·
the provision of evidence of local ethics committee approval (in line with the
user’s clinical, academic or jurisdictional affiliations); and
·
a HealthConnect ethics approval process.
This process is consistent with the approach used to access de-identified data from other
national data collections, such as those held by the Australian Institute of Health and
Welfare (AIHW), preventing any potentially identifiable data being released into the
public domain.
The use of identified data for research purposes will be assessed through a rigorous
approval process, including ethics committee assessment. Such approved purposes will
only be permitted according to strict criteria, and with agreements in place to govern the
handling and security of stored data within an organisation and subsequent publication
of the research findings to protect individual and community privacy.
HealthConnect will not support any secondary uses that involve:
·
identification of individual HealthConnect consumers or providers explicitly
through use of consumer and provider identification details, except in limited,
approved circumstances as determined by the HealthConnect governing body;
·
identification of individual HealthConnect consumers or providers implicitly
through small cell inference, for example, participants from small populations or
local communities; or
·
uses that contravene national legislation or recognised best practice.
97
HealthConnect
7.4.3
Business Architecture v1.9
Information Access Process
In most cases, requests for access to HealthConnect data for approved secondary uses
will result in the provision of an authorised HealthConnect “report” (i.e. an extract of
data) consisting of the required data set.
The report will be issued to the requestor for use exclusively in the way defined by the
approval process.
HealthConnect will not provide the analytical tools required to process the data set,
although HealthConnect will support requestors in the interpretation and use of
HealthConnect data.
As part of the approval, HealthConnect will have the right to scrutinize research prior to
it being published to ensure compliance with the ethics approval guidelines.
7.5 Secondary User Scenario
Scenario – HealthConnect – Value Add for the Population
Dr Debra Fern is a consultant public health advisor to a number of Australian
governments and has been carefully tracking the progress of HealthConnect since state
implementations began in late 2005. She has been delighted with the progress she has
seen in the last three years but is convinced the best is yet to come. She has seen the
secondary uses of HealthConnect data deliver major benefits, especially in the areas of
preventive care, improved patient safety and detection of systemic quality of care
failures.
Most especially Debra remembers the time before HealthConnect and similar systems
were available when medication side effects, which were not picked up in standard
clinical trials, could go unrecognised for years after initial product marketing because of
the gaps in post marketing surveillance. Among the risks for which detection seems to
have been significantly delayed, often with fatal consequences, but which are now know
about are the risk of:
·
Suicide in young patients given some antidepressants to treat their depression;
·
Hyperkalemia and cardiac arrest in spironolactone treatment for some heart
failure patients and;
·
Life threatening muscle problems associated with some of the cholesterol
lowering medicines.
Debra now sees a range of HealthConnect research applications in frequent use
including:
1. A much enhanced post-marketing surveillance program for prescription, over the
counter (OTC) and complementary medicines. Hospital discharge event summaries are
now routinely searched for evidence of admissions related to side effects of drug
therapies and medical practitioner and pharmacist event summaries are screened for
evidence of out-of-hospital adverse events. Even with 20 per cent of the population
registered to use HealthConnect, there is the capacity to detect the rarest of side effects
98
HealthConnect
Business Architecture v1.9
(which may not have been found in clinical trials which typically involve less than a
few thousand patients) quickly and ensure the proper warnings are given to doctors and
the public promptly. Thus, despite the fact that not everyone is signed up for
HealthConnect, this has resulted in a dramatic improvement in the quality of medicine
safety surveillance for everyone. Better than this, in the event of a serious problem
being identified in post marketing surveillance, press coverage and letters to
practitioners can help to promptly alert people to take whatever remedial action is
required for the whole population.
2. With effective coding of procedures and outcomes developed during 2006
HealthConnect has the capacity to very effectively monitor the quality of care delivered
in a range of areas and to use well understood indicators to monitor patient safety in
great detail. What may be monitored can include such parameters as: re-admission rates
for particular diseases, unexpected re-admissions following surgery or medical
treatment, medical device failures, use of crucial recommended treatment for specific
illnesses etc. This allows early and effective responses to ‘health black spots’ and the
difficult to recognise systemic health system failures. The detail of the information now
available to ensure patients receive optimal treatment is genuinely amazing and really
only possible with a national network like HealthConnect.
3. Daily tracking of prescribing patterns nationally now occurs routinely. Not only does
this permit assessment of the various influences on prescribing and drug use patterns
(advertising etc) but it also provides early warning of emerging epidemic diseases
through monitoring of prescriptions for anti-flu or symptom-management medication.
4. Geographically linked prescribing data of the sort now available from HealthConnect
also allows for assessment of regional variations in prescribing and medical device use
to assist in identification of under and over use of expensive resources. HealthConnect
now can also assist in ensuring all cases where a medical device of critical importance
such as a heart valve or implantable defibrillator is used the fact is entered on a registry
so adverse outcomes for those patients can be regularly assessed and the risk of failure
identified and modified / acted upon if necessary.
5. HealthConnect event summaries can be aggregated over time to provide profiles of
usage and resource consumption. These can augment that found in the Medicare
statistics because they cover Medicare and non-Medicare transactions and contain more
clinical information, which can provide a finer-grained view of what is driving resource
use.
6. Linkage of event summaries associated with such diverse matters as cancer diagnosis
and childhood vaccination is assisting to identifying areas of special need, concern or
risk where further investigation and research may be warranted.
7. In special circumstances Debra is pleased to know it is even possible to check
patients who have a diagnosis of potentially lethal clots in their legs to see if they had
the diagnosis at a time when they had recently been overseas. This can be done with
none of the patients being identified in any way – but can permit certainty as to just how
risky flying overseas is and if necessary prompt extra study as to how this potentially
lethal problem can be avoided and if it would be safe and effective to do so.
Debra is very firmly of the view that, with careful planning, HealthConnect can make a
major contribution to the reduction of risks which may not become obvious for months
99
HealthConnect
Business Architecture v1.9
or years without its help, thereby improving the opportunity for earlier, better and more
cost-effective intervention and cures. As well it can act as a very effective monitoring
tool for the quality and patient safety of the whole health system and pin point problems
well before too much harm is done.
100
HealthConnect
Business Architecture v1.9
Part D – Description of HealthConnect Components
101
HealthConnect
Business Architecture v1.9
This part identifies and describes key components of HealthConnect and its surrounding
context with a focus on developing the links between the high-level business
requirements discussed in previous parts and the more detailed descriptions of
components required as part of an enterprise architecture that can support the
development of HealthConnect. This work is informed by the Federal Enterprise
Architecture Framework (FEAF) used in the development of both version 1 of the
HealthConnect Business Architecture and version 0.9 of the HealthConnect Systems
architecture and is intended to provide a foundation for subsequent work on the
HealthConnect data, application and technology architectures.
In this part, various HealthConnect components and their interrelationships are
developed by use of process mapping, which considers the roles, processes, information
and technology needed to support HealthConnect. The following sections discuss each
of the identified components in more detail from the following perspectives:
1.
Section 8 presents the analysis of HealthConnect roles and discusses the entities,
processes, information and technologies used to perform the role.
2.
Section 9 identifies the high-level information components needed to deliver
HealthConnect (informing the HealthConnect data architecture).
3.
Section 10 catalogues and discusses the business processes associated with the
delivery of HealthConnect (forming a basis for the HealthConnect applications
architecture and more detailed functional requirements).
4.
Section 11 presents an overview of the major application systems and
technology components needed to support HealthConnect (providing an input to
the technology architecture).
The functions and characteristics of these HealthConnect components are also
developed in a separate attachment to this business architecture entitled Specification of
HealthConnect Business Requirements.
8.
HealthConnect Context and Roles
Figure 8.1 on the following page presents a role map illustrating the major roles and
functions associated with the delivery of HealthConnect services. The role map
includes both roles performed within HealthConnect itself (indicated by the shaded zone)
and roles performed within associated entities (such as providers and consumers).
Roles associated with the delivery of HealthConnect are grouped as follows:
1.
HealthConnect participants - consumers, providers and secondary users;
2.
Core HealthConnect roles, including those for registration of consumers and
providers, maintaining the HealthConnect EHR repository, managing the
structure and content of EHR information, and for governance of HealthConnect,
which includes regulating interaction with HealthConnect and evaluating
HealthConnect performance;
103
HealthConnect
Business Architecture v1.9
3.
HealthConnect Consumer Access Services (HCCAS) that support customer
interaction with HealthConnect and may also offer additional services of interest
to consumers;
4.
Provider eHealth Access Services (PeHAS) that support providers interacting
with HealthConnect;
5.
eHealth Message Bank Service, an adjunct to the core services, to facilitate
electronic information interchange for HealthConnect and other purposes, such
as electronic retrieval of prescriptions, referrals and notifications;
6.
HealthConnect ICT infrastructure (for HealthConnect and other services), which
includes secure networks, IT processing platforms, clinical applications and the
organisations that support these services;
7.
National health infostructure, which provides national repositories and
information definitions that underpin the operation of HealthConnect; and
8.
Other contributors and recipients of information – specifically value-added
eHealth services and (potentially) health registries.
National Health InfoStructure
National Health
Identifier Service
(Consumers)
Health Information
Standards, Terminologies
and Data Sets
National Health Metadata
Repositories
National Health
Provider
Directory
Secondary
User
HealthConnect Governance
HealthConnect
Metadata
Repository
HealthConnect
EHR Repository
National Data Store
Consumer
Consumer
Registration &
Management
HealthConnect
Consumer
Access
Services
HRS/
AEM
...
HRS/
AEM
Provider
Registration &
Management
Health
Connect
Provider
Directory
HealthConnect Consumer Index
Provider
Provider eHealth
Access
Services
Value Added eHealth Services
Health Registries
eHealth Message Bank Service
Supporting ICT Infrastructure
Processing Platforms
Clinical Information
System Support
Clinical Applications
Secure Communications
Networks
Figure 8.1 – Role Map for Delivery of HealthConnect Services
Each role is discussed in more detail on the following paragraphs with consideration
being given to the entities that might carry out the role, and the processes, functions and
information needed to perform the role.
104
HealthConnect
Business Architecture v1.9
HealthConnect Participants
8.1
Consumers
All Australian citizens and residents of Australia will be eligible to participate in
HealthConnect as consumers. In stage 1 this participation is expected to be limited to
those identified as being eligible to receive Medicare benefits but, in the future, this may
be extended to other persons determined by the HealthConnect governing body.
A consumer’s participation in HealthConnect will be subject to the consumer (or an
appropriate agent) having given consent to participate and having completed the
consumer registration process.
Agents able to register a consumer include parents (for a child), a legal guardian or
person with power of attorney over the consumer’s health care or a person specifically
authorised by the consumer in accordance with HealthConnect rules.
Each consumer’s EHR will be held by an Approved EHR Manager (AEM) on a
HealthConnect Records System (HRS) and consumers will be able to access and
interact with HealthConnect through one or more HealthConnect Consumer Access
Services (HCCAS). The primary processes and functions which HealthConnect
consumers may perform include:
(a)
Registering as a HealthConnect consumer, providing initial registration
details;
(b)
Accessing HealthConnect as a consumer (including maintaining an
access control list, reviewing EHR information and checking access by
others);
(c)
Maintaining consumer registration details;
(d)
Seeking HealthConnect support assistance, where required; and
(e)
Accessing value added eHealth services (where available) through the
consumer’s HealthConnect consumer access service.
Consumer access to HealthConnect will typically be via web browser interface hosted
by the relevant HealthConnect consumer access service and will be protected by a
password/PIN.
8.2
Providers
8.2.1
Types of HealthConnect Provider
Provider participation in HealthConnect occurs at the level of both:
(a)
an individual provider, and
(b)
a provider organisation.
In the medium to longer term, HealthConnect must be able to service a broad range of
individual providers, including:
105
HealthConnect
Business Architecture v1.9
(a)
General practitioners;
(b)
Specialist medical practitioners;
(c)
Diagnostic specialists including pathologists and radiologists;
(d)
Nurse practitioners and community nurses:
(e)
Pharmacists;
(f)
Physiotherapists, chiropractors, podiatrists, optometrists and dentists;
(g)
Other allied health workers delivering individual health care services,
including: occupational therapists, speech therapists; dieticians; social
workers and clinical counsellors;
(h)
Aboriginal and Torres Strait Islander (ATSI) health workers.
Provider organisations may be either publicly or privately funded and include:
(a)
Any of the above individual providers, operating as a sole trader or as a
business enterprise;
(b)
General practices and medical centres;
(c)
General hospitals and specialist hospitals;
(d)
Aboriginal Community Controlled Health Services (ACCHS);
(e)
Residential aged care facilities and nursing homes;
(f)
Community health centres, community care and shared care teams;
(g)
Clinical staff working in call centres providing health advisory services;
and
(h)
Any similar type of service offering health services to consumers as
individuals or as part of identified group of consumers within a health
care program (such as a shared care program).
Where the word "provider" is used without qualification in this part, it should be
interpreted as encompassing both individual providers and provider organisations as
appropriate to the context in which the word is used.
8.2.2
Provider Access to HealthConnect
A provider’s participation in HealthConnect will be subject to the provider having
entered into a legal agreement with the HealthConnect governing body which will set
out the obligations of the provider and provide the basis both for the provider’s use of
HealthConnect and the protection of consumer privacy.
In the case of provider organisations, the agreements will place requirements on the
provider with respect to its employee’s activities and the interoperation of its systems
with HealthConnect and will identify the person responsible for the organisation’s use
of HealthConnect.
106
HealthConnect
Business Architecture v1.9
To facilitate an appropriate level of access control without presuming how provider
organisations may register with HealthConnect, HealthConnect needs to allow major
organisational units (such as a hospital or clinic) to be identified separately within
HealthConnect while still recognising their link to the head provider organisation.
Provider organisations will interact with HealthConnect through one or more provider
eHealth Access Services (PeHASs), which provide communication pathways between
the provider and the HRS/AEM in which a consumer’s EHR is held.
Before permitting a provider organisation to access the consumer’s EHR, providing any
confidential consumer identification details, or allowing any entry to be made in the
EHR, the HRS/AEM must authenticate the initiating provider organisation’s access
credentials against the consumer’s access control list.
Each event summary submitted for inclusion in a consumer’s HealthConnect EHR must
be attributable to a registered individual provider, even though entries will originate
from within a provider organisation.
All persons accessing a HealthConnect EHR on behalf of a provider organisation must
be either a registered individual provider or a person (eg support staff and junior
clinicians) authorised by the provider organisation and uniquely identified to
HealthConnect by the provider organisation.
Provider access to HealthConnect will be accommodated via a combination of access
technologies including HL7 and/or XML-based web service messaging to and from the
provider’s clinical information system and an option of providers using a limited web
browser interface (hosted by the relevant PeHAS).
8.2.3
Provider Processes
Specific processes identified as potentially being performed by providers include:
(a)
Register with HealthConnect as an individual provider and/or a provider
organisation;
(b)
Retrieve/use consumer EHR information;
(c)
Update consumer EHR information;
(d)
Send/Receive eHealth communication;
(e)
Access value-added services; and
(f)
Seek HealthConnect support assistance.
8.3
Secondary Users
Secondary users who access HealthConnect information for legitimate purposes other
than direct care delivery to a consumer and are expected to include:
(a)
researchers, carrying out basic and applied research;
(b)
health managers and planners
107
HealthConnect
Business Architecture v1.9
(c)
HealthConnect evaluators; and
(d)
the HealthConnect management team, for purposes associated with
management and control of HealthConnect itself.
All secondary uses of HealthConnect must be subject to stringent approval including
review and acceptance by an ethics committee and measures that protect the privacy of
individuals and the confidentiality of their personal data. The HealthConnect governing
body sets and enforces the policies and guidelines for secondary uses.
Core HealthConnect Roles
HealthConnect Governance
8.4
Details of the proposed governance structure for HealthConnect are being finalised in
parallel with the documentation of this business architecture and are discussed in further
detail in Part E below. While details are still being resolved, it is widely accepted that
overall management of the HealthConnect program at the national level will be vested
in a dedicated organisational entity on behalf of all the participating governments and
other stakeholders. This organisational entity is commonly referred to as the
HealthConnect governing body.
HealthConnect is also being progressed regionally through HealthConnect trials and
lead-state/territory implementations. Each of these initiatives currently has its own
governance structure, which encompasses many of the same functions at a
local/regional level as are proposed to be carried out by the HealthConnect governing
body at a national level. For the short- to medium-term a significant proportion of
HealthConnect management functions will be performed at a regional level.
8.4.1
HealthConnect Governance - Functions and Processes
The HealthConnect governance role may be encapsulated by three high-level functions:
·
Administration of HealthConnect programs;
·
Management of HealthConnect participation; and
·
Establishment and operation of HealthConnect infrastructure.
Identified processes for administering HealthConnect programs include:
(a)
Establish HealthConnect operational policies and standards
(b)
Establish arrangements for coordinated national delivery of
HealthConnect
(c)
Procure HealthConnect systems and infrastructure
(d)
License HealthConnect consumer access and provider eHealth access
services
(e)
Evaluate HealthConnect outcomes
108
HealthConnect
Business Architecture v1.9
Processes for managing HealthConnect participation include:
(a)
Promote community awareness of HealthConnect
(b)
Engage with stakeholder bodies
(c)
Contract with health providers for use of HealthConnect
(d)
Agree HealthConnect supply terms for consumers
(e)
Manage approval and monitoring of secondary uses
(f)
Administer access to HealthConnect
(g)
Monitor access and audit/report usage
(h)
Handle consumer and provider complaints
(i)
Coordinate HealthConnect records management functions
Processes for establishing and operating HealthConnect infrastructure include:
(a)
Promulgate metadata and standards for HealthConnect
(b)
Maintain National Data Store
(c)
Maintain HealthConnect Metadata Repository
(d)
Maintain HealthConnect Consumer Index
(e)
Maintain HealthConnect Provider Directory
(f)
Manage HealthConnect ICT infrastructure
(g)
Run HealthConnect operations
(h)
Organise clinical systems to inter-operate with HealthConnect
There are many routine HealthConnect operational activities that will be managed
through or on behalf of the HealthConnect governing body, these include:
(a)
Maintaining processes for the creation, update and distribution of
HealthConnect metadata and for managing its application and use in
HRS facilities and in HealthConnect interfaces.
(b)
Operation of the national data store and processing services to support
secondary uses of HealthConnect data.
(c)
Oversight of message handling and transport operations.
(d)
HealthConnect registration operations.
(e)
Performing other management, technical and operational tasks delegated
by the HealthConnect governing body from time to time.
These functions may be undertaken by the HealthConnect governing body itself or,
alternatively, they may be performed by other organisations contracted to perform them
on its behalf.
109
HealthConnect
Business Architecture v1.9
Until the HealthConnect governing body and its operational support arrangements are
fully active, similar operational functions will be needed locally to support initial
HealthConnect implementations. Longer-term integration of these functions into the
national Program will need to be considered by the HealthConnect governing body and
the relevant jurisdictions.
Front-line HealthConnect registration functions may be carried out through various
registration agencies; however, the following types of registration operations may be
best handled through a HealthConnect registration centre operating at a national level:
(a)
Providing a contact point (potentially via a call centre) for consumers
needing to modify their registration details or seeking information about
participation in HealthConnect.
(b)
Providing a contact point (potentially via a call centre) for providers
needing to modify their registration details.
(c)
Supervision of HealthConnect registration systems and processes,
including management of the HealthConnect registration application
system and overseeing the activities of HealthConnect registration
agencies.
(d)
Ensuring the operational integrity of the Consumer Index and Provider
Directory, including handling complex registration issues (such as
resolution of duplicate identities).
8.5
HealthConnect EHR Repository
8.5.1
The Federated Model for HealthConnect Delivery
HealthConnect is to be implemented as a federation of HealthConnect Records Systems
(HRS) supported by common services at a national level, with the entirety of each
consumer’s EHR being stored in only one HRS.
All EHR information submitted to HealthConnect is received by the HRS on which the
consumer’s EHR is held and, if valid, is incorporated into the consumer’s EHR.
Within 24 hours of an EHR being updated (and preferably much earlier), a copy of the
updated EHR material is to be transmitted in a standard format by the responsible
HRS/AEM to the National Data Store for archiving and long-term retention.
Together, the EHR information held in each HRS and the National Data Store comprise
the HealthConnect EHR repository. Whilst the HealthConnect EHR repository is to be
distributed across a number of federated elements, it is intended that it be available as a
single national resource from the viewpoint of access, interoperability, reporting and
inquiry. Within this framework, it is proposed that the National Data Store be used to
support all secondary use of HealthConnect EHR data for research and planning
purposes, while all operational interaction with a consumer’s EHR will occur through
the HRS.
Such a federated approach has the potential to relieve problems of scale and, depending
on the implementation model adopted, may allow for a diversity of technology solutions.
110
HealthConnect
Business Architecture v1.9
It has also been perceived as being more consistent with local strategies and the current
regional nature of healthcare delivery.
For HealthConnect to have seamless capability to accept, store and interchange
standardised EHR information using the federated approach, each HRS must conform to
a common EHR architecture, common interface standards and common specifications.
It is important that each HRS validate, accept and be capable of delivering event
summaries in accordance with national HealthConnect information standards – nonstandard records cannot be used by other HRS nodes, at the national level or by
individual provider systems.
Certainly, in the first few years, as the HealthConnect concept is developed through
separate implementations in several jurisdictions, there will be differences in the role
and function of each HRS. Reconciling these differences with the preferred approaches
set out in this business architecture remains one of the key challenges facing
HealthConnect as a national program and strategies for managing this issue need to be
developed as a high priority.
8.5.2
HealthConnect Records System (HRS)
Version 0.9 of the HealthConnect Systems Architecture proposed that the core element
of HealthConnect be the HealthConnect Records System, or HRS, on which a
consumer’s EHR is stored, with the HRS managing EHR updates and controlling access
to the EHR. While the precise role and functions of an HRS have been refined
considerably since they were documented in the HealthConnect Systems Architecture,
the HRS continues to be the centrepiece of a HealthConnect implementation,
performing the functions of EHR storage, update and access control. It also remains a
core principle of HealthConnect that: “a consumer’s entire HealthConnect EHR should
reside on one and only one HRS”.
Each HRS is based on an HRS Application which is to provide functions in the
following general areas:
8.5.3
(a)
Controlling access to EHR and consumer information;
(b)
Maintaining consumer details and access control lists for those
consumers holding their EHR on the HRS;
(c)
Processing event summary information into a consumer’s EHR
(including maintaining managed lists and views);
(d)
Responding to (authorised) EHR information requests;
(e)
Interaction with the shared HealthConnect consumer index, provider
directory and metadata repository; and
(f)
Keeping audit trails and access logs recording all access, outputs and
changes involving consumer information held in the HRS.
Approved EHR Manager (AEM)
In the federated structure proposed for HealthConnect, service providers referred to as
“Approved EHR Managers” (AEMs) will contract with the HealthConnect governing
body to provide the functions of a HealthConnect data centre or service bureau.
111
HealthConnect
Business Architecture v1.9
Under this version of the HealthConnect business architecture, the role of an AEM in
managing an HRS has been identified as being different from the roles of a
HealthConnect Consumer Access Service (HCCAS) and/or a Provider eHealth Access
Service (PeHAS), although, for some implementations of HealthConnect all three roles
may be performed by the one organisation.
Each AEM will be responsible for the security and access control of EHR information
held in the HRS that they operate. The AEM must protect the confidentiality, integrity
and availability of the EHR, by:
·
providing a physically secure processing environment for the HRS with access
restricted to personnel that have been vetted and are duly authorised;
·
authenticating the identity of all users or organisations that seek access to EHR
information;
·
restricting access to an EHR (including any views and reports derived from the
EHR) in accordance with the consumer’s consent settings and policies defined
by the HealthConnect governing body;
·
managing, maintaining and administering the HRS databases, audit trails and
access logs;
·
ensuring that the access log for each EHR is maintained, complete and
accessible for review over an extended period;
·
ensuring that HRS applications, systems software and hardware are properly
maintained to ensure integrity and performance of the service;
·
protecting the confidentiality and integrity of data communicated over public
networks;
·
providing business continuity and disaster recovery for the EHR Repository
(covering EHR information, access logs and audit trails);
HRS/AEM – Processes
8.5.4
The following high-level processes were identified in the context of performing the role
of an HRS/AEM, include:
(a)
Manage HRS databases and audit trails
(b)
Apply updates to consumer details and access control lists
(c)
Apply consumer preferences
(d)
Control access to EHR information
(e)
Update/maintain HRS Application software
(f)
Maintain compatibility with HealthConnect metadata
(g)
Maintain HRS processing platform and network environment
(h)
Apply and monitor ICT security measures
112
HealthConnect
8.6
Business Architecture v1.9
National Data Store
The National Data Store (NDS) is managed by (or on behalf of) the HealthConnect
governing body to provide a data storage and archiving service that aggregates EHR
information sent from all HealthConnect EHR datasets to support:
(a)
Reporting across the national HealthConnect population for use in
research, planning and management of the HealthConnect program;
(b)
Review, development and management of HealthConnect metadata; and
(c)
Maintenance of archival copies of each EHR to support recovery of
records (if corrupted at an HRS), allow access for secondary use without
impacting operational performance, and support ad-hoc access for
specific enquiries.
An access log is also to be maintained of all access to the National Data Store.
Where access to an HRS (such as a query) results in new artefacts being added to an
EHR, those artefacts will form part of the updated EHR material that the HRS supplies
to the National Data Store.
HealthConnect Metadata Repository
8.7
The role of the HealthConnect Metadata Repository is to maintain a long-term versioncontrolled collection of metadata implemented within HealthConnect and provide a
single reference point that can be accessed by everyone needing authoritative metadata
for:
(a)
interfacing with HealthConnect and supplying information for
incorporation into the HealthConnect EHR repository;
(b)
validating the structure and content of EHR information submitted as
event summaries;
(c)
interpretation, linkage and storage of EHR information;
(d)
accessing information held in the HealthConnect EHR repository;
(e)
production of meaningful views and lists spanning information submitted
over time; and
(f)
interpreting HealthConnect EHR information in other applications, such
as clinical decision support systems.
The HealthConnect metadata repository will be centrally maintained by (or under the
authority of) the HealthConnect governing body and each HRS/AEM will derive the
structure, content and validation rules for event summaries, lists and views from locally
applied versions of this metadata.
The metadata will also form the authoritative source of information for the design of
interfaces to HealthConnect.
113
HealthConnect
Business Architecture v1.9
Maintenance of the HealthConnect metadata repository will be carried out in close
cooperation with the Clinical Information Project, which will provide formalised
metadata definitions for incorporation into the repository. There will also be close
liaison with the AIHW, to ensure that HealthConnect definitions and structures comply
as closely as possible with the definitions in the National Health Data Dictionary
(NHDD) and are compatible with METeOR (the proposed new national health metadata
repository).
Maintaining the HealthConnect Metadata Repository is identified as one of the highlevel business processes required as part of the establishment and operation of the
HealthConnect infrastructure – currently being performed by the HealthConnect
Program Office in collaboration with the Clinical Information Project (CIP) but
ultimately to be done under the auspices of the HealthConnect governing body.
8.8
Consumer Registration and Management
Consumer registration and management is an important aspect of HealthConnect and
has, justifiably, received a great deal of attention since the concept of a national system
of electronic health records was first proposed in the National EHR Taskforce (NEHRT)
report.
At the national level, the HealthConnect governing body has responsibility for
establishing and enforcing appropriate policies and procedures for managing the
relationship between participating consumers and various elements of the overall
HealthConnect solution. This includes rules for consumer registration, notification of
consent and for deregistration from HealthConnect.
The HealthConnect governing body also has responsibility for national awareness and
marketing of the HealthConnect program to consumers, providers and the community at
large.
A consumer must be uniquely identified and registered in order to participate in
HealthConnect. The avoidance of duplicate identities requires that, in most cases, the
consumer will need to identify themselves personally to an authorised HealthConnect
consumer registration agency. While some registration management functions can be
performed online by electronic means, many, including initial registration for some
consumers, will require face-to-face contact, at considerable cost to both the consumer
and HealthConnect. To achieve high participation rates, HealthConnect Consumer
registration and management functions need to be efficient and available in
communities across Australia, close to the consumers themselves.
Efficiencies in HealthConnect registration are anticipated through the implementation of
a national health identifier, possibly coupled with the introduction of individual
Medicare smartcards. The new smartcards will be issued to most Australians over the
next few years as a replacement for their current magnetic stripe Medicare cards.
Holders of the new smartcards will have a unique secure identity for accessing a wide
range of health care benefits, including a separate identifier for registering with, and
accessing, HealthConnect. Consumers that obtain the new smartcards will have already
identified themselves to the Health Insurance Commission (HIC) through Medicare.
114
HealthConnect
Business Architecture v1.9
It is not currently proposed that the HealthConnect governing body establish its own
Australia-wide physical presence to perform consumer registration and management
functions, but rather, that it will:
(a)
Allow consumers holding the new Medicare smartcard to register online
by using the smartcard and other information (eg. a PIN) to identify
themselves; and
(b)
Appoint one or more HealthConnect consumer registration agents to
provide face-to-face registration services.
Although Medicare outlets are ideally placed to provide HealthConnect registration
services; this would be subject to resolution of jurisdictional issues and an agreement
between HIC and the HealthConnect governing body. Subject to them having access to
appropriate facilities (including the ability to access the registration application), there is
no reason for other organisations not to be licensed to perform the HealthConnect
consumer registration role – candidates include HealthConnect consumer access
services, registration agencies established to support a state or regional HealthConnect
initiatives, and organisations having a close relationship with various large groups of
health consumers.
The consumer registration and management role must be supported by a group of
business processes to establish and maintain consumer registration, including:
(a)
Market HealthConnect to consumers
(b)
Register consumer with HealthConnect
(c)
Update/recover consumer registration details
(d)
Process consumer deregistration from HealthConnect
(e)
Manage tracking of consumer surrogates
The process of registering a consumer with HealthConnect includes:
(a)
the allocation and activation of unique HealthConnect consumer
identifier linked to the National Health Identifier (should it proceed);
(b)
capturing the consumer’s details and the provider organisations to be
included on their access control list;
(c)
setting up the consumer with a record on an HRS/AEM;
(d)
providing or capturing a security code for accessing/authorising
HealthConnect information;
(e)
entering the consumer’s identifier and personal details into the
HealthConnect Consumer Index; and
(f)
arranging for information to be collected (eg. from the consumer and any
treating practitioners) for the consumer’s initial health profile and
loading it into the consumer’s EHR.
115
HealthConnect
Business Architecture v1.9
The processes involved in establishing and maintaining consumer registrations and
associated consumer details need to be supported by a single HealthConnect registration
application available to all licensed HealthConnect consumer registration agencies.
Local requirements may accommodate different registration processes, where required
to meet particular local needs eg different registration processes for ATSI people.
Once a consumer is registered with HealthConnect, their registration details can be
maintained by online access, in person at any HealthConnect consumer registration
agency or by telephone to a HCCAS or to the central HealthConnect registration centre.
In all cases, the consumer must provide one of the forms of identification normally
required for access to HealthConnect.
Where a consumer has lost or mislaid their HealthConnect identification details or
password/PIN, they would either visit a HealthConnect consumer registration agency in
person or, alternatively, contact the HealthConnect registration centre so that the access
could be reset, using other identifying information held in the HealthConnect
registration system.
8.9
HealthConnect Consumer Index
As a consumer is registered with HealthConnect, their HealthConnect identifier, their
personal details, and a link to the HRS on which their EHR is held, are set up in the
HealthConnect Consumer Index. The index will also hold a reference to their entry in
the National Health Identifier system (should it proceed).
The primary role of the HealthConnect Consumer Index is to provide the linkage
information needed by HealthConnect message handling and transport applications to
identify the appropriate HRS on which a registered consumer’s EHR is stored. In this
way, a communication pathway can be established between an authorised provider
(operating via a PeHAS) and the HRS so that the provider may retrieve and contribute
to the consumer’s EHR information. Similarly, the Consumer Index provides flexibility
for consumers to access their EHR via HealthConnect portals not directly associated
with the HRS on which their EHR is stored.
The master copy of the HealthConnect consumer index is to be maintained by (or on
behalf of) the HealthConnect governing body as a national HealthConnect resource and
this copy alone will hold information needed to re-establish the consumer’s
HealthConnect identity should this be lost. Some information from the Consumer Index
is expected to be replicated to access services to facilitate faster processing.
The main function of the HealthConnect Consumer Index is to direct HealthConnect
transactions to the HRS on which the consumer’s EHR and other information is held –
not to validate a person’s right to access the consumer’s EHR information. Once a
HealthConnect transaction arrives at the relevant HRS, the HRS is responsible for
controlling access, using the access control list supplied by the consumer.
The Consumer Index will hold sufficient information in secure form to enable a frontend application or HRS to confirm that the HealthConnect identifier matches the
consumer’s password/PIN, thereby permitting the consumer to use their password/PIN
to authenticate HealthConnect transactions online.
116
HealthConnect
Business Architecture v1.9
HealthConnect Consumer Access Services
8.10
The primary role of HealthConnect Consumer Access Services (HCCAS) is to provide
consumers with an effective means of accessing HealthConnect services and to give
them front line support for using HealthConnect. Processes identified as being
potentially associated with the HealthConnect Consumer Access Service role include:
(a)
Provide HealthConnect consumer access portal service (for consumers
accessing HealthConnect via a web browser and via consumer health
information systems)
(b)
Provide advice, assistance and training to consumers using or starting to
use HealthConnect
(c)
Provide consumer hotline support to resolve HealthConnect access and
usage problems
(d)
Assist with marketing HealthConnect to consumers
(e)
Facilitate consumer registration
(f)
Provide consumer access to value added services, potentially including
supply of HealthConnect-compliant consumer health information
systems
(g)
Monitor and report service delivery performance indicators
Depending on decisions taken by the HealthConnect governing body, this business
architecture does not restrict the organisations that can perform an HCCAS role.
Potentially, consumers could obtain HealthConnect Consumer Access Services via a
number of different approaches, including:
·
Directly via a national HealthConnect web portal organised directly by the
HealthConnect governing body (for simple consumer access);
·
Via an organisation operating as a HealthConnect registration agency;
·
Via organisations offering value-added services to consumers, including health
information service providers, health insurers, and associations providing
targeted services to specific groups of health consumers (such as shared care
programs); and
·
From a service originally established to support a regional implementation of
HealthConnect.
Those operating an HCCAS would have access to the Consumer Index and the
HealthConnect message handling and transport applications. It is most important that
HCCAS operators support standard HealthConnect interface protocols for accessing
HRS and national HealthConnect services. To ensure that confidentiality of consumer
personal information and the security of the HealthConnect ICT infrastructure is
preserved, all HCCAS operators must be licensed by the HealthConnect governing body.
As part of their being licensed, they must agree with reasonable conditions relating to
compliance with HealthConnect policies, maintaining confidentiality and security of
117
HealthConnect
Business Architecture v1.9
HealthConnect information, support of HealthConnect, technical protocols and
standards and their relationships with consumers on behalf of HealthConnect.
8.11
Provider Registration and Management
At the national level, the HealthConnect governing body has responsibility for
establishing and enforcing appropriate policies and procedures for managing the
relationship with participating providers, including rules for provider registration and
for deregistration of providers from HealthConnect. The HealthConnect governing
body also has responsibility for national awareness of HealthConnect and for marketing
the program to providers (as well as to consumers and to the community at large).
A provider’s registration with HealthConnect will be subject to the provider having
entered into a legal agreement with the HealthConnect governing body which will set
out the obligations of the provider and set out the basis both for the provider’s use of
HealthConnect and the protection of consumer privacy.
The roles of a provider organisation and as an individual provider are different, in
particular:
·
Access to HealthConnect for retrieval and/or update of EHR information is only
granted to registered provider organisations (even though, in many cases, this
will be a one-person practice or business entity employing one or two staff).
·
Each entry submitted by a provider organisation for inclusion in a consumer’s
HealthConnect EHR must be attributable to an individual provider registered
with HealthConnect.
HealthConnect will provide a simple, integrated registration process for small practices.
It is required that each person accessing HealthConnect EHR information be uniquely
identifiable. Support staff and junior clinicians who are not registered as individual
providers may be authorised by a provider organisation, providing that the provider
organisation uniquely identifies them and gives undertakings relating to their use of
HealthConnect information. Provider organisations will need to agree to retaining a
record of the identification of authorised staff.
There are plans at the national level for providers to be registered in a single national
provider directory/index. Efficiencies could be achieved if the HealthConnect provider
registration could be facilitated by this directory. In the short- to medium-term and
depending on the scope of the national provider directory, HealthConnect will need to
maintain its own information on providers, to track their HealthConnect status and to
efficiently manage their HealthConnect access privileges.
Where a provider is entered on the proposed national provider directory, their national
health provider identifier will be used to uniquely identify them to HealthConnect.
Given the existing relationship between many healthcare providers and the Health
Insurance Commission (HIC) through Medicare and with the States/Territories through
licensing and professional registration, it is anticipated that processes for recruitment,
118
HealthConnect
Business Architecture v1.9
identification and registration of providers will involve liaison with both HIC and
State/Territory health authorities.
It is proposed that the HealthConnect governing body establish a single integrated
process for provider registration, but may appoint HIC and/or a small number of other
provider registration agents (eg. state professional registration boards) to run the process
on its behalf. To implement this approach, all provider registration agents would
require access to appropriate facilities (including the ability to access the registration
application).
Although HIC is well placed to provide HealthConnect provider registration services;
this would be subject to resolution of jurisdictional issues and an agreement between
HIC and the HealthConnect governing body.
The provider registration and management role must be supported by business processes
to establish and maintain provider registration, including:
(a)
Market HealthConnect to providers
(b)
Register individual provider with HealthConnect
(c)
Register provider organisation with HealthConnect
(d)
Maintain provider registration details
(e)
Process deregistration of individual provider from HealthConnect
(f)
Process deregistration of provider organisation from HealthConnect
The process of registering an individual provider or provider organisation with
HealthConnect includes:
(a)
confirming (where relevant) an individual provider’s existing Medicare
provider number, a provider organisation’s practice identifier and all
providers’ National Provider Directory entries (if and when available);
(b)
capturing the provider’s details – contact details (including email
address), additional security information to facilitate access, and profile
for electronic exchange of information;
(c)
obtaining the provider’s consent for any publication of directory
information to facilitate contact;
(d)
for a provider organisation, agreement to additional terms relating to
access and use of HealthConnect information; ABN; responsible practice
manager;
(e)
providing or capturing a security code for accessing/authorising
HealthConnect information; and
(f)
entering the provider’s identifier, details and eHealth contact addresses
into the HealthConnect Provider Directory.
In addition to registered authorised providers, a provider organisation may authorise
other staff to access HealthConnect on its behalf. The information that a provider
119
HealthConnect
Business Architecture v1.9
organisation should retain in relation to those staff which are authorised to access
HealthConnect should include:
(a)
the training program and agreements under which a staff member is
authorised to access HealthConnect (which comply with any
HealthConnect rules in this regard);
(b)
the individual identifier by which the person will be uniquely identified
when accessing HealthConnect information;
(c)
the person's full name, title/role, and contact details within the
organisation; and
(d)
the date of authorisation and the officer who approved the authorisation.
The processes involved in establishing and maintaining registration of provider
organisations and individual providers need to be supported by the HealthConnect
registration application system. This application should be accessible by the
HealthConnect registration centre and all HealthConnect provider registration agencies.
Once a provider is registered with HealthConnect, their registration details can be
maintained by online access, by personal contact with a HealthConnect provider
registration agency or by telephone to the national HealthConnect registration centre. In
all cases, the provider must provide one of the forms of identification normally required
for access to HealthConnect.
Where a provider has lost or mislaid their HealthConnect identification details or
password/PIN, they would contact the HealthConnect registration centre so that the
access could be reset, using other identifying information held in the HealthConnect
registration system.
Because access control is tied to provider organisation and some larger private and
public health services have complex structures that change from time to time, the
facility must exist within HealthConnect to have some provider organisations (eg
individual hospitals) also being part of a larger provider organisation (eg a regional
hospital group) to several levels of nesting. Administrative processes and systems
functions will also be required to re-establish the status of organisational units and their
responsibilities when provider organisations merge, split or change hands.
8.12
Provider eHealth Access Services
The primary role of Provider eHealth Access Services (PeHAS) is to give providers
effective means of accessing HealthConnect services and any front line support needed
to help them in using HealthConnect. Processes identified as being potentially
associated with delivery of eHealth access services include:
(a)
Provide HealthConnect access portal and message handling service (for
providers accessing HealthConnect via both clinical information systems
and web browsers);
(b)
Provide advice, assistance and training to HealthConnect providers using
or starting to use HealthConnect;
120
HealthConnect
Business Architecture v1.9
(c)
Provide eHealth telephone and web-based support service to resolve
HealthConnect access and usage problems;
(d)
Provide access to eHealth message bank service and facilities that
support secure transmission of eHealth messages (including prescriptions,
referrals and notifications) between providers;
(e)
Provide access to value-added services, potentially including supply of
health information and clinical decision support services, HealthConnectcompliant clinical information systems, and associated consulting and
advisory services;
(f)
Assisting to market HealthConnect to providers and facilitate provider
registration;
(g)
Monitoring and reporting performance indicators on services delivered to
providers; and
(h)
Assisting to market HealthConnect to providers and facilitating provider
registration.
Depending on decisions taken by the HealthConnect governing body, this business
architecture does not restrict the organisations that can perform an PeHAS role;
however, providers will be encouraged to access HealthConnect and submit event
summaries through clinical information systems, interchanging information with
HealthConnect via web-based access portals running the HealthConnect message
handling applications, which are expected to including some portals operated and
supported by independent organisations performing the PeHAS role.
A HealthConnect web portal running a simple provider front-end application, will be
available for web-browser access by providers and for simple administrative functions,
such as updating registration details.
Organisations possibly able to offer PeHAS capabilities include:
·
Organisations offering value-added services to providers, including vendors of
health information services, clinical information systems and secure
communications services;
·
State/Territory health departments, private hospital groups, or the larger nursing
services who have the capability to offer this service to themselves, their own
employees and associated private practitioners;
·
Peak bodies representing large groups of providers;
·
Organisations already providing electronic business services to large groups of
health providers (eg. billing or supply services); and
·
Any service used to support a regional implementation of HealthConnect.
Those operating a PeHAS facility would have access to the Consumer Index, the full
Provider Directory, and the HealthConnect message handling and transport applications.
It is most important that PeHAS facilities support standard HealthConnect interface
protocols for accessing HRS and national HealthConnect services. To ensure that
confidentiality of consumer personal information and the security of the HealthConnect
121
HealthConnect
Business Architecture v1.9
ICT infrastructure are preserved, all PeHAS operators must be licensed by the
HealthConnect governing body. As part of their being licensed, they must agree with
reasonable conditions relating to compliance with HealthConnect policies, maintaining
confidentiality and security of HealthConnect information, support of HealthConnect,
technical protocols and standards and their relationships with providers on behalf of
HealthConnect.
8.13
eHealth Message Bank Service
The eHealth message bank service is an adjunct to the HealthConnect message handling
and transport application. It provides facilities needed to receive, hold and forward
eHealth messages being transmitted between participating providers for purposes such
as electronic prescriptions, electronic referrals, and electronic notifications and,
potentially, a range of other health-to-health and business-to-business transactions.
The eHealth Message Bank Service role is to be developed in conjunctions with
HealthConnect, and is needed to provide essential HealthConnect functions so it may
have the full range of required functionality. In particular, there is a requirement for
HealthConnect to be able to accept, hold and forward prescriptions in electronic form in
order to incorporate functionality previously provided by the MediConnect system.
If this functionality is provided purely within HealthConnect (and it could be) it would
only be available for handling communication relating to consumers and providers
participating in HealthConnect. Whereas the requirement for eHealth communication
between providers is much wider and applies, whether a particular message contains
information about a consumer participating in HealthConnect or not. This business
architecture has therefore proposed that the eHealth Message Bank Service be specified
as a separate component, to be developed in conjunction with HealthConnect.
It is too early in the development of the eHealth messaging concept to define the
organisation or organisations likely to provide the service or the supporting technologies.
However, various proprietary services supporting various forms of health-to-health
messaging need to be taken into account by developers of HealthConnect as they
progress the development of the eHealth message bank concept.
8.14
Value Added eHealth Services
Value Added eHealth Services encompass any service or function (including supply of
an application system or product) that complements the use of HealthConnect and gives
consumers, individual providers or provider organisations added value from
participating in HealthConnect. Potential examples of value added eHealth services
include:
(a)
Access to health information repositories and online knowledge bases
containing reference information;
(b)
New online clinical decision support tools and applications that might
emerge (with a capacity to use EHR information, such as that held in
HealthConnect);
122
HealthConnect
Business Architecture v1.9
(c)
Consumer health information systems - allowing a consumer to monitor
their general health and progress in managing specific conditions
(particularly if the system can produce or use EHR information);
(d)
Health maintenance programs involving periodic personal recording of
progress in maintaining or improving healthcare parameters;
(e)
Clinical Information Systems and applications specifically configured to
make use of HealthConnect EHR information; and
(f)
Access to health transaction processing services - for handling provider
billing or booking transactions.
Adherence to mainstream international and global standards for the representation of
EHR information is one of the key enablers for expanding the availability and use of
value added eHealth services in conjunction with HealthConnect.
8.15
National Health InfoStructure
National health infostructure work is being progressed to service a number of national
priorities, including HealthConnect, but is not part of the HealthConnect program. The
following areas of this work are of particular relevance to HealthConnect:
(a)
A proposed national health identifier
(b)
National health metadata repositories
(c)
National health data sets
(d)
Health information standards, terminologies and data sets
(e)
A proposed national provider directory
8.15.1
National Health Identifier
Proposals for the introduction of a National Health Identifier (NHI) are currently being
prepared for presentation to Australian health ministers and it is expected that over the
coming years, consumers will be issued with a national health identifier that will
uniquely identify them for several healthcare initiatives, including HealthConnect.
The national consumer identification service is expected to include a client (consumer)
master index linked to the consumer-held smartcard, which is available to replace the
current Medicare magnetic stripe card.
If approved by the ministers, and with appropriate regulatory backing, this initiative has
the potential to impact on HealthConnect in the following ways:
(a)
It provides a unique identifier, usable for health applications, which can
be checked to avoid duplicate registration of individual consumers within
HealthConnect;
(b)
It provides a unique identification token, in the form of the smartcard, on
which the healthcare identifier can be stored and which can be used by
123
HealthConnect
Business Architecture v1.9
the consumer to identify themself and to facilitate the access to their
HealthConnect information.
(c)
If developed in consultation with HealthConnect, the indexes supporting
the National Health Identifier may be able to replace the HealthConnect
consumer index.
The entities that might provide such a service, or indeed the nature of the service itself,
are matters to be determined as part of a major review to be completed by the end of
2004.
8.15.2
National Health Provider Directory
Further investigation of a National Health Provider Directory (NHPD) is one of the
high-priority initiatives currently being progressed for presentation to Australian health
ministers and it is expected that it will provide the basis for providers being uniquely
identified for several healthcare initiatives, including HealthConnect.
If approved by the ministers, and with appropriate regulatory backing, this initiative has
the potential to impact on HealthConnect in the following ways:
(a)
It provides a unique identifier, usable for health applications, which can
be checked to avoid duplicate registration of individual providers within
HealthConnect; (and depending on the scope of the NHPD may also
avoid duplication of identifiers for provider organisations).
(b)
If developed in consultation with HealthConnect, indexes supporting the
National Health Provider Directory may be able to replace the
HealthConnect provider directory.
How such a national service might be provided, and whether it is worthwhile, are
matters to be determined as part of a major review to be completed by early 2005.
8.15.3
National Health Metadata Repositories
To achieve its objectives, HealthConnect needs to collect and produce information in
the most meaningful way, without imposing overheads on those who must supply the
information. Given that HealthConnect is a recipient of EHR data from a wide range of
sources, it is important that it is supported by national standards.
For a long time, many organisations have been defining how health information is to be
collected for use in health applications. These organisations include: the Australian
Institute of Health and Welfare (AIHW), the Australian and state departments of health,
specialised registries for clinical research and planning (such as cancer registries) and,
more recently, the Clinical Information Project.
In May 2004, the National Health Information Management and Information and
Communications Technology Strategy prepared by Boston Consulting Group for the
National Health Information Group (NHIG) and Australian Health Information Council
(AHIC) identified over 70 groups developing health information standards and
requirements across the entire spectrum of national, state, government, not-for-profit
and private-sector areas.
124
HealthConnect
Business Architecture v1.9
Well formed metadata supports the effective use of information by ensuring that it is
properly defined by reference to an appropriate ontology and terminologies, structured
by reference to information models (compiled with input from the subject domain) and
is expressed in a format and using values that can be readily interpreted.
It will be one of the tasks of the HealthConnect governing body to identify and
promulgate the metadata that is to be used in collecting, processing and retrieving
information for HealthConnect – and, more specifically, HealthConnect EHR
information. Wherever possible, metadata selected for use with HealthConnect should
conform to appropriate international, global and national standards to minimise the cost
and maximise the potential for clinical systems to interoperate with HealthConnect.
As an extension its ongoing role in maintaining the National Health Data Dictionary
(NHDD), AIHW have released a specification for a new automated National Health
Metadata Repository (to be called METeOR) supported by contemporary information
management tools. The NHDD is also being extended to include an increasing array of
clinical data items, which will be added to METeOR as they are developed.
In consultation with stakeholders, the Clinical Information Project is developing the
information models and defining the information structure and content of event
summaries, lists and views to provide HealthConnect with well-formed metadata. This
work is proceeding in collaboration with AIHW, the National InfoStructure
Development Section and the HealthConnect Program Office and, as the outputs are
endorsed by relevant authorities (currently the National Data Standards Committee –
NDSC - on behalf of the Australian Health Ministers’ Council), it is proposed they
become available as electronically interpretable XML specifications on METeOR.
While all these developments are expected to influence HealthConnect strongly,
HealthConnect will also need to accept a range of material in a recognised form not
necessarily conforming to approved metadata registered in the national health metadata
repository. HealthConnect also has a responsibility to ensure the long-term retention
and availability of any metadata used to define EHR information stored in the
HealthConnect EHR repository. In these key respects, the requirements of
HealthConnect metadata repository may diverge from those of the national health
metadata repository. Nevertheless, HealthConnect should ensure that the techniques it
uses for metadata representation are harmonised with those used by the CIP and the
National health metadata repository to allow speedy comparisons, automated processing
and information sharing.
As HealthConnect is developed, consideration also should be given to whether
METeOR (or a derivative subsystem) can become the HealthConnect Metadata
Repository.
8.15.4
Health Information Standards, Terminologies and Data
Sets
Without agreement on appropriate standards for representation and use of information,
effective interchange and interpretation of information is not possible. It is therefore
important that the development of HealthConnect be strongly guided by the substantial
work currently being undertaken to identify and establish Health Information Standards,
125
HealthConnect
Business Architecture v1.9
Terminologies and Data Sets. The specific factors bearing on HealthConnect in this
regard include:
(a)
The national health standards agenda – establishing standards for the
representation and interchange of EHR information;
(b)
Adoption and implementation of a standard terminology (or combination
of terminologies ) for representation and coding of clinical concepts so
that they can be unambiguously interpreted by automated clinical
systems (including HealthConnect); and
(c)
Programs to establish and maintain key national data sets of clinically
relevant information that will support accurate representation of clinical
information and enhance the potential for interoperability.
HealthConnect will follow and adopt the results of these national health infostructure
programs and also make substantial contributions to their development, so as to ensure
that they are informed by and can support HealthConnect’s own requirements.
Specific initiatives of particular relevance to HealthConnect include:
·
Development of the Australian Catalogue of Medicines (ACoM) and a standard
terminology for medications and medical devices;
·
Development of standard notifications for allergies and alerts and adverse
reactions;
·
Australian input to CEN and HL7 standards development programs aimed at
harmonisations of international standards for representation of EHR information;
and
·
Formalisation of Australian Standards for implementation of HL7 messages,
discharge summary and referrals.
Where code sets are used to represent information submitted in event summaries, it is
important that the update of these code sets be controlled with each new release being
retained for the long term, so as to enable HealthConnect EHR information to be
interpreted long into the future.
8.16
Supporting ICT Infrastructure
Being engaged in the collaborative electronic sharing of information across the
Australian health community, HealthConnect will interact with ICT infrastructure
supplied, owned, operated and supported by a wide variety of organisations.
Key ICT infrastructure elements identified as being required for the success of
HealthConnect (in addition to the core HealthConnect applications) include:
(a)
Secure Communications Networks – maintaining a high level of open
access, good response times, and effective security protection for
messages flowing across interconnected networks supplied by different
providers represents a significant challenge.
126
HealthConnect
Business Architecture v1.9
(b)
Clinical Applications – end-user applications are typically supplied by
independent vendors selling to groups of providers - these must be
maintained to comply with HealthConnect interface standards to
effectively interchange EHR information with HealthConnect.
(c)
Processing Platforms - the very scale of HealthConnect represents a
significant challenge to its ability to acquire, configure and manage
underlying processing technologies for the long term.
(d)
Clinical Information System Support – the cooperation of suppliers of
networking, applications and technology services, which is essential to
achieving the other elements of the required ICT infrastructure.
The success of HealthConnect will therefore not only depend on those elements which
are under the direct influence of the HealthConnect governing body, but also on its
ability to manage its interoperation with other systems and organisations.
The technology components supporting core HealthConnect activities are discussed
further in section 11 of this business architecture.
127
HealthConnect
9.
Business Architecture v1.9
Information Components
9.1 Introduction
This section identifies, classifies and discusses the information objects that are involved
in the future delivery of HealthConnect and considers the relationship of these objects to
each other. This task has been approached with a degree of formality with a view to
informing the subsequent development of the HealthConnect Data Architecture.
The following are the information objects discussed in this section:
·
HealthConnect EHR Repository:
-
HealthConnect Electronic Health Record (EHR)
-
HealthConnect National Data Store
·
HealthConnect Event Summary
·
EHR Views
·
EHR Lists
·
EHR Query/Response
·
HealthConnect Notifications
·
Consumer Details
·
Access Control List
·
EHR Access Logs and Audit Trails
·
HealthConnect Reports
·
HealthConnect Consumers and Providers
-
HealthConnect Consumer Index
-
HealthConnect Provider Directory
·
HealthConnect Metadata
·
HealthConnect Registration Objects
·
National Information Repositories
·
eHealth Communications Messages
Note
Descriptions of each of the above components and associated requirements are being
developed as part of this business architecture in conjunction with the preparation of a
detailed statement of business functional requirements. This section 9 will be
progressively updated to reflect the results of this work as it becomes available.
128
HealthConnect
Business Architecture v1.9
9.2 HealthConnect EHR Repository
HealthConnect is designed to be capable of operation as a federated system in which the
entire EHR for each consumer is held on one of a number of HealthConnect records
systems (HRS), but is accessible by any health provider participating in HealthConnect
anywhere in Australia. Each HRS also provides EHR extracts to the HealthConnect
national data store (NDS) to allow reporting on a national basis. The HealthConnect
EHR repository is therefore the sum total of the EHR information held in:
·
All Electronic Health Records held in HealthConnect records systems; and
·
The HealthConnect national data store.
The information content of these objects and the associated processing is discussed
below.
9.3 HealthConnect Electronic Health Record (EHR)
The following definition of the term EHR (Electronic Health Record) is commonly used
within HealthConnect and is taken from The National Electronic Health Records
Taskforce report:
“An electronic, longitudinal collection of personal health information, usually
based on the individual, entered or accepted by health care providers, which can
be distributed over a number of sites or aggregated at a particular source. The
information is organised primarily to support continuing, efficient and quality
health care. The record is under the control of the consumer and is stored and
transmitted securely.”
In HealthConnect, each EHR is a longitudinal collection of health information relating
to a single consumer that is stored within the HealthConnect system itself. The logical
contents of a HealthConnect EHR include:
·
Consumer identifier;
·
Consumer data – key demographic data about the consumer, including date of
birth, sex, contact details, next of kin etc;
·
Access Control List, which identifies the providers which the consumer has
allowed to access the EHR – associated with this is the option for authorised
providers to request notification when specific types of event summary arrive for
processing into the EHR;
·
A long-term collection of all Event Summaries incorporated into the EHR, each
containing information received from points of care (eg. a GP surgery or
hospital), typically providing salient information about one or more care event;
·
EHR Views –commonly referenced, clinically meaningful aggregations of EHR
information drawn from one or more event summaries (eg. the “critical view”
which shows problems, alerts and medications, care plan summary, or a
microbiology sensitivity report);
·
EHR Lists –commonly referenced sets of similar clinically meaningful data
items selected from the EHR, e.g. “active problems”, “current medications”,
“therapeutic precautions”, “cumulative laboratory report”; and
129
HealthConnect
·
Business Architecture v1.9
EHR Version Log, Access Log and Audit Trail, which are logically part of each
consumer EHR but may be implemented as part of a different physical database
to the EHR itself.
The structure and content of EHR components are to be formally expressed and
maintained in HealthConnect metadata. An appropriate and consistent range of
messages will also need to be defined for submission of event summaries (and other
information such as consumer details) to HealthConnect Records System (HRS) nodes
and for EHR query/response sequences to retrieve EHR information from them.
9.4 The CEN EHR Reference Information Model
Following considerable international collaboration to secure convergence between those
working on the European CEN standards and those working on US-based HL7 EHR
standards, there is now substantial agreement as to what constitutes the reference model
for an “EHR Extract” (or portion of an EHR that may be communicated between EHR
systems). Figure 9.1 illustrates the broad structure of this converging EHR reference
model.
EHR Extract
-Versioning
-Consumer Demographics
-Access Control List
1
1
Core EHR Extract
Objects
*
*
1
1
1
Composition
*
Composition
(Event Summary)
*
Folder
EHR Compositions
(Event Summaries) may be
constrained at each of these
levels by using
Archetypes (CEN)
or
Templates (HL7)
───────────
Folder
1
*
Section
*
*
Entry
*
1
Cluster
1
1
Element
Optional
EHR Organiser
Objects
*
1
Cluster
Entry
*
*
Element
1
*
1
1..*
1
Section
Data Value
Fig. 9.1. Simplified CEN EN 13606-1 Reference Model
When applying this model, the “Composition” level is used for each discrete event
summary submitted to HealthConnect (eg. a discharge summary). The observations (e.g.
vital signs, a blood pressure measurement, APGAR score or pathology test result) are
130
HealthConnect
Business Architecture v1.9
incorporated into the Event Summary as “Entries”. A composition may comprise a
number of entries.
It is a business requirement that HealthConnect have the capacity to accept, store and
recognise EHR information which has been structured according to this model –
including any more complex EHR event summaries which use the “optional” organiser
levels (which may also be nested) and any of the many Data Value constructs.
While localised EHR implementations are working towards support of a more restricted
model (eg. for HealthConnect trials or EHR feeder applications), HealthConnect itself,
as a national EHR system must support the converging EHR reference model fully.
The object models used to fully describe the CEN 13606 and HL7 CDA reference
models are quite complex and undergoing change as convergence progresses. At this
time, the most developed, tested and definitive version of the converging EHR reference
model is Part 1 of the draft CEN EN13606 EHR messaging standard. This Part is
expected to be published as a full European standard by early 2005 and has been
translated into a draft DMIM for use in the HL7 v3 messaging and CDA environment.
Part 1 of the CEN EN13606 EHR messaging standard has therefore been selected as a
starting point for defining the content of event summaries, recognising that
HealthConnect must consider extensions and potential simplifications when using the
model to structure the HealthConnect EHR and its components.
This should not be misinterpreted as a requirement that all data submitted to
HealthConnect must originally be structured according to this model, but all event
summaries specifically developed for acceptance of structured information into
HealthConnect will be developed by constraining this model.
9.5 HealthConnect National Data Store
The HealthConnect National Data Store will hold archival copies of HealthConnect
EHR information in a format complying with standard HealthConnect metadata to
facilitate searching and the production of reports.
Information held in the National Data Store will replicate information contained in, and
received from, each HRS/AEM as EHR extracts - rather than being a reconstruction of
the EHR from basic transactions.
The HealthConnect data architecture and on-going metadata definitions will need to
define the specific content of EHR material being supplied to the NDS and allow for
both complete copies of each new version of an EHR and incremental updates of
specific material (planned for later versions of HealthConnect). For this update process
to succeed, all HRS implementations will need to be able to produce replicated EHR
material in accordance with the appropriate HealthConnect standards, even if they
themselves do not use these standards internally.
EHR material provided by an HRS for incorporation into the National Data Store
conforms to the CEN EN 13606 notion of an EHR Extract and, therefore, this standard
is probably the most appropriate to apply to the transfer of this material.
131
HealthConnect
Business Architecture v1.9
9.6 HealthConnect Event Summary
The HealthConnect EHR will be largely made up of event summaries, which are central
to the concept of HealthConnect. An event summary has been defined in the following
terms:
“Health information about one or more healthcare event(s), that is relevant to the
ongoing care of a consumer/patient. The collection of health event summaries
relating to a consumer/patient will constitute their (HealthConnect) shared EHR.
Health event summaries define inputs to HealthConnect”.16
The intention is that an event summary should present a provider’s summary of key
details relevant to the ongoing care of the consumer and would normally be produced at
or near the end of a clinical encounter and at an appropriate level of detail to inform
other providers involved in the current episode of care. Nevertheless, all separately
attributed information headed for storage in the consumer’s HealthConnect EHR must
be presented as an “event summary” and HealthConnect will need to be able to handle a
wide range of inputs from a very simple observation through to complex clinical reports
all within the paradigm of an event summary.
For each event summary supplied to HealthConnect, the following information
components are required:
·
The identity of the consumer (via the HealthConnect identifier);
·
The identity of the individual provider to whom the event summary is attributed
(in line with the identification requirements of the National Provider Directory);
·
The identity of the provider organisation (in line with provider organisation’s
registration details);
·
Other event summary header information, including the type of event summary,
the date and time of the consultation and the date and time of submission to
HealthConnect; and
·
The data elements or sections that make up the event summary in line with CIP
event summary definitions.
The Clinical Information Project (CIP) has been given the responsibility for researching,
designing and recommending the information content and structure of HealthConnect
event summaries. As a result of CIP Phase 1 and 2 work, prototypes of the following
priority event summaries have been designed to capture information expected to be
commonly exchanged in HealthConnect settings:
16
·
Initial Health Profile (which captures a person's EHR information on initial
enrolment with an EHR system and may need to be compiled from several
sources);
·
GP Consultation;
·
Hospital Discharge Summary;
·
Diagnostic Imaging (report); and
Clinical Information Project, Phase 1 Overview Report, March 2004
132
HealthConnect
·
Business Architecture v1.9
Pathology Test (report).
Work on stage 1 has indicated that they will require a range of other event summaries
not yet on the CIP work program, these include specific event summary formats for
events arising in the following areas:
·
Pharmacy;
·
Clinical specialties; and
·
ATSI health.
All HealthConnect implementations must support event summaries as they are
developed and adopted by the HealthConnect governing body.
The structure and content of each event summary is to be formally expressed and
maintained in HealthConnect metadata. An appropriate and consistent range of
messages will also need to be defined for submission of event summaries.
Clinical Observations
Within an event summary, each separate clinical observation (or set of observations) is
represented as a “component” (usually at the level of an “Entry”), whose purpose,
structure and content may be defined as HealthConnect metadata (such as by an
archetype constraint on the Entry, Compound and/or Data Value classes of the
EN 13606-1 reference information model). An overriding objective in constructing
metadata for HealthConnect components (and archetypes in general) is to ensure that
any clinical observation or concept is consistently represented using the same metadata
in different types of event summaries so that HealthConnect can identify and relate the
same types of information when found in different contexts.
For example, considering the five prototype event summaries designed by CIP, a
pathology test result may occur in an initial health profile, GP consultation, hospital
discharge summary or (clearly) a pathology report – it is important that this result be
characterised in the same way in each of these contexts to enable proper management
and comparability of information. Other re-usable (or “spanning” components include
medication prescriptions and dispensing; vital signs; care plans and health outcomes).
Those working on archetypes have had a long-standing interest in the efficient
specification and grouping of reusable EHR components, but a similar concept has also
been more recently progressed through work in the HL7 community on “clinical
statements”.
The following specific EHR data elements were characterised by the CIP as part of its
design of the five prototype HealthConnect event summaries.
• Advance Directive
• Adverse Reactions
• Alert/Warning
• Diagnostic Imaging
• Family Clinical History
• Functional Status, Social
Circumstances
• Immunisation
• Lifestyle, Risk Factor
• Medication
• Problem / Diagnosis
Presenting Complaint
Reason for Encounter
• Procedure/ Treatment
History
• Referral/ Care Team
133
HealthConnect
• Discharge Summary
Business Architecture v1.9
• Pathology
The CIP is currently identifying further high-priority event summaries required for
HealthConnect through consultations with HealthConnect trials, lead implementations
and professional bodies. These priority event summaries will make up the CIP work for
2004 / 2005. Thereafter, the CIP will develop further event summaries and associated
data elements in line with national priorities, including the priority requirements of
HealthConnect.
Structured and unstructured information in event summaries
The extent to which HealthConnect should require the content of all event summaries to
be structured is a topic that has been thoroughly examined through extensive
consultation with stakeholders throughout this update of the HealthConnect business
architecture.
On one hand, there are strong arguments (backed up by cost-benefits identified in
formal evaluation studies) that EHR systems only achieve significant improvements in
health outcomes, where strongly structured data is used to enable applications such as
clinical decision support. On the other hand, many feeder systems are not currently in a
position to collect and deliver any significant amount of well-structured information to
HealthConnect for quite some time. It has also been found that clinicians are more
willing to participate, if there is an option of starting with relatively simple information,
including free text entries. Based on these considerations, the following principles have
been adopted:
1.
HealthConnect should strongly encourage the submission of EHR information in
a structured form that allows interpretation by automated systems.
2.
HealthConnect event summaries should be progressively designed to encompass
all common clinical statements in structured form.
3.
Event summaries capable of being used with minimally structured content (eg.
free text) or content expressed in a structure alien to HealthConnect must also be
available but should not be used where a more structured event summary is
available.
4.
HealthConnect should require all medication lists, alerts and diagnoses/problems
to be submitted in a structured form.
5.
The level of structure in event summaries should be increased as terminologies,
code sets and archetypes are developed for use with HealthConnect.
Consumer-supplied HealthConnect event summaries
Supporting consumer access and the ability of consumers to contribute to their own
HealthConnect records has long been an important goal of HealthConnect. However,
while stage 1 of HealthConnect will support consumer access, consumers will not
initially be able to supply consumer event summaries for incorporation into the
HealthConnect EHR until the associated medico-legal issues have been resolved.
Nevertheless, stage 1 is required to be designed with capability for consumers to supply
consumer event summaries for inclusion in their HealthConnect EHR.
134
HealthConnect
Business Architecture v1.9
9.7 EHR Views
From the viewpoint of the HealthConnect system, all information retrieved from the
event summaries in a consumer’s EHR (other than for secondary uses) will be delivered
as an EHR view, which may be defined as:
“A pre-defined set of data items selected from the EHR, processed and returned in
response to an EHR request”.17
The term “EHR view” can also be applied to the visual presentation of material received
from HealthConnect in response to a user request. However, this presentation will
normally be determined by the functionality and configuration of the application system
used by each user, rather than by HealthConnect itself. Nevertheless, HealthConnect
must anticipate and include functions that support the users’ interactions with EHR
views delivered from HealthConnect.
All EHR views will be defined by, and structured in accordance with, HealthConnect
metadata.
When a user issues a request for EHR information relating to a consumer (by means of
an EHR query), the relevant HRS application will process the request and will return a
response in the form of an EHR view containing the required information. For the
present, HealthConnect will only support the retrieval of pre-defined (but parameterised)
EHR views to ensure systems responsiveness and retain greater control over the clinical
integrity of the responses provided. This contrasts with the approach whereby
HealthConnect would offer users the ability to retrieve EHR information via more
generalised ad-hoc query language. From a practical perspective in implementing
HealthConnect, the CIP has identified the following advantages of pre-specifying
standard EHR views:
·
It allows for prioritising the data sets that need to be specified;
·
Agreement can be reached on what data should be supplied, and therefore which
health event summaries are needed to supply the information; and
·
Vendors of existing systems can be given a smaller set of specifications to
incorporate into their systems.
On the basis of CIP consultations to date, two priority views have been identified:
·
The Primary (or ‘Critical’) View; and
·
The Health Profile View.
The Primary View is the first view delivered when a provider gains access to a
consumer’s EHR. The information contained within the view is that considered to be the
most critical and will contain links to EHR lists and other EHR views. In due course, a
number of different primary views may evolve to serve the needs of different provider
groups (eg. dispensing pharmacists, GPs, specialists, community nurses, emergency
departments).
17
Clinical Information Project. Phase 2 Report: Part A – Clinical Information Framework, v1.0, s7.1.
135
HealthConnect
Business Architecture v1.9
The Health Profile View displays the information provided from the Initial Health
Profile Event Summary (used to initialise HealthConnect), which is updated via
subsequent health event summaries.
Much of the information within EHR views will be maintained within the EHR in the
form of EHR lists (see below).
From a technical viewpoint, the retrieval of subsidiary information that is identified but
not presented in an initial EHR view (eg. subsidiary information obtained from drilling
down into the EHR or by following links in EHR lists) also needs to be defined as an
EHR request, followed by provision of an EHR view. A large amount of
HealthConnect metadata will be needed to define the EHR queries and matching EHR
views for retrieving these lower-level EHR components.
Deciding what information ought to be presented in any particular EHR view is based
on the needs identified by consumers and providers obtained through CIP consultation.
The challenge will be to make the EHR views appropriate to the user – for example a
specialist might be interested in complex disease management views, while consumer
views will need to be more user-friendly.
The priority EHR views will also need to maintain the integrity of the information by
ensuring that important components of an EHR are always included so that information
cannot be misinterpreted by being seen out of context.
9.8 EHR Lists
An EHR list is a collection of similar EHR items describing a key aspect of a
consumer’s health, formed to serve a specific purpose.17 An EHR List is a special form
of the more general EHR View and carries with it some notion of persistence,
completeness, currency, maintenance and/or order.
All EHR lists will be defined by, and structured in accordance with, HealthConnect
metadata.
The CIP has identified two types of EHR lists: derived lists and maintained lists, which
have the following characteristics.
Derived EHR Lists
Derived lists are those that can be automatically generated by querying all relevant
event summaries. For efficiency reasons, it might be preferable for HealthConnect to
build derived lists as the event summaries are entered, rather than to query a substantial
amount of data to build the list dynamically at the time that it is requested. A derived
list is the EHR view that results by running a predefined query against a consumer’s
EHR information in accordance with parameters supplied as part of the query.
Typically such lists will be constrained by some time window, (e.g. prescribing history
or recent events) but may also be constrained in other ways (such as by test type for a
pathology result list).
136
HealthConnect
Business Architecture v1.9
Work by the CIP included the following as potential derived EHR lists:
·
Prescribing and dispensing history (a generated list of prescriptions and
associated dispensing events);
·
Procedure/treatment History (a generated list of treatments or procedures); and
·
Recent Health Events (a generated list from recent event summaries).
Maintained EHR Lists
A “maintained list” is an EHR list maintained by a process of review and update by
providers having knowledge of the consumer’s condition and treatment (see section
6.3.4). Even though the maintenance of such lists might be assisted by a high degree of
automation, the ultimate decision on their content requires an element of clinical
judgement or contemporary information, which is not readily available to automated
processes operating within an HRS application. Typically, the maintenance of such a
list might involve clinical judgement as to:
·
Whether an entry in the list is valid (e.g. "Is depression still an active problem
for this patient?")
·
Whether an entry is still significant, or whether it can be removed in order to
increase the relevance and reduce the size of the list (e.g. is a 10-year old X-ray
to determine fracture of the femur of a patient aged 12 still a “significant
investigation”?); or
·
In some cases, whether a new item of information is sufficiently significant to be
added to the list. (eg. whether an acquisition of OTC Panadol to treat the
symptoms of a minor headache needs to be added as “current medication”).
Based on the above definitions, the CIP has identified the following as being maintained
EHR lists:
• Current Medications
• Active Problems/Diagnoses
• Adverse reactions
• Warnings
• Recent and/or Significant Tests and
Investigations
• Immunisations
• Inactive Significant Problems/Diagnoses.
It is an important characteristic that, when a maintained EHR list is updated, the updated
version is the one used to produce any subsequent EHR view that contains the list. In
this respect, the maintained EHR list differs from an event summary, each one of which
persists in its own right as part of the current EHR.
It should also be noted that a maintained EHR list may be retrieved and viewed by a
user without it being updated.
9.9 EHR Query/Response
Providers and consumers will access HealthConnect EHR information through
applications that will interact with HealthConnect, by sending EHR queries to
137
HealthConnect
Business Architecture v1.9
HealthConnect and receiving the HealthConnect responses in the form of EHR views
(which include information provided as EHR lists).
All such applications, whether they be a provider’s clinical information system or a
web-based front-end application running in a HealthConnect access portal will use
standards-based query/response messaging to interact with the HRS node on which the
consumer's EHR is held.
It is anticipated that many broad classes of EHR query (and associated EHR views in
response) will be required to support interaction between normal users and
HealthConnect. These include:
(a)
Initial EHR query to establish a user’s access to an EHR. If the user is
authorised to access the consumer record, the initial EHR query should result in
the allocation of an end-to-end HealthConnect session identifier. The provider
nominated primary/critical view will be delivered to the user, from which the
user may drill down to more detailed information in that consumer’s EHR.
(b)
An EHR query to enable retrieval of the EHR views predefined to support
particular clinical functions.
(c)
Parameterised EHR queries to support selection and retrieval of each type of
EHR component, including each type of event summary (by time/data, type or
both) and each type of entry-level and event-level component (in context).
(d)
Parameterised EHR queries to support selection, retrieval and
aggregation/summarisation of information contained in EHR lists.
(e)
An EHR query that will enable information specified via secure links in a
previous EHR view to be efficiently retrieved from the HRS.
(f)
A category of EHR queries which retrieve trend data and measures (averages,
maxima, minima, totals, counts etc) drawn from relatively small amounts of data
from potentially large numbers of event summaries, entries and/or elements
within an EHR.
(g)
A category of EHR queries (and potentially query/update transactions) that
operate on information held in a consumer’s EHR other than that held in event
summaries – such as consumer details, access log or audit trail.
The structure and content of each EHR query and responses is to be formally expressed
and maintained in HealthConnect metadata. An appropriate and consistent range of
messages will also need to be defined for communication of both queries and responses.
The HL7 v2.x request for patient clinical information (event I05 RQC/RCI) and
request/receipt of clinical data listing (event I06 RQC/RCL) and/or v3 Find Act
Reference Registry Entry Messages provide possible messaging frameworks for this
purpose.
138
HealthConnect
Business Architecture v1.9
9.10 HealthConnect Notifications
The CIP defines notifications as:
“a type of message or ‘flag’ sent between applications, users or systems to
communicate about important occurrences – usually specified in terms of a
condition or set of conditions that when satisfied, triggers a pre-defined
response.”
Two types of notifications have been identified for stage 1 of HealthConnect:
·
Provider Notifications regarding key consumer healthcare events including
hospital admissions and discharges and emergency department presentations.
These HealthConnect notifications are generated at the HRS when triggers
maintained in the notification list within the consumer’s EHR are activated by an
incoming event summary. Each provider with access to the EHR may set
notification triggers, which will remain active for so long as the provider
continues to have access (or until the provider de-activates them). When the
consumer removes a provider’s access to the EHR, the triggers are retained
(along with the provider details) but are de-activated. If the provider’s access is
restored, the notification list is also restored.
·
Electronic lodgement of registry notifications. As a by product of processing
certain specific types of event summary, official registries and data repositories
such as births, deaths and notifiable disease registers may be approved to receive
notifications from HealthConnect. The business rules for generating these
registry notifications will primarily support statutory notifications and will be
applied outside the context of an individual consumer EHR.
The information content of a notification may include:
a) the consumer’s HealthConnect identifier;
b) the consumer’s name, date of birth and sex;
c) the recipient’s HealthConnect identifier or other addressing details known to
HealthConnect; and
d) the type and details of the notification (for example, admission details, discharge
details, emergency presentation details or birth notifications).
9.11 Consumer Details
Once a consumer has been registered and their EHR has been allocated to an HRS, the
consumer will be able to maintain many of their own consumer details by accessing the
EHR or by asking an approved provider to make the changes on their behalf.
The consumer details accessible as part of the consumer’s EHR are those which would
be required in establishing practice records or for admission to a healthcare institution,
including (to the extent provided by/for the consumer):
(a)
current HealthConnect name;
139
HealthConnect
Business Architecture v1.9
(b)
date of birth (fixed from registration);
(c)
sex (fixed from registration);
(d)
current address and contact details;
(e)
demographic information - ethnicity, language, religion, place of birth, ATSI
status etc;
(f)
Medicare number;
(g)
National Health Identifier (fixed from registration)
(h)
next of kin with contact details;
(i)
previous address and contact details;
(j)
previous name(s) and aliases;
(k)
details of any consumer agent(s) (for example, parents, guardian, powers of
attorney or informal carer); and
(l)
a list of other healthcare services and identifiers (eg private health insurer, state
UPI number).
In addition to being held in the EHR, a copy of this information, along with security
information needed to re-establish lost identity is also to be maintained in a secure zone
within the consumer’s entry in the HealthConnect consumer index, and maintained by
the HealthConnect registration application.
Consumers and providers have access to, and may update, the consumer details in the
EHR but it is not intended that individual consumers or providers have access to the
HealthConnect registration application, which will only be available to the
HealthConnect registration centre and to licensed HealthConnect consumer registration
agencies.
Because some (but not all) consumer details will be accessible via the EHR and, also,
held in the consumer index, the maintenance of consumer details will need to be
carefully synchronised between HRS nodes and the registration system. This will
include:
(a)
The registration application both loading initial consumer details to the restricted
zone of the consumer index and passing them to the HRS when the consumer
first registers with HealthConnect;
(b)
The registration application providing updated consumer details to both the
consumer index and to the HRS when the consumer updates their details through
a HealthConnect consumer registration agency; and
(c)
A means for consumer details in the registration application and the EHR to be
updated simultaneously, when changes are made online by the consumer (or an
authorised provider with access to the EHR).
Some key identification details are normally fixed at registration and may not be
changed by the consumer (or their agent) or by a provider other than by the consumer
making special application to the HealthConnect registration centre; these include date
140
HealthConnect
Business Architecture v1.9
of birth, sex, and national health identifier and the security information the consumer
provides to assist in re-establishing their access in the event that they lose their
HealthConnect security code.
9.12 Access Control List
A key aspect of the consent process is the identification of provider organisations
authorised to access the consumer’s HealthConnect record. It is expected that these
provider organisations would generally be those routinely or potentially involved in the
consumer’s care.
The consumer access control list identifies the provider organisations that the consumer
has authorised to access their EHR from time to time. The information to be retained in
the consumer access control list includes:
(a)
the identities and HealthConnect identifiers of those provider organisations to
which the consumer grants access; and
(b)
the person and means by which each grant and removal of access was made and
the date/time at which each such event occurred.
Whenever a provider organisation is displayed to the consumer or to HealthConnect
agencies, the name, role and contact details of the provider organisation should also be
provided.
By changing entries in their access control list, consumers will be able to change their
HealthConnect access control arrangements in line with their changing healthcare needs;
for example, changing the general practitioner practice or adding specialist groups to
their list.
When the consumer removes a provider’s access to the EHR, the provider’s details and
any notification list are retained but access is suspended. Providing consumers can
identify themselves to HealthConnect, they may grant, review or reinstate a provider’s
access at any time by using online access facilities, or through a HealthConnect
consumer registration agency or at a HealthConnect provider’s premises. If they have
lost their identification, they may obtain access by obtaining a temporary access code by
identifying themselves to the HealthConnect registration centre.
9.13 EHR Access Logs and Audit Trails
Access logs detail individual access to EHR records (including emergency override
access) by providers, consumers, HealthConnect registration agencies and
HealthConnect system administration functions.
The EHR access log is to be available to the consumer for review at any time and is to
be automatically updated by the HRS application whenever the EHR is accessed.
Information to be recorded on the EHR access log and audit trail includes:
(a)
a unique sequence number for all transactions (including accesses);
(b)
the date and time of transaction/access;
141
HealthConnect
Business Architecture v1.9
(c)
a unique identifier for the person (and the identity of any individual provider)
and, where relevant, the provider organisation from which the access was
performed;
(d)
for EHR inputs:
(e)
(1)
identification of the type of information inserted into the EHR including
the type and version of any event summary;
(2)
the complete event summary transaction (including header information)
for each and every event summary received by the HRS; and
(3)
the event summary status indicator for each event summary, indicating
whether the event summary is a new event summary or a replacement
event summary; and
for EHR outputs (including notifications):
(1)
identification of the type of information retrieved from the EHR
including the type and version of any query, view or trigger event and
any query parameters; and
(2)
the complete output transaction (for example, the view, the list, the
HealthConnect notification or the individual event summary);
All changes to the consumer’s EHR data must be versioned and retained on the audit
trail in such a way that previous versions of EHR information can be accessed.
9.14 HealthConnect Reports
HealthConnect reports provide a view of EHR information aggregated across a
collection of EHRs within the HealthConnect EHR repository. Reports will also be
available to extract detailed information and metadata from individual EHR records to
assist in analysing problems in the processing of HealthConnect EHR data.
The principal function of the HealthConnect report will be to support secondary uses
including various forms of approved research, and the management and technical
development of HealthConnect. It is proposed that population-based reporting and
aggregated reports across large numbers of consumers’ EHR take place using the
HealthConnect national data store, rather than the EHR information held at operational
HRS nodes.
A formal query language informed by HealthConnect metadata will be needed to allow
reports to be generated in response to report requests and this will need to be supported
by tools that provide the means of parsing HealthConnect report queries and of,
extracting, analysing, processing and compiling report information.
HealthConnect reporting might also include:
·
Providing search-engine functionality to retrieve filtered lists of EHR entries,
selected on a combination of metadata and content and processed to provide
consolidated information derived from the records identified; and
·
Any query on populations of patients, including queries addressing either
clinical (e.g. find all patients having a correlation between several characteristics)
142
HealthConnect
Business Architecture v1.9
or administrative (find patients who have not received a certain recall for a given
time) parameters.
Access to these functions will be restricted with the HealthConnect governing body
managing access and the processing of report queries (see Section 7.4.3).
9.15 HealthConnect Consumers and Providers
Information on the principal participants involved in HealthConnect transactions –
consumers and providers - is maintained by the registration application on:
·
The HealthConnect Consumer Index;
·
The HealthConnect Provider Directory.
The information content of these objects and the associated processing is discussed
below.
9.15.1
HealthConnect Consumer Index
The HealthConnect consumer registration application sets up consumer index entries
from information provided when the consumer registers with HealthConnect. Selected
parts of the consumer’s personal information may subsequently be maintained by the
consumer via online interaction with HealthConnect itself or a HealthConnect consumer
registration agency.
The main function of the HealthConnect Consumer Index is to direct HealthConnect
transactions to the HRS on which the consumer’s EHR and other information is held.
Once a transaction arrives at the relevant HRS, the HRS has responsible for controlling
access, using the access control list supplied by the consumer.
The information components associated with the HealthConnect Consumer Index
include:
·
a unique HealthConnect consumer identifier;
·
the HRS on which the consumer’s EHR information is being held;
·
consumer PIN and/or password details in a secure form,
And the following information in a more restricted, secure environment, not generally
accessible to front-end applications or users:
·
potentially, the proposed national health identifier as unique identification;
·
consumer personal details including name, date-of-birth, sex, address, telephone
and other contact details;
·
other information needed by an authorised helpdesk operator to help re-establish
the consumer’s identity and access privileges, if the consumer loses their
HealthConnect identifier or their password/PIN.
143
HealthConnect
Business Architecture v1.9
The Consumer Index will hold sufficient information in secure form to enable a frontend application or HRS to confirm that the HealthConnect identifier matches the
consumer’s password/PIN.
The Consumer’s HealthConnect identifier, secure access key, summary identification
information and linkage information will be available for replication so that relevant
index entries may be held locally for faster access by those organisations licensed by the
HealthConnect governing body to deliver HealthConnect access services.
9.15.2
HealthConnect Provider Directory
The HealthConnect provider registration application sets up provider directory entries
from information supplied when an individual provider or provider organisation
registers with HealthConnect. Selected parts of the provider’s details may subsequently
be maintained via online interaction with HealthConnect itself or via a provider service
line at the HealthConnect registration centre.
The information components of a provider directory for HealthConnect are likely to
include:
·
unique identifiers for individual providers and provider organisations - linked to
the provider’s existing Medicare provider number (where relevant), and/or
National Provider Directory entry (if and when available) ;
·
the type of provider organisations (for example, individual practitioner, GP
practice, public or private hospital, community pharmacy, aged-care facility);
·
an individual provider’s full name, title, role and clinical speciality (for example,
General Practitioner, specialist, other medical practitioner, pharmacist,
podiatrist);
·
the provider’s professional registration number(s) and professional registration
body (or bodies);
·
records of agreement to additional terms relating to access and use of
HealthConnect information; ABN; responsible practice manager;
·
additional security information to facilitate access;
·
the provider’s primary contact details, including address, phone, email, eHealth
communications details and HeSA key; and
·
for provider organisations, the nominated contact person (for example, hospital
administrator, GP practice manager or specialist’s receptionist) for receipt of
HealthConnect related information.
9.16
HealthConnect Metadata
All information used in HealthConnect, such as event summaries, views and lists must
be defined in the form of metadata, which is to be retained indefinitely in the
HealthConnect metadata repository. This metadata must be sufficiently extensible and
144
HealthConnect
Business Architecture v1.9
flexible to accommodate changes in clinical practices and yet also needs to be available
in many years time for reviewing and using contemporary information.
HealthConnect metadata defines both the syntax and semantics of event summaries,
EHR views, EHR lists and EHR queries by specifying some or all of: the structure,
optionality, rules, conditions, bindings/relationships and value ranges applicable to these
EHR components.
These metadata resources are the key to HRS applications being interoperable with
source systems and each other, as well as being adaptable and therefore economic in the
long term. It can reasonably be expected that such metadata will need to accommodate
emerging terminologies, vocabularies, templates and archetypes.
HealthConnect metadata must therefore be extensible – that is, it must allow data
definitions to change over time, without invalidating information already collected.
Once developed, metadata can be rendered in different forms for distribution and
application. The exact form of HealthConnect metadata has yet to be finalised but the
use of archetypes to constrain an information model based on the CEN EN 13606-1
reference information model is considered the most likely approach. Metadata that CIP
will deliver as specifications of event summaries, EHR views and EHR lists is proposed
to comprise:
·
a standardised written specification based on ISO/IEC 11179;
·
a metadata definitions for registration and dissemination by the HealthConnect
governing body (using a form of XML representation); and
·
usage notes to highlight potential data quality, implementation or other issues.
Proposed principles for HealthConnect metadata include:
1.
Archetypes, expressed in an appropriate XML syntax, should be used to
represent HealthConnect metadata.
2.
All HealthConnect metadata should be defined in both machine-readable and
human-readable form and in accordance with the ISO 11179 standard.
3.
HealthConnect must have a governance process for quality assurance and to
oversee compliance of HealthConnect metadata.
4.
Archetypes may be defined using languages such as ADL, OWL, RDF(2) and
tools are becoming available to transform archetypes between representations.
5.
While XML Schema Definition (XSD) may not be sufficiently comprehensive
or structured to define and interpret HealthConnect metadata, archetypes may
still be communicated as XML documents.
6.
EHR views, EHR lists and EHR queries at any future point in time are likely to
encounter data created under older metadata, hence backward compatibility of
metadata (and also definitions of previous versions) need to be maintained.
7.
EHR components must be tagged with the version of metadata they were created
under and HealthConnect applications will require the flexibility to merge data
145
HealthConnect
Business Architecture v1.9
from a number of versions of metadata in adding to an EHR or when forming a
list or view.
8.
9.17
Incremental updating of metadata is needed, particularly in the case of large
terminologies, should they be adopted in Australia.
HealthConnect Registration Objects
The processes of consumer registration and provider registration that will be carried out
by the HealthConnect registration applications will involve a range of subsidiary
registration objects required to maintain the HealthConnect consumer index and the
HealthConnect provider directory. In addition to information contained in basic
registration transactions, the registration application will manage the following types of
information objects:
(a)
updates to consumer details including contact details, changed business
parameters, voluntary and enforced deregistration;
(b)
audit trails and logs of all accesses and transactions processed by the registration
application;
(c)
confidential questions used to assist in identifying consumers and providers and
temporary access codes issued to allow an authorised user temporary access to
an EHR; and
(d)
details of registration with professional registration boards in various
jurisdictions including any change in status (particularly, suspension or
cancellations of registration).
9.18
National Information Repositories
HealthConnect business processes will make substantial use of national health
infostructure now being developed. The following areas of this work are of particular
relevance to HealthConnect:
(a)
A proposed national health identifier, which may provide a universally
recognised unique health identifier for consumers that will underpin and may
even replace the unique HealthConnect consumer identifier.
(b)
National health metadata repositories being established by the AIHW under the
oversight of the inter-governmental National Data Standards Committee.
(c)
National health data sets – in particular the Australian Catalogue of Medicines
(ACoM)
(d)
Health information standards and terminologies;
(e)
A proposed national provider directory, which may provide a universally
recognised unique health provider identifier that may even replace the unique
HealthConnect provider identifier.
146
HealthConnect
Business Architecture v1.9
As these national infostructure components come to fruition, HealthConnect will
harness these resources to assist with the identification of consumers and providers and
to enhance the semantic interoperability of HealthConnect and supporting applications.
Further information on the role and impact of each of these elements of the national
health infostructure is provided in section 8.14.
9.19 eHealth Communication Messages
The eHealth message bank service provides facilities needed to receive, hold and
forward eHealth messages being transmitted between participating providers for
purposes such as electronic prescriptions, electronic referrals, electronic notifications
and, potentially, a range of other health-to-health (H2H) and B2B transactions.
The information content for these messages is still being addressed, but is expected to
include the following broad categories of information:
·
The provider organisation and/or individual provider from which the message
originated;
·
The identity of the consumer (via the HealthConnect identifier);
·
The HealthConnect (or national provider directory) identifier for the receiving
provider;
·
The type of eHealth communication message;
·
The message body – containing the clinical comments and information; and
·
Associated event summary header information.
147
HealthConnect
Business Architecture v1.9
10. HealthConnect Business Processes
10.1
High Level Business Process Context
The following process map illustrates the high-level groups of business processes
associated with the delivery of HealthConnect:
Secondary
User
A. Administer HealthConnect Programs
Provider
B. Manage HealthConnect Participation
Consumer
Consumer
Registrations
G. Access
HealthConnect as a
Consumer
Provider
Registration
D. Establish &
Maintain Provider
Registration
C. Establish &
Maintain Consumer
Registration
E. Use HealthConnect
Information for Health
Service Delivery
I. Provide HRS/AEM Services
Consumer
Transactions
H. Deliver
Consumer
Access to
HealthConnect
J. Respond to EHR
Information Request
K. Process Event
Summary into EHR
F. Deliver
Provider
Access to
HealthConnect
L. Establish/Operate HealthConnect Infrastructure
HealthConnect
Processes
Metadata Repository
National Data Store
Audit Trails
Consumer Index
Provider Directory
Networks & Systems
Provider
Transactions
eHealth
Message
Bank
M. Maintain National Health Infostructure
> Health Information Standards,
Terminologies & Data Sets (eg ACOM)
> National EHR Metadata
> National Health Identifier Service
> National Health Provider Directory/Index
Figure 10.1 HealthConnect Process Map
The process map identifies 13 aggregated process groups, which may be further broken
down into processes, sub-processes and tasks. In many cases, execution of these
processes involves participation by different entities and interaction between roles and it
is the identification and management of such interactions which is necessary to have an
effective design and implementation of HealthConnect.
A.
Administer HealthConnect programs
B.
Manage HealthConnect participation
C.
Establish and maintain consumer registration
D.
Establish and maintain provider registration
E.
Use HealthConnect information for health service delivery
F.
Deliver provider access to HealthConnect
G.
Access HealthConnect as a consumer
H.
Deliver consumer access to HealthConnect
I.
Provide HRS/AEM services
J.
Respond to EHR information request
K.
Process event summary into EHR
L.
Establish and operate HealthConnect infrastructure
148
HealthConnect
M.
Business Architecture v1.9
Maintain national health infostructure
Within these high-level process groups, over 80 business processes were identified,
which are addressed in more detail in the business requirements document produced as
part of this business architecture.
149
HealthConnect
10.2
Business Architecture v1.9
Major Business Processes
The following table shows the break-down of the aggregated process groups into the
major business processes required for the development and operation of HealthConnect.
150
HealthConnect
A.
Administer HealthConnect programs
Administer HealthConnect programs
A1
Establish HealthConnect operational policies
and standards
Business Architecture v1.9
B.
Manage HealthConnect participation
B1
Promote community awareness of
HealthConnect
B2
Engage with stakeholder bodies
A2
Establish arrangements for coordinated
national delivery of HealthConnect
B3
Contract with health providers for use of
HealthConnect
A3
Procure HealthConnect systems and
infrastructure
B4
Agree HealthConnect supply terms for
consumers
A4
Licence HealthConnect consumer access and
provider eHealth access services
B5
Handle applications for secondary use of
HealthConnect data
B6
Administer access to HealthConnect
B7
Monitor access and audit/report usage
B8
Handle consumer and provider complaints
B9
Coordinate HealthConnect records
management functions
151
HealthConnect
Business Architecture v1.9
C.
Establish and maintain consumer
registration
D.
Establish and maintain provider
registration
C1
Market HealthConnect to consumers
D1
Market HealthConnect to providers
C2
Register consumer with HealthConnect
D2
C3
Update/recover consumer registration details
Register individual provider with
HealthConnect
C4
Process consumer deregistration from
HealthConnect
D3
Register provider organisation with
HealthConnect
C5
Manage tracking of consumer surrogates
D4
Maintain provider registration details
D5
Process deregistration of individual provider
from HealthConnect
D6
Process deregistration of provider
organisation from HealthConnect
F.
Deliver provider access to HealthConnect
F1
Provide HealthConnect access portal and
message handling
F2
Provide advice, assistance and training to
HealthConnect providers
E.
Use HealthConnect information for health
service delivery
E1
Identify consenting consumer to
HealthConnect
E2
Retrieve/use consumer EHR information
E3
Update consumer EHR information
F3
Provide eHealth support service
E4
Send/receive eHealth communication
F4
E5
Access value-added services
Provide access to eHealth message bank
service
E6
Seek HealthConnect support assistance
F5
Provide access to added-value services
F6
Monitor and report service delivery
performance indicators
F7
Assist to market HealthConnect to providers &
facilitate provider registration
H.
Deliver consumer access to
HealthConnect
H1
Provide HealthConnect consumer access
portal
H2
Provide advice, assistance and training to
HealthConnect consumers
G5 Access value-added services
H3
Provide consumer support service
G6 Seek HealthConnect support assistance
H4
Assist with marketing HealthConnect to
consumers
H5
Facilitate consumer registration
H6
Provide consumer access to added-value
services
H7
Monitor and report service delivery
performance indicators
G.
Access HealthConnect as a consumer
G1 Maintain consumer access control list
G2 Maintain consumer registration information
G3 Retrieve/use EHR Information
G4 Update/Annotate EHR information
G7 Check access log
152
HealthConnect
Business Architecture v1.9
I
Provide HRS/AEM services
J.
Respond to EHR information request
I1
Manage HRS databases and audit trails
J1
Validate EHR information request
I2
Apply updates to consumer details and
access control lists
J2
Provide EHR View/List
I3
Control access to EHR information
J3
Process EHR Query/Response
I4
Update/maintain HRS Application software
J4
Produce EHR Report
J5
Maintain access log
I5
Maintain compatibility with HealthConnect
metadata
I6
Maintain HRS processing platform and
network environment
K.
Process event summary into EHR
K1
Validate incoming event summary
I7
Apply and monitor ICT security measures
K2
Update EHR
I8
Monitor and report service delivery
performance indicators
K3
Maintain audit trail and NDS
L.
Establish and operate HealthConnect
infrastructure
M.
Maintain national health infostructure
L1
Maintain National Data Store
L2
Maintain HealthConnect Metadata Repository
M2 Develop and maintain national health
metadata repository
L3
Maintain HealthConnect Consumer Index
M3 Implement health information standards
L4
Maintain HealthConnect Provider Directory
M4 Provide standard terminologies and data sets
L5
Manage HealthConnect ICT infrastructure
L6
Promulgate metadata and standards for
HealthConnect
M5 Provide national Health Provider Directory
service
L7
Run HealthConnect operations
L8
Organise clinical systems to inter-operate with
HealthConnect
M1 Provide National Health Identifier Service
Descriptions of each of the above process groups, processes and, where relevant,
associated sub-processes are contained in the attachment to this business architecture
entitled Specification of HealthConnect Business Requirements.
153
HealthConnect
Business Architecture v1.9
11. Technology Components
This section provides an overview of the systems and subsystems which interoperate
to provide HealthConnect functionality.
While the overall technology framework and relationships between the individual
parts of the HealthConnect solution should remain relatively constant, more specific
requirements will evolve through further detailed design and from experience gained
through stage 1.
11.1
Systems Overview
National Health
Metadata
Repository
National Health
Terminologies etc
National HealthConnect Applications
───────────────────────────
NDS Maintenance & Reporting
HealthConnect Metadata Maintenance
HealthConnect Administrative Applications
Secondary User
HealthConnect
National Data Store
(& Audit Trail Index)
HRS
───────────────────
HRS Access Control
EHR Input Validation & Update
EHR Information Retrieval
Maintain Consumer Access List
Maintain Audit trails
Provide NDS Information
Messaging Interface
HealthConnect
Metadata
Repository
National Health
Identifier Service
(NHI)
National Health
Provider Directory
HealthConnect Registration
Applications
─────────────────
Consumer Registration
Provider Registration
HealthConnect
Registration
Operatons
HealthConnect
Consumer Index
EHR Repository
HealthConnect
Provider Directory
eHealth
Message
Bank
Application
HealthConnect Message Handling & Transport
Clinical
Information
System
Web
Browser
HealthConnect
Provider/Consumer
Access Portals
eHealth Transmission
Service (ETS)
Consumer Health
Information
System
HCCAS Operations
Web
Browser
PeHAS Operations
Provider
Consumer
Figure 11.1 HealthConnect Systems Overview
The core function of HealthConnect is the processing of EHR event summaries and
query transactions, which is to be carried out by a federation of HealthConnect
Records Systems (HRS) that maintain the primary HealthConnect EHR repository.
154
HealthConnect
Business Architecture v1.9
The operating environment of HealthConnect is illustrated in Figure 11.1. To
exchange information with HealthConnect users, each HRS interacts with
HealthConnect-enabled user applications via a common HealthConnect message
handling and transport system.
HRS services are the centrepiece of HealthConnect, controlling access to the
consumer’s EHR information and managing the input, validation, storage, retrieval
and delivery of this information in accordance with HealthConnect processing rules.
The HRS also maintains consumer details, an access control list and an audit trail of
all access to each EHR. Each HRS is to regularly forward copies of EHR information
and logs of audit trail accesses, to the HealthConnect National Data Store for archival
storage and approved secondary uses.
These core components of HealthConnect are all to be securely interconnected by an
eHealth Transmission Service, which is also required to support other applications,
such as storage and delivery of electronic prescriptions and referrals.
A provider may use a clinical information system to interact with HealthConnect
(provided that the clinical information system is HealthConnect-enabled) or,
alternatively, may use a web browser to interact with HealthConnect via a provider
access portal running a provider front-end application.
Consumers will typically use a web browser to access HealthConnect via a consumer
access portal running a consumer front-end application. Alternatively, it is expected
that consumers may eventually be able to acquire HealthConnect-enabled consumer
health information systems that will allow them to interact with HealthConnect via the
message handling and transport system.
All communications between an HRS and user applications are conveyed as messages
via the message handling and transport system that manages communications between
HealthConnect and external participants using standard HealthConnect message
protocols. It is expected that the message handling and transport system will also be
federated across several providers, such as those supplying HRS services,
HealthConnect consumer access services, provider eHealth access services and/or
value-added health information services.
The message handling and transport system and HRS services will rely on the
HealthConnect consumer index and HealthConnect provider directory for information
needed to identify HealthConnect users and to route messages to and from the
appropriate HRS and other application components in the federated HealthConnect
environment.
The HealthConnect consumer registration application sets up consumer index entries
from information provided when the consumer registers with HealthConnect (with the
possibility of including identification provided through the proposed national health
identifier). Selected parts of the consumer’s personal information may subsequently
be maintained by the consumer via online interaction with HealthConnect itself or a
HealthConnect consumer registration agency. The HealthConnect consumer index
allows HealthConnect applications to use the consumer’s unique HealthConnect
identifier to find and access the HRS on which the consumer’s EHR is held.
155
HealthConnect
Business Architecture v1.9
A copy of parts of the consumer’s information, necessary for ensuring accurate
identification of the consumer eg name, is held on the consumer index for use in
managing HealthConnect but should not be made available to external applications
using the index. Up-to-date consumer demographic information will be available as
part of each EHR and becomes available to those users authorised to access the
consumer’s EHR, thereby enabling them to check the identity of a consumer before
retrieving further EHR information or updating the EHR.
The HealthConnect provider registration application maintains the HealthConnect
provider directory based on information set up when a provider registers with
HealthConnect (with the possibility of including identification and other information
provided through the proposed national health provider directory). Selected parts of
the provider’s information may subsequently be maintained by the provider via online
interaction with HealthConnect itself or the HealthConnect provider registration
agency. Parts of the HealthConnect provider directory are generally accessible to all
providers and contain electronic contact details that permit HealthConnect messages
to be addressed and delivered to the provider (via a proposed eHealth message bank
application).
The registration applications are to log all transactions in an audit trail, which is to be
archived indefinitely.
The HealthConnect registration applications, consumer index and provider directory
are proposed as national HealthConnect infrastructure available to:
·
each HRS;
·
each consumer registration agency;
·
those organisations responsible for registering providers; and
·
the HealthConnect registration centre.
Nevertheless, until these national HealthConnect registration components are fully
operational, trials and lead-state implementations may proceed with local registration
initiatives, with a view to their early integration into the national HealthConnect
infrastructure.
A HealthConnect Operations Centre should have responsibility for the ongoing
management of registration functions in order to ensure the registration process
functions effectively on behalf of the HealthConnect governing body and to perform
more sensitive functions, such as maintaining consumer identification parameters,
periodic reviews, de-registration and enabling of suspended registrations and setting
up short-term access to an EHR based on telephone identification.
The structure and content of HealthConnect EHR information is defined by
HealthConnect metadata, which will be used by the HRS services, national data store,
message handling and transport system and clinical information system interfaces to
format and exchange EHR information. All versions of HealthConnect metadata that
are actually promulgated and used for the formation and storage of HealthConnect
EHR information must be retained indefinitely to allow future interpretation of the
EHR information.
156
HealthConnect
Business Architecture v1.9
The national data store, which is discussed in more depth in sections 8 and 9, is a
national repository of all the EHR information held across all the HRS services
retained in a perpetual archive and available to support reporting and other approved
secondary uses, including research to improve health care and health care delivery. A
consolidated access log is also to be maintained as part of the national data store data
collections.
If the proposed national health identifier and national provider directory are
established and when the national health metadata repository, Australian Catalogue of
Medicines (ACoM) and clinical terminologies and code sets become available, it is
proposed that HealthConnect and its component applications will access these
resources to assist with the identification of consumers and providers and to enhance
the semantic interoperability of HealthConnect and supporting applications.
Security of consumer information and of HealthConnect facilities and services is an
important part of the HealthConnect operational infrastructure and is the subject of
further analysis in this section, as are the requirements for appropriate interface and
messaging technologies.
Note
Descriptions of the operation and functions of each of the above components are
further developed in a separate attachment to this business architecture entitled
Specification of HealthConnect Business Requirements.
157
HealthConnect
Business Architecture v1.9
Part E – Managing and Implementing HealthConnect
159
HealthConnect
Business Architecture v1.9
The previous sections of the Business Architecture have concentrated on defining the
principles of HealthConnect, explaining how it would work for the different types of
participants and defining the components of HealthConnect.
Part E addresses governance, legal and implementation issues associated with realising
HealthConnect. These important topics have been the subject of major research
initiatives in their own right and detailed reports have been produced in parallel with the
development of the Business Architecture. These reports have already been circulated
for review under separate cover.
The purpose of this section is not to duplicate the findings contained in these related
reports, rather to link them back to the Business Architecture. The focus will be on
indicating how the recommendations support the realisation of HealthConnect,
highlighting key issues necessary for progress to be achieved.
12. Managing HealthConnect
This section addresses issues relating to the key aspects of managing HealthConnect
namely governance structure, privacy issues and legal issues.
12.1 HealthConnect Governance Structure
12.1.1 The Governance Approach
Details of the proposed governance structure for HealthConnect are being finalised in
parallel with the documentation of this business architecture.
Given that the model for delivering HealthConnect may change over time, the
governance arrangements need to have the capacity to change, while at the same time,
ensuring that the HealthConnect functions and operations remain accountable to
Australian, state and territory governments and the public.
It is proposed that the ongoing management of the HealthConnect program at the
national level be vested in a dedicated organisational entity on behalf of all the
participating governments and other stakeholders. This organisational entity is
commonly referred to as the HealthConnect governing body.
The functions which this governing body would be expected to cover include:
overseeing the implementation and operation of HealthConnect, providing clinical
governance, maintaining approval mechanisms to assess requests for secondary uses of
HealthConnect data, overseeing registration process for both consumers and providers,
determining the rules and standards applicable to HealthConnect activities, establishing
contractual and licensing arrangements with various HealthConnect participants and
suppliers, and monitoring of compliance throughout the network.
In the short term, the governance arrangements of the project implementation activities
will be based on the current HealthConnect Board, Steering Committee and Advisory
Group arrangements.
161
HealthConnect
Business Architecture v1.9
HealthConnect is also being progressed regionally through staged HealthConnect
state/territory implementations and the ongoing HealthConnect trials. Each of these
initiatives currently has its own governance structure, which encompasses many of the
same functions at a local/regional level as are proposed to be carried out by the
HealthConnect governing body a national level. For the short- to medium-term some of
the HealthConnect management functions will be performed at a regional level.
12.1.2 Ongoing Management Governance Structure
The key elements of the ongoing management structure are presented below. More
detailed descriptions of the key roles are presented in Part D – HealthConnect
Components.
The HealthConnect Governing Body
The centralised HealthConnect governing body will be established to manage
HealthConnect. The Clayton Utz Legal Issues Report has explored a number of
structuring alternatives including establishing the governing body as: a departmental
function without establishing an executive agency, a company, an executive agency, a
statutory authority, or an unincorporated joint venture. These alternatives are currently
being reviewed.
As stated in Part D in the HealthConnect Context and Roles Section, the HealthConnect
governance role may be encapsulated by three high-level functions.
·
·
·
Administration of HealthConnect programs, including:
-
Establish HealthConnect operational policies and standards
-
Establish arrangements for coordinated national delivery of
HealthConnect
-
Procure HealthConnect systems and infrastructure
-
License HealthConnect consumer support and eHealth access service
providers
-
Evaluate HealthConnect outcomes.
Management of HealthConnect participation including:
-
Promote community awareness of HealthConnect
-
Engage with stakeholder bodies
-
Contract with health providers for use of HealthConnect
-
Agree HealthConnect supply terms for consumers
-
Manage approval and monitoring of secondary uses
-
Administer access to HealthConnect
-
Monitor access and audit/report usage
-
Handle consumer and provider complaints.
Establishment and operation of HealthConnect infrastructure including:
-
Promulgate metadata and standards for HealthConnect
162
HealthConnect
Business Architecture v1.9
-
Maintain National Data Store
-
Maintain HealthConnect Metadata Repository
-
Maintain HealthConnect Consumer Index
-
Maintain HealthConnect Provider Directory
-
Manage HealthConnect ICT infrastructure
-
Run HealthConnect operations
-
Organise clinical systems to inter-operate with HealthConnect.
Operational Structure and Support
While the HealthConnect governing body will have overall responsibility for
HealthConnect operations, many of the routine HealthConnect operational activities will
be performed by other organisations contracted to perform them on behalf of
HealthConnect. These might include:
·
Registering and managing consumer and provider participation – A number of
HealthConnect Registration Agencies may be contracted to perform front line
registration functions. There will also be a requirement for a HealthConnect
Registration Centre operating at a national level to set policy and oversee the
registration process;
·
Maintaining the HealthConnect EHR repository; including the individual Health
Record Systems and the National Data Store – Approved EHR Managers will
be contracted to run the HRS; and
·
Governing the interaction with HealthConnect - HealthConnect Consumer
Access Services will be contracted to support customer interaction with
HealthConnect; and Provider eHealth Access Services will be contracted to
support providers interacting with HealthConnect.
12.1.3 Project Implementation Governance Structure
The key elements of the current governance structure which is overseeing the design
and implementation of HealthConnect are presented below.
The HealthConnect Board
The HealthConnect Board reports to the Australian Health Ministers’ Advisory Council
(AHMAC) through the National Health Information Group (NHIG).
The Board has the responsibility to:
·
Oversee the formulation of policy related to the design, development,
implementation and evaluation of HealthConnect;
·
Provide advice to AHMAC on the alignment of Australian, State and Territory
Government electronic health records projects within a national architecture;
·
Monitor the operation and progress of HealthConnect and recommend policy
and operational changes.
163
HealthConnect
Business Architecture v1.9
Expert Advisory Groups
A number of expert advisory groups will be appointed to advise the Board and Steering
Committee and, in the future, the HealthConnect governing body on issues that arise in
the implementation of HealthConnect and to provide a link with the locally-based
implementation activities. The expert advisory groups will maintain this important
stakeholder participation. In the first instance these will be:
·
Clinical Advisory Group - Clinical input into the HealthConnect
implementation will be critical to its success. This group will provide expert
advice on clinical matters and the effective collection, storage and retrieval of
clinical information. Members will also advise on structural, organisational and
workforce changes necessary for the implementation of HealthConnect.
·
Architecture Advisory Group - The Architectural Advisory Group (AAG) will
advise on technical aspects of data and systems architecture. This will
complement the work of the Clinical Advisory Group (CAG), which will be
addressing business process issues associated with the design and
implementation of HealthConnect.
·
Evaluation Advisory Group - The Evaluation Advisory Group (EAG) will
provide advice to the HealthConnect Board on processes for evaluating and
monitoring HealthConnect implementation.
As implementation progresses it is anticipated that other advisory groups may be
required. This might include a privacy and access control advisory group to provide
input on issues such as establishing and monitoring privacy protocols, defining consent
options and rules; approval of research requests. This Group could fulfil the
requirements for the independent and transparent monitoring of the role of
HealthConnect in authorising and managing access to information for secondary uses.
Ensuring overall operation of HealthConnect, monitoring usage and handling
complaints will be part of the core HealthConnect governing body role.
Regional Implementation Governance
While the HealthConnect governing body will have the overall responsibility for the
implementation and operation of HealthConnect from a national perspective, the Stage 1
state/territory and trial implementations of HealthConnect will have local governance
structures. Key characteristics of these structures will include establishment of:
·
Local steering committees to make decisions on the scope and priorities of the
local implementation. The committees will also be responsible for reporting to
the HealthConnect governing body/steering committee to ensure compliance and
consistency of implementations;
·
Local advisory groups such as a clinical group to make decisions relevant to the
local implementation, within the framework established by the HealthConnect
governing body and its advisory groups;
·
Support for collaborative partnerships between local stakeholders, public and
private organisations;
164
HealthConnect
Business Architecture v1.9
·
“Champions” who will represent the interests of their clinical area and to assist
in the local promotion of HealthConnect; and
·
Any local Registration Agencies, Approved EHR Managers, HealthConnect
Consumer Access Services Operators or Provider eHealth Access Services
Operators, as required.
Until the HealthConnect governing body and its operational support arrangements are
fully active, similar operational functions will be needed locally to support Stage 1
HealthConnect implementations. Longer-term integration of these functions into the
national program will need to be considered by the HealthConnect governing body and
the relevant jurisdictions.
12.1.4 National eHealth Transition Authority
For HealthConnect to be successful it must take into consideration the wider e-health
agendas and the bodies responsible for their management.
The Australian Health Information Council (AHIC) and the National Health
Information Group (NHIG), to which the HealthConnect Board reports, are jointly
developing a national IM&ICT strategy due to be completed at the end of 2004.
Ministers have endorsed the establishment of the National eHealth Transition Authority
(NEHTA) to drive the national priorities over the next 12 months. The longer term
strategy will then be determined, potentially including the establishment of an
independent legal entity.
NEHTA has established a work program focussing on the national priority areas of
clinical data standards, identification standards, consumer and provider directories,
supply chain procurement standards, consent models, secure messaging and information
transfer, and technical integration standards. These initiatives will support the future
development and implementation of HealthConnect.
The HealthConnect Board has endorsed the establishment of a process to achieve
alignment between HealthConnect needs and the NEHTA work program.
12.2 HealthConnect Privacy Issues
12.2.1 Need for Strict Privacy Control
The success of HealthConnect will depend on consumers, providers and provider
organisations having confidence and trust that health information is kept confidential
and secure. To this end, a robust privacy framework, together with strong security
measures, is required.
Personal health information is particularly sensitive information. Inappropriate
handling of such information can lead to serious consequences to the individual such as
being socially ostracised, being personally embarrassed or having difficulty gaining
employment. While consumers generally have a high level of trust in the way in which
their health care providers maintain confidentiality, the capacity of electronic health
record systems to quickly assemble, store and transfer information beyond
organisational boundaries naturally raises privacy concerns.
165
HealthConnect
Business Architecture v1.9
These concerns are evident in the research undertaken to date on consumer and provider
attitudes to electronic health record initiatives. While consumers and providers can
readily see the benefits of electronic health records, privacy and security issues are
consistently of most concern. For HealthConnect to be successful, the privacy concerns
of consumers need to be adequately addressed.
The results of stakeholder consultations in relation to HealthConnect likewise support
these findings. Key concerns raised include the potential for:
·
the use of information by third parties that act against the interests of the
individual concerned (eg employers and insurers);
·
personal sensitivities or embarrassment if health information is accessed
inappropriately;
·
potential harm to an individual if information is accessed by someone who poses
a threat to that person (eg domestic violence); and
·
information being used for other purposes that are not for the health benefit of
the person involved (eg unacceptable commercial use of data).
Therefore, before HealthConnect can proceed on a national scale, both providers and
consumers would need to have a strong sense of trust that their health information
would be adequately protected and that only those who ‘need-to-know’ can access their
records.
While security and confidentiality are essential prerequisites, the ability for consumers
to have access to information held about them and to be able to maintain control over
how their information is used and to whom it is disclosed are also fundamental aspects
of health information privacy within HealthConnect.
12.2.2 Existing Privacy Frameworks
The privacy framework under which health records are currently treated consists of
several sets of legislation and rules.
The Australian Government public sector is regulated by the Information Privacy
Principles18 which are provided by the Privacy Act 1988. The private health sector is
covered by the National Privacy Principles19 within the Privacy Act 1988. To aid the
private health sector to meet their obligations under this Act the Federal Privacy
Commissioner has developed the Guidelines on Privacy in the Private Health Sector.
Victoria, New South Wales and the Australian Capital Territory currently have health
specific privacy legislation. Western Australia is developing health specific legislation.
South Australia, Tasmania and Queensland have administrative arrangements in place
which govern the privacy rules of health information.
This creates different privacy requirements within the current health system – divided
both by the sector (public versus private) and by the State or Territory in which that
health service is provided.
18
19
For the Commonwealth public sector only
For the private sector only
166
HealthConnect
Business Architecture v1.9
To overcome this lack of consistency, the National Health Privacy Code (NHPC) is
being developed by the Australian Health Ministers’ Advisory Council (AHMAC)
National Health Privacy Working Group. Additional policy rules and/or legislation to
deal with specific privacy issues relating to HealthConnect may need to be developed.
12.2.3 HealthConnect Privacy Framework
In the absence of a national privacy framework, HealthConnect specific privacy
arrangements have been developed based upon the National Privacy Principles and the
proposed National Health Privacy Code.
Providers participating in HealthConnect will be obligated to abide by existing privacy
legislation and by specific HealthConnect privacy protocols – including when they
access and use information from consumer’s HealthConnect records, and when they add
information to these records.
Multi layered Approach
Privacy arrangements for HealthConnect will take a multi-layered approach
incorporating legislation and policy rules; technical and security measures; and
organisational practices. Key elements of this multi-layered approach could include:
·
The National Health Privacy Code, currently under development by the
AHMAC National Health Privacy Working Group;
·
Specific rules underpinning the establishment and operations of HealthConnect
that set out primary uses of data; authority and processes by which secondary
uses of data are approved; consent processes; offences, penalties and sanctions
for breaches; and complaints mechanisms;
·
Development of a national security framework for HealthConnect which covers
the functions of identification/authentication, access control mechanisms,
message protection, monitoring and detection mechanisms; and audit/logging
processes; and
·
Establishment and maintenance of organisational practices, including staff
training, which ensure appropriate privacy and security standards are maintained
by organisations participating in HealthConnect.
Safeguards
The HealthConnect framework aims to establish a range of safeguards relating to
HealthConnect governance and operations and will include specific reference to:
·
complaints mechanisms and rights of redress;
·
the circumstances under which health information can be collected by
HealthConnect and subsequently used and disclosed;
·
how individuals who misuse such information would be held liable for such
actions;
·
HealthConnect information only being used and disclosed for agreed purposes;
167
HealthConnect
Business Architecture v1.9
·
how consumers can have access to their own health information held on
HealthConnect and control who has access to their information and to whom it
can be disclosed; and
·
the controls over who has access to what information and by which authorisation.
Checks and Balances
The HealthConnect framework will also include a range of checks and balances to be in
place including:
·
Consumers participating in HealthConnect having a clear understanding of how
their information may be used and disclosed - informed consent;
·
Clear lines of decision making for determining the secondary uses of
HealthConnect data, including ethics approval and independent scrutiny by an
expert external to the HealthConnect governance framework.
12.3 HealthConnect Legal Issues
The firm of Clayton Utz has researched and prepared a report20 to provide guidance to
the HealthConnect Program Office and key stakeholders on the way forward with
potential legal issues identified in the research and development phase of the
HealthConnect project.
Legal issues raised to date include issues in relation to information privacy, security,
access control, data quality (ensuring the integrity and currency of data, and the correct
degree of reliance on the data), intellectual property, stakeholder liability and indemnity,
and stakeholder rights and responsibilities.
The Clayton Utz report has addressed these issues under the following headings:
Custodianship and Controls, Information Technology and e-Commerce, Privacy and
Consent, Intellectual Property, and Liability and Indemnity.
This report is currently being reviewed and finalised and will be circulated under
separate cover. At this stage it is understood that issues raised in the report will not
necessarily require changes to the HealthConnect solution outlined in the Business
Architecture; rather that they need to be managed through specific policy and process
planning activities.
20
Clayton Utz HealthConnect Report, 20 August 2004
168
HealthConnect
Business Architecture v1.9
13. Implementing HealthConnect
13.1 HealthConnect Implementation Approach
Fujitsu has conducted research into implementation approaches required to achieve a
successful national implementation of HealthConnect. The Implementation Approach21,
together with the HealthConnect Benefits Realisation Framework22, and the
HealthConnect Implementation Plan constitutes the HealthConnect implementation
planning work.
The implementation strategy recognises the need to embrace a change program across
the national population base as well as to coordinate the more technical aspects of
HealthConnect needed to support the changed work practices, information storage and
information provision services.
This section discusses how the implementation approach supports the achievement of
key HealthConnect principles.
13.1.1 Implementation Drivers
The HealthConnect implementation approach is benefits driven and is based on a
Benefits Realisation Framework; the key features of which include:
·
Take up and clinical processes - high take-up rates by both providers and
consumers will maximise the realisation of benefits from the implementation of
HealthConnect. HealthConnect should focus on increasing the efficiency of the
processes that underpin episodes of clinical care;
·
Information - increasing the usefulness of information to clinicians will ensure
providers use the EHR; similarly focus should be on information flows between
providers and among health care facilities to increase patient safety by
decreasing the impact of adverse events including adverse drug events;
·
Governance and evaluation - implementing full cycle governance to ensure the
ongoing management of the HealthConnect program. This should include an
overarching economic evaluation construct to ensure the requisite data is
captured to enable benefits to be identified, measured and attributable to
HealthConnect in terms of health gains, cost offsets and broader social
objectives; and
·
Population groups - initially focusing the HealthConnect registration,
enrolment and communication processes on the areas where there is a high
incidence of health care expenditure.
In addition to the key benefits drivers, the implementation will focus on achieving high
levels of provider and consumer take-up and developing core HealthConnect
capabilities, particularly in relation to HealthConnect governance, systems/
infrastructure, organisation and operations. These are discussed below.
21
22
Implementation Approach, Draft for Final Review, Draft 0.18, 2 August 2004, Fujitsu
HealthConnect Benefits Realisation Framework V1.0 October 2004
169
HealthConnect
Business Architecture v1.9
13.1.2 Provider and Consumer Take-up
Consumer Take Up
HealthConnect Principles state that consumer participation in HealthConnect will be
voluntary and available to all Australian citizens and residents of Australia.
The implementation approach proposes that HealthConnect needs to have a focus and
priority on specific target consumers that will realise the highest value clinical and
social benefits. The targeting of consumers therefore needs to consider factors such as:
·
Degree of “sickness/wellness” – bringing the more chronically ill consumers
onto HealthConnect will address directly the quality of clinical care benefits;
·
Type of disease and its “growth pattern” – the major types of diseases that could
best utilise HealthConnect capabilities, e.g. chronic diseases;
·
Geographic basis – the population areas would provide opportunity for
HealthConnect critical mass. The geographic catchment area must include a
cohesive collection of all the key providers and other selected providers; and
·
Demographic basis – the age groups that could best utilise HealthConnect
capabilities in the short and long term, e.g. the very young, the elderly.
While this implies a focus on specific consumer groups, once HealthConnect is
operational in their geographic area, any consumer may register with HealthConnect.
Provider Take-up
HealthConnect Principles state that participation in HealthConnect will be made
available to all providers involved in the chain of health care delivery.
The implementation approach highlights that a critical mass of provider enrolment
needs to be achieved. The strategy for provider take-up includes targeting providers
taking into consideration the consumer target group and the provider professional focus,
and developing and implementing appropriate marketing approaches. For take-up to be
effective:
·
Virtually all of the HealthConnect functionality (provider capability/
infrastructure, HealthConnect data and views) needs to be in place such that
provider benefits might be achieved;
·
A key group of providers must participate in HealthConnect for clinical
outcomes to be achieved. Initially this will include general practitioners,
community pharmacists, hospital clinicians, pathologists and radiologists; and
·
A high take-up of consumers with ongoing health care needs and the majority of
providers need to be involved to achieve provider efficiency outcomes.
Thus a targeted approach that takes account of the realities of consumer and provider
capabilities and also key health priority areas, driven by anticipated benefits, is
necessary. In this sense, it is not so much the rate of take-up for providers that is
important, but more so the mix of take-up. The goal is to be able to support the
continuum of care for consumers who participate in HealthConnect.
170
HealthConnect
Business Architecture v1.9
When one or two key providers caring for a consumer are not participating in
HealthConnect, it is likely that essential data will be absent from their EHR. Hence the
consumer’s record will be much less useful to participating providers and consumers. A
key goal for provider take-up in HealthConnect is to avoid broken links in the care
chain.
13.1.3 HealthConnect Capabilities Compliance
For an implementation to be considered a HealthConnect implementation, it must be
compliant with the HealthConnect Business Architecture. In particular it must comply
with the HealthConnect Principles in Section 3 and the Specification of HealthConnect
Business Requirements23 provided as a separate attachment to the Business Architecture.
The implementation approach’s HealthConnect Capabilities foundation element is
focused on the ability of relevant HealthConnect stakeholders to design, plan, develop
and execute each of the Governance, System, Organisational and Operational aspects of
HealthConnect.
The HealthConnect Capabilities framework defines four specific Compliance Levels,
each of them reflecting an increasing depth/breadth of coverage and the sophistication
of the capabilities that would be required to deliver progressively higher degrees of
HealthConnect benefits. These levels are: 1. Trial, 2. Standalone, 3. Limited National
Solution (utilising common National Layer services); and 4. Full National Solution.
The implementation approach recognises the reality that HealthConnect implementers
are at different stages of HealthConnect compliance and that future implementers are
likely implement HealthConnect to accommodate local requirements. To address this,
the implementation approach supports the concept of Progressive Compliance
Pathways, whereby the implementers can join HealthConnect at different level of
compliance and progress through the remaining levels to reach full compliance.
This concept is illustrated on the following diagram which has been extracted from the
Fujitsu Report.
23
Specification of the HealthConnect Business Requirements
- Attachment to the Business Architecture v1.9 (October 2004)
171
HealthConnect
Business Architecture v1.9
Figure 13.1 HealthConnect Progressive Compliance Pathways
Some HealthConnect implementers may travel down a path whereby they step through
all levels of compliance. This would be particularly likely in the case of the stage 1
implementations. In the most likely scenario, the majority of adopters will join the
HealthConnect at the compliance Level 3 and then proceed to Level 4 at some later
stage. However, depending on the timing of the implementation, it would be feasible
for late adopters to directly implement Level 4.
13.2 Current Implementation Activities
13.2.1 HealthConnect Version 1
The first full implementation of HealthConnect is to be termed HealthConnect version 1
and will be based on the requirements detailed in the HealthConnect Business
Architecture version 2 which will be developed after version 1.9 consultation.
The HealthConnect Principles contained in the Business Architecture define the current
design position and is of necessity limited in scope in some areas while further research
and analysis is undertaken. Areas requiring further research include access to consumer
records based on provider type, introduction of more restricted ‘secure’ areas for
sensitive information, and consumer contribution to their EHR.
13.2.2 Stage 1 HealthConnect Implementations
The longer term implementation of HealthConnect will be based on the Business
Architecture version 2 and the procurement of HealthConnect version 1. Given that the
HealthConnect version 1 detailed requirements have not yet been finalised and that
there are a number of issues yet to be resolved, the procurement and the subsequent
development and implementation will take a number of years.
172
HealthConnect
Business Architecture v1.9
HealthConnect is therefore undertaking a staged approach to implementations. The
stage 1 implementations will not be extensions of the trials, though they will make use
of components and lessons from the trials. These implementations will:
·
build on the work conducted in the trails, ensuring that key issues are resolved;
·
be compliant with Version 1.9 of the Business Architecture;
·
have a scope aligned with the needs and capabilities of the specific regions;
·
be established as a cooperative project between the Australian government,
states and territory with shared development activities;
·
optionally include HealthConnect related services such as value added services
(eg referrals) and eHealth message bank services, according to local priorities;
and
·
importantly, include a migration path to HealthConnect version 1.
13.2.3 Current HealthConnect Trials
The HealthConnect trials have been a significant achievement for the HealthConnect
project and have been the principal means for testing the HealthConnect concept. While
some of the trials are approaching the wrap up phase, others are being extended.
Two longer-term HealthConnect trials have been established in Queensland in the
second half of 2003. The North Queensland HealthConnect trial, which went live in
December 2003, focuses on the peri-operative assessment and preparation of consumers
travelling to undergo elective surgery at Townsville Hospital. This trial has now been
extended for a further 12 months. The Brisbane Southside HealthConnect trial,
commenced in late 2004, focuses on testing new openEHR software technology for
managing health records and shared-care plans for consumers with diabetes.
The New South Wales Health-e-Link initiative currently under development is also
considered a HealthConnect trial. The project will test HealthConnect infrastructure in
two pilot sites. The Child Health Information Network (CHIN) will operation in Greater
Western Sydney and includes the Children’s Hospital at Westmead. The Chronic
Disease Management System project will operation in the Hunter Valley and includes
the John Hunter Hospital in Newcastle. These two pilots are expected to go live in mid2005. The Health-e-Link implementations are NSW Health pilots and as such are long
term implementations.
173
HealthConnect
Business Architecture v1.9
Glossary of Terms
175
HealthConnect
Business Architecture v1.9
HealthConnect Business Architecture –
Glossary of Terms
Access control
A means of ensuring that an information system such as
HealthConnect can be accessed only by authorised persons and
organisations in authorised ways.
Access control
list
A list of provider organisations authorised by a consumer, or by a
surrogate of a consumer, to access that consumer’s HealthConnect
EHR.
Access log
Record of access to EHR records (including emergency override
access) by healthcare providers, consumers, HealthConnect
registration agencies and HealthConnect system administration
functions.
Access portal
A computer system that provides users with a means of accessing an
information system across the Internet using a web browser.
Consumer access portals and provider access portals will be one
means by which consumers and providers respectively may access
HealthConnect functions.
ACOM
Australian Catalogue of Medicines
A directory of all medications available in Australia organised
according to a common classification scheme and linked to a
terminology for medicines and medical devices.
ADL
Archetype Definition Language
A formal language for expressing archetypes that can be used to
structure and validate the content of an EHR.
AEM
Approved EHR Manager
A public or private entity authorised by the HealthConnect governing
body to provide a HealthConnect Records System (HRS) service.
Agent
Within HealthConnect, a person nominated by a consumer to access
HealthConnect on behalf of the consumer. Also referred to as a
“consumer agent” an agent is one form of consumer surrogate and
would an appropriate form of arrangement to cover the authorised
involvement of a consumer’s family members, friends, or carers.
Aggregated data
Data about more than one consumer that are grouped together where
the identity of the consumers cannot reasonably be ascertained.
176
HealthConnect
Business Architecture v1.9
Archetype
A formal specification of the allowable structure and content of
information held in an EHR system in which the specification is
derived by constraining a reference information model of the EHR.
The current notion of archetypes in health informatics arose out of
the work of the openEHR Foundation. Archetypes are usually used
to define clinical information but may be applied in other domains.
Archetypes may define simple concepts such as “blood pressure” or
“address” or more complex concepts such as “family history” or
“microbiology result”.
Attestation
The process of recording responsibility for a particular unit of
information, such as a provider confirming the content of an event
summary prior to its transmission to HealthConnect.
Audit trail
A record of access and changes to information held in a computer
system or database.
Authentication
The process by which a degree of confidence is established about the
truth of an identity. In terms of computer security, the identification
or verification of the eligibility of a consumer or healthcare provider
to access a HealthConnect record.
B2B
Business to Business.
Call centre
A group of people processing telephone calls or other electronic
communications in accordance with defined protocols and supported
by computer systems. A health call centre is a call centre staffed by
health professionals that may offer health advice, health assessment
(triage) and health screening services.
Casemix
The Hospital Information, Performance Information Program
(HIPIP), formerly known as Casemix, aims to improve health service
delivery (in terms of cost, equity and quality) through classification
and data development, as well as research, analysis and information
dissemination.
CCoW
Clinical Context Object Workgroup (in HL7)
Using a technique called “context management”, standards
developed by CCOW allow information in multiple healthcare
applications to be unified under the control of the user so that all of
the healthcare applications are referring to the same patient,
encounter or user at any point in time.
CEN
Comité Européen de Normalisation (European Standards
Organisation)
177
HealthConnect
CEN 13606
Business Architecture v1.9
The family of European Standards relating to electronic healthcare
record communication, which include:
(a)
The European Pre-Standard (ENV), CEN ENV13606 issued
in four parts between 1999 and 2000; and
(b)
The full European Standard (EN), CEN EN13606 Electronic
Healthcare Record Interchange, now being finalised for issue
in five parts:
Part 1: Reference model.
Part 2: Archetype interchange specification.
Part 3: Reference archetypes and term lists
Part 4: Security.
Part 5: Exchange models.
CEN EN13606-1
The European Standard, EN13606 Electronic healthcare record
communication, Part 1: Reference model, which describes a
reference model for EHR information as it would appear in an EHR
extract (in draft form proceeding to ballot at time of writing).
CIP
Clinical Information Project
Project group responsible for developing and recommending
definitions of information content for use in HealthConnect
Electronic Health Records and the national priorities for
HealthConnect event summaries and views.
CIS
Clinical Information System
A computer system designed to support healthcare providers in the
delivery of healthcare. Examples include GP desktop systems,
pathology laboratory systems and point of care clinical systems
Clinical data
repository
A data store that holds and manages clinical data consolidated from a
variety of sources (e.g. hospitals, clinics, etc.)
Clinical decision
support
Systems including computer applications that assist healthcare
providers to make decisions about patient care.
CDA
Clinical Document Architecture (in HL7)
A set of HL7 standards that specify the structure of “clinical
documents”. Clinical documents are attributed to authenticated
authors and differ from HL7 messages in that they are designed to be
persistent. CDA is a popular architecture for EHR systems.
Coding
The process of assigning alphanumeric or numeric symbols to
convey information in accordance with an agreed classification
system.
178
HealthConnect
Business Architecture v1.9
Confidentiality
Legal duty of individuals and organisations that receive information
in confidence to respect that confidence, not to be confused with
privacy.
Consumer
A general term used for a person who accesses or uses health
services. Within HealthConnect, a ‘consumer’ or ‘participating
consumer’ means a person that registers with HealthConnect as a
consumer in accordance with the HealthConnect rules.
Consumer access
portal
see access portal
Consumer agent
See agent.
Consumer
consent
Agreement by an informed consumer to participate in HealthConnect
or otherwise to authorise the collection or use of their personal
information.
Consumer health
tools
Services to consumers that are made available by organisations
working with HealthConnect but not a service provided directly by
HealthConnect eg access to knowledge bases, care management
advice.
Consumer index
Within HealthConnect, a database holding every HealthConnect
consumer identifier, links to the HRS on which a consumer’s EHR is
held, consumer demographics and other information that can be used
to re-establish the HealthConnect consumer identifier, and
information on providers and surrogates that may access the
consumer’s EHR. The HealthConnect consumer registration service
is responsible for maintaining the consumer index (through the
HealthConnect consumer registration system) and for making
information in the consumer index available to other HealthConnect
services and components including consumer registration agencies,
HRS services and message handling and translation services.
Consumer
registration
agency
An organisation authorised by the HealthConnect governing body to
register HealthConnect consumers in accordance with the
HealthConnect rules.
Consumer
surrogate
A person (including a body corporate or partnership) that is uniquely
identified to HealthConnect for the purpose of accessing EHR
information on behalf of a consumer in accordance with
HealthConnect rules. Identified subclasses of consumer surrogate
include consumer agents, parents (for a child), persons with powers
of attorney over a consumer’s health care, guardians of the
incapacitated and any others recognised by the general law as having
the right to act on behalf of the consumer.
De-identified data
Data about a person or persons is termed ‘de-identified’ when the
identity of the individual person or persons to which the data refers is
not apparent, and cannot reasonably be ascertained from the data.
179
HealthConnect
Business Architecture v1.9
Deregister
The process by which a consumer or provider discontinues their
participation in HealthConnect. When a consumer deregisters, the
consumer’s record is retained but made unavailable for further access
by provider organisations and the consumer; information in the
record remains available for secondary use.
D-MIM or
DMIM
Domain Message Information Model (in HL7)
An information model that represents all the concepts needed to
support the communications requirements of a particular domain
(such as pharmacy, laboratory medicine or patient administration).
eHealth
Health care components delivered, enabled or supported through the
use of information and communications technology.
eHealth access
service
A facility to give healthcare providers effective means of accessing
HealthConnect services and any front line support needed to help
them in using HealthConnect.
eHealth message
bank service
A facility for conveying eHealth messages between healthcare
providers relating to any consumer (not only consumers registered
with HealthConnect).
EHR
Electronic Health Record
A longitudinal collection of personal health information about a
consumer, stored electronically. HealthConnect is Australia’s
implementation of a national EHR.
EHR Extract
The unit of communication of all or part of the EHR which is itself
attestable and which consists of one or more EHR compositions.
EHR List
A collection of similar EHR items describing a key aspect of a
consumer’s health, formed to serve a specific purpose. An EHR List
carries with it some notion of persistence, completeness, currency,
maintenance, ordering.
Examples include problem list and current medications.
EHR Notification
A type of message or ‘flag’ sent to communicate important
occurrences – usually specified in terms of a condition or set of
conditions that when satisfied, triggers a pre-defined response.
Examples might include hospital admission, emergency department
attendance and hospital discharge.
EHR Report
See report.
EHR Request
An input transaction component sent to the EHR repository
whenever users want to access data, and includes information such as
the identity of the requestor, type of request (e.g., EHR view or
request to enter/update data), the purpose of the request, and the
EHR query itself.
180
HealthConnect
Business Architecture v1.9
EHR System
Method for recording, retrieving, and manipulating information in
electronic health records.
EHR Transaction
An input or output from an EHR representing a single unit of activity
on the EHR repository as a result of a provider’s interaction with the
EHR.
EHR View
A pre-defined set of data items selected from the EHR and returned
in response to an EHR request.
Encryption
Transformation of data to an unintelligible form in such a way that
the original data either cannot be obtained (one-way encryption) or
cannot be obtained without using the inverse decryption process
(two-way encryption).
Enrolment
The process by which consumers, individual health providers and
health provider organisations become participants of HealthConnect.
Also see the preferred term: registration.
Emergency
override
The ability of personnel of a healthcare provider organisation to
access a consumer’s HealthConnect EHR in an emergency situation
where: (a) the consumer is unable to consent; (b) there is no one else
available to give consent; and (c) the provider organisation is not
already on the consumer’s access control list.
Event summary
Within HealthConnect, information about one or more healthcare
events, that is relevant to the ongoing care of a consumer and may be
a subset of the information about the consumer held by the provider.
The collection of health event summaries relating to a consumer
forms the basis of the consumer’s EHR within HealthConnect.
Proposed event summaries include some that contain information
currently found in a specialist referral, hospital discharge summary
or laboratory test report.
Extensible
Sufficiently flexible to allow future changes that were not previously
anticipated at the outset.
FEAF
Federal Enterprise Architecture Framework
The US Government’s FEAF was selected by the HealthConnect
Program Office to guide the development of the HealthConnect
architecture.
Federation
paradigm
The assumption that HealthConnect is to be implemented as a unity
of potentially different HealthConnect Records Systems operating to
common interface standards and supported by common services at a
national level.
Front end
See user interface.
181
HealthConnect
Business Architecture v1.9
Governance
The process of public accountability for the way in which an
organisation conducts its business and may involve stakeholder
representation and structures supporting responsibility,
accountability and reporting.
H2H
Health-to-Health
Health record
A repository of information regarding the health of a consumer. The
health record may be paper-based or held electronically. See EHR.
Healthcare
provider
See provider.
HealthConnect
governing body
An entity on behalf of all the participating governments and other
stakeholders with the overall management of the HealthConnect
program at the national level.
HeSA
Health eSignature Authority
An independent subsidiary of the Health Insurance Commission that
acts as a registration authority for the provision of digital keys and
certificates required for public key infrastructure used within the
Australian health care sector.
HL7
Health Level 7 Inc.
A global standards development organisation that specialises in
standards for information interchange between systems in the health
care sector.
HRS
HealthConnect Records System
A computer system for storage and management of consumers’ EHR
information and for controlling access to that information. The
HealthConnect EHR repository is the sum total of the EHR
information held by the HRS services.
HRS service
The operational function that manages and provides access to EHR
information in an HRS.
Identified data
Data are termed ‘identified’ when an individual’s identity is readily
apparent, or can reasonably be ascertained, from elements of the
record.
Identifier
A universal number or code that uniquely identifies a person or other
discrete entity.
IM&ICT
Information Management and Information and Communications
Technology
182
HealthConnect
Business Architecture v1.9
Individual
provider
Within HealthConnect, a registered health professional that is
registered with HealthConnect as an individual provider under the
HealthConnect rules. Individual providers include medical
practitioners, registered nurses, pharmacists and allied health
professionals involved in the delivery of health services to individual
consumers.
Initial health
profile
Summaries of a consumer’s previous health care (eg past medical
history, family history and key pathology results) that form the initial
entries in a consumer’s HealthConnect EHR.
Interoperability
Equivalent to ‘functional interoperability’;- The ability of
information systems to reliably exchange information without error.
Also see semantic interoperability.
ISO/IEC 11179
A specification that describes the standardising and registering of
data elements to make data understandable and sharable.
Metadata
Data about data. Metadata describes how and when and by whom a
particular set of data was collected, and how the data is formatted.
METeOR
METadata Online Registry
A knowledgebase of metadata items maintained by the Australian
Institute of Health and Welfare.
National data
store
A data storage and archiving service that aggregates EHR
information from across all HealthConnect HRS services.
National health
identifier
A universal number or code that uniquely identifies each person at a
national level.
NEHTA
National E-Health Transition Authority
Entity created to drive the national information management and
information and communications technology priorities to June 2005,
at which stage a longer term authority may be established.
National health
provider directory
A national repository of healthcare providers supporting several
health care initiatives, including HealthConnect. See also provider
directory.
NHDD
National Health Data Dictionary
Data definitions recommended for use in Australian health data
collections, as well as the National Minimum Data Sets agreed for
mandatory collection and reporting at a national level.
Non-repudiation
The capacity to obtain proof that cannot be forged and confirms the
integrity and origin of a data item.
183
HealthConnect
Business Architecture v1.9
openEHR
openEHR is an international not-for-profit foundation working
towards interoperable, life-long electronic health records, proven in
practice.
OWL
Web Ontology Language
A semantic web standard that provides a framework for the
management, integration and sharing and reuse of data on the web.
PIN
Personal Identification Number.
Provider
Within HealthConnect, a term encompassing individual providers
and provider organisations.
Provider directory Within HealthConnect, a database holding details of every provider
participating in HealthConnect, their HealthConnect identifier, and
contact information that enables the provider to be contacted by
various means including delivery or collection of eHealth messages.
Provider
organisation
Within HealthConnect, an organisation that is registered with
HealthConnect as a provider organisation under the HealthConnect
rules. A provider organisation may be any business entity (including
a sole trader in the case of an independent practitioner) that delivers
health services directly to individual consumers. A provider
organisation or other legal entity that provides health services may
include other provider organisations. For example, a corporation that
delivers health services may be registered as a provider organisation
and may comprise several regional hospital groups, each registered
with HealthConnect as a provider organisation, and each of these
may include hospitals and, below that, particular care teams, all
registered with HealthConnect as provider organisations. Within
HealthConnect, control of access to information within the
consumer’s EHR is by provider organisation.
Provider
registration
agency
An organisation authorised by the HealthConnect governing body to
register HealthConnect providers in accordance with the
HealthConnect rules.
Registration
The process by which consumers, individual health providers and
health provider organisations become a participants in
HealthConnect. Similar to enrolment.
Report
Data from one or more EHRs designed to serve the needs of
secondary users (such as clinical research or epidemiology
reporting).
Secondary Use
Any authorised use of a HealthConnect EHR other than for the
purpose of supporting the direct delivery of healthcare eg clinical
research, epidemiology, population health and health planning.
184
HealthConnect
Business Architecture v1.9
Semantic
interoperability
The ability for information shared between disparate information
systems to have the same context and meaning within each
information system in which the information is used.
Shared EHR
Those parts of a consumer’s health record that are made available to
(and therefore shared) as part of the consumer’s EHR.
Standard
A 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 interoperability between
information systems.
Trigger
An act that sets in motion some course of events.
User interface
The aspect of an information system that a person sees, and the way
in which the person interacts with the information system.
Value-added
services
Additional services, created due to a specific business need, that are
packaged with the core services.
VPN
Virtual Private Network
The concept of using the internet or other 'public' carriers as transit
for private network traffic, usually in encrypted form.
XML
eXtensible Markup Language
A language for organising and annotating data for interchange
between disparate information systems.
In moving from version 1.9 to version 2.0 of this Business Architecture, there will be
further amendments to this glossary, including changes arising from further checks
against relevant ISO and other standard vocabularies.
185