1. Retention policy enforcement
2. Individual’s rights to rectification, erasure, restriction
3. How do you demonstrate compliance with subject access requests?
3.1 How is a SAR captured and what information is captured?
3.2 What is a ‘reasonable’ request?
3.3 How do we track compliance meeting the prescribed time limit?
3.4 What format should the information be presented to the requestor?
3.5 How do we capture and view historic requests?
3.6 Should annotations and digital signatures be included in the output?
4. What level of access to patient records is appropriate?
4.1 Role-based access
4.2 Handling sensitive documents
5. What depth of audit information is required to monitor ‘appropriate access’?
1. Retention policy enforcement
Based on the NHS Code of Practice for Records Management, patient records should be kept for a minimum of eight years following the end of treatment, and GP records for 10 years, although certain types of records, such as children’s records, obstetric records, and mental health records are kept for longer.
Throughout the digitisation process, a patient record will go through multiple phases in its lifecycle:
- Physical state ‘paper patient record’;
- Scanned but pre-QC;
- Digital (but the scanned physical may be retained for, say, 3 months);
- Scanned physical destroyed, destruction certificate issued (this is an important step for BS10008 as proof that the digitised record is the only available version);
- Digital but withdrawn and inaccessible due to retention period;
- Digital record destroyed.
MediViewer provides functionality to track the patient record through all 6 stages. The Batch Manager module handles steps 1 – 4 and the Records Retention module handles stages 4-6. We provide functionality to flag records as being ‘on hold’, with the hold flagged for review on a particular date, and a feature to manage these holds. A hold could have all sorts of effects, depending on the nature of the hold, which could include:
- Preventing a record in stage 1 from being pulled for scanning (e.g. outstanding legal claim);
- Preventing a physical scanned record in stage 3 from being a candidate for secure destruction (e.g. QC issue);
- Preventing a record in stage 4 from being withdrawn or destroyed (e.g. patient on drug trial).
The MediViewer Records Retention module provides secure document retention and disposal functionality. Only a designated user such as systems administrator has the rights to delete a complete set of document or records.
A digitised patient record will be updated over time and can comprise records that have been either scanned (either archive or day forward), ingested digitally from third-party clinical systems, or captured via direct entry (e.g. e-forms). Each collection of documents (known as ‘bundles’) are marked with an identifier as to their type, date of origination and allocated an appropriate retention policy set up in accordance with Trust Policy. For instance, a Maternity bundle may have a policy applied to retain those records for 25 years from last appointment date. We can therefore apply different rules and therefore different expiry dates to different sets of records (such as General Notes, Maternity, Mental Health) stored within a single patient record.
The MediViewer retention policy mimics that of the NHS guidelines for retention and disposal, taking into account the types of patient activity and documents and whether they fall into the exceptions category. For instance, patients that have had drug trials, blood transfusion, hip replacements etc. all can be defined as exceptions.
Initially retention policies can be created by Records Administrators according to document type and associated with patient specific information such as age, date of death, last appointment date as triggers each with a specified retention period. These pre-set periods then generate a default retention date for every document captured, which can be overwritten for specific patient records where required.
MediViewer prevents the unauthorised destruction/deletion of content (document, images and metadata) by requiring these processes to be conducted only by authorised users.
Reports can be generated within MediViewer to display selected records for destruction. MediViewer does not retain expiry dates against patient records, it applies the policy rules that are in force whenever the ‘culling agent’ is run – a scheduled activity that identifies candidate records for destruction. Candidate records for destruction can viewed in advance of deletion and the authorised user can either:
- Confirm scheduled destruction;
- Defer decision (although the record will continue to appear on the retention schedule as overdue);
- Apply new policy rules to recalculate the retention
MediViewer allows the Record Administrator to specify whether the digitised records should be logically or physically deleted. A logical deletion ‘hides’ the patient record from view (except for users with admin rights) but can be reinstated if required whereas a physical deletion is permanent. The administrator can configure MediViewer to define an interval between logical and physical deletion or default to immediate physical deletion. A batch job can be scheduled to run overnight that either logically or permanently deletes the patient records that have been authorised for destruction in accordance with these configuration settings. Finally, an appropriate audit transaction will be generated to record the physical deletion of the patient record/bundles, who authorised and when.
2. Individual’s rights to rectification, erasure, restriction
According to ICO web site “If a patient is diagnosed by a GP as suffering from a particular illness or condition, but it is later proved that this is not the case, it is likely that their medical records should record both the initial diagnosis (even though it was later proved to be incorrect) and the final findings. Whilst the medical record shows a misdiagnosis, it is an accurate record of the patient’s medical treatment. As long as the medical record contains the up-to-date findings, and this is made clear in the record, it would be difficult to argue that the record is inaccurate and should be rectified.”.
(https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation- gdpr/individual-rights/right-to-rectification/)
“Records should not be amended because of a request for access. Indeed, it is a criminal offence under the forthcoming Data Protection Act 2018 to amend or delete records in response to a SAR. Information which is clinically relevant must not be deleted from medical records. For electronic records, information can be removed from display but the audit trail will always keep the record complete”.
(https://www.bma.org.uk/-/media/files/pdfs/employment%20advice/ethics/access-to-health- records-may2018.pdf)
MediViewer does not allow for the amendment or deletion of any images stored within the patient record unless a record or part of a record is deleted in line with the Trust’s record management and retention policy. Any action associated with the image from viewing to changing meta data or refiling will generate an appropriate audit transaction.
Whilst the health professional is not obliged to accept the patient’s opinion, they may wish to capture the patient’s view within the record. If the patient wishes to submit correspondence requesting the rectification of information held about them this can be incorporated into the patient’s digital record.
In such circumstances, MediViewer allows for establishing a hyper-link between images. For example, if a patient points out that a GP letter contains a mis-diagnosis, they can request that a file note is appended to relevant correspondence. MediViewer allows the digital equivalent by allowing the linking of one or more images, regardless of where they are stored in the record, providing a visual prompt to the clinical user that there are additional notes relating to the image being viewed.
3. How do you demonstrate compliance with subject access requests?
MediViewer’s Medico-Legal module allows the creation and retention of patient specific record subsets or on a project basis (multiple collections of patient records or subsets), with a unique set of redactions. It is designed to support subject access requests, clinical audits, mortality reviews and legal requests.
Alternatively, they can append a comment to the image which will be made evident to any user accessing the image in the future.
3.1 How is a SAR captured and what information is captured?
MediViewer allows the capture of the original request for information and includes:
- Purpose of request (e.g. SARs, Tertiary care, Clinical Audit);
- Identity of requestor (e.g. patient, solicitor);
- Address and contact details (telephone numbers, email);
- Patient name(s) and identifier(s) (validated against PMI);
- Date of original request;
- Specifics of request (e.g. documentation relating to specific hospital visit);
- Required format (e.g. printout, encrypted CD, PDF or USB stick);
- Due date;
- Status (e.g. to be allocated, in progress, complete);
- Request owner (who will action the request).
3.2 What is a ‘reasonable’ request?
According to ICO guidance the Hospital can “refuse to comply with a subject access request if it is manifestly unfounded or excessive, taking into account whether the request is repetitive in nature” (https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation- gdpr/individual-rights/right-of-access/)
MediViewer will maintain a log of all requests made by a single patient and preserve the original collections of documents (with redactions) that have been despatched. This will assist in helping the Trust to determine whether the requests are excessively onerous and take appropriate action.
3.3 How do we track compliance meeting the prescribed time limit?
The user will have the ability to define a due date. Where the purpose is a SARs the due date can be set to auto-populate to 28 days from original request date although this can be overridden. Imminent or overdue requests can be reported upon.
3.4 What format should the information be presented to the requestor?
MediViewer will allow the user to print the requested redacted pages (with watermark) or create an encrypted PDF that can sent via email, CD or USB stick as required.
3.5 How do we capture and view historic requests?
Once a user has searched and found the correct patient record, they have the functionality to create a subset of documents or the entire record. Users can select the required documents using user-defined filters (e.g. correspondence only), encounter linking (documents relating to a particular stay or stays), via a performed OCR text search (looking for a particular key word (e.g. consultant or speciality name), a bundle type (e.g. entire maternity record), or the entire record. Once this subset of documents has been assembled the user can commence the redaction process on the selected documents where the redactions will only appear on the copied documents and not the originals.
3.6 Should annotations and digital signatures be included in the output?
When creating the output report or file, the user can optionally request that any text contained within annotations and associated with digital signatures can be included in the print out. This information will be printed onto a page immediately following the page it is associated with. This is set as an optional feature as it will be dependent upon the Trust’s own Record Management policy, whether annotations should be used for capturing clinically relevant information.
4. What level of access to patient records is appropriate?
Implied consent to patient records for provision of patient care is accepted, however it is incumbent on the healthcare organisation to ensure that level of access provided is appropriate according to role.
The level of access that a user has, and the activities they can perform within MediViewer are governed by the following access control mechanisms:
- Access control to function by authorised user role;
- Access control to specific document
MediViewer can also restrict access to certain patient records if the Trust EPR has flagged the patient as VIP or member of staff.
4.1 Role-based access
Access rights are restricted according to the role of a user. Although the creation of AD (Active Directory) roles are performed by AD administrators, MediViewer implements an ABAC (Attribute based access control) system that assigns authorization tickets (to access specific functionality) to users based on their attributes (such as AD group membership).
The role that a user is assigned will dictate the actions that the authorised user is able to perform by the appropriate application of authorisation tickets. All activities will be subject to full audit and accounting. The activities that will be regulated according to role are:
- Annotate a record: MediViewer has functionality that enables authorised users to add comments to a patient record;
- Redact a record: MediViewer has functionality that enables authorised users to highlight text and redaction features;
- Print all or part of a record: an authorised user will be able to print all or part of a patient’s record;
- Export patient information: an authorised user can select part or all of a patient’s record for the creation of an encrypted PDF. Typically this will be in response to a request for patient documents for tertiary care or in response to a Subject Access Request;
- Print cover sheets: these will provide a means of entering new patient documentation to the record for Medical Secretaries (e.g. filing) and Ward Clerks (e.g. patient temporary sets). The system has the potential to audit and track the production of cover sheets, flagging when cover sheeted material has not been scanned back into the system;
- Batch Manager: access to the back/forward scanning preparations and tracking module;
- Modify document meta-data: an authorised user can move specified pages or bundles within a record in circumstances where information has been misfiled within a record. This could arise where a page has been incorrectly identified or an incorrect bar-coded cover sheet has been used in front of a bundle of patient documents;
- Move material between records: an authorised user will be able to move pages/bundles between one patient record and another where that material was originally filed in the wrong record;
- Logically delete material from within a record: Where a page or pages have been incorrectly filed within a record, an authorised user will be able to remove the pages from view without physically deleting the information for audit purposes;
- System Configuration: typically restricted to a system administrator can manage user accounts, smart indexing rules
4.2 Handling sensitive documents
Some material within the patient’s record will be subject to additional security controls that will be exercised through the ‘sealed envelope’ function. Under this arrangement, a user will be made aware that the information that they are about to access in MediViewer is flagged as ‘restricted access’. Any user can gain immediate access and view this information if, in their judgement, there is a professional need to do so. The user will be made aware that either the Hospital Caldicott Guardian, SIRO or Information Governance team could be automatically notified of any such activities.
Examples of the type of documentation that will be controlled in this way are:
- Information pertaining to mental or sexual health;
- Certain categories of medical photography;
- Information pertaining to Child Protection and other Safeguarding
MediViewer takes a ‘bundle’ approach to stored documents; a bundle can represent a single document (such as an electronically-fed referral letter) or several ‘documents’ (such as is encountered when back-scanning a section of a historical paper based medical record). Bundles can have attributes representing virtually any detail the administrators wish to store. Commonly bundle attributes would be date/time of ingest, data source and bundle class – the ‘type’ of data this bundle represents (e.g. safeguarding). The ABAC access control model determines access rules based on a combination of both attributes from the user (AD group etc.) combined with attributes of the bundle. This means that the administrator can control who can see which bundles, with three levels of access:
- Deny access – the bundle is not visible to the user
- Challenge – the user is aware that the bundle exists, and can see limited meta-data (in search results etc.) but attempts to view the content leads to a customisable challenge that they have to accept (e.g. ‘Are you sure you have a requirement to view this patient’s safeguarding record?’) Challenge presentations and acceptances are recorded as distinct audit events so that Information Governance staff can readily filter for and review
- Allow Access – access
MediViewer is installed with a template security model configured to default ‘allow’ model for all but administrative and export functions, so regular users can see everything, but cannot export or print. However, simply setting the default rule to ‘deny’ blocks access to all except system administrators, who can then proceed to set up a very granular security model, if required.
5. What depth of audit information is required to monitor
‘appropriate access’?
MediViewer maintains a comprehensive audit trail that can be actively monitored by authorised personnel to help detect when inappropriate access has taken place. MediViewer provides querying tools for the audit transactions that can report on (not limited to):
- Accesses by a user
- Accesses to a patient record (including individual images viewed)
- Accesses by date range
- Accesses by transaction type (e.g. print)
All MediViewer users will have access to an audit trail within the patient record to be able to see who has viewed the record (or even individual page). Exposing this level of detail can act as a visual deterrent to expose inappropriate access.
This ensures that all activity can be audited and reported on by authorised users. Reporting can be scheduled to run weekly, monthly or on an ad-hoc basis. Reports can also be created as dashboards and presented to the user when accessing the administration console.
