Revert "Updates for control access to 0.7.3 #1161"

This reverts commit b70b6b9.
nhsconnect · May 3, 2022 · 7d26c12 · 7d26c12
1 parent c53ea07
commit 7d26c12
Show file tree

Hide file tree

Showing 4 changed files with 20 additions and 46 deletions.
diff --git a/pages/accessrecord/accessrecord.md b/pages/accessrecord/accessrecord.md
@@ -12,7 +12,7 @@ toc: false
 
 ## HTML view ##
 
-{% include custominfocallout.html content="<strong>Information:</strong> For Direct Patient Care purposes only, the Primary Care record contains a wealth of useful information which can improve patient safety and efficiency if it is made interoperable across health care settings (subject to [IG](designprinciples_ig_principles.html) and [Clinical Safety](designprinciples_clinical_safety_principles.html) requirements which consumers **MUST** meet and confirm compliance with during assurance). <br/><br/>Access Record HTML is delivering the capability to view a patient record and **MUST** be used in real time for read only. <br/><br/> Please refer to [NHS Digital - FAQ on legal access to personal confidential data - Definitions questions - How is Direct Patient Care defined?](http://content.digital.nhs.uk/article/3638/Personal-data-access-FAQs){:target='_blank'} for details of what constitutes direct patient care. " type="danger" %}
+{% include custominfocallout.html content="<strong>Information:</strong> For Direct Patient Care purposes only, the Primary Care record contains a wealth of useful information which can improve patient safety and efficiency if it is made interoperable (subject to IG and Clinical Safety requirements) across health care settings. <br/><br/>Access Record HTML is delivering the capability to view a patient record and **MUST** be used in real time for read only. <br/><br/> Please refer to [NHS Digital - FAQ on legal access to personal confidential data - Definitions questions - How is Direct Patient Care defined?](http://content.digital.nhs.uk/article/3638/Personal-data-access-FAQs){:target='_blank'} for details of what constitutes direct patient care. " type="danger" %} 
 
 
 ### Purpose ###
