• profession

• medical region (deanery)/ dental region/ pharmacy region

• specialty

• stage Staff Group

• Preferencing regions and sub-regions

• Training Programme

• Grade (eg Foundation, core, higher specialty)

• type Type (eg standard / academic / priority)

  • The above is not explicitly on Oriel but will be derived from combinations of fields including Staff Group, Training Programme and Grade

• Vacancy title

• Deep Unique link to vacancy on Oriel 

• Vacancy Post type (eg core training; foundation training)

• Staff Group (eg medical, dental)

• Specialty/sub-specialtyTraining Programme

• Grade (eg ST3, CT2)

• person specification

• Lead Recruiter

• Lead Recruiter contact details

• Applications opening and closing dates (including future recruitment round dates if applications are currently closed)

• Country recruiting for - eg England/Wales/Scotland/N Ireland/UK-wide

• Regions/deaneries/units of application recruiting for 

• Training programme commencement date

• Salary

• programme reference

• programme name

• programme sites - locations and trusts/providers

• Number of places

• lead employer trust

• competition ratio

• post reference

• post nameVacancy Advert Description

• Vacancy RO

• Main contact for person/office for queries

  • In most cases this will be a generic email address

• Application opening/closing date/time

• Recruiting for (multi select)

  • This may be a country or a region/sub-region

• Preferencing regions and sub-regions (all potential offer regions) 

• Post commencing from

• Salary

  • This is not stored on Oriel and will instead be determined by grade

• Programme Number

  • This field will not be populated in all vacancies but provide wherever possible

• Programme Name

  • This field will not be populated in all vacancies but provide wherever possible

• Programme Sites - locations and trusts/providers

  • This field will not be available in all vacancies but provide wherever possible

• Number of places

• Lead Employer Trust

  • This field will not be available in all vacancies but provide wherever possible

• Competition Ratio, (i.e. the number of posts compared to the number of applicants in the previous year

  • This data is not available on Oriel and will need to be sourced from historical Oriel data held by the Recruitment Team or Local Offices

• Offer code of preferences/sub-preference/programme preference

• post site - trust/provider and locationpost department

  • This field will not be available in all vacancies but provide wherever possible

• Number of places

• post durationPreference/sub-preference/programme preference duration

What is the frequency of requests to the API? On demand, hourly, daily etc?

Hourly

Not all of the data fields above will refresh so regularly. Many will refresh daily, yearly or not for the foreseeable future.

Are you expecting the full dataset to be returned in the API to only be the changes or the full data set each time?

Full data set

As per above, is the full data set in fact required hourly or can this be refined to a subset based on key points in the recruitment cycle when these fields can actually change in Oriel?

How would you like us to handle records that are removed or archived? For example, if a vacancy is archived would you prefer we keep this in the extract but identify it in a certain way?

Still return but flag as archived

The API we would look to create would be RESTful passing JSON data structures as needed, would this pose any issues?

RESTful JSON is fine

The API itself would be secure via a client certificate we would provide to you and only accessible from designated IP addressed. Again, do you foresee any issues with this?

Authenticate via an auth token instead

Some vacancies have multiple layers of preferencing. For example an applicant may first rank regions and then rank individual posts within that region as a separate activity. How do you see this working? Would we always extract the lowest level of preferences to you?

All levels of preferencing needed. Lowest level information would need its own ID and higher level IDs. In the example instance we would be likely to make two calls - one for the region and one for the individual posts. We can send an example of how we think the JSON could be structured.