GP Systems Interface Requirements V1

Programme Sub-Prog /Project Prog. Director Sub Prog/Proj Mgr Author GPSoC Technology Office Kemi Adenubi Mike Curtis Tim Tett / Danny Solomon

DOCUMENT RECORD ID KEY

HSCIC-FNT-TO-TAR-0110.01
Version Date Status 11 16 February 2013 Draft FOR COMMENT

GP Systems Interface Requirements V1

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Page 1 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Amendment History
Version draft 08 draft09 draft10 draft11 Date 29 Jan 13 1 Feb 13 6 Feb 13 16 Feb 13 Amendment History Amendments prior to release for comment to supplier community. Added section being explicit about the need to support internet-facing patient services. Updates following comments from Kemi Adenubi 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 Tim Tett Brendan McEnroe Title / Responsibility GPSoC Technical Architect GPSoC Technical Architect Date Version

Approvals:
This document requires the following approvals: Name Mike Curtis Kemi Adenubi Title / Responsibility Lead Technical Architect for GPSoC GPSoC Programme Director Date Version

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 baselined for use throughout the programme).

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 2 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Glossary of Terms:
Term NRD PDS Principal clinical system Subsidiary module RBAC UKTC RBAC UKTC Acronym Definition NRD PDS National RBAC Database a source of nationally defined roles and activities for system users. Personal Demographics Service a national application providing patient demographic data services Integrated system providing majority of clinical IT services within practices.

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. Role Based Access Control 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.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 3 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Contents
1 Introduction .................................................................................................................................... 5 1.1 1.2 1.3 1.4 2 3 4 Audience ................................................................................................................................. 5 Document Scope ..................................................................................................................... 5 Document Overview ............................................................................................................... 6 Definitions ............................................................................................................................... 7

Background ..................................................................................................................................... 8 Requirements Overview ................................................................................................................. 9 System Requirements applicable to both Principal Clinical Systems and Subsidiary Modules .... 10 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Audit ...................................................................................................................................... 10 Provenance ........................................................................................................................... 11 System Authentication .......................................................................................................... 11 System Context ..................................................................................................................... 11 Appropriate use of integration capability ............................................................................. 12 System Invocation ................................................................................................................. 13 Interface Management ......................................................................................................... 13 Error & failure handling ........................................................................................................ 14 Practice Population Data ...................................................................................................... 14

Principal GP System Requirements ............................................................................................... 16 5.1 5.2 5.3 5.4 User and other non-Patient Data.......................................................................................... 16 Patient Demographics ........................................................................................................... 17 Individual Patient Clinical Data ............................................................................................. 18 Supporting Patient Services .................................................................................................. 20

Subsidiary Module System Requirements .................................................................................... 21 6.1 6.2 6.3 6.4 User Authentication & Access Controls ................................................................................ 21 User Synchronisation ............................................................................................................ 21 Patient Demographic Data .................................................................................................... 22 Individual Patient Clinical Data ............................................................................................. 22

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 4 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 5 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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:

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 6 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx
Crown Copyright 2013

Page 7 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 2way data exchange. The process by which these interface mechanisms are published, and made available for testing and development, is described elsewhere [TBD].

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 8 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 9 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 AP4.1.01 Requirement Text 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 ) 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. AP4.1.03 The system MUST log all successful and unsuccessful (where possible) interface activity. Type MUST

AP4.1.02

MUST

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 10 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Req ID AP4.1.04

Requirement Text 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. The system MUST include the identity of the external system in the audit data. This SHOULD include the product and the version number.

Type MUST

AP4.1.05 AP4.1.06

MUST

The system MUST, where a user initiates an exchange of data (as MUST 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 )

4.2 Provenance
Req ID AP4.2.01 Requirement Text 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. Type MUST

4.3 System Authentication

Req ID AP4.3.01 Requirement Text The system SHOULD provide mechanisms to authenticate external systems using an interface mechanism, so that only approved external systems can utilise the interface. Type SHOULD

4.4 System Context

This means the context of the system within a users desktop/workstation/session.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 11 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Req ID AP4.4.01

Requirement Text 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. The current system context information MUST include, where appropriate: The user The selected patient

Type MUST

AP4.4.02

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 suppliers 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 AP4.5.01 Requirement Text 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. Type MUST

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 12 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Req ID AP4.5.02

Requirement Text 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. 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).

Type MUST

AP4.5.03

SHOULD

4.6 System Invocation

Req ID AP4.6.01 Requirement Text 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)). 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. Type MUST

