Interoperability Toolkit End of Life Care Additional Functional Module Requirements

balecomputerSecurity

Nov 3, 2013 (3 years and 9 months ago)

153 views


Interoperability Toolkit


End of Life Care
-

Additional Functional Module Requirements

Directorate

Tech Office

Document Record ID Key

Division

ITK

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX.XX

Chief Technology
Officer

Paul Jones

Status

Draft

Owner

Adam Hatherly

Version

0.3

Author

Adam Hatherly

Version Date

21

December 2012


© Crown Copyright
2013










Interoperability Toolkit

End of Life Care

Additional Functional Module Requirements





ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
2

of
21

Amendment History:

Version

Date

Amendment History

0
.1

11
/
1
2
/201
2

Draft

0.2

14/12/2012

Updated following internal review

0.3

21
/12/2012

Updated following internal review














Reviewers:

This document must be reviewed by the following:

Name

Title / Responsibility


Date

Adam Hatherly

Technical Architect


Damian Murphy

Technical

Architect


Mike Odling
-
Smee

Technical Architect


George Hope

Technical Architect



Approvals:

This document must be approved by the following:

Name

Title / Responsibility

Date

Keith Naylor

Head of Data Standards Implementation and Outreach
Group












Distribution:

ITK Community





ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
3

of
21

Document Status:

This is a controlled document.

Whilst this document may be printed, the electronic version maintained in FileCM is
the controlled copy. Any printed copies of the document are not controlled.


Related Documents:

These documents will provide additional information.

Ref
no

Doc Reference Number

Title

Version

1

NPFIT
-
ELIBR
-
AREL
-
DST
-
0422

ITK

Specifications Overview

Latest

2

NPFIT
-
ELIBR
-
AREL
-
DST
-
0433

ITK Messaging Architecture
Requirements

Latest

3

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX

Document Retrieval
-

Additional
Functional Module Requirements

Latest

4

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX

Notifications

-

Additional Functional
Module Requirements

Latest

5

NPFIT
-
ELIBR
-
AREL
-
DST
-
0439

DTS Transport Specification

Latest

6

NPFIT
-
ELIBR
-
AREL
-
DST
-
0430

ITK Web Services Transport
Specification

Latest

7

http://www.endoflifecareforadults.nhs.uk/strategy/
strategy/coordination
-
of
-
care/end
-
of
-
life
-
care
-
information
-
standard

ISB1580


National Information
Standard for End of Life Care Co
-
Ordination

Latest

8

http://tinyurl.com/qipp

QIPP Digital Technology Website

Latest

9

NPFIT
-
ELIBR
-
AREL
-
P1R2
-
0178

Technical Guidance for Templated CDA
Domains

Latest

10

NPFIT
-
ELIBR
-
DST
-
0367

IG Control Implementation Patterns

Latest

11

NPFIT
-
ELIBR
-
AREL
-
DST
-
0361

Trust
Operating Model


Overview

Latest

12

http://www.endoflifecareforadults.nhs.uk/
publications/record
-
keeping
-
guidance

End of life care co
-
ordination record
keeping

guidance

March
2012

13

http://www.endoflifecareforadults.nhs.uk/
publications/implementation
-
guidance

End of life care co
-
ordination
i
mplementation guidance

March
2012

14

http://www.endoflifecareforadults.nhs.uk/
publications/record
-
keeping
-
summary

Summary of end of life care co
-
ordination record keeping guidance

Marc
h
2012



Glossary of Terms:

Please see ITK 2.0 Specifications Overview (See Related Document 1) for a consolidated
glossary of terms used in the ITK documents


Other terms acronyms and abbreviations commonly used with NHS CFH can be found in the
Acronyms Guide
http://www.connectingforhealth.nhs.uk/about/acronyms





ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
4

of
21

Contents

1

Introduction

................................
................................
................................
..........

5

1.1

Document Purpose

................................
................................
........................

5

1.2

Audience

................................
................................
................................
.......

5

1.3

Document Scope

................................
................................
...........................

5

1.4

