Content Library & Medical Services

Alongside the check flow, the Symptom & Illness Check API exposes three lookup families that work without an ongoing check — no check-id header, just authentication. Use them to build search screens, "find a doctor" features, and the bridge between a report and local care.

Content Library

Content Library is the medical knowledge base the checks themselves run on: every symptom and illness with descriptions, categories, ICD-10/UMLS codes, and the medical sources behind them. Reach for it when you build a symptom/illness search or autocomplete (for example to obtain a mainSymptomId for initialization), an illness detail page, or when you need to show the publications an illness's content is based on. Endpoints: universal search, illness list, illness details, illness sources, and symptom details.

Example: search by term

GET /v1/contentLibrary?top=5&searchTerm=tension%20headache
language: en

{
  "count": 73,
  "items": [
    {
      "id": "3416dc71-b330-4b85-bc21-ef33ba0b3369",
      "name": "Headache",
      "type": "SYMPTOM",
      "description": "Deep pain sensation in the head",
      "isFrequent": true,
      "code": { "coding": [{ "code": "C0018681" }] }
    },
    {
      "id": "c1b6e0d4-2f3a-4e8b-9a71-5d2c8e4f6a10",
      "name": "Tension-type headache",
      "type": "ILLNESS",
      "description": "Tension-type headache is the most common form of headache...",
      "isFrequent": true,
      "code": { "coding": [{ "code": "G44.2" }] }
    }
  ]
}

The type field tells symptoms and illnesses apart in the mixed result list; the code carries the UMLS code for symptoms and the ICD-10 code for illnesses. Search matching can be medical rather than alphabetical, so result names do not always contain the search term literally. See GET /v1/contentLibrary for all parameters.

Notes

• Content Library paging: count is the total number of items matching the filters, ignoring top and skip — that is what makes it usable for paging. Page with top/skip and keep showing count as the overall total.

Medical Services

Medical Services finds real-world care providers — doctors, pharmacies, hospitals — by location and filters (name, gender, specialization, insurers, opening hours), plus location-independent virtual services. Reach for it when a report should end with "here is who can help nearby". The intended flow is: check what is supported in the country (features), fetch the available filters (filters), let the user pick values and apply them (filters/apply), then show a detail page (service details). If the user's map position can cross a border, run the selection through filters/borderChange; for telemedicine-style offers use virtual services.

Example: apply filters

POST /v1/services/filters/apply
language: en

{
  "genders": ["80e5d6f2-d486-45c7-8e3e-7e73e3dd0519"],
  "location": { "latitude": 48.218323, "longitude": 16.32402 }
}

{
  "count": 1,
  "items": [
    {
      "id": "e6d452f3-32c3-4738-a820-b3812b75583e",
      "name": "Dr. Anna Beispiel",
      "type": "DOCTOR",
      "gender": "FEMALE",
      "phone": "011234567",
      "location": {
        "country": "AT",
        "zip": "1170",
        "city": "Wien",
        "address": "Musterstraße 1",
        "latitude": 48.219104,
        "longitude": 16.326217
      },
      "specializations": [
        { "id": "a7c31b02-88d4-4f2e-9c65-3d1e0b7a54c9", "name": "Dentist", "type": "DOCTOR" }
      ],
      "openingHours": { "...": "..." },
      "monogram": "AB"
    }
  ],
  "serviceDetailState": { "isAllFeaturesAvailable": true }
}

The filter values (genders here) are not free text — they are the option ids returned by GET /v1/services/filters for that location. See POST /v1/services/filters/apply for the full parameter set, including selector for trimming the response.

Notes

• Medical Services counts differ: on filters/apply the count is the number of items in the returned page, while on virtual services it is the total without top/skip. Don't assume the Content Library semantics carry over.
• Filter keys come and go: on GET /v1/services/filters, any filter key except name can be absent — filters differ per country and per selected specialization type (for example, the HOSPITAL type has no gender filter, so genders is omitted). Build the search form from the response instead of hardcoding filter keys. Exactly one of countryCode or location must be provided.
• The 250-result cap and the radius rule: on filters/apply, the maximal result count is 250 — except when limiting by radius (limit: { radius, unit }), where the cap does not apply but the radius itself is capped at 10 KM or MI, and the unit is required. location is mandatory on this endpoint; genders accepts at most 2 values and specializations at most 15.
• Virtual services are location-free: POST /v1/services/virtual has no location/countryCode filtering at all; types is the only required body field.

Specializations

Specializations deals with medical specializations as filterable entities: list all specializations to build a specialization picker for the Medical Services filter, as the reference app does, and get localized details for XUND specialization ids. Reach for the details lookup when a report's illnesses carry specialization references (localSpecializations) and you want to turn those ids into named, localized specializations — for example to pre-fill the Medical Services specialization filter and route the patient to the right kind of doctor.

Example: localized details for XUND ids

GET /v1/specializations/convertFromXundSpecializationsAndGetDetails?xundSpecializationIds[]=84ed952b-cadf-42ad-a70d-71fdc6d5894d&xundSpecializationIds[]=85d0eae0-4123-4350-9c90-a5981f89363a
language: en

{
  "84ed952b-cadf-42ad-a70d-71fdc6d5894d": [
    {
      "id": "84ed952b-cadf-42ad-a70d-71fdc6d5894d",
      "name": "Gastroenterology and Hepatology",
      "type": "DOCTOR"
    }
  ],
  "85d0eae0-4123-4350-9c90-a5981f89363a": [
    {
      "id": "85d0eae0-4123-4350-9c90-a5981f89363a",
      "name": "Visceral Surgery",
      "type": "DOCTOR"
    }
  ]
}

The response maps each requested id to its own localized details, so the ids in the response equal the requested ones — the one-element array shape is kept for compatibility; ids that do not match a known specialization are silently omitted rather than rejected. See the reference page for language-fallback behavior.

Notes

• The specialization list is not country-specific: the countryCode path parameter of GET /v1/specializations/{countryCode} is required but ignored — the returned list is the same for every country.