PDS Test Patient - Int environment Issues

[Kevin_Mayfield]

Is it possible to protect our test patients from modifications by others? Or get the test patients reloaded periodically (overnight?)

We’re establishing a multi NHS Trust and Diagnostic system which involves several organisations using the same PDS test patients.

We are finding our test patients are getting unrealistic modifications. For example:

Our Sansa Manchester (9737383192) patient has been given an Indian like name, also become Cersei London (9737383230) and also moved to Scunthorpe. (NHS Number didn’t change just the demographics)

This causes our IG and data quality checks to start rejecting clinical interactions we are testing. At present this is a local issue with NHS trusts in two ICS (one region) but we are likely to add a second region (so whole of the North).

[dunmail]

It’s been a frustration for a couple of years:

PDS API Patient search returns unexpected match

Whilst the test data page says that the data are read-only, in reality they can be updated by users of the system and therefore can differ from the details in the spreadsheet. This is compounded by the problem that @chris.clarke described where the data underpinning read and search interactions become unsynchronised. You can request a dataset specifically for your own use that is less likely to be modified.

I would be delighted if the static data stopped changing …

[Kevin_Mayfield]

I should have checked that either you or @iminshall had raised this before.

We originally noticed this issue around the old EDITESTPATIENTS (for pathology) and decided to create our own for genomics.

Most of the test systems already had these EDITESTPATIENTS and we would have reused them (we are a variation of this and so it makes sense).

We’re about to extend the use of our test patients across “The North”.

[Adrian_Hall]

I’m not sure it is possible to stop this happening. Other consumers should not be using your test data, but marshalling that is very hard.
Reloading patients can’t be done globally, because state needs protecting. I’m not sure what processes are available for your circumstances, but I will ask around.

I’m assuming you have raised a service desk ticket about it?

[dunmail]

Issue raised 3 years ago, but no resolution.

Our approach for testing is to pull current state from PDS INT during initialisation of a regression test suite and then use that state to infer tests. For example, if 4123456789 has surname Smith, we expect to match Patient?name=Smith. This limits some of the regression tests we can conduct, but means we are only exposed to changing state for the duration of the test suite.

It’s not a viable option for testing across multiple systems (i.e. Kev’s case) unless they all use PDS as their MPI.

[jakob]

Changes in INT messing up patients seems to be a common problem across services. GP Connect errors for integration testing

[Nicholas_Hunt]

You can use TDSSP to reload your own PDS packs into spine PTL. This will re-baseline the records to how they are defined in TDSSP, effectively negating any changes that might have been made outside of TDSSP.