Document Overview

................................
................................
......................

6

2

Module: End of Life Care

................................
................................
.....................

7

2.
1

Introduction

................................
................................
................................
....

7

2.2

End of Life Care Sender Requirements

................................
.........................

8

2.3

End of Life Care Receiver Requirements

................................
....................

10

2.4

Receiver System Functional Guidance

................................
........................

11

2.5

Error Scenarios

................................
................................
...........................

12

3

Example Use
-
Cases

................................
................................
..........................

13

3.1

Share End of Life Care Document On
-
Request

................................
..........

14

3.2

Broadcast End of Life Care Document

................................
........................

15

3.3

Populate New Record into EPaCCS
................................
............................

16

3.4

Return Updated End of Life Care Document

................................
...............

17

4

Appendix A

ISB1580 Data Set to End of Life Care Document Mapping

..........

19





ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
5

of
21


1

Introduction

1.1

Document Purpose

This document defines additional functionality which
is

required to gain ITK
accreditation for
sending and receiving of
end of life care information and
preferences
. It provides a mechanism for
the
QIPP Digital Technology team

to define
specifications to support
end of life
care co
-
ordination,
to define specialisations or
additional functional requirements over and above the baseline ITK interface
specifications.

1.2

Audience

The primary audience are technical and product developme
nt staff within software
suppliers who are interested in developing a Toolkit Implementation offering.

A further intended audience are technical staff within an implementing organisation
-

who wish to understand the selection criteria for procuring a
n ITK
compliant solution
.

1.3

Document
Scope

This document is part of a set of technical specifications relating to
implementing ITK
specifications
. See the Toolkit Specifications Overview
(related document 1)

for more
about other documents in the set.


Messaging Architecture
Supporting Infrastructure
Additional Modules
Web Services
Service Interfaces
Distribution Infrastructure
Transport Patterns and Features
Common
Application
Specific
Middleware
Specific
DTS
(Other
Transport)
Transports
Addressing and
Routing
Other Core
Features
Other Core
Features



ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
6

of
21

1.4

Do
cument Overview

The rest of this document covers a number of functional add
-
on modules. Within
each module a number of requirements are listed in bold type, with additional detail
provided in smaller type below this.

MOD
-
xxx
-
xxx: Formal requirements statem
ents are highlighted in bold boxes

The accompanying text provides supporting detail, background and rationale

Source:
Where a requirement originated from an external source, that will be listed here [
Re
lated document

X
]







ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
7

of
21

2

Module:
End of Life Care

2.1

Introduction

The majority of people, given the right care and support, would prefer to die at home,
yet only around 20% of people die at home, with a further 17% dying in a care home.
The Healthcare Commission estimates that half of all acute hospital comp
laints are
related to end of life care.

For people nearing the end of life, the National End of Life Care Programme
(NEoLCP) and QIPP End of Life Care National Workstream aim to reduce:



Emergency attendances to hospital



Subsequent bed days



Unwanted treatme
nts



Complaints relating to end of life care

A key enabler for the above goals is capturing and sharing a patient’s end of life care
preferences. To help achieve this the NEoLCP

is supporting nationwide
implementation of local Electronic Palliative Care Co
-
ordination Systems (EPaCCS)
following successful piloting of end of life care ‘locality registers’ in eight sites across
England during 2009/11.

One of the issues with many of
the current EPaCCS deployments is that the core
information within these systems cannot easily be shared electronically with users of
other systems in other care settings. The ITK end of life care specification aims to
address this by providing a nationall
y defined standard for exchanging core end of
life care information and preferences between IT systems. The clinical content of the
message is defined as a HL7 CDA document, and is based on the agreed national
information standard for electronic palliative

care co
-
ordination (ISB1580


see
related document 7).

The
End of Life Care

Domain Message Specification provides a set of messages that
can be delivered over a range of transport mechanisms.

The message specification
also provides details on how the mess
ages must be constructed using a set of
supplied schemas and the individual messages wrapped with the standard ITK
distribution envelope before submission to the Message Handling System and
Transport
.