AP4.6.01.1

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.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 13 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 AP4.7.01 AP4.7.02 AP4.7.03 AP4.7.04 Requirement Text The version of the interface mechanism SHOULD be available to external systems as a function of the interface mechanism. The version identifier SHOULD be included in all data exchanges between the system and external systems. The system SHOULD support multiple versions of the same interface mechanism simultaneously. Any change to an interface mechanism MUST NOT cause an external system using that interface to fail. Type SHOULD SHOULD SHOULD MUST

4.8 Error & failure handling

Req ID AP4.8.01 Requirement Text 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. AP4.8.02 AP4.8.03 All errors and failures MUST be logged in the interface audit trail. 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 cant be retried). MUST SHOULD Type MUST

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.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 14 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 AP4.9.01 AP4.9.02

Requirement Text The system MUST provide a mechanism to provide all the clinical data2 for all registered/active patients of a Practice to an external system. 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. Information provided by these mechanisms MUST NOT be more than 24hrs old. Information provided by these mechanisms MUST be returned at a rate that is no slower than 10 minutes for every 1000 patients. Where a patients 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. The interface mechanism MUST support the ability to request data both with and without such attachments.

Type MUST SHOULD

AP4.9.03 AP4.9.04 AP4.9.05

MUST MUST MUST

AP4.9.06

MUST

See section 5.3 for a definition of Patient Clinical Data. Page 15 of 22

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 AG5.1.01 Requirement Text 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 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 Type MUST

Sufficient data to enable an Subsidiary Module to browse/search the terminology data in order to add coded clinical data to patient records.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 16 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 AG5.2.01 Requirement Text 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). 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). The system MUST also provide a mechanism to supply the demographics of ALL registered/active patients of a Practice to 3rd Party systems. 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) 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. 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. Type MUST

AG5.2.02

MUST

AG5.2.03

MUST

AG5.2.04

SHOULD

AG5.2.05

SHOULD

AG5.2.06

MUST

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 17 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 patients 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 AG5.3.01 AG5.3.02 AG5.3.03

Requirement Text The system MUST provide a mechanism for all the clinical data of a selected patients clinical record to be retrieved by a 3rd Party system. The system SHOULD provide a mechanism for a subset of a selected patients record to be retrieved by a 3rd Party system. It SHOULD be possible to define a subset by: Effective/applicable date Date entry made Clinical code(s) Author(s) Data Type(s)4

Type MUST SHOULD 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. It MUST be possible to add such entries to existing Problems, i.e. to a parent entry in the patient record.

MUST

AG5.3.05

MUST

To be defined by the supplier. May include data types such as problems, medication, document type (e.g. referral), appointment, etc.

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 18 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Req ID AG5.3.06 AG5.3.07 AG5.3.08 AG5.3.09

Requirement Text

Type It MUST be possible to add such entries as standalone unlinked clinical MUST entries. It MUST be possible to include attached files (documents) when adding a clinical entry. It MUST be possible to add a reference to an externally held file (document) when adding a clinical entry. 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. The system SHOULD provide a mechanism for 3rd Party systems to (logically) delete entries previously added by the 3rd Party system. 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.) 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. 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 informationsharing mechanisms. 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 MUST SHOULD

AG5.3.10 AG5.3.11

SHOULD MUST

AG5.3.12

SHOULD

AG5.3.13

MUST

AG5.3.14

MUST

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 19 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

5.4 Supporting Patient Services

Req ID AG5.4.01

Requirement Text 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)

Type MUST

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 20 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

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 modules 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 AS6.1.01 Requirement Text 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) When the system is an integrated component of a Principal GP system, utilising the Principal GP systems user authentication and access controls, details of the Principal GP system user MUST be included in any audit mechanisms employed by the system. Type MUST

AS6.1.02

MUST

6.2 User Synchronisation

Req ID AS6.2.01 Requirement Text 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 users corresponding entry in SDS. Type MUST

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013

Page 21 of 22

GP Systems Interface Requirements

HSCIC-FNT-TO-TAR-0110.01, Version 11, Status: Draft

Req ID AS6.2.02

Requirement Text 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 users access rights so that access to appropriate functions/data is controlled within the system and when accessing data in the Principal GP system.

Type MUST

6.3 Patient Demographic Data

The authoritative source of patient demographic data is the Principal GP system. Req ID AS6.3.01 AS6.3.02 Requirement Text If the system holds patient demographic data it MUST synchronise this with the Principal GP system. 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. If the system allows demographic data to be amended it MUST also update the Principal GP system. Type MUST MUST

AS6.3.03

MUST

6.4 Individual Patient Clinical Data

Req ID AS6.4.01 Requirement Text 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. 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. Type MUST

AS6.4.02

MUST

On screen, on printouts or in other system outputs (e.g. messages) Page 22 of 22

HSCIC-FNT-TO-TAR-0110.01 GP Systems Interface Requirements v1 - draft11.docx

Crown Copyright 2013