gp systems interface requirements v1 - draft11
Post on 28-Apr-2015
71 Views
Preview:
DESCRIPTION
TRANSCRIPT
GP Systems Interface Requirements V1
Programme GPSoC DOCUMENT RECORD ID KEY
HSCIC-FNT-TO-TAR-0110.01 Sub-Prog /Project Technology Office
Prog. Director Kemi Adenubi Version 11
Sub Prog/Proj Mgr Mike Curtis Date 16 February 2013
Author Tim Tett / Danny
Solomon
Status Draft FOR COMMENT
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 1 of 22
GP Systems Interface Requirements V1
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 2 of 22
© Crown Copyright 2013
Amendment History
Version Date Amendment History
draft 08 29 Jan 13 Amendments prior to release for comment to supplier community.
draft09 1 Feb 13 Added section being explicit about the need to support internet-facing
patient services.
draft10 6 Feb 13 Updates following comments from Kemi Adenubi
draft11 16 Feb 13 Clean version, updated diagrams, for distribution to supplier
community for input and comment
Reviewers:
This document must be reviewed by the following (delegated as necessary).
Name Title / Responsibility Date Version
Tim Tett GPSoC Technical Architect
Brendan McEnroe GPSoC Technical Architect
Approvals:
This document requires the following approvals:
Name Title / Responsibility Date Version
Mike Curtis Lead Technical Architect for GPSoC
Kemi Adenubi GPSoC Programme Director
Distribution:
Reviewers and approvers plus GP System Supplier community.
Document Status:
This is a controlled document. This document is valid from: 16 February 2013
On receipt of a new issue, please destroy all previous issues (unless a specified earlier issue is base-
lined for use throughout the programme).
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 3 of 22
© Crown Copyright 2013
Glossary of Terms:
Term Acronym Definition
NRD NRD National RBAC Database – a source of nationally defined roles and activities for system users.
PDS PDS Personal Demographics Service – a national application providing patient demographic data services
Principal clinical system
Integrated system providing majority of clinical IT services within practices.
Subsidiary module
Functionality that can be provided by an independent supplier, that integrates with principal clinical system via Interface Mechanism. Can also be provided as part of an integrated principal clinical system.
RBAC RBAC Role Based Access Control
UKTC UKTC United Kingdom Terminology Centre – responsible for the provision of clinical coding terminologies for use in Healthcare Systems including READ version 2, Clinical Terms Version 3 (CTV3) and SNOMED CT UK edition.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 4 of 22
© Crown Copyright 2013
Contents
1 Introduction .................................................................................................................................... 5
1.1 Audience ................................................................................................................................. 5
1.2 Document Scope ..................................................................................................................... 5
1.3 Document Overview ............................................................................................................... 6
1.4 Definitions ............................................................................................................................... 7
2 Background ..................................................................................................................................... 8
3 Requirements Overview ................................................................................................................. 9
4 System Requirements applicable to both Principal Clinical Systems and Subsidiary Modules .... 10
4.1 Audit ...................................................................................................................................... 10
4.2 Provenance ........................................................................................................................... 11
4.3 System Authentication .......................................................................................................... 11
4.4 System Context ..................................................................................................................... 11
4.5 Appropriate use of integration capability ............................................................................. 12
4.6 System Invocation ................................................................................................................. 13
4.7 Interface Management ......................................................................................................... 13
4.8 Error & failure handling ........................................................................................................ 14
4.9 Practice Population Data ...................................................................................................... 14
5 Principal GP System Requirements ............................................................................................... 16
5.1 User and other non-Patient Data .......................................................................................... 16
5.2 Patient Demographics ........................................................................................................... 17
5.3 Individual Patient Clinical Data ............................................................................................. 18
5.4 Supporting Patient Services .................................................................................................. 20
6 Subsidiary Module System Requirements .................................................................................... 21
6.1 User Authentication & Access Controls ................................................................................ 21
6.2 User Synchronisation ............................................................................................................ 21
6.3 Patient Demographic Data .................................................................................................... 22
6.4 Individual Patient Clinical Data ............................................................................................. 22
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 5 of 22
© Crown Copyright 2013
1 Introduction
This document defines the interface requirements for GP systems. It defines the functional aspects
of interface mechanisms that are required in order to support the integration between Principal
Clinical Systems and Subsidiary systems, in order to deliver functionality to users within General
Practice.
Suppliers should be aware that there are commercial aspects to the provision and use of such
interface mechanisms, that are provided separately.
This document is DRAFT and is currently provided to the
supplier community for their comment.
1.1 Audience
The primary audience for this document is:
Principal GP Clinical System suppliers
Suppliers of Subsidiary Modules
GP Practices and other organisations involved in the purchase of GP Clinical IT Systems may also be
interested in the contents of this document.
1.2 Document Scope
The scope of this document is to define a generic set of interface requirements, from a functional
rather than a technical perspective. It includes a number of performance requirements to ensure
that such capabilities are sufficient to meet business requirements.
There are many different kinds of subsidiary modules that may take advantage of interface
mechanisms exposed by Principal Clinical Systems. The functionality delivered by those modules,
and the degree to which they store personal data outside of the Principal Clinical System, will
determine the degree to which they are required to expose interface mechanisms themselves.
Specifically: a subsidiary module will not be required to expose an interface mechanism to these
requirements unless (i) it stores personal data or (ii) there is a functional need for other subsidiary
modules to integrate, in which case this will be specified in that subsidiary module’s requirements.
Therefore, it is not expected that every system that integrates with a Principal Clinical System has to
expose an interface mechanism to these requirements. However, every Principal GP Clinical System
must meet all of the applicable interface requirements in this document.
This document covers “Phase One” of the Interface Mechanism arrangements, where suppliers are
free to define the technical form of the interface mechanism. In parallel with the delivery of these
requirements, “Phase Two” will proceed to the definition and implementation of a common
interface, and technical satisfaction of that interface, across all principal clinical systems.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 6 of 22
© Crown Copyright 2013
1.3 Document Overview
The requirements are separated into three sections:
requirements that apply to both Principal clinical systems and to Subsidiary Modules
requirements that apply to Principal clinical systems only and
requirements that apply to Subsidiary Modules only.
Suppliers of Principal GP systems will be able to utilise the functionality provided by systems
providing Subsidiary Modules and thus will have an interest in those requirements. Suppliers of
Subsidiary Modules will be able to utilise the functionality provided by Principal GP systems and thus
will have an interest in those requirements.
The relationship between principal clinical systems, subsidiary modules and the interface mechanism
is illustrated in the following diagram:
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 7 of 22
© Crown Copyright 2013
1.4 Definitions
The term “interface mechanism” means any mechanism by which any two systems (for example, a
Principal GP system and a system delivering Subsidiary Module requirements) exchange data or
otherwise integrate between themselves. It does not imply any particular technology and suppliers
are free to adopt whatever technical method(s) they wish providing that the requirements are met.
Where used in this document set, the keywords MUST, SHOULD and MAY are to be interpreted as
follows:
MUST: This word, or the terms "REQUIRED" or "SHALL", means that the definition is an
absolute` requirement of the specification.
SHOULD: This word, or the adjective "RECOMMENDED", means that there may exist valid
reasons in particular circumstances to ignore a particular item, but the full implications
MUST be understood and carefully weighed before choosing a different course.
MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One
implementer may choose to include the item because a particular implementation
requires it or because the implementer feels that it enhances the implementation while
another implementer may omit the same item. An implementation which does not
include a particular option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with reduced
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 8 of 22
© Crown Copyright 2013
functionality. In the same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which does not include
the option (except, of course, for the feature the option provides).
2 Background
Suppliers of Principal Clinical Systems to General Practice are required to provide integration
capability via an interface mechanism(s). This interface mechanism enables separate third-party
systems to access (in bulk, or at an individual patient level) demographic and clinical data held within
the system. This includes both the ability to read from and write to the system for purposes such as:
data extraction to support secondary uses, data entry from medical devices, integration with
specialist software applications such as pathology requesting systems and document management
systems.
Suppliers of any subsidiary modules that interface to the Principal GP clinical system, and which
store patient-specific clinical data, are also required to provide an interface mechanism to support 2-
way data exchange.
The process by which these interface mechanisms are published, and made available for testing and
development, is described elsewhere [TBD].
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 9 of 22
© Crown Copyright 2013
3 Requirements Overview
The requirements in this document are technology neutral; they describe ‘what’ an interface must
provide and not ‘how’ it is achieved. They are also data type neutral in that they do not specify any
data formats or data types. However, there is an expectation that the data model used by the
Principal GP Clinical system in any interface mechanism is the same as the data model used within
the system, e.g. that an address comprises 5 lines of 35 characters, an NHS number is 10 digits, etc.
The requirements in this version aim to achieve consistency across systems in the functions
supported by interfaces.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 10 of 22
© Crown Copyright 2013
4 System Requirements applicable to both Principal Clinical
Systems and Subsidiary Modules
Principal GP Systems must meet all the requirements in this section.
The nature of each Subsidiary Module, and its intended and/or expected use, will determine which
of the requirements within this section apply to a particular Subsidiary Module; in particular, a
Subsidiary Module that stores personal data is required to support the requirements in this area.
Interpretation note:
If the system that meets these requirements is a Principal GP system, then the use of the word
‘system’ means the Principal GP system and use of the phrase ‘external system’ means a Subsidiary
Module.
If the system that meets these requirements is a Subsidiary Module, then the use of the word
‘system’ means the Subsidiary Module and use of the phrase ‘external system’ means a Principal GP
system or an additional separate system that integrates with the Subsidiary Module.
4.1 Audit
Req ID Requirement Text Type
AP4.1.01 The system MUST ensure that all uses of mechanisms to support
integration capability are audited and that audit trials MUST be subject
to the standard IG audit requirements around access, tamper
resistance, retention, etc. (See ‘IG Requirements for GP Systems’ )
MUST
AP4.1.02 The system MUST audit the following interface activity:
Inbound requests or queries from external systems
Outbound responses, including data, to external systems
Inbound data ‘writes’ (including logical deletions) from external
systems
Outbound data ‘pushed’ to external systems or to holding areas
for collection/use by external systems, including any activity
not in response to a request/query (e.g. daily dump of
demographic changes)
Any other data changes made as a result of activity with
external systems through interface mechanisms.
MUST
AP4.1.03 The system MUST log all successful and unsuccessful (where possible)
interface activity.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 11 of 22
© Crown Copyright 2013
Req ID Requirement Text Type
AP4.1.04 The system MUST audit all access and data changes within the system
as a result of activity through an interface mechanism by an external
system in the same way that internal access and changes are recorded.
MUST
AP4.1.05 The system MUST include the identity of the external system in the
audit data. This SHOULD include the product and the version number.
MUST
AP4.1.06 The system MUST, where a user initiates an exchange of data (as
opposed to a system event), include the external system user identity
in the audit data. (Note: External system users must be synchronised
with internal system users. See sections 5.1 User and other non-Patient
Data and 6.2 User Synchronisation )
MUST
4.2 Provenance
Req ID Requirement Text Type
AP4.2.01 All additions, amendments or deletions to administrative and clinical
data made via an interface mechanism MUST be clearly identified at a
data-structure level with information regarding the provenance of the
data (e.g. timestamp, details of source system, details of user), so it is
clear which information has been entered through an interface
mechanism rather than the local system itself.
MUST
4.3 System Authentication
Req ID Requirement Text Type
AP4.3.01 The system SHOULD provide mechanisms to authenticate external
systems using an interface mechanism, so that only approved external
systems can utilise the interface.
SHOULD
4.4 System Context
This means the context of the system within a user’s desktop/workstation/session.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 12 of 22
© Crown Copyright 2013
Req ID Requirement Text Type
AP4.4.01 The system MUST provide mechanisms for external systems to be kept
aware of the state of the system. This MUST not require any user
intervention.
MUST
AP4.4.02 The current ‘system context’ information MUST include, where
appropriate:
The user
The selected patient
MUST
AP4.4.03 The current ‘system context’ information SHOULD include, where
appropriate:
Functional state (e.g. prescribing module selected, add
appointment selected)
SHOULD
AP4.4.04 The current ‘system context’ information SHOULD include, where
appropriate:
Data state (e.g. the drug selected, the problem/diagnosis
selected)
SHOULD
AP4.4.05 The ‘system context’ MUST be kept up to date. MUST
4.5 Appropriate use of integration capability
Where a system provides alternative mechanisms to support an interface function (e.g. retrieve the
demographics of a single patient, retrieve the demographics of multiple or all patients) the supplier
should, where appropriate, provide guidance on when to use each mechanism. The documentation
that describes the supplier’s technical implementation of these requirements should also indicate
whether the use of any particular interface mechanism may adversely affect the performance of the
system, e.g. extracting all the clinical data for all patients impedes general system performance and
should be run during periods of low usage or when no users are using the system.
Req ID Requirement Text Type
AP4.5.01 Where a system provides alternative interface mechanisms to support
a function and guidance is provided over when to use each, the
external system MUST adhere to that guidance.
MUST
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 13 of 22
© Crown Copyright 2013
Req ID Requirement Text Type
AP4.5.02 When a user initiates an action where it is known that the interface
activity may cause adverse performance of either the system or the
external system, the system MUST warn the user prior to the activity
commencing of the possible consequences. The warning must allow
them to continue or to cancel the action. If the user decides to
continue, it SHOULD be possible1 to cancel or abort the activity before
it has completed.
MUST
AP4.5.03 If the system carries out non user-initiated actions/tasks that may
affect either Principal GP system performance or Subsidiary system
performance it SHOULD be possible for such actions/tasks to be
scheduled to occur at times that reduce the impact on the Practice (e.g.
to occur outside business hours).
SHOULD
4.6 System Invocation
Req ID Requirement Text Type
AP4.6.01 The system MUST provide mechanisms for an external systems to
launch the system and/or invoke specific key application functionality
with appropriate parameters relevant to the function (e.g. launch
system in the context of a user ID and a supplied patient identifier,
launch system in the context of an object identifier (e.g. document,
clinical data item)).
MUST
AP4.6.01.1 The system MUST prevent such activity to cause loss of data in the
system, e.g. prompting a user to close/save current session before
allowing an external system ‘request’ to be completed.
MUST
4.7 Interface Management
It is recognised that suppliers may need to update an interface mechanism from time to time. Given
that the use of the interfaces support critical Practice processes it is important that any such changes
are managed in a way that prevents any systems failures and minimises any system ‘downtime’.
Suppliers are therefore recommended to, wherever possible, implement updates in a manner that
supports backward compatibility leaving existing interfaces working. Should this not be possible,
1 It is recognised that, depending on the nature of the interface mechanism, it may not be possible to stop an
activity in an external system.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 14 of 22
© Crown Copyright 2013
suppliers must only make such changes with the agreement of the Practice(s) using that interface
and in co-ordination with any suppliers using that interface, so that arrangements can be made for a
managed update which minimises loss of functionality to the Practice(s).
It is also accepted that versions of interface mechanisms cannot be expected to be supported
forever and that suppliers will want to manage deprecation of old interfaces. Management of such
deprecations should be in agreement with Practices and suppliers using those interfaces.
Req ID Requirement Text Type
AP4.7.01 The version of the interface mechanism SHOULD be available to
external systems as a function of the interface mechanism.
SHOULD
AP4.7.02 The version identifier SHOULD be included in all data exchanges
between the system and external systems.
SHOULD
AP4.7.03 The system SHOULD support multiple versions of the same interface
mechanism simultaneously.
SHOULD
AP4.7.04 Any change to an interface mechanism MUST NOT cause an external
system using that interface to fail.
MUST
4.8 Error & failure handling
Req ID Requirement Text Type
AP4.8.01 The system MUST adopt failsafe error and failure handling mechanisms
such that any detected error or failure:
does not cause the system to halt or to lose any data
causes an appropriate message to be displayed to a user,
entered in a log, or sent to an external system as applicable.
MUST
AP4.8.02 All errors and failures MUST be logged in the interface audit trail. MUST
AP4.8.03 Error/failure messages displayed to a user SHOULD indicate whether
the error/failure is permanent or whether a ‘retry’ may be performed
at a later time. (e.g. a locked patient record could be retried later, an
invalid clinical code can’t be retried).
SHOULD
4.9 Practice Population Data
In order to support the needs of the Practice and its related organisations (e.g. commissioners,
organisations responsible for public health) access to clinical data in systems needs to be easily
available but securely and appropriately released.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 15 of 22
© Crown Copyright 2013
The use of such data upon leaving the system is covered by the IG requirements which place
responsibility for this usage upon the Data Controller (The Practice).
It is recognised that some suppliers may provide off-line data for reporting purposes in order to
minimise the impact on operational systems.
Req ID Requirement Text Type
AP4.9.01 The system MUST provide a mechanism to provide all the clinical data2
for all registered/active patients of a Practice to an external system.
MUST
AP4.9.02 The system SHOULD provide a mechanism to provide all the clinical
data for a defined subset/cohort of the registered/active patients to an
external system.
SHOULD
AP4.9.03 Information provided by these mechanisms MUST NOT be more than
24hrs old.
MUST
AP4.9.04 Information provided by these mechanisms MUST be returned at a rate
that is no slower than 10 minutes for every 1000 patients.
MUST
AP4.9.05 Where a patient’s clinical data includes an attached/embedded
file/document, the system MUST either include such files in situ in the
data or separately. If provided separately the system MUST include a
reference in the patient data extract that uniquely identifies the
associated file so that the external systems can correctly re-build the
association between file and clinical data item.
MUST
AP4.9.06 The interface mechanism MUST support the ability to request data
both with and without such attachments.
MUST
2 See section 5.3 for a definition of Patient Clinical Data.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 16 of 22
© Crown Copyright 2013
5 Principal GP System Requirements
This section provides a generic set of requirements that are intended to support a wide range of
Subsidiary Modules, ensuring that all Principal GP Systems provides a range of interface capability
required by those modules.
Definition
The use of the word ‘system’ in the following tables means ‘Principal GP System’ unless otherwise
prefixed.
3rd Party system – any system using interface mechanisms exposed by a Principal GP System.
5.1 User and other non-Patient Data
The user data, data about the Practice and clinical terminology data held in the Principal GP systems
are regarded as the authoritative source of this data. The clinical terminology data may be obtained
from other authoritative sources (e.g. UKTC).
Req ID Requirement Text Type
AG5.1.01 The system MUST provide mechanisms for 3rd Party systems to access
the following data held in the system:
registered/active users, including their ID(s) and access rights
the version/release/edition of any clinical coding terminologies
used
the version/release/edition of the dm+d drug database
MUST
AG5.1.02 The system SHOULD provide mechanisms for 3rd Party systems to
access the following data held in the system:
clinical coding terminologies3
other administrative data required for system setup (e.g.
organisation ODS code and name, messaging parameters)
SHOULD
3Sufficient data to enable an Subsidiary Module to browse/search the terminology data in order to add coded
clinical data to patient records.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 17 of 22
© Crown Copyright 2013
5.2 Patient Demographics
The patient demographics held in the Principal GP systems are regarded as the authoritative set of
demographics for patients currently registered with the Practice as far as 3rd Party systems are
concerned. For 3rd Party Systems that use patient demographics it is essential that mechanisms exist
for these systems to have access to this information and for this to be up to date.
Req ID Requirement Text Type
AG5.2.01 The system MUST provide mechanisms for 3rd Party systems to access
unique individual patient demographic records using appropriate
selection parameters (e.g. NHS number, local ID).
MUST
AG5.2.02 The system MUST provide a mechanism that allows a 3rd Party System
to search for a patient by providing patient demographic data items as
search parameters and the system returning an NHS number/local ID
and/or the full set of demographics for the matching patient(s).
MUST
AG5.2.03 The system MUST also provide a mechanism to supply the
demographics of ALL registered/active patients of a Practice to 3rd Party
systems.
MUST
AG5.2.04 The system SHOULD provide a mechanism to allow 3rd Party systems to
be informed of changes (additions, deletions, amendments) to patient
demographics on a regular basis (e.g. a daily change log or list of IDs of
changed records)
SHOULD
AG5.2.05 The system SHOULD provide a mechanism for 3rd Party systems to
amend patient demographics held in the system without the need to
invoke any (Principal GP system) user interface.
SHOULD
AG5.2.06 For any demographic data changes received via an interface
mechanism the system MUST:
Update PDS with any changes to demographic data held in
common and kept synchronised with PDS
Update NHAIS with any changes to demographic data held in
common and kept synchronised with NHAIS through
‘Registration Links’
i.e. the system must treat a change received via an interface
mechanism as if it was a change made by a local user.
MUST
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 18 of 22
© Crown Copyright 2013
5.3 Individual Patient Clinical Data
The use of the phrase ‘all the clinical data’ in the following table means all patient-specific data
(whether coded or otherwise) that forms part of the clinical record within the principal system;
specifically, but not limited to, the following attributes of every coded clinical entry in a patient’s
record:
Unique ID (optional)
Effective/applicable date(s)
Clinical code
Clinical term
Value(s)
Free text notes
Person making the entry
Authorising person (if applicable)
Date entry made
Any attached file/document (where applicable) or a reference to it and a mechanism for
retrieving it
ID of parent clinical entry (where applicable)
Req ID Requirement Text Type
AG5.3.01 The system MUST provide a mechanism for all the clinical data of a
selected patient’s clinical record to be retrieved by a 3rd Party system.
MUST
AG5.3.02 The system SHOULD provide a mechanism for a subset of a selected
patient’s record to be retrieved by a 3rd Party system.
SHOULD
AG5.3.03 It SHOULD be possible to define a subset by:
Effective/applicable date
Date entry made
Clinical code(s)
Author(s)
Data Type(s)4
SHOULD
AG5.3.04 The system MUST provide a mechanism for 3rd Party systems to add
new coded clinical entries to the patient record held in the system
without the need to invoke any (Principal GP system) user interface.
MUST
AG5.3.05 It MUST be possible to add such entries to existing Problems, i.e. to a
‘parent’ entry in the patient record.
MUST
4 To be defined by the supplier. May include data types such as problems, medication, document type (e.g.
referral), appointment, etc.
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 19 of 22
© Crown Copyright 2013
Req ID Requirement Text Type
AG5.3.06 It MUST be possible to add such entries as standalone unlinked clinical
entries.
MUST
AG5.3.07 It MUST be possible to include attached files (documents) when
adding a clinical entry.
MUST
AG5.3.08 It MUST be possible to add a reference to an externally held file
(document) when adding a clinical entry.
MUST
AG5.3.09 The system SHOULD provide a mechanism for 3rd Party systems to add
new Problems to the patient record without the need to invoke any
(Principal GP system) user interface.
SHOULD
AG5.3.10 The system SHOULD provide a mechanism for 3rd Party systems to
(logically) delete entries previously added by the 3rd Party system.
SHOULD
AG5.3.11 Any modification to patient clinical data as a result of interface activity
that would, if made by a user of the system, result in an update to
other data held in national systems (e.g. SCR, EPS, Choose and Book)
MUST result in such changes being communicated to those systems in
the usual manner. (i.e. the system MUST treat a change received via
an interface mechanism as if it was a change made by a local user.)
MUST
AG5.3.12 In an environment where the system provides information-sharing
across clinical settings, data provided to 3rd Party systems SHOULD
include all data (including that from other settings) that is visible to
the principal system user.
SHOULD
AG5.3.13 Where such data is provided to 3rd Party systems, it MUST be made
clear to the 3rd Party system which data is managed within the
principal clinical system, and which is visible as a result of information-
sharing mechanisms.
MUST
AG5.3.14 Information provided by the system to a 3rd Party system about a
single patient by any of these mechanisms above MUST be up-to-date
and SHOULD be returned within a timeframe appropriate to the user
scenario being supported, i.e. it MUST NOT subvert the (3rd Party
system) user experience or adversely affect the performance of the
(Principal GP) system.
MUST
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 20 of 22
© Crown Copyright 2013
5.4 Supporting Patient Services
Req ID Requirement Text Type
AG5.4.01 The system MUST support the requirements of subsidiary modules
that provide services to patients (such as online appointment booking,
requesting repeat prescriptions, access to records, patient-clinician
communication)
MUST
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 21 of 22
© Crown Copyright 2013
6 Subsidiary Module System Requirements
The large variation in the functionality, and hence interface requirements, provided by Subsidiary
Modules means that the requirements in this section do not necessarily apply to every Subsidiary
Module. The nature of the system and its intended and/or expected use will determine which of the
requirements in this section apply to specific Subsidiary Modules. In particular, if a Subsidiary
Module stores personal data, these requirements will apply. In other circumstances, the degree to
which these requirements are applicable will be based on need, and will defined on a case-by-case
basis as part of a specific subsidiary module’s requirements.
Definition
The use of the word ‘system’ in the following tables, unless otherwise prefixed, means a Subsidiary
Modules.
6.1 User Authentication & Access Controls
Req ID Requirement Text Type
AS6.1.01 If the system provides stand-alone functionality (i.e. it can operate
independently of a Principal GP system and/or it provides its own login
facilities, it MUST support standard IG requirements on user
authentication and access controls (see ‘IG Requirements for GP
Systems’)
MUST
AS6.1.02 When the system is an integrated component of a Principal GP system,
utilising the Principal GP system’s user authentication and access
controls, details of the Principal GP system user MUST be included in
any audit mechanisms employed by the system.
MUST
6.2 User Synchronisation
Req ID Requirement Text Type
AS6.2.01 The user records in the system MUST be kept synchronised with the
corresponding user record in the Principal GP System or, if SSO Smart
Card and NRD support is provided, kept synchronised with the user’s
corresponding entry in SDS.
MUST
GP Systems Interface Requirements HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft
HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx Page 22 of 22
© Crown Copyright 2013
Req ID Requirement Text Type
AS6.2.02 Such synchronisation, as a minimum, MUST include:
Whether the user is active or inactive
The user ID (as shared between the system for audit purposes)
The user’s access rights so that access to appropriate
functions/data is controlled within the system and when
accessing data in the Principal GP system.
MUST
6.3 Patient Demographic Data
The authoritative source of patient demographic data is the Principal GP system.
Req ID Requirement Text Type
AS6.3.01 If the system holds patient demographic data it MUST synchronise this
with the Principal GP system. MUST
AS6.3.02 Patient demographic data used5 by the system MUST be no more than
24 hours old with respect to its synchronisation with the Principal GP
system.
MUST
AS6.3.03 If the system allows demographic data to be amended it MUST also
update the Principal GP system.
MUST
6.4 Individual Patient Clinical Data
Req ID Requirement Text Type
AS6.4.01 The system MUST provide a mechanism to allow Principal GP systems
to access and retrieve all patient-specific clinical data held by the
system for a specified patient.
MUST
AS6.4.02 Any clinical data ‘written’ to a Principal GP System MUST use the same
clinical terminology as that being used by the Principal GP system and
this SHOULD be the same version/release of that terminology.
MUST
5 On screen, on printouts or in other system outputs (e.g. messages)
top related