Additional guidance on the wider information sharing pa
tterns for EPaCCS
is being
drafted by the QIPP Digital Technology team, and this will help local teams to identify
solutions using ITK that can address the needs of their local IT and organisational
landscape. At the time of writing, this guidance is not y
et complete, but will be made
available on the QIPP Digital Technology website (see related document 8). Other
specific guidance including on information governance for EPaCCS will also be made
available here.




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
8

of
21

2.2

End of Life Care Sender
Requirements

Some of
the requirements outlined in this document originate from the published ISB
standard, and others have been defined during workshops and WebEx sessions
facilitated by the QIPP Digital Technology team. Where a requirement is derived from
a document forming p
art of the ISB1580 standard, the relevant original document is
referenced accordingly.

Many of the sections within the document allow an author and date to be recorded
against the section


indicating when that section was last updated and by whom.
This is

in addition to the overall document author,
who is the
individual who last
reviewed and attested the accuracy of the document in its entirety (likely to be at the
last multi
-
disciplinary team meeting).

EOL
-
S
ND
-
01
:
An author MUST be populated for updated s
ections

if different to
document author

Where a section within the document has been updated, and the section allows for an author to be
specified, the author of that section MUST be populated. If the author of the section is the same as the
overall
document author, this MAY be omitted.

NOTE: A similar approach can also be used for text sections


see “
Representation of author
inheritance within text sections
” within the
“Technical Guidance for Templated CDA Domains”
document for further information a
bout this (related document 9).


Local EPaCCS may hold information using different clinical coding schemes, but
information that is shared should use the nationally defined vocabularies:

EOL
-
SND
-
02
:
Mappings for coded items MUST be clinically validated.

Any mapping
to or
from a locally held code to the published SNOMED CT or Data Dictionary codes (or
any other published codes) for any field
in the ITK message

MUST be clinically validated.


Appropriate governance controls should be in place:

EOL
-
SND
-
0
3
:
The patient SHOULD be able to prevent specific parts of their
record
being shared.

The solution SHOULD include a mechanism to allow a patient to request that certain information
within a record is not shared in
messages sent to other systems.

NOTE: This
is a simple form of “sealed envelope”


further details and potential approaches for this
are outlined in the ITK Trust Operating Model


specifically in the Sealed Enveloped section of the “IG
Control Implementation Patterns” document (related document 10
).

Source:
Record Keeping Guidance


S
ection 6.9
, Consent [
Related Document 12
]






ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
9

of
21

EOL
-
SND
-
0
4
:
Information MUST not be shared without consen
t

It MUST NOT be possible to send a document unless the
re is a mandate to share information


ei瑨敲e
瑨牯畧栠
數plici琠t潮s敮琬r 瑨牯畧栠h 扥st
-
in瑥牥t瑳⁤ cisi潮慤攠e渠ne桡lf ⁡ 灡瑩敮琮⁔桥⁰牥 is攠
cri瑥物愠a潲⁴ois慮摡瑥tm畳琠t攠es⁤敦i湥d⁢y⁴ 攠ea瑩潮al⁥ 搠dfif攠e慲攠灲潧aamm攠e湤⁲慴afie搠
瑨牯畧栠h潣慬 䥇⁲敱uir敭敮瑳.

NOTE: The “DCR Consent to Sh
are” requirements within the “IG Control Implementation Patterns”
摯c畭敮琠⡲敬慴a搠d潣畭e湴n㄰F 慲攠a潴oa灰lic慢l攠瑯t瑨ts⁳桡ri湧⁳c敮慲楯I⁡ ⁴ 攠e慴io湡l⁥ 搠dfif攠
c慲攠灲潧a慭m攠e慶攠摥termi湥搠dh慴at桥⁳桡ri湧 ⁥湤 if攠e慲攠灲敦敲敮e敳⁩s⁳畢
j散琠瑯⁳灥cific
c潮s敮琠i渠n摤i瑩潮⁴漠o敮er慬⁲散潲搠oh慲楮g⁰牥 敲敮c敳.

