IM1 - Interface Mechanism v1.0.0
ID | S47 |
|---|---|
Version | 1.0.0 |
Type | Interoperability Standard |
Status | Retired |
Effective Date |
- 1 Introduction
- 1.1 Applicability
- 2 Requirements
- 2.1 Generic Integration Requirements
- 2.2 Transaction or Practice Integration
- 2.2.1 Patient Information Maintenance
- 2.2.2 Appointments Management
- 2.2.3 Consultation Management
- 2.2.4 Documents Management
- 2.2.5 Prescribing
- 2.2.6 Referral Management
- 2.2.7 Resource Management
- 2.2.8 Communications Management
- 2.3 Patient/Citizen Facing interfaces
- 2.4 Non Primary Care Settings
- 2.5 IM1 Refresh
- 2.6 Bulk Extracts
- 2.7 Deprecation of Interfaces
- 2.8 Compliance & Assurance
- 2.9 Important terms and definitions
- 2.10 Dependencies (Patient facing interface Only)
- 3 Roadmap
Introduction
IM1 is a mechanism for accessing data held in GP Systems (Systems providing one or more Capabilities as part of the GP IT Futures Framework). The interface mechanism should facilitate the following use-cases:
Patient - real-time access to APIs exposed over the Internet supporting both read and limited write / transactional operations for the purposes of Patient/Citizen Facing Services (including registration and authentication of Citizens)
Bulk - Bulk data extracts of all data held by the GP System Supplier
Practice real-time APIs for integrating systems, which may operate locally
Provider Suppliers acting as consumers of their own interfaces must take note of requirements in the Interoperability Standard, particularly those relating to equitable access to functionality and data (Requirement: ISNFR07)
Please also note that suppliers must be compliant with the overarching Commercial Standard, and comply with the Model Interface Licence contained within.
Applicability
A system or application is required to provide IM1 interfaces if ANY of the following are true:
It offered IM1 interfaces under GPSoC
It offers ALL Foundation capabilities under GP IT Futures
Where a GP Connect interface capability is available, suppliers would be expected to develop against that, rather than developing a new bespoke or proprietary interface.
A system or application may wish to consume IM1 interfaces where they have a requirement to access data held in GP Systems.
Requirements
This page describes integration requirements for systems which are required to be an IM1 interface provider and\or consumer.
The scope of this document includes:
Generic requirements which allude to best practices in Applications integration, Extract Transformation Loading & API Management
Requirements around some high level API Calls and its expected behaviour in generic terms
Requirements around System Context, Authentication & Version Management
The following are not in scope:
Low level Interface specifications and schema definitions. IM1 interfaces are not built to a standard specification and core system suppliers are currently free to implement in whatever way they see fit, however, suppliers should read the Principles section of the Interoperability Standard and ensure their approach is aligned accordingly. Where applicable they should be able to demonstrate adherence to Principles
Commercial arrangements and charging
Assurance and testing
Mechanisms to get a Consumer Supplier on board and giving access to test environments
Generic Integration Requirements
Monitoring & Response Times
This pertains to individual requests and responses for each message interaction and how these are monitored.
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_resp_001 | The Provider Integration Architecture must be capable of monitoring requests received by various Consumers, including the capture of response times required for processing the request within the confines of the Supplier Data Centre / Cloud boundary | Provider | Practice & Patient | MUST |
Authentication and End Points
This refers to how Consumer Systems and Users are authenticated and mechanisms for Consumer systems to access the IM1 interfaces
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_auth_001 | The Provider must provide a seamless process to authenticate Consumer systems and Users without any extra overhead or usability issues User of a Consumer Solution can refer to a patient in case of Citizen Facing capabilities or refer to a healthcare professional or NHS Staff | Provider | All | MUST |
im1_auth_002 | The access to Provider Endpoints should not be constrained by existence of a User Session on the Provider Solution | Provider | Practice | should |
im1_auth_003 | For the Practice IM1 where feasible, the access to Provider Endpoints should not be constrained by requiring the Consumer integration components to be present within a Practice or within the GP's workstation/PC | Provider | Practice | should |
im1_auth_004 | The access to Provider file Extracts must not be constrained by requiring the Consumer integration components to be present within a Practice or within the GP's workstation/PC for the Bulk IM | Provider | Bulk | should |
System Context & Invocation
This refers to the context of the User Session within a Provider Solution and its visibility to the Consumer
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_context_001 | The Provider Solution must provide mechanism for Consumer to be kept aware/notified of context information. At the very minimum notification should include
Note: Providers will notify Consumers of state/context changes; Consumers will not be required to poll or repeatedly call the Provider system to establish if there has been a change | Provider | Practice | should |
im1_context_002 | In addition the Provider Solution context information must include, where appropriate (and where subscribed to / requested by Consumer):
| Provider | Practice | should |
im1_context_003 | The Provider Solution should have a mechanism to launch the Consumer Solution, in a particular Context, by a User of the Provider Solution- This will be dependent on Consumer Solution providing a suitable link via which the Provider could launch / invoke the Consumer Solution | Provider | Practice | MAY |
Appropriate use of integration capability
Ensuring the Provider Solution is not impacted by huge influx of request messages and how it handles such scenarios.
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_use_001 | Provider must be capable of applying appropriate throttling techniques in order to spread the processing load of incoming requests or Extracts processing | Provider | All | MUST |
im1_use_002 | Provider must be capable of notifying the Consumer of unavailability or delay of request processing (eg. during heavy usage of the Provider System) | Provider | All | MUST |
im1_use_003 | If the Consumer supports non user-initiated actions/events that may affect either Provider or Consumer Solution performance then such actions/events must be capable of being scheduled at appropriate times | Consumer | All | MUST |
im1_use_004 | Where a Provider includes mechanisms to retrieve large sets of data in real time, they must provide guidance on when to use each API call or method- The documentation that describes the supplier's IM1 must 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 | Provider | Practice & Patient | MUST |
im1_use_005 | The Consumer must ensure it displays the most up-to date information to its user - Where the information is not up-to date then it should be clearly notified to the User and the User should have visibility of date-time modified for the particular data item | Consumer | All | MUST |
Interface Version Management
It is recognized that suppliers will need to update their interface mechanisms. These requirements ensure version updates are done in a standard manner giving enough notification to Consumers and also providing them the relevant details pertaining to changes.
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_ver_001 | The version of the Interface Mechanism will be available to Consumer systems either via API calls or messages, or provided on request to Provider | Provider | All | MUST |
im1_ver_003 | Provider implement updates in a manner that supports backward compatibility leaving existing interfaces working. Where an interface has to be retired then relevant requirement applies | Provider | All | MUST |
im1_ver_004 | Deprecation of interfaces must only be carried out with agreements from Authority and Consumers by providing them with enough advanced notice | Provider | All | MUST |
im1_ver_005 | Any interface change which would break existing Consumer App needs to be notified beforehand and Consumers should be given the opportunity to test their Solutions against it. | Provider | All | MUST |
im1_ver_006 | Any new changes in an interface needs to be very clearly documented such that different between latest version and earlier version is very clear | Provider | All | MUST |
im1_ver_007 | Consumers of IM1 will be notified of deprecated interfaces and will be given suitable notice in order for their Solution to be migrated away from deprecated interfaces and utilize the latest offering of IM1 from the Provider. Consumers must work to implement the latest version | Consumer | All | MUST |
Error & failure handling
How errors in message processing should handled and notified to consumers.
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_error_001 | Any error condition experienced by the Provider in processing a request needs to be clearly identified, captured and logged - The Consumer should get clear specific information as to what that error was | Provider | All | MUST |
im1_error_002 | Error conditions must not result in abrupt disconnection or failure of the overall Provider interface. The provider should gracefully exit when errors occur and return meaningful error messages to the consumer | Provider & Consumer | All | MUST |
im1_error_003 | Consumer must display the relevant specific error message to the end-user to give them a clear indication as to what went wrong | Consumer | Practice & Patient | MUST |
Terminology & Coding Data Sets
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_code_001 | Provide a mechanism for a Consumer Supplier to discover versions of any coding schemes used within the Provider Solution (including SNOMED-CT, DM+d, any other standard coding terms) | Provider | Practice and Bulk | MUST |
Transaction or Practice Integration
Requirements are listed in terms of API Calls or Methods categorized by GP IT Futures Capabilities. For existing IM1 Providers none of the API calls should be removed unless an equivalent or an uplifted version is provided.
Patient Information Maintenance
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_cap_001 | Search Patient Description: The Supplier must provide a mechanism that allows Consumer systems to search for a patient by providing patient demographic data items as search parameters. At the very minimum the Provider should provide search using the following fields used independently or used in combination: first name, last name, dob, NHS Number and Provider should return the full set of demographics for the matching patient(s) | Provider | Practice | MUST |
im1_cap_002 | Update Demographics Description: The Supplier should provide a mechanism for Consumer systems to create a request for amending patient demographics via APIs, which can then be performed by a user of the Provider system | Provider | Practice | should |
im1_cap_003 | Get Patient Demographics | Provider | Practice | MUST |
im1_cap_004 | Get Full Medical Record | Provider | Practice | MUST |
im1_cap_005 | File Data in Patient Record | Provider | Practice | MUST |
Appointments Management
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_cap_006 | Get Bookable Slots (Appointment) Note: This should be met via GP Connect requirements as per Interoperability Standard | Provider | Practice | should |
im1_cap_007 | Book Appointment Note: This should be met via GP Connect requirements as per Interoperability Standard | Provider | Practice | should |
im1_cap_008 | Cancel Appointment Note: This should be met via GP Connect requirements as per Interoperability Standard | Provider | Practice | should |
im1_cap_009 | Check in a Patient (on arrival) | Provider | Practice | SHOULD |
Consultation Management
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_cap_010 | Get Consultation Records for a Patient | Provider | Practice | should |
im1_cap_011 | Create a new Consultation Record | Provider | Practice | should |
im1_cap_012 | Add a document or attachment to a Consultation Record | Provider | Practice | should |
Documents Management
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|---|---|---|---|
im1_cap_013 | File Document into a Patient Record | Provider | Practice | MUST |
im1_cap_014 | Retrieve Documents for a Patient | Provider | Practice | MUST |
Prescribing
ID | Requirement | Consumer or Provider | IM1 Type | Level |
|---|