Page Comparison

API:

1. Interaction style/pattern:

   1. Existing paradigm of TIS request to GMC Service is more consistent;

   2. registering a TIS service that the GMC notifies of changes to the List of Registered Medical Professionals.

   3. Drop the GMCDetails table, each time GMC data is needed (e.g. doctor page view)

   4. Upsert a person record triggers a call to persist the GMC data in TIS.

Operations:

1. They are:

   1. "Get all doctors"

   2. "Get doctor number 9999999"

   3. "Get doctors updated since ddmmyyyy"

   4. something else?

2. We could make use of the 1st planned Operation (ii) but would prefer to make use of (iii), especially if specifying a very old dateSince on a “Get Doctors Updated Since” could replace the “Get All” operation.

3. Assumption is TIS would call (iii) daily but should evaluate whether calling it more frequently would make much difference.

Batching/Paging:

Batching/Paging of Response data is desirable if there are more than c.?10,000? records; will also need to consider batching of requested data if we have large numbers of trainees that are bulk uploaded.

Format:

1. A RESTful JSON Service would be preferable, but

2. we are just as happy to create a SOAP WebService (like the revalidation services).

Data:

1. We assume the response will include the full dataset but only intend to use Status, Start & End Dates.

2. We expect to match on Surname & GMC Number but could use further demographics (e.g. Forename or Gender).

3. We only ever want the current information.

GMC's MVP/Pilot:

The pilot of “Get Doctor By GMC Number” probably involves (subtasks);

1. search for GMC data on Create or Update of Identifying information (Surname or GMC Number).

2. scheduled job to run a search for all doctors.

What (if any relationship) is there between the DoctorsForDesignatedBody (revalidation) and the LRMP data? Does LRMP include more than just the doctors that we would be interested in? LRMP contains c.308K records.

Are there existing WebService Operations that could include LRMP data? No

If it were needed before a pilot is ready; we could create a Client to:

1. Get the zipped CSV resources, or if that isn’t possible

2. use something like GreaseMonkey (or import.io) to simulate logging in and scraping the resources page.

Do we have the current SFTS doc/data spec? Is data well populated (esp. Gender)?

Are there metrics (Google Analytics, person page per. week) that we can get ahead of talking to the GMC team (Pete et al.)?

Should we take LRMP data from ESR, which is taken from GMC until there is a GMC Service available?

Pete:

We don't have an LRMP API at the moment.

We hope to build and pilot one later next year.

What would your use case be?

• A - "Get all doctors"
• B - "Get doctor number 7654321"
• C - "Get doctors updated since ddmmyyyy"
• D - something else?

... as I expect our MVP and pilot version is only likely to deliver 'B'.

Your intended usage may help us steer our roadmap.

TIS Team:

• The A → C →  B is how we’d imagined a go-live would be implemented in terms of an order of what we'd use. In terms of frequency we’d use it (C → B → A); would be C daily, B on updates/creation of trainees, A to load and possibly at infrequent intervals.
• We're also doing some thinking about what it would look like and wanted to clarify what was meant in 2); was it every time a user looks at the record or just on every 'save' action that changes the 'identifying information'

A couple of challenges for consideration/discussion:

• Is it good API design for us to provide a payload of ~308,000 doctor records on a single API call?   Would you want us to serve that method on demand?  Hourly maybe?  Bear in mind we would likely have hundreds of subscribers.  I personally struggle to see how such an API call would be workable at scale.

• Is there really a requirement to keep the TIS system fully synchronised with our data?   What about taking a different approach – where GMC data isn’t stored at all, but instead; every time you reviewed a record in TIS, it called our API and retrieves that individual’s data in real time?  Would you agree that this is more in the spirit of modern API architecture?