Source:
Record Keeping Guidance


S
ection 6.9
, Consent [
Related Document 12
]


In addition, the usual IG and clinical safety requirements apply as they do for any
clinical system


including the requirement for a
clinical safety assessment to ensure
the sharing of information is clinically safe
.

See the Trust Operating Model for further
guidance (related document 11).


Versioning

Each change to the content of the end of life care do
cument should result in a new
CDA document version within a CDA “document set”. The “Parent Document” class
within the message will relate each version with the previous version in the set. This
aligns with existing requirements used in all ITK CDA domains

-

see the “NHS CFH
CDA Update Semantics” section within the “Technical Guidance for Templated CDA
Domains” document for further information about this (related document 9).




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
10

of
21

2.3

End of Life Care Receiver Requirements

All messages should be acknowledged at a
system level by the receiving system:

EOL
-
REC
-
01
:
Documents MUST be acknowledged by receiving system

Whe
n an end of life care document is received in a system, an ITK
Infrastructure Acknowledgement
MUST be returned automatically to the sending system.

This does not require that the document has
been processed or acted upon


simply that it was received by the system.


EOL
-
R
EC
-
0
2
:
Section authors MUST inherit when not specified

Where a section within the document allows for an author to be specified, and no author has been
specified
for that section
, the overall document author MUST be displayed as the author of th
e

section.

NOTE: A similar approach can also be used for text sect
ions


see “
Representation of author
inheritance within text sections
” within the
“Technical Guidance for Templated CDA Domains”
document for further information about this (related document 9).


EOL
-
REC
-
03
:
A version and date MUST be prominently displaye
d

When a received document is displayed, either on
-
screen or in a print
-
out, the version number and
date
the document was last updated
MUST be prominently displayed to the user


Appropriate
information
governance controls should be in place, as described

in the
ISB Implementation guidance (related document 13).

This includes

(but is not limited to)
:



C
ontrols to ensure that the system only allows users to access the records for
patients under their care (i.e. those with whom they have a legitimate
relation
ship).



Role base access controls
to ensure that the rights to view, create, edit or
delete specified clinical content elements are limited to appropriate clinicians
as defined by local clinical governance and IT safety leads.



Audit


all actions should be
auditable to support investigations into misuse.



Permission to view controls


The ISB documentation recommends
professionals
should

seek consent each time the record is viewed

(see
Section 2.2, Requirement 6 in the ISB Specification


related document 7)
.

Further Guidance on these and other IG controls are available in the Trust Operating
Model


specifically in the
“IG Control Implementation Patterns” document (related
document 10)
.

More specific IG guidance for EPaCCS will be developed and published on t
he QIPP
Digital website (related document 8).






ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
11

of
21

2.4

Receiver System Functional Guidance

In addition to the specific interoperability requirements outlined above, the ISB
specification includes a number of statements about how receivers of End of Life
Care info
rmation should use the information. This was also built
-
upon during
workshops held to discuss these interoperability specifications, which involved both
NHS and supplier stakeholders.

Whilst these are not specifically ITK requirements, and they will not be

assessed or
accredited by the ITK team, they are still important to consider in local
implementations using this
document
.

EOL
-
FNC
-
0
1
:
It MUST be possible to print a copy of the document

The solution MUST allow a copy of a patient's EPaCCS record
(document) to be printed.

Source:
ISB Specification


S
ection
2
.
2, Requirement 1 [
Related Document 7
]


EOL
-
FNC
-
02
:
Doc content COULD be combined with other content for display

A document that is received COULD be rendered to a user in a way that is
appropriate for the type of
user, care setting, and user interface conventions of the system. It could also be combined with
additional information stored in the local system relating to that patient

(or relevant reference
information). Any such views
MUST

have been locally assured as clinically safe.


If a system retrieves a document from an EPaCCS, it may conceivably wish to send
back an updated version incorporating some changes. This is potentially a technically
complex use
-
case, and it is described in

more detail later in this document.