@@ -54,6 +54,6 @@ Please refer to the [AccessRecord HTML FHIR Resources](datalibraryaccessRecord.h
 
 The Access Record HTML capability message set includes the following set of Spine interactions:
 
-| Operation                 | InteractionID             |
-|---------------------------|---------------------------|
+| Operation                 | InteractionID             | 
+|---------------------------|---------------------------| 
 | [Get Care Record](accessrecord_use_case_retrieve_a_care_record_section.html) | `urn:nhs:names:services:gpconnect:fhir:operation:gpc.getcarerecord` |
diff --git a/pages/accessrecord/accessrecord_development_html_implementation_guide.md b/pages/accessrecord/accessrecord_development_html_implementation_guide.md
@@ -109,12 +109,12 @@ If differences exist then the consumer system **MUST** show an alert/warning and
 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` |
+| 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.
 
@@ -129,10 +129,6 @@ Where a patient is flagged on the Personal Demographics Service (PDS) as sensiti
 
 ## Section retrieval ##
 
-The consuming system **MUST** provide role based access controls to the HTML section retrieval at an appropriate level such that the consuming organisation can meet its obligations as described in the [Information governance principles](designprinciples_ig_principles.html) page.
-
-The consuming organisation **MUST** provide appropriate support to its users to understand the error messages associated with the HTML sections as follows.
-
 ### Error handling ###
 
 If a GP principal system can't meaningfully supply content for a requested HTML section (or subset of the Summary View) then the system **MUST** return the following HTML fragment in place of the HTML table.
@@ -237,3 +233,5 @@ The following HTML classes **MUST** be applied across the HTML view:
 | `gptransfer-banner`| Applied within the `<div>` tag of any section/subsection exclusion banner                | All views
 | `date-column` 	 | Applied within the `<td>` tag of any table column with a `dd-Mmm-yyyy` date format       | All views
 | `med-item-column`  | Applied within the `<td>` tag of a grouped distinct `Medication Item`       				| Medications (All Medication (Summary) & All Medication Issues only)
+
+
diff --git a/pages/designprinciples/designprinciples_ig_principles.md b/pages/designprinciples/designprinciples_ig_principles.md
@@ -1,11 +1,11 @@
 ---
 title: Information governance principles
 keywords: engage, fot, information, governance, infogov, ig
-tags: [information_governance,engagement,commissioning]
+tags: [information_governance,engagement,commissioning,first_of_type]
 sidebar: overview_sidebar
 toc: false
 permalink: designprinciples_ig_principles.html
-summary: "High-level principles related to information governance (IG) of data within the system"
+summary: "High-level principles related to information governance (IG) of data within the system for First of Type (FoT)"
 ---
 
 {% include important.html content="The principles below have been discussed and agreed in workshops with the GP principal providers and NHS Digital IG stakeholders.<br/><br/>
@@ -14,38 +14,35 @@ Review and agreement as to IG model changes (to accommodate additional capabilit
 " %}
 
 
+## First of Type (FoT) principles ##
+
 - provider systems **MUST** be compliant with NHS codes of practice and legal obligations, and their existing NHS contractual IG requirements - for example, the foundational requirements for the GP principal systems are covered by the GP Systems of Choice (GPSoC) IG v4 schedule as well as the other common authority requirements
   - requirements additional to these will be documented and included in GP Connect development, assurance and deployment activities and documentation  
 
 - the GP Connect APIs are for use in direct patient care settings only
 
 - the responsibility of ensuring that consuming suppliers' use of the GP Connect APIs is compliant with NHS codes of practice and legal obligations resides with the consuming supplier (not NHS Digital)
 
-- consuming organisations are responsible for data sharing agreements with data controllers, augmented by data controller-data processor contracts, IG process and policy and fair usage notifications if national agreements are not in place
+- FoT early adopter deployments will represent organisation groupings where the necessary data sharing agreements between data controllers, augmented by data controller-data processor contracts, IG process and policy and fair usage notifications are already in place - for example, existing federation or shared record groups
 
-- organisational data-sharing validation will be implemented as part of the Spine Secure Proxy (SSP) and therefore provider GP Connect go-live must not be dependent on local organisational data-sharing configuration to support this;  local organisational data-sharing rules **MUST NOT** be applied as part of GP Connect operation and **MUST NOT** be changed as a result of GP Connect
+- organisational data-sharing validation will be implemented as part of the Spine Secure Proxy (SSP) and therefore provider GP Connect go-live must not be dependent on local organisational data-sharing configuration to support this;  local organisational data-sharing rules **MUST NOT** be applied as part of GP Connect operation and **MUST NOT** be changed as a result of GP Connect 
 
-- consuming organisations **MUST** be N3, IGSoC and IG Toolkit compliant, and meet national requirements for:
+- FoT early adopter consuming organisations are N3, IGSoC and IG Toolkit compliant, and meet national requirements for:
   - technical (endpoint) security
-  - user authentication
+  - user authentication 
   - user authorisation
 
-- consuming organisations **MUST** seek permission to view from the Patient for any information supplied via a GP Connect service; in scenarios where the patient is not present, for example a referral to an outpatient clinic where it would be reasonable to review the GP record prior to the appointment, access to the record can be made based on a Legitimate Relationship with the patient, subject to Data-Sharing agreement and absence of Provider System Patient Dissent to share indicator
-
-- consuming organisations **MUST**
-  - ensure the service is only accessed for the sole purpose of supporting direct patient care, and
-  - ensure appropriate role-based access controls are applied such that only appropriate users are able to access the service, subject to the extent to which it can be limited for each capability, and
-  - be aware of any limitations set as to the extent of access allowed for a healthcare setting and / or user role, and ensure such limitations are robustly applied
+- Consuming Organisations **MUST** seek permission to view from the Patient for any information supplied via a GP Connect service; in scenarios where the patient is not present, for example a referral to an outpatient clinic where it would be reasonable to review the GP record prior to the appointment, access to the record can be made based on a Legitimate Relationship with the patient, subject to Data-Sharing agreement and absence of Provider System Patient Dissent to share indicator
 
 - the presence of any local patient dissent to share flag within a GP Practice system **MUST** be implemented when accessing the patient medical record and cannot be overridden by consent given at the point of care
 
-- functionality to support the application of an exclusion set **MUST** be provided;  the current Royal College of General Practitioners (RCGP) sensitive dataset for specific conditions (for example, sexual health, HIV and so on) will be applied (excluded) with any changes arising from national policy to be reflected
+- functionality to support the application of an exclusion set **MUST** be provided;  the current Royal College of General Practitioners (RCGP) sensitive dataset for specific conditions (for example, sexual health, HIV and so on) will be applied (excluded) for FoT with any changes arising from national policy to be reflected
 
 - any data marked as private/sealed/locked/practice-designated confidential within the GP Patient record **MUST NOT** be shared outside the practice
 
-- the Access Record HTML view will provide appropriate indication of withheld data
+- the Access Record HTML view will provide appropriate indication of withheld data 
 
-- audit requirements as defined in existing contractual frameworks as well as the NHS Digital assurance process **MUST** be met by provider and consumer systems
+- audit requirements as defined in existing contractual frameworks as well as the NHS Digital assurance target operating model **MUST** be met by provider and consumer systems
 
 - 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
diff --git a/pages/overview/release_notes/0_7_3.md b/pages/overview/release_notes/0_7_3.md
@@ -36,26 +36,5 @@ Please see below for further details.
 
 ---
 
-### Consumer limitations set for some healthcare settings / roles  ###
-This change does not impact technical delivery of the API and as such NHS Digital have chosen not to uplift the version number of the specification to avoid confusion with Supplier delivery and compliance.
-
-**Tickets**:&nbsp; [#1161](https://github.com/nhsconnect/gpconnect/issues/1161)
-
-**Affects:**&nbsp; Core, Access Record HTML
-
-**Description:**
-
-- Added bullet point to the information governance principles to require consumers to apply role based access controls in support of direct care access and to ensure any limitations to the extent of access for their healthcare setting or user roles is applied e.g. limitating some users to a subset of the HTML views
-- Removed references to first of type in the information governance principles to bring it up to date
-- Strengthened note on the HTML introduction for consumers to meet the IG and clinical safety requirements
-- Added note to the implementation guidance section retrieval section to note need to meet IG principles in controlling access to the views required or permitted by user roles
-
-**Pages changed:**
-
-- [Information governance principles](designprinciples_ig_principles.html)
-- [Access Record HTML Introduction](accessrecord.html)
-- [HTML Implementation Guidance - Standards](accessrecord_development_html_implementation_guide.html)
-
----
-
 **Information associated with the current emergency can be found here [nshconnect/gpconnect-emergency-codes](https://github.com/nhsconnect/gpconnect-emergency-codes)**
+