PDS FHIR API test packs - inconsistent data

We’re currently in the process of writing integration tests against the PDS FHIR API (Application Restricted), using the test data packs provided: PDS FHIR API test data

Using the General Tests: All PDS data (all-pds-data2.xlsx), we haven’t gotten very far before running into inconsistencies between the test packs and the data returned by the integration API. It states that it is read-only, but some of the inconsistencies with names suggest that it they may have been modified.

It also states that it should be used to test retrievals by NHS number, which I would assume means that each row should return a valid patient.

We’ve only done some very brief testing so far, gotten as far as ensuring we’re parsing the responses correctly, and checking the names for each record.

I guess we have two questions:

  1. Are the data packs meant to differ this much from the integration API? It makes verifying the tests very tedious.
  2. Where non-spec compliant responses are returned, is this likely to happen in the production API also? Do we need to make affordances for these cases?

Findings below:

  • 6 resources are returning INVALIDATED_RESOURCE, that aren’t noted as invalidated in the pack
    • 9449306699
    • 9449305102
    • 9449310378
    • 9449310718
    • 9449310599
    • 9449310408
  • 18 have family names that are not present in the names returned by the API
    • e.g. 9449304424: test pack = “AINDOW”, API responds with “Jones” (no history)
    • 9449304424
    • 9449306583
    • 9449306559
    • 9449306044
    • 9449306508
    • 9449308136
    • 9449303371
    • 9449303282
    • 9449303274
    • 9449303231
    • 9449303363
    • 9449303355
    • 9449303347
    • 9449303339
    • 9449303320
    • 9449303312
    • 9449303304
    • 9449303290
  • 6 patients are returning the text “Usual address for patient X” for each address, instead of one of the cases defined in the OpenAPI spec
    • 9449310351
    • 9449310343
    • 9449310688
    • 9449310432
    • 9449310572
    • 9449303266
  • Unknown number with mismatching given names

Many thanks,

Hi Dec,

unfortunately, while it’s stated that the test pack data is read-only, it’s not functionally possible to disable write access.

As such we have some inconsiderate users that modify the data in the test pack, rather than requesting their own set of data to test modifications

It’s worth raising any inconsistencies you see with TEST, Data (NHS ENGLAND - X26) testdata@nhs.net as these records can be reloaded.

You can also contact them if you’d like a set of data that you can use for testing modification

Hi Chris,

Thanks for letting me know; we’re not looking to enable modification of records, but will flag the inconsistencies with them.

Would you suggest any other approaches to access a stable data set? Would setting up our own test data using TDSSP host the data in a separate environment (ie. would it prevent others from potentially modifying the records)?

Many thanks,

apologies for hijacking this thread however it relates to the test data

i’m looking at superseded and invalidated records and when looking at the test data on the website for those specific scenarios I either get

“Error while calling the external API.Received an unsupported resource type: OperationOutcome”

or the patients just don’t exist

i’ve been given other test data and still no luck

It would be great if we could have static data so that us devs can meet the requirements without having to keep going back to test data team

alternatively examples of FHIR responses for those given scenarios would be beneficial

1 Like