EOL
-
FNC
-
03
:
Controls MUST be in place when incorporating data into a record

Individual coded items from a received document MUST not be incorporated directly into a local
patient record without rigorous controls
(likely to involve manual checks). These controls MUST have
been locally assured as clinically safe.


The above apply to any system
exchanging
the End of Life Care Document. For
EPaCCS specifically, there is a much more comprehensive set of recommended
system requirements being produced by the QIPP Digital technology team, and this
will be available from the QIPP Digital Website (related document 8).




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
12

of
21

2.5

Error Scenarios

The below table summarises some of the possible error scenarios relating to the
sending
and receiving of End of Life Care Document, with some guidance on how
each should be handled:

Error
Type

Potential Error
Scenario

Recommended Action

Technical
Failure
1



System error at
recipient



Malformed or Invalid
request



Recipient system
does not unders
tand
message type

Error handling will be specific to transport
and interaction pattern
.

For Web Services, this
could
be a HTTP error or a SOAP Fault


see the Web Services Transport Specifications (related document
6).

For DTS see the DTS Transport Specifi
cation

(related document 5
).

In some cases, where the message can be processed and a
meaningful error can be sensibly generated providing more
information, an ITK Infrastructure NACK may be used.

Connection drop/timeout

Sender system to handle, and may
retry.

See requirement “COR
-
REL
-
02” within the messaging architecture
requirements (related document 2)

Validation

Recipient does not
recognise the End of Life
Care document profile (but
does support CDA
generally)

The recipient can either:



Use a
transport
-
specific mechanism (as described above)
to return an error stating that the document profile is not
recognised



Use standard CDA rendering rules to render the document
to a user (see the “Technical Guidance for Implementation
of Templated CDA Doma
ins” document


related
document 9


for an example CDA rendering template.

Business
Process
Issues

Document sent to wrong
recipient

The recipient can either:



Use a Business Acknowledgement with a
DetectedIssueEvent to return an error stating that the
rec
ipient was wrong.



Handle manually and don’t return an
error.
The r
ecipient
would then
handle accordingly


preferably by contacting
the sender to inform them of the error so they can update
their local directory/address book.

Patient not known in
recipient system (where
recipient is NOT an
EPaCCS system)

NOTE: Applicable to use
case outlined in section
3.2 below)

No error returned. Recipient to handle accordingly


options could
be:



Create new skeleton record for patient automatically and
import/at
tach information from message



Store document for human checking/matching



Store document in a queue for matching against future
patient registrations (i.e. trigger appropriate behaviour
when patient is registered).

Patient record already
exists in
recipient system
(where recipient IS an
EPaCCS system that
cannot accept updated
versions)

NOTE: Applicable to use
case outlined in section
3.3 below)

Use a Business Acknowledgement with a DetectedIssueEvent to
return an error stating that and EPaCCS recor
d already exists for
this patient, and the EPaCCS cannot accept document updates for
existing records.




1

Note: In a multi
-
hop scenario, errors passed back via intermediary middleware will be transformed
into an ITK Infrastructure NACK.




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
13

of
21

3

Example Use
-
Cases

This section outlines some examples of how the End of Life Care message could be
used to support a range of potential integration sce
narios (referred to here as use
-
cases). These are intended to be illustrative only, and are not formal requirements for
how the messages mentioned should be used.

These use
-
cases all assume that there is an agreed “EPaCCS” for within a locality,
which is w
here all end of life care preferences in that locality are held. This may be a
single system, or may in reality be spread across multiple systems (for example in
the case where GP systems are acting as
an
EPaCCS).

With all the below use
-
cases there are two

variations to consider:



Variation 1: The EPaCCS could generate the End of Life Care Document
whenever the core information changes, and stored in a repository. Any
requests for this document could then be served directly from that repository.



Variation 2: The EPaCCS could generate the End of Life Care Document
whenever another system requests it. If someone requested an old version of
a document, the system would ideally also need to be able to generate that
historical version on
-
demand (see
DO
C
-
REQ
-
03

in the “Document Retrieval
Additional Functional Module Requirements
” document


related document 3
).

