Skip to main content

Focusing Manager

The Focusing Manager is the central orchestration component of the Focusing module that coordinates all steps of the personalization workflow.

Responsibilities​

1. Service Discovery​

  • Discovers Preprocessors via Kubernetes labels: 
    eu.gravitate-health.fosps.preprocessing=true
  • Identifies available Lens selectors (which retrieve and list available Lenses) via Kubernetes labels: 
    eu.gravitate-health.fosps.focusing=true

2. Workflow Orchestration​

  1. Receives requests to initiate focusing with necessary data (ePI, IPS, PV) in various methods/formats (IDs, JSON, XML, turtle)
  2. Retrieves referenced resources if needed
  3. Invokes Preprocessors in sequence
  4. Selects/discovers Lenses
  5. Calls LEE with p(ePI), IPS, PV if provided
  6. Returns f(ePI) to requester in the desired format

3. Data Management​

  • Queries FHIR Server for resources if referenced by ID
  • Manages preprocessor stacking (sequential execution)
  • Caches preprocessed data if needed for performance (different layers of caching can be implemented: in memory, Redis, etc.)
  • Handles LEE execution context and data passing
  • Transforms and formats data as needed for different steps (e.g., converting between JSON and XML when needed)

The Focusing Manager supports different input, output formats and invocation methods, allowing for flexible integration into various user interfaces and workflows. The core requirement is that the necessary data (ePI, IPS, optionally PV) is provided in a format that the focusing process can consume:

ePIIPSPV (optional)
Implicit (referenced) in http post parameterepiId (retrieved from FHIR_EPI_URL endpoint)patientIdentifier (retrieved from FHIR_IPS_URL endpoint)personaVectorID (retrieved from PERSONA_VECTOR_URL endpoint)
Implicit (referenced) as URL parameter/focusing/focus/{epiId} (retrieved from FHIR_EPI_URL endpoint)
Explicit Serialized in the post body. by setting Content-Type http header select the formatepi (if ips and pv are referenced)ips (if epi and pv are referenced)pv (if epi and ips are referenced)
Explicit Serialized in multipart post body, by setting Content-Type http header for each part/file select the formatepiipspv

Additionally an Explicit legacy JSON can be provided in the post body. This is A JSON object with epi, ips, and (optionally) pv attributes, each with their respective JSON representation.

{
  "epi": { ... },
  "ips": { ... },
  "pv": { ... }
}

By setting the Accept header in the request, the client can specify the desired output format (e.g., JSON, XML, Turtle) for the focused ePI response.

Acceptable content types for input and output include:

  • JSON: application/fhir+json, application/json,
  • XML: application/fhir+xml, application/xml,
  • RDF/turtle: application/fhir+turtle, text/turtle, text/n3,

Architecture Position​

Located in the Service Layer of FOSPS.

API Endpoints​

Exposes OpenAPI documented endpoints for:

  • focusing
  • retrieving available preprocessors and lenses
  • retrieve p(ePI) by executing preprocessors (if not cached already) without focusing
  • Status and health checks

Integration Points​

Stacking Logic​

Manages Preprocessor stacking:

  • Executes preprocessors sequentially
  • Each preprocessor receives output of previous
  • Builds complete p(ePI) with all annotations