Developed by Dr. P. S. Ramkumar (ITU)

5.1 Requirements

The Cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the architecture specification document.

5.1.1 Source code considerations (RECOMMENDED)

Since Scheduler provides time-based triggering of various Building Blocks/Applications, the Scheduler Building Block may use pre-compiled code in the microservices instead of run-time interpreter-based scripted code, to minimize latency in utilizing the time-keeping functions of the underlying operating system.

5.1.2 Infrastructure considerations (RECOMMENDED)

For mission-critical applications, it is recommended to use Scheduler as an embedded internal block of the target Building Block or application. In general, for minimizing internet latency it may be suitable to collocate the scheduler in the same infrastructure hosting other Building Blocks. Multiple instances of Scheduler Building Block may be hosted with load balancing in high-concurrency demand.

5.1.3 Audit considerations (REQUIRED)

Building Block must provide internal functionality to log and report indicators (such as latency, traffic density, queue depth, system resource consumption, service exceptions, and failures, etc.) provisioning and maintaining adequate Quality of Service (QOS). Building Block must provide internal functionality to configure rules to monitor, detect and notify QOS issues to Administrators.

5.1.4 Service caller authentication (REQUIRED)

In all service calls to the Scheduler Building Block, the requestor's token (maybe JWT containing requestor's authentication and requesting application ID) will be published along with the payload of the request, as a security requirement. The BB must be able to independently verify the token with a central IAM server to make sure the service call is from an authenticated user and from an authenticated Application within Govstack.

5.2 Exceptions to Architectural Cross-Cutting Specifications

5.2.1 SQL/NoSQL databases

Local factors (cost, convenience, existing Databases, skillsets, suitability of data structures, etc.) of a given target demography will influence this decision. In practical settings, such factors may lead to an implementation time decision of appropriate databases. From GovStack's point of view, the Scheduler Building Block needs to be agnostic to the type of database implementation and allow flexible choice.

5.2.2 Use of stored procedures

Several mundane localized operations on data such as searching, filtering, and format transformations may find a better performance by being collocated with the database itself in the form of stored procedures in typical SQL databases. Such procedures must be configured to handle the concurrent processing of multiple requests, with an appropriate mechanism (e.g. SQL agents/SSIS packages/service brokers/etc.). Since data is collocated with the code, when scaled up to clusters of multiple instances of database servers, each instance will utilize local Safeguard for Privileged Sessions. However, this will create an additional burden on maintenance and update of source code as applications may have part of logic in backend code and partially embedded in database servers. To host complex queries related to data from different databases it is recommended to implement it in business logic rather than stored procedures. In this case, scalability must be ensured by suitable application infrastructure scaling mechanisms such as Virtual Machine-level scaling and automatic elastic frameworks.

5.3 Standards

The following standards are applicable to data structures in the Scheduler Building Block:

Typical data structure requirements and format representations relevant to this Building Block have been . However, the schema and data elements are optimized for minimizing footprint and external dependencies, given that this Building Block handles time-critical alerts. The common minimum datasets have been described in the schema and the table in the Data Structures Section.

10.1 Key Decision Log

A historical log of key decisions regarding this Building Block.

10.2 Future Considerations

.

10.3 Use Case Examples

10.4 Digital Infrastructure for Vaccination Open Credentialing

.

The various actors and their activities described in section 2 must be supported by a set of non-redundant, Key Digital Functionalities listed below:

4.1 Event Management

Authorized organizers of a host entity (such as health workers/admins/etc.)must be able to create and manage schedules of events involving several resources, subscribers, and activities that have to be reminded/triggered/informed through alerts at appropriate times before/during/after the event. Schedules of multiple events can be configured, tracked, and managed, avoiding any duplication.

A Set of microservices are defined to receive requests from other GovStack-compatible Building Blocks and applications with relevant inputs and return processed results from key digital functionalities of this Building Block. This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.