For simplicity, the below all assume that the
End of Life Care

document is generated
on request, but the same use
-
cases would apply if a document

repository was used
to store EPaCCS documents.

The examples all show the recipient system as a clinical system, but the use of these
interactions could also be considered for other types of system, including systems
used in social care and 3
rd

sector orga
nisations.
It would also be possible for
a
patient portal
to

make use of these interactions to provide patients with direct access
to their core end of life care information held in the EPaCCS.




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
14

of
21

3.1

Share
End of Life Care Document
On
-
Request

The EPaCCS will ho
ld the end of life care information and preferences for patients
within a locality. Whenever records are created, updated, or removed, some form of
notification
(see related document
4
)
will generally be sent to other systems used by
services providing car
e to patients in the locality. The identifier passed in this
notification can then be used by a recipient system to issue an electronic document
retrieval request
(see related document 3
)
for the document to the EPaCCS. The
EPaCCS would then return
the
cor
e content in an
End of Life Care
document
described in this document and associated
Domain Message Specification
.

The below sequence diagram shows how these interactions could look:


EPaCCS System
Cl i ni cal System
Cl i ni ci an 1
Cl i ni ci an 2
Update()
Noti fi cati on()
Infrastructure Acknowl edgement()
Request to Vi ew()
Document Retri eval Request(DocSetID)
End Of Li fe Care Document()
Di spl ay Document()



ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
15

of
21

3.2

Broadcast End of Life Care Document

In some cases, there may be recipie
nts of End Of Life Care documents who always
want to be sent the latest document whenever it changes. Whilst the above scenario
could be used for this (i.e. the recipient system could automatically request the
document whenever a notification is received),

it is also possible that the EPaCCS
could broadcast the document to that recipient whenever the document changes.

Note: The “broadcast” here refers to the nature of the business interaction, and does
not imply that an ITK broadcast
service

would be used (
the
SendCDADocument

service would be used in this case


see core ITK requirements for details).

The below sequence diagram shows how these interactions could look:



Cl i ni ci an 1
EPaCCS System
Cl i ni cal System
Cl i ni ci an 2
Update()
End of Li fe Care Document()
Infrastructure Acknowl edgement()
Request to Vi ew()
Di spl ay Document()



ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
16

of
21

3.3

Populate New Record into EPaCCS

An EPaCCS record contains a certain amount of basic patient information such as
demographics, and details of others involved in care. Much of this information may
already be held in existing clinical systems, and a clinician who wants to create a
new EPaCC
S record currently has to re
-
key this information into the EPaCCS, and
then add the relevant end of life care preference information. The End of Life Care
message could be used in this scenario to send the basic patient information (and
any end of life car
e preferences already held in the clinical system) to the EPaCCS to
allow a new record to be created with this information pre
-
populated. The clinician
might then access the EPaCCS system to add any additional information that was
not transferred over from

their own system.

The below sequence diagram shows how these interactions could look:



Cl i ni ci an 1
Cl i ni cal System
EPaCCS System
Request addi ti on to EPaCCS()
End of Li fe Care Document()
New record
created()
Infrastructure Acknowl edgement()
Add addi ti onal i nformati on di rectl y (i f requi red)
«OPTIONAL»



ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
17

of
21

3.4

Return Updated
End of Life Care Document

Once a system has retrieved an End of Life Care document as outlined in the
previous use
-
cases, technically it could then in
corporate the information into a local
patient record. Once this was done, there may be a requirement to send any
changes to that information back to the EPaCCS to ensure it is kept up to date.

The existing messaging could potentially be used to send an up
dated version of the
End of Life Care document back to the EPaCCS:


Such a solution would need to take into consideration a range of potential issues
however. One major consideration for such a solution would be managing conflicting
updates. A
n example of

this is shown in the below sequence diagram:


Such conflicts are more likely to occur when copies of the information are kept locally
for a longer period of time


