New /api/initialise handling procedures for PulseTile

[robtweed]

Changes are needed to PulseTile to cater for the new Discovery Data Loading step.

The Helm back-end now includes an initial first step at login, whereby it checks for any new data for the user in the Discovery database, and merges it into the EtherCIS system.

The very first time a newly-onboarded user logs into PulseTile, there will potentially be a sizeable quantity of data needing to be loaded, so we can expect a potentially significant delay before the user's records are set up in EtherCIS.

However, on subsequent logins, there may also be new data in Discovery that needs to be merged - so, although not likely to be as long a delay as at very first login, we need to be prepared for a bit of a delay every time a user logs in.

Once logged in, however, QEWD caches the EtherCIS data, so the performance is extremely good after the initial data loading.

In order to handle this, the /api/initialise API has been changed significantly in its behaviour, and PulseTile will need to be amended to properly cater for this behaviour.

Here's how it will work:

When the user has successfully logged in and PulseTile loads into the user's browser and sends the /api/initialise request, it will immediately get back the JSON response:

{
  "status":"loading_data",
  "new_patient": true | false
}

The "new_patient" property will be true if this is the very first time the user has logged in, and potentially PulseTile can expect a longer delay in loading time that if "new_patient" is false.

In the background, QEWD will now be busy loading data from Discovery into EtherCIS for the user.

PulseTile now needs to introduce a polling step, as detailed here:

** Polling Step:

What PulseTile should now do is to:

a) Display something to keep the user busy / pre-occupied whilst also informed that their data is being prepared.

b) Regularly re-send /api/initialise requests

If an /api/initialise request is sent and QEWD is still busy loading the user's data, then you'll get back the same response as before:

{
  "status":"loading_data",
  "new_patient": true | false
}

in which case you repeat the above ** Polling Step

Data Loading Complete:

If QEWD has finished loading the user's data, then the /api/initialise request will return the response:

{
  ok: true,
  mode: 'secure'
}

which, of course, is what QEWD previously would have returned.

If this response is received, then PulseTile can continue as usual, loading up the user synopsis screens and demographics info.

Suggested Polling Rates:

In terms of polling times, I'd suggest that for a new user, PulseTile polls every 5 seconds or so. For an existing patient, polling can be every 1 - 2 seconds

For a very large initial data load, we might be looking at a 5 minutes or longer delay. My guess is that most existing users will have their data updated within about 5 seconds or so, often much more quickly than that, but we need to get some experience of how they behave in reality.