7. Data - nhsconnect/nrls-reference-implementation GitHub Wiki

7.1 The Data Store

The data store is a MongoDB data store, connection details to this store for the Demonstrator and NRL stub can be found in each of the respective solutions appsetting files.

The data specific to the Demonstrator and the NRL stub are held in their of respective data bases within the MongoDB instance.

We are using one single instance on MongoDB here but it is possible to use multiple.

The following services require the data store:

  • Demonstrator Front end
  • Demonstrator Back end and fictitious EPR
  • NRL Stub
  • ODS Search
  • PDS Search
  • SSP Stub

7.2 Default Data and Examples

As part of the deploy process the default data is dropped and rebuilt.

The default data is a set of basic JSON files located at \[Repo-Root]\data\defaultdata

7.3 Refreshing and Adding data

In the data directory \[Repo-Root]\data there is a sub folder named cmds.

This folder contains helper files to quickly refresh all user and app data.

To refresh the data or makes changes and redeploy, make any changes required and the just run the respective run file.

7.3.1 Adding New Entries

You can add new entries to each default file. When doing so it is advised to pre-populate the MongoDB Id for each.

This can be achieved by running the mongo shell commands and then running the command new ObjectId() to obtain a new Id.

The main reason for this is because some data types contain related resources and having the ID available now allows you to pre-populate the relationships.

Yes I did say relationships.

7.3.2 Linux and Windows data

There is a version of the helper commands for both Linux and Windows.

Changes to either must be replicated across.

7.4 The Structure

7.4.1 Demo App Models

ActorOrganisation

The model attributes can be viewed in the repository.

Personnel

The model attributes can be viewed in the repository.

GenericSystem

The model attributes can be viewed in the repository.

NRLSPointerMaps

No default data is stored. This data is auto generated via the Back end and is used to map a Medical Record to a DocumentReference.

MedicalRecords

No default data is stored. This data is generated via the Back end when creating a care plan in the front end app.

7.4.4 Shared Models

The following models are utilised by both the Demo Apps and NRL Reference Implementation.

Patient

A simple list of STU3 FHIR Resources of type Patient.

Attributes of note:

  • Identifier
    Contains the NHS Number
  • ManagingOrganisation
    Contains the ODS code that matches an Organisation below

Organization

A simple list of STU3 FHIR Resources of type Organization.

Attributes of note:

  • Identifier
    Contains the ODS code for the organisation referenced in Patient, SDS, and DocumentReference resources.

SDS

The model attributes can be viewed in the repository.

DocumentReference

A simple list of STU3 FHIR Resources of type NRL DocumentReference.

Attributes of note:

  • Subject
    Maps directly to a Patient, detailed above
  • Custodian & Author
    Maps directly to an Organization, detailed above

7.5 Data Map

The diagram below depicts how the data relates to one another and where within the authentication and authorization flow they fit.

NRL Data Map

Step-by-step process (provider example)

  1. Provider organisation assured system generates and sends a HTTP POST message to the NRL

    1. Included in the HEADERS

      • Provider ASID
      • Authorization as an encoded JWT
      • additional headers will also be sent

    2. Included in the BODY (DocumentReference)

      • Subject (patient NHS Number)
      • Custodian (Provider organisation ODS code)
      • Content[x].attachment.url
      • additional properties will also exist on the body

    3. In LIVE service an x509 certificate is also sent

  2. The POST interaction is checked to ensure Provider is allowed to do this using the ASID HEADER value
    The x509 certificate would normally also be checked to ensure it matches the ASID supplied and the Providers associated FQDN

  3. The Authorization (JWT) value is checked to ensure that the included values are valid

  4. The ASID is checked to ensure it is associated to the Custodian ODS code included in the BODY

  5. The Custodian and Author ODS codes included in the BODY are checked to ensure they exist and are valid

  6. The NHS Number included in the BODY is checked to ensure it exists

  7. When a Consumer attempts to retrieve the record referenced in Content[x].attachment.url the first part of this is checked against the Endpoints registered for the associated Provider