for example in a mobile working scenario where a copy
is taken and worked on offline, befo
re being updated back with the EPaCCS once the
Cl i ni ci an 1
Cl i ni cal System
EPaCCS System
Document Retri eval Request(DocSetID)
End Of Li fe Care Document()
Di spl ay EOL Preferences()
Update EOL Preferences()
End of Li fe Care Document()
«Versi on 2»
Update EPaCCS Record()
Cl i ni ci an 1
Cl i ni cal System
Cl i ni cal System 2
EPaCCS System
Cl i ni ci an 2
This updated document conflicts
with the previous one received
from clinical system 2
Doc Retri eval Req(DocSetID)
End Of Li fe Care Document()
Doc Retri eval Req(DocSetID)
End of Li fe Care Document()
Di spl ay EOL Prefs()
Update EOL Prefs()
End of Li fe Care Document()
«Versi on 2»
Update EPaCCS
Record()
Di spl ay EOL Prefs()
Update EOL Prefs()
End of Li fe Care Document()
«Versi on 2»



ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
18

of
21

user is back on a network. Even without mobile working scenarios however, as soon
as other systems are able to contribute updates this scenario would have to be
planned for and handled within systems. Any conf
licts such as these are likely to
require a human to review and “merge” the information (similar to the side
-
by
-
side
view used by systems accessing PDS).




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
19

of
21

4

Appendix A

ISB1580
Data Set to End of Life

Care

Document
Mapping

ISB 1580 Da
taset Items

CDA Representation [Class: attribute cardinality]

Comments

Rendered

1. Record Creation Date

EoLCarePlan
/effective time


Yes

2. Planned Review Date

EoLCarePlan//PlannedReviewDate: value 1..1


Yes

3. Date and time of Last Amendment

EoLCarePlan
: Author1: time 1..1


Yes

4. Person Family Name

RecordTarget///Patient: name 1..*

CDA model separates Family and Forename

Yes

5. Person Forename

RecordTarget///Patient: name 1..*

CDA model separates Family and Forename

Yes

6. Person Preferred Name

RecordTarget///Patient: name 1..* (SET
-

PREFERRED)


No

7. Person Birth Date

RecordTarget///Patient:birthtime 1..1


Yes

8. NHS Number

RecordTarget///PatientRole: id 1..*


Yes

8a NHS Number status

RecordTarget///PatientRole: id 1..* (OIDs for
Verified/Unverified)


N/A

9. Person Gender

Patient: administrativeGenderCode 1..1


Yes

10. Need for an Interpreter

RecordTarget///LanguageCommunication: proficiencyLevelCode 0..1


Yes

11. Preferred Spoken Language

RecordTarget///LanguageCommunication:
languageCode 0..1


Yes

12. Disability

TextSection/Section(n): text 0..1


Yes

13. Person Address

RecordTarget///PatientRole: addr 0..4

i.e. 4 lines of address

Yes

14. Person Telephone Numbers (Home
and Mobile)

RecordTarget///PatientRole: telecom 0..*


Home only shown

15. Main Informal Carer Name

EoLCarePlan:PatientRelationships///Person: name 1..1


Yes

16. Main Informal Carer Telephone
Numbers

EoLCarePlan: PatientRelationships///ParticipantRole: telecom 0..*


One only shown

17. Is Main Informal Carer

Aware of
Person’s Prognosis?

ProgosisAwareness/value 1..1 (Snomed Code)

Does this link back to the PatientRelationships for
main informal carer?

TP 16/11/12 "The subject is repeated i.e. main
informal carer is repeated with in XML to carry
prognosis aware
ness code."

Yes

18. Usual GP Name

EoLCarePlan:PatientRelationships///Person: name 1..1


Yes

18a. GP's ODS Code

EoLCarePlan:PatientRelationships///ParticipantRole: id 1..1


Not shown

19. Practice Details Including Phone and
Fax Numbers

EoLCarePlan
:PatientRelationships///ParticipantRole: telecom 0..*


No fax shown

20. Key Worker Name if Not Usual GP

EoLCarePlan:PatientRelationships///Person: name 1..1