Scheduler must expose its microservices through RESTful API interfaces as defined by OpenAPI v3+ standards. The Scheduler must have any response data payload it returns through its API only in the form of JSON formatted datasets. A summary of the APIS exposed by this Building Block is summarized in the table below. The Scheduler Building Block can be used also as an internal sub-block of another Building Block. In such a case the same services APIs will be used to embed the Scheduler Building Block (without having to pass through the Information Mediator).

The GovStack non-functional requirements document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.

The tests for the Scheduler Building Block can be found in .

8.1 Event Management

8.2 Entity Management

8.3 Alert Schedule Management

8.4 Alert Message Management

8.5 Resource management

8.6 Subscriber management

8.7 Affiliation management

8.8 Appointment management

8.9 Status Logging and Reporting

4.10 Information Mediator Interface

This Services APIs is not yet specified, but it should be the purpose of a next iteration of the Scheduler Building Block Specification.

4.11 PubSub Interface

This Services APIs is not yet specified, but it should be the purpose of a next iteration of the Scheduler Building Block Specification.

4.12 Messaging interface

This Services APIs is not yet specified, but it should be the purpose of a next iteration of the Scheduler Building Block Specification.

4.13 Scheduler Administration

This Services APIs is not yet specified, but it should be the purpose of a next iteration of the Scheduler Building Block Specification.

API standards

• The microservice interfaces are defined as per .

• For implementation purposes, it is suggested to refer .

Digital governance may employ common software components (Building Blocks) to automate heterogeneous software applications. Different activities of such components may be triggered based on a specific epoch (date-time) in order to orchestrate a sequence of steps within an automated workflow. Instead of replicating the logic needed by each component to schedule, track, trigger and coordinate its activities with other building blocks and applications the "Scheduler" Building Block enables aggregated coordination of time-driven activities within and across Building Blocks by sending appropriate "alert" messages to appropriate Building Blocks according to a predefined schedule.

Each event is identified by an ID field and has a specific name, date, time, and duration. An event may empanel multiple resources (personnel, facilities, equipment, etc.) from different entities to perform various activities. An event may also enrol subscribers to benefit from activities of the event. The Scheduler may have to alert (trigger) specific resources and subscribers at specific times before, during, and after the event. With specific messages in order to carry out respective activities. The Scheduler Building Block contains various functionalities necessary to enable planning, booking, tracking, triggering, notifying, and status reporting needs of multiple events. It hosts several micro-services that orchestrate these functionalities, exposed through RESTful APIs. This Building Block can be used for scheduling events in a wide variety of applications and use cases such as:

Health sector

In the current scope, examples drawn from user-journey steps of use-cases of Post-Partum care and Unconditional Social Benefit transfer programs were considered to derive Key Digital Functionalities required to orchestrate services from this Building Block. In this section, we identify workflows to manifest some of the main services. These may be enhanced or customized as needed for specific implementation needs. The following common preconditions may be needed to be met before utilizing these services:

• Entities that Host an Event registered in the Scheduler before scheduling respective events;

• Subscriber, Organizer, and Resources are registered in Scheduler before being used in Event;

• Service Endpoints of Scheduler and other Building Blocks it will interact with are already configured in Information Mediator Building Block;

• All users are logged into the GovStack Host application to do their respective tasks;

• Subscriber/Organizer knows preferred host entity, and event category to search for resources and available events;

• Any payments associated with event subscription are done outside of the Scheduler;

• Records of the latest resource and subscriber contact details stored in the Scheduler are up-to-date;

• Target Building Block is registered as publisher and Scheduler is registered as a subscriber in the “status” room of Information Mediator Building Block Pub/Sub dedicated to the target Building Block before using Pub/Sub mode for status updates/triggers;

• Event schedule with a unique ID already exists in Scheduler before seeking cancellation update;

• Scheduler can also call some of its APIs from inside for operations that do not need external interaction in a particular workflow if the information is already available internally.

