Emis Web Systems

There are 3 versions of EMIS Web that have different roles.

Version	Description
GP (Primary Care)	Designed specifically for GP practices. It focuses on managing patient care within a single GP practice. GP links is enabled by default for registering and deducting patients as per the mandatory requirements set out in the GMS contract, including maintaining a list of patients, the process for registering new patients, and the circumstances under which patients can be removed from the list. EMIS Web GP can create a deduction request in Registration, which is sent via the GP Links (regular patients only) to the Trading Partner (see below about Trading Partners).
Clinical Services	This is what the GP Federations/PCN Hubs have (in a relatively small guise – in terms of numbers of users) – used for services that can be run outside of GP practices by a number of services/provider units, including enhanced services, multi-disciplinary teamwork and broader healthcare operations, including community and outpatient services. Has access to the NHS Spine (PDS, GP Connect, SCR). It should be configured not to use GP Links, so patients are not (accidentally) deducted from their regular GP Practice. Organisations running Clinical Services will pay more per user for support as EMIS will provide first line support. Clinical Services pay for each module organisations wish to activate (i.e Laboratory Links) Clinical Services sit on a shared environment, so updates (patches/fixes/enhancements, etc) that are pushed to the GP practices, follow to Clinical Services, and therefore organisations have no say when these take place. If organisations want a testing/training environment, there is an additional cost and again, it is on a shared environment.
Community, Children, Mental Health (CCMH)	Scaled up version of the above configured and deployed for full community teams, delivering multitude of adult and children’s services across a healthcare economy- District and Community Nurses, Healthcare Visitors, CM teams, school health, children’s services, child health etc. usually with 800-5000 users in multiple teams, services and locations. The pricing model and the server architecture put in place are the main differences between Clinical Services and CCMH. Organisations running CCMH must provide their own first line support. Most modules for CCMH, like Mobile, NHS Spine functions are inclusive. Updates and fixes that are not pushed to CCMH. CCMH get a UAT (User Acceptance Testing) and training environment which are on separate domains, so they can manage their updates before loading into LIVE.

What is a Trading Partner?

A Trading Partner refers to an organisation or entity that has been set up to exchange data electronically with another organisation, typically for administrative or clinical purposes. This term is often used in the context of electronic data interchange (EDI) systems, such as EMIS Web, where trading partners are configured to facilitate the secure and efficient sharing of information.

Why non-GP organisations (i.e. GP Federations) cannot use EMIS Web GP

The GP version of EMIS Web is provided solely under the GPSoC (now GP IT Futures) contract with HSCIC and has a specific funding and payment mechanism.  So the end user has to be a GP practice.  EMIS cannot provide the GP IT Futures GP version of the system outside of this framework.

Also there is a technical reason – if the non-GP organisation system was the same as the GP system, each time a patient was registered, it would be possible for the GP links functionality to request a deduction of that patient from their actual registered practice as the GP system lets regular patients only be registered to one practice at a time – this would cause chaos, and prove to be difficult to administer locally as well as costly to local practices who contract payments would be affected.

There is also some slightly different functionality in several areas that the clinical services version of the software becomes more flexible for use in data sharing with GP practices.  Such as the use of the patient administration model that allows for this to be the mechanism to establish the legitimate relationship between the extended service or other service and the GP practices so that the referral path can (if chosen to) drive the data sharing.  This cannot be the case if the GP system is used. 

Patient Trace v Remote Consultations

Patient Trace and Remote Consultations can take place in all versions of EMIS Web GP.  However there must be data sharing agreements in place.  If you wish to use between GP to GP systems there will be a many-many set up of Data Sharing Agreements.  Clinicians may also have multiple logins if working across several services.  If you use EMIS Web Clinical Services then it’s a one-many data sharing agreement so easier to maintain, and the clinician only has one login to remember.  However considerations need to be made who will be the data controller of EMIS Web Clinical Services.

Patient Trace

Patient Trace enables a clinician using EMIS Web Clinical Services to trace a patient across from their GP Practice system (if a Data Sharing Agreement has been activated) and look at their GP notes (with the patient explicit consent) in read only format.  If a consultation is required it is recorded on EMIS Web Clinical Services with read only access back at the GP Practice.  Any QoF codes, etc, have to be copied back to the local record by the GP Practice.

Remote Consultations

A patient still needs to be traced across to the EMIS Web system (GP or Clinical Services) so they can be added to the Appointment Book.   Explicit consent is still required from the patient which takes place during the appointment booking (patient trace) stage.  A remote consultation has to start from a traced patient in the appointment book and can then only be carried out by the session holder of that appointment book.  The consultation however takes place on the patients GP system (a tunnel is opened).  The clinician cannot access any other part of the EMIS Web GP system whilst doing a remote consultation.  The consultation can be updated for up to a maximum of 28 days and only by the same clinician.  There is no EPS access.  It does mean however patients notes remain all on one system.  

More information about Remote Consultations including a video can be found here.

Figure 1: Workflow of Patient Trace & Remote Consultations

Benefits & Considerations of Patient Trace & Remote Consultations

Patient Trace Benefits

• consulting GPs can access the patient’s medical information – better information for better decisions
• convenient for patients
• audit trail in both organisations
• integrates with EMIS Web in clinical services
• Faster than Remote Consultations

Patient Trace Considerations

• QoF codes must be copied across
• Patient Consultation notes exist on ‘other’ system so would not travel with patient if they leave practice
• GP practices only get site of consultation if notified or click on ‘All Records’
• No EPS

Remote Consultation Benefits

• consulting GPs can access the patient’s medical information – better information for better decisions
• filed against the primary care record – efficient and secure (and travels with patient if moving to another practice)
• convenient for patients
• audit trail in both organisations
• integrates with EMIS Web in clinical services
• no charge for activation – only a one-off implementation charge

Remote Consultation Considerations

• Only session holder of the appointment book can remote into patients record
• Only the same session holder can amend the remote consultation for up to a maximum of 28 days (this can be changed)
• Can be slow
• No EPS
• Cannot have generic appointment books – appointment book belongs to clinician (hard for a clinical contact centre) 
• More admin overhead (managing appointment books)

Considerations for Remote Consultations or Clinical Services Information Sheet