Yes

21. Key Worker Telephone Number

EoLCarePlan:PatientRelationships///ParticipantRole: telecom
0..*


Yes

22. Formal Carers Involved in Care: Name

EoLCarePlan:PatientRelationships///Person: name 1..1


Yes




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
20

of
21

23. Formal Carers Involved in Care:
Professional Group

Qualifier of code attribute within participant role class (jobrolename)

TP 16/11/12
-

"professional group is not yet
covered in the COCD_TP145226GB01 template"

Yes

24. Telephone Numbers for Formal Carers
Involved in Care

EoLCarePlan:PatientRelationships///ParticipantRole: telecom 0..*


Yes

25. Primary End of Life Care Diagnosis

TextSection/Section(n): text 0..1

To be coded entry in later iterations

Yes

26. Other Relevant End of Life Care
Diagnoses and Clinical Problems

TextSection/Section(n): text 0..1

To be coded entry in later iterations

Yes

27. Allergies/Adverse Drug Reactio
ns

TextSection/Section(n): text 0..1

To be coded entry in later iterations

Yes

28. Anticipatory Medicines/Just in Case
Box Issued

AnticipatoryMedicineBoxIssueProcedure: code 1..1


Yes

29. Location of Anticipatory Medicines/Just
In Case Box

AMBoxLocation:

value 1..1


Yes

30. EoLC tool in Use? (e.g. GSF, LCP (or
other ICP), PPC, other)

EoLToolUsed: value 1..1


Yes

30a. End of life Pathway stage

EoLCurrentStage: value 1..1


Yes

31. Advance Statement Requests and
Preferences

TextSection/Section(n): text
0..1


Yes

32. Preferred Place of Death 1st Choice

TextSection/Section(n): text 0..1

To be coded entry in later iterations

Yes

33. Preferred Place of Death 2
nd

Choice

TextSection/Section(n): text 0..1

To be coded entry in later iterations

Yes

34.
DNACPR Decision Made

DNACPRbySRClinician: value 1..1


Yes

34a. Resuscitation status unknown by
patient

ResuscitationStatus: value 1..1


No

35. Date of DNACPR Decision

DNACPRbySRClinician: effectiveTime 1..1


Yes

36. Date for review of DNACPR decision

ReviewDateDNACPR: value 1..1


Yes

37. Location of DNACPR Documentation

DNACPRDocsLocation: value 1..1


Yes

38. Person has made an Advance
Decision to Refuse Treatment

PatientADRT: value 1..1


Yes

38a ADRT discussed with clinical
professional

ADRTDiscussed: value 1..1


Yes

39. Location of Advance Decision to
Refuse Treatment Documentation

ADRTDocsLocation: value 1..1


Yes

40. Name of Lasting Power of Attorney for
Personal Welfare

AuthorityToLPA///Person: name 1..1


Yes

41. Authority of LPA

AuthorityToLPA: value 1..1


Yes

42. Telephone Number(s) Concerning
Lasting Power of Attorney

AuthorityToLPA///ParticipantRole: telecom 1..1


Yes

43. Name of Additional Person to be
Involved in Decisions (1)

EoLCarePlan:PatientRelationships///Person:
name 1..1


Yes

44. Telephone Number of Person (1) to be
Involved in Decisions

EoLCarePlan:PatientRelationships///ParticipantRole: telecom 0..*


Yes




ITK


End of Life Care
-

Additional Functional Module Requirements

NPFIT
-
ELIBR
-
AREL
-
DST
-
XXXX
.
XX



Draft / 0.3

/
2
1
st

December 2012

© Crown Copyright
2013


Page
21

of
21

45. Name of additional person to be
involved in decisions (2)

EoLCarePlan:PatientRelationships///Person:
name 1..1


NA

46. Telephone Number of Person (2) to be
Involved in Decisions

EoLCarePlan:PatientRelationships///ParticipantRole: telecom 0..*


NA

47. Other Relevant Issues or Preferences
about Provision of Care

TextSection/Section(n): text 0..1


Yes