Overview of the common HTML view rendering guidance in relation to the Access Record capability

HTML implementation standards

Purpose

This document is intended for use by software developers, both provider supplier and consumer supplier, looking to build a conformant GP Connect HTML care record viewer application.

Information: See section HTML layout guide for details of the layout of the HTML views.

Notational conventions

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Near real time view

Information: The record returned from the provider system is near real time.

changes to the GP practice clinical record that are in progress (for example, where a patient consultation that is currently taking place), may not be available
the record is machine generated and therefore is not owned or attested by any single clinician

Record locking

GP Connect queries/requests may be received while the patient’s record is being updated.

Record locking inside a provider system MUST NOT impact the ability of the system to fulfil read/query requests of the patient’s record.

However, it is understood that there are differing approaches to record locking within the GP principal systems which have an effect when any local/pending changes are actually committed back to the patient’s record.

When a consumer system accesses a patient’s record, the provider systems MUST only return data that has been successfully committed back to the patient’s record and thus has become available to all users (including users of the provider APIs).

Common user interface guidance

Where appropriate the following Common User Interface (CUI) guidance documents SHOULD be followed when generating the GP Connect HTML views.

Consumer systems MUST present a patient banner above the HTML content returned from the GP Connect APIs in line with the CUI guidance.

Patient Banner
Patient Banner - Quick Implementation Guide

Minimum display resolution

This guidance is applicable to user interfaces displayed on desktop or laptop computers. It is assumed that, at a minimum, these computers are capable of operating at a minimum display resolution of 1024 x 768 and have a keyboard and pointing device.

Structured data

FHIR resources

Provider systems MUST return a minimal set of structured data along with the HTML content as follows:

FHIR resource(s)	Composition section
`Patient`	Subject
`Practitioner`	User
`Organization`	Custodian
`Device`	Author¹

¹ As the composition is machine-generated the concept of a single Author does not make logical sense. It is expected that the Author field will be populated with the details of the software system which generated the composition.

Details of these profiles can be found here in the DMS bundle.

Demographic cross checking

Consumer systems MUST compare the returned structured patient demographic data (supplied by the provider system as structured data) against the demographic data held in the consumer system.

If differences exist, then the consumer system MUST show an alert/warning and provide details of which fields/values are different between the two systems.

The following data MUST be cross checked between consumer and returned provider data. Any differences between these fields MUST be brought to the attention of the user.

Item	Resource element
Family Name	`patient.name.family`
Given Name	`patient.name.given`
Gender	`patient.gender`
Birth Date	`patient.birthDate`
GP Practice Code	`patient.managingOrganization`

Additionally, the following data MAY be displayed if returned from the provider to assist a visual cross check and for safe identification but SHOULD NOT be part of the automatic comparison.

Address and Postcode
Contact (telephone, mobile, email)
Responsible GP Code and Name
GP Practice Name and Address

Where a patient is flagged on the GP clinical system as sensitive (and as such the GP practice must not identify that the patient is registered at this location), the provider system MUST NOT return any clinical records and instead return the error Patient not found.

Where a patient is flagged on PDS as sensitive (and as such it is not possible to confirm their registered GP practice), the consumer system SHOULD NOT use GP Connect.

Section retrieval

Error handling

If a GP principal system can’t meaningfully supply content for a requested HTML view (or subset of the view) then the system MUST return the following HTML fragment in place of the HTML table.

Supported but hasn’t been recorded

system can store the data
BUT no data has been recorded for the patient

<div>
	<p>No '[section]' data is recorded for this patient.</p>
</div>

Supported but can’t be technically provided

system can store the data
BUT no data is available for the patient via the GP Connect APIs due to a technical limitation

<div>
	<p>This system does not support retrieval of '[section]' data.</p>
	<p>This data may still exist in the source system.</p>
</div>

Supported but is masked/access denied

system can store the data
BUT no data is available for the patient via the GP Connect APIs due to a IG/DS rule

<div>
	<p>Access is denied to '[section]' data for this patient.</p>
	<p>This data may still exist in the source system.</p>
</div>

Not supported

system doesn’t store the data

<div>
	<p>'[section]' data is not supported by this system.</p>
</div>

HTML section views

Provider systems MUST use XHTML constructs as defined in the FHIR narrative guidance contained within the FHIR® standard.

XHTML narrative

As outlined in the Narrative section of the FHIR® standard:

The XHTML content MUST NOT contain a head, a body element, external stylesheet references, deprecated elements, scripts, forms, base/link/xlink, frames, iframes, objects or event related attributes (e.g. onClick). This is to ensure that the content of the narrative is contained within the resource and that there is no active content. Such content would introduce security issues and potentially safety issues with regard to extracting text from the XHTML.

Note that the XHTML is contained in general XML so there is no support for HTML entities like   or © etc. Unicode characters MUST be used instead. Unicode   substitutes for  .

Information: The content MUST NOT contain any platform-specific escape or formatting characters such as \r\n, as these may cause inconsistent rendering within consumer applications, with potential impacts on clinical safety.

Styling the XHTML

As outlined in the ‘Styling the XHTML’ section of the FHIR® standard:

In order to minimise manageability and security issues, authoring systems cannot specify the CSS stylesheet to use directly. Instead, the application that displays the resource provides the stylesheets. This means that the rendering system chooses what styles can be used, but the authoring system must use them in advance. Authoring systems can use these classes, which MUST be supported by all rendering systems.

Please see the FHIR Runtime CSS or Styling the XHTML on the FHIR website for full details.

Tags:

API Hub

Explore and Make use of Nationally Defined Messaging APIs

Implementation standards