This section captures the example workflows that may take place between internal functional blocks to orchestrate key functionalities for a minimum viable product as follows. The exact workflows may be decided depending on implementation time considerations.

• Event creation;

• Finding resources of a host entity which are available in a given date-time range;

• Finding event slots of a given category and resource Id in a given date-time range;

9.1 Event Management

9.1.1 Event Creation

An organizer can use this workflow to create a new event in the system. The Organizer will need to feed in minimum details such as the event name, category, address, start and end date-time, host entity, terms for subscription, and subscription limit (e.g. a doctor consultation event is limited to one patient. In a training event the limit may include multiple students). Optionally, a deadline may be specified for participants to log attendance to the event (else marked as absent). The Scheduler avoids duplication of a given event by checking if the same properties are already registered in its Event_List. The start and end date-time is an JSON array structure that enables scheduling the same event multiple times at different date-time slots. It then returns either success status along with an array of unique event ids one for each requested slot, or an appropriate error code to host the application of the organizer.

9.1.2 Cancellation of scheduled event

Organizer can request the cancellation of a prescheduled event through the host app by supplying the event id. The Scheduler first removes dependent alert_schedules and appointments empanelled in the event. It then deletes the event from the event list and returns success to the host app for confirmation to the organizer. Optionally it can send out an event cancellation message through preferred channels to all subscribers and resources of the event, before deleting the event from the event list.

9.1.3 Finding events of a given type and status having a specific resource in a given date-time range

In some scenarios, one may search for events of a specific category involving a specific resource of a specific host entity (e.g. consultation with a specific doctor in a particular hospital) that are open for subscription. The organizer can feed through a host app, a date range, event type, entity ID, and resource_id seeking matching events with status=open. The Scheduler seeks its appointment_List for the event_ids of events with a given type, resource and entity, within a given time range. For each event, the Scheduler gets details of the event if the event status is = "open". The Schedule returns details of selected open events or returns the appropriate error code (e.g. if specified category/resource not found, etc.). The Host app will present the results or error appropriately to the Organizer.

9.2 Entity Management

9.2.1 Registering a new entity

A new entity that can use the Scheduler must be registered by the administrator of the Scheduler Building Block. The Administrator requests entity registration in the scheduler through Scheduler's administrative front-end user interface by supplying relevant entity details. The Scheduler after verifying the requestor's credentials will store the entity information against a new entity id it generates. In case it finds that the entity details match any of the earlier registered entities it returns an error code and avoids duplication. In the normal course, the entity id is returned to the Administrator along with a prompt to register an Organizer resource for that entity, to use the Scheduler further.

9.3 Alert Schedule Management

9.3.1 Scheduling Alerts for a given event

An organizer may schedule different alert messages to be sent to subscribers and resources before, during, and after a prescheduled event. It is assumed here that the alert messages are borrowed from a list of messaging templates within the Scheduler that have been pre-registered and affiliated with a specific entity. The Organizer may use a host app to request the Scheduler to create a new alert schedule by choosing the alert message template, date-time of when the alert is to be sent, and type of targets to receive the message (subscriber/resource/both). If the Scheduler finds all inputs valid it will store the details against a unique Alert Schedule id in the Alert_schedile_list and returns success status and the unique id, otherwise, it will return an appropriate error code. This workflow assumes that the message templates created by the organizer of one entity should not be accessible to organizers affiliated with the host entity. Also, it is assumed that all participants of a given type (resource/subscriber/both) will receive the alert. If a specific implementation needs to define individual participants who should receive a specific alert, it will require further refining of the steps laid out here and is out of scope of the current workflow.

9.3.2 Tracking and Alerting as per schedule

The Scheduler's internal tracker keeps fetching (with a predefined interval) a list of all alerts for which the scheduled date time has arrived (within the interval). For each alert that is ready to go and based on the given target type (resource/ subscriber/ both) it will list participants of that associated event from the appointment list and send the alert message to them. The alert message will be sent using the preferred channel (sms/URL/mail) registered in the resources /subscribers list. It should be noted that the Scheduler does not wait for confirmation of the delivery of the message. In the current context, a recipient of an alert may asynchronously send back a delivery acknowledgement to the log update (see log update workflow) of the Scheduler.

9.4 Alert Message Management

9.4.1 Registering new Alert Message Template

Several predefined templates of alert messages can be stored in a Message List so that they can be reused in different alerts and events (for example appointment reminders, triggers to devices and software applications, etc. Using a host app an organizer may submit a new message and request the Scheduler to register the message. The Scheduler tries to store a new entry in its message list and returns a success or error code in response.

9.5 Resource management

9.5.1 Registering a new resource

An organizer must register into the scheduler various categories of resources {people, equipment, vehicles, facility, etc.) into a specific entity before the resource can be used in different events. An organizer is also a resource of an entity but can be registered only by the Administrator of the Building Block. An organizer can register resources of other categories only into his/her affiliated entity only. The registration process begins with the submission of resource details with the request to the Scheduler for registration of the resource. The Scheduler internally stores details of the resource into a resource_list and generates a new resource ID.

9.5.2 Finding resource availability in a given date-time range

An organizer may use a host application to seek the Scheduler for availability within a specific period (date-time range) of a chosen resource in a chosen entity. The Scheduler finds the affiliated workdays-hours of a given resource in the given entity from its Affiliation_List and calculates corresponding date-time slots that fall within the given date-time range. Then it finds from Appointments List the start and end date-time zones of all events booked for a given resource id and entity, in a given date-time range. From all this information it calculates the free time zones of the given resource, within the affiliated time zones of the given entity and given date-time range. Finally, the Scheduler returns a list of free zones of the given resource within the given date-time range and affiliated workday hours in the given entity. The host application presents this information to the Organizer. If any of the given criteria have invalid values, the scheduler notifies an appropriate error message to Host-App.

9.6 Subscriber Management

9.6.1 Registering a new Subscriber

A subscriber can be registered into the scheduler with relevant details, either by organizer or by subscriber himself. A subscriber must be registered into the scheduler before they are allowed to book appointments for various events. The user submits subscriber details through Host_App to Scheduler requesting registration. The Scheduler internally stores details of the subscriber into its subscriber_list and generates a new subscriber ID. The Scheduler returns the new subscriber id or a duplication error if it finds the subscriber profile is already existing. The Host app confirms registration or duplication error to the Organizer.

9.7 Affiliation management

9.7.1 Affiliating a resource to an entity

A registered resource must be affiliated with at least one entity. A resource may be affiliated with different entities only in non-overlapping day-time zones (e.g. doctor may give consultation in multiple hospitals). An organizer can be affiliated only by an administrator. All other categories of resources can be affiliated by an Organizer. The affiliation request may be submitted through the host-App to the scheduler along with affiliation details (resource_id, entity_id, affiliated days and time zones in that entity, etc.). The scheduler will add a new affiliation of that resource to the new entity in the Affiliation List and generate a new affiliation ID. The Scheduler flags an error if it finds a duplicate entry.

9.8 Appointment Management

9.8.1 Appointment Scheduling for resource or subscriber to a specific event

An organizer may enrol a subscriber or resource to a specific event through a host app. The host application first finds out details of a chosen event_id. Then the host application requests a new appointment booking by giving participant details, and event details as needed. The Scheduler stores appointment details against a unique appointment id in its Appointment List. The Scheduler then confirms successful enrolment to the user through the host app and publishes the unique appointment id for that participant.

9.8.2 Cancellation of appointment

An organizer may cancel an existing appointment of a resource or a subscriber for an event using the Host App. The user may submit the participant id or participant type (subscriber/resource) and the event ID to the Scheduler through the host app, requesting for cancellation of respective enrollment for the event. If the Scheduler finds the given event id and subscriber/resource id in the appointment_list it will delete the enrolment entry of the given resource in the given event, else it will return an appropriate error message. The Host-app confirms success or error condition to the user. The Scheduler also emits a notification through Messaging Building Block to inform the cancelled participant only (in different implementations one can also inform all participants). It should be noted that the deletion of the enrolment of a subscriber does not remove subscriber/resource details stored in the subscriber/resource list, but it removes only the allocation to the specific event.

9.9 Status Logging and Reporting

9.9.1 Log reporting

In this workflow, a simple case of extracting chosen type of log in a given time range is described. The Organizer requests the Scheduler through a host app to report logs of a chosen category within a chosen date range. The Scheduler fetches a list of matching logs found from its Log_List, or null if nothing is found. The Scheduler publishes the logs or null to the user through the host app. This function can be extended in different implementations to generate more complex types of reports based on information in the log.

The Scheduler can be visualized as a black box with all key digital functionalities discussed in section 4 built-in and all interactions with the building block happening through RESTful API interfaces that exchange service requests and responses with external Building Blocks or Applications. A brief description of the functional requirements required to orchestrate each key digital functionality is been given below, considering a minimum viable product perspective. Detailed design and more elaborate feature lists of these blocks can be customized by developers to optimally match respective implementation needs. It is also left to the application to receive the responses from the scheduler and present it appropriately (e.g. as an Event list or calendar) and provision for associated user interface interactions

6.1 Event Management

• The Scheduler must enable an event organizer to create/update/delete/modify/search and list schedule details of multiple events. The Scheduler must enable setting up in advance with a minimum of a specified starting and ending date-time of an event, an event name and category and placeholders for other details that can be populated later on (REQUIRED)

• It must be possible the modification of event details after registration of the new event scheduled in the Scheduler's Event List (REQUIRED)

• The Scheduler must not allow the addition/modification of any details of an event after the scheduled event is over (REQUIRED)

• In the case of events such as workshops, training sessions, medical camps, marketplace exhibitions, etc., which may host repeated events at different places by different resources for different subscribers, the Events could have the same name, but each instance would have a unique ID. The Scheduler must not allow events with the same name and same host entity to overlap at the same date-time epochs (REQUIRED)

• It must be possible to find details of all events in a chosen date-time range, filtered by a given category, having specific resources and still open for a subscription (REQUIRED)

• If an event is deleted, the Scheduler must remove all dependent appointments of resources and subscribers and all scheduled alerts associated with an event and notify the organizer of the host entity (REQUIRED)

• The Scheduler should send notifications to all resources and subscribers when an associated event is deleted (RECOMMENDED)

6.2 Entity Management

• This sub-block must enable event administrators to create/update/delete/search and list entities that host various event schedules using the Scheduler (REQUIRED)

• All the details about the entity must be stored in a common internal repository so that the resources may be affiliated with multiple entities and booked into multiple events as needed (REQUIRED)

• An entity must have at least one affiliated resource in the Organizer role to manage event scheduling on behalf of the entity. An entity may affiliate with multiple registered resources (REQUIRED)

6.3 Alert Schedule Management

• The Scheduler must enable an organizer to create/update/delete/search and list alert_schedules for sending alert messages in association with a specific event. A single alert schedule specifies details of only one epoch of sending a specific message to a specific category of participants of a single event (REQUIRED)

• Each alert schedule must enable sending of the same message to multiple targets (resources/subscribers/both) of a specific event (REQUIRED)

• The Scheduler must assign a unique Id to each alert schedule (REQUIRED)

6.4 Alert Message Management

• The Scheduler must enable an event organizer to create/update/delete/modify/list Alert message templates that can be used to communicate with participants of events. (e.g. appointment reminders to various patients, triggering a periodic transfer of salaries, etc.) (REQUIRED)

• Alert messages must be tagged to a specific host entity and are not accessible to other entities. Each entity must retain its own stack of alert message templates (REQUIRED)

• All the details about the message must be stored in a common internal repository so that the messages may be reused into multiple events in high throughput environments (REQUIRED)

6.5 Resource management

• The Scheduler must enable an event organizer to create/update/modify/search and list multiple Resources (persons/facilities/equipment/vehicles/etc.) as needed for taking part in various events (REQUIRED)

• All the details about the Resource must be stored in a common internal repository so that the resources may be affiliated with multiple entities and booked into multiple events as needed (REQUIRED)

• Each Resource must be defined with a specific category (doctors/nurses/ambulance/room/ etc.) that helps in the grouping, searching, and selection of the resource (REQUIRED)

6.6 Subscriber management

• The Scheduler must enable an event organizer to create/update/modify/search and list subscribers (persons/facilities/equipment/vehicles/etc.) as needed for taking part in various events (REQUIRED)

• All the details about the subscriber must be stored in a common internal repository so that the subscribers may be enrolled into multiple events as their contact details be reused to send alerts as needed (REQUIRED)

• A Subscriber may be affiliated with multiple Events that do not overlap with each other in date-time (OPTIONAL)

6.7 Affiliation Management

• The Scheduler must enable an event organizer to create/update/delete/list affiliation of the organizer's entity with multiple Resources (persons/facilities/equipment/vehicles/etc.) as needed for various events hosted by that entity (REQUIRED)

• All the details about the Resource must be stored in a common internal repository so that the resources may be affiliated with multiple entities and booked into multiple events as needed (REQUIRED)

• A Resource must be affiliated with at least one entity with specific working hours during registration. Subsequently, the same Resource may be affiliated into multiple entities such that the weekdays and working hours allocated to affiliated entities do not overlap with each other (REQUIRED)

6.8 Appointment Management

• This sub-block must enable an event organizer to add/modify/delete/search and list specific participants (resources and subscribers) into specific predefined events. Each new appointment will have a unique appointment ID (REQUIRED)

• All resources must have been registered in Scheduler and MUST have been affiliated with specific entities before they can be enrolled in different events (REQUIRED)

• All actors, except the super-admin, can access information from only entities that the actor is affiliated with in the Scheduler (RECOMMENDED)

6.9 Status Logging and Reporting

• Recipients of alerts may send acknowledgements and participants, in general, may send status/attendance updates either directly to Scheduler or through respective Information Mediator Pub/Sub blocks or in response to a status polling request from the Scheduler to the alerted participant. The Scheduler must log all alerts sent and log updates received from participants of all events it handles and store them in a searchable indexed manner (REQUIRED)

• This sub-block must periodically monitor and log specified internal metrics (e.g. latency, queue depth, errors, system resource consumption, number of retries, etc. from critical indicators of the performance of the Scheduler Building Block).(REQUIRED)

6.10 Information Mediator Interface

• This sub-block runs protocols to communicate with the Information Mediator Building Block for exposing Scheduler services to external Building Blocks and applications (REQUIRED)

• It also provides specific calls to APIs of information mediator Building Block to access services of external applications and Building Blocks (REQUIRED)

• It also handles any errors and failures in data exchange between the Scheduler and other Building Blocks/Apps (such as backoff and retries, etc.) (REQUIRED)

6.11 Pub/Sub Interface

• This Block must maintain the endpoint address of specific rooms dedicated to the Scheduler Building Block to publish Alert notifications. These are dedicated API interfaces defined in the Pub/Sub (Information Mediator Building Block) and hence are not defined here (REQUIRED)

• It must also use the logging sub-block to maintain the history of Pub/Sub transactions handled by the Scheduler Building Block (REQUIRED)

• It must enable the Scheduler to subscribe with Pub/Sub rooms of other Building Blocks (such as Messaging, Accounting, Payments, etc.) (for example, to receive status updates on the completion of an ongoing event) (REQUIRED)

6.12 Messaging Interface

• The Messaging interface should send relevant information to the logging sub-block to maintain the history of all messages sent from this Building Block, which are useful for audit purposes (RECOMMENDED)

• This sub-block should also route response messages coming through the Messaging Building Block from participant users/devices/applications for updating of the status/ attendance/etc. of specific events. The Scheduler should publish an endpoint for receiving notifications from messaging Building Block and a log list to log all messages received (RECOMMENDED)

• The messaging interface should provide the necessary protocol, data format, and information and interface to interact with the Messaging Building Block for sending notifications to specific target users/applications through a variety of channels (SMS/email/etc.) (RECOMMENDED)

6.13 Scheduler Administration

• This component must enable Building Block admins to configure rules for monitoring, detection, and escalation of any performance/security conditions to the administrator proactively. The exact parameters and statistical indicators may be decided at implementation time (REQUIRED)

• This sub-block must enable setup and updates of various end-point addresses (Information Mediator/other Building Blocks/PubSub/Applications/etc.) and associated communication settings such as back-off mechanisms, error handling, network breakdown resilience mechanisms, latency limits, etc. stored in various interfaces of the Building Block (REQUIRED)

• This sub-block may provide native user interfaces to administrators of this Building Block through an API Gateway, as decided during implementation time (OPTIONAL)

The proposed resource model showing the relationship between data objects that are used by this Building Block is illustrated in the diagram below. The Scheduler Building Block stores details of Events in EventList, Resources in a ResourceList, Subscribers in SubscriberList, Alert message templates in an AlertList, alert schedules in an AlertScheduleList, entities in EntityList and Affiliations of resources in entities in the AffiliationList. Entries in this list include properties of respective items and linkages between them Apart from these, the Scheduler has several "internal" registers that are used to log information arising from transactions, from the system, from communications, etc., and metrics/indicators as needed for housekeeping, audit, and administration of the Building Block. The archival and retrieval mechanisms for data generated or received in the Scheduler Building Block are left to implementation time considerations of IT infrastructure planning.

7.1 Resource Model

7.2 Data elements

7.2.1 Group: EventList

7.2.2 Group: Appointment LIst

7.2.3 Group: EntityList

7.2.4 Group: Address

7.2.5 Group: ResourceList

7.2.6. Data Group: AffiliationList

7.2.7 Group: SubscriberList

7.2.8 Group: AlertScheduleList

7.2.9 Group: MessageList

7.2.10 Group: LogList

7.2.11 Group: FreeResources

7.2.12 VenueDetails

7.3 Notes on the Data Model

The internal storage of the Scheduler Building Block MUST hold configuration, status, and logged information of all scheduled events. It MUST also maintain a repository of details of resources and subscribers affiliated with various events

The internal data requirements of the Scheduler operations from heterogenous use cases can be reduced into a comprehensive set of unique data elements, organized into a schema of common reusable datasets, formed by a grouping of closest related data elements, avoiding unnecessary duplication.

In this model, the basic unit of Scheduling is an “Event“, each Event has a unique ID. The API structure that defines the service interface should accommodate various fields relevant across use cases that may consume the service. Some fields may be mandatory inputs while others may be optional depending on the use case.

All details of a data set in the data model may not be populated at once, it may be filled in parts as and when relevant (e.g. although a consultation session may be provisioned, consumers may be appointed later).

As new use cases are discovered, one can add fields that are not in the set in the model already. It is assumed each use case will define the respective subset of the data model along with the mandating of appropriate data fields.

Besides the basic data set needed for scheduling, there are data sets such as configurations, etc., that help to administer and audit the Scheduler Building Block itself (e.g, Security, performance, Transactional and Schedule Compliance audit reports, etc.).

Support of polymorphic data sets and data types is provided by means of a list of generic meta-attributes, to enable Polymorphism in data sets which may occur when different collections inherit common data from base entities.