GP Systems Interface Requirements v1 - Draft11

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


© 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).




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.




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




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.




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:




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




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




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.




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.





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


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


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.





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.


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





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


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.




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.


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


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.




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.


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.




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


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.




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.


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




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)


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.





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




5.4 Supporting Patient Services


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




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


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


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





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.


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


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)

Documents

GP Systems Interface Requirements v1 - Draft11