EM-G2P-UC2-Online Reservation System (ORS)
eM-G2P-UC2-Online Reservation System (ORS)
MKT-G2P-UC2-ORS-Online Reservation System
Product Use Case Summary
| ID | MKT |
|---|---|
Name | Online Reservation System |
Sector | Government Marketplace |
Version | 1.0 |
Status | Draft |
This use case explain the three broad steps in booking a doctor's appointment by a citizen. The three steps included are (1) Citizen's registration (2) Hospital Staff Registration (3) Booking a doctors appointment by a citizen. The ORS service involves a health application consisting of registered hospitals with various departmental services in it pooled across multiple cities in a state or a country. A citizen can choose to select a service in a particular hospital and book an appointment. Then, the citizen can visit the hospital as per the appointment time and seek medicine receipts/diagnostic services, if any, into his/her registered account. A citizen can avail deemed social benefits as per eligible criterian defined by the government. For example, a citizen can choose to scroll through nearest town/city, select a general or specialized government hospital (for ex. Cancer hospital) and then select a department (oncology) and see who all doctors/slots are available; and then book an appointment as per their convenience. Once the appointment is booked, the citizen receives confirmation details and visits the hospital to consult the doctor. If the doctor suggests any prescription, the same is uploaded into citizen's account by hospital staff-which can be shown across medical shops to get medicine. Nominal fee payments, receiving of medical aid in terms of cash etc. are not considered in this case study.
SDG Targets
12.7: Promote public procurement practices that are sustainable, in accordance with national policies and priorities
12.7.1: Number of countries implementing Sustainable Public Procurement policies and action plans
3.7 By 2030, ensure universal access to sexual and reproductive health-care services, including for family planning, information and education, and the integration of reproductive health into national strategies and programmes.
3.8 Achieve universal health coverage, including financial risk protection, access to quality essential health-care services and access to safe, effective, quality and affordable essential medicines and vaccines for all.
Building Blocks
Consent
Identification and Verification
Messaging
Registration
Scheduling
Information Mediator
Work flow and Algorithm
Registries
Future building blocks inclusion
Payments
UI/UX
Analytics and Business Intelligence
Artificial Intelligence (AI)
Geographic Information Services (GIS)
Steps1 - Outreach Communications
Staff from the Ministry of Health or another leading agency / organization organizes an information awareness campaign about booking health appointments and its benefits through ORS through various channels of communication via mobile messaging and/or aired on national radio/television, internet, social media. Outreach communication is intensive during the kick-off phase of the new programme, but also requires ongoing touchpoints and additional information sharing, e.g. on grievance redressal, rights and responsibilities, behavioural change communication, etc.
Workflows
Client communication to facilitate the spreading of programme awareness for target audience and encouraging enrolment via mobile,web, kiosk, media channel(s)
Client education for educating potential target beneficiaries around the approach and objective(s), benefit(s), constraint(s), partner(s), etc. of the programme
Content management for the backend Health department and stakeholder staff to populate relevant educational and promotional content that local officers can use during on-the-ground outreach campaigns
Identification and Registration (with aid of geographic information services tool for potential use) in mapping and locating households and individuals for outreach target
Example Implementation
To do
Building Blocks
Messaging
Scheduling
Information Mediation
**2 - Registration, **Identification and Verification
Registration is the process of collecting information of stakeholders such as citizens and hospital staff, in this use case. Depending on specific grography context, registration works in very different ways – either through self registration, on-demand at local hospitals (either approach potentially building on interoperability existing data sources) or single admin registration of hospital staff. While the practicalities of data collection differ across the types, with very different implications for data quality, currency and completeness, the underlying digital processes are broadly the same. A self registration involves providing data inputs by the citizen while the on-demand registration will facilitate the same services for the individuals who might not be able to help themselves. Further, an adminstrator of hospital may also choose to enrol/register all the doctors details (for example), on behalf of them.
The data registered can be saved into type of registries (for example, citizens, hospital staff registries, hospitals registry, cities registry, departments registry) and can be accessed to collect, organize, store, process, transform, create, and distribute information necessary to support intake and registration of potential beneficiaries (gateway function).
Workflows
Data Collection and Reporting for capturing interview responses or observations during registration process
Identification and Registration for enrolled identified beneficiaries in the system and enabling possible permissions for interaction with the Health Application, and (with aid of geographic information services tool) to potentially locate and track households during the interview process
Client Case Management for creating beneficiary user records
Example Implementation
Building Blocks
Consent
Registration
Registries
Identity and Verification
Information Mediation
Messaging
3 - Booking a doctor's apointment
This is a key process of the use case where a citizen access the health application (ORS) and books an appointment. The process involves a citizen visiting a catalogue of cities, government hospitals in each city; and selects a department (for example: neurology) in a selected hospitals and books a doctor's appointment at a scheduled slot. Once the citizen visits the hospital, their appointment is reconfirmed and entitlements, if any, are verified by the hospital staff. The doctor, upon completion of diagnosis, can direct the staff to upload the prescriptions, diagnosis results in the same account of the citizen so that the citizen can show case the same to receive medicine and to store the health hisory.
Workflows
Cross verification of citizen appointment details when the later visits the hospital
Catalogue of services The citizen should be able to select a service under a department of a hospital in a city
Client Case Management for determining and assigning benefit packages and benefit levels to specific user groups
Data Analysis and Business Intelligence / Decision Support potentially for identifying different benefit levels / types in correlation to target groups’ socioeconomic / demographic information, based on existing eligibility criteria
Document Management that uploads/stores the prescriptions, diagnosis results by the hospital staff
Scheduling The time slot shall get updated automatically whenever a slot is booked or when the slot is cancelled. It shall also communicate the appointment details to citizen and to the hospital staff.
Example Implementation
Building Blocks
Identity and Verification
Consent
Information Mediation
Digital Registries
Registration
Scheduling
UI/UX
Messaging
Client Case Management
Analytics and Business Intelligence
Outputs
The citizen is able to successfully register a doctor's appointment in a government hospital
Failure Points
Internet connectivity
Lack of awareness
Technical failure of the application
G2P-UC2-ORS-S1-Citizen Registration
Use Case Step | Self-Registration of citizen (how about Mee-Seva channels?) |
Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) |
|
Data inputs |
|
Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: CitizenSystem:
|
Normal Course (what happens if the event is triggered and the preconditions have been met) | The registration form screen for the Healthcare application provides a list of initial details required to proceed with the registration (eligibility verification, required documents such as national ID/EHR proof).Step 1: The citizen enters the required initial details, including, but not limited to the following:
Feature: Get Consent AgreementScenario: Healthcare Application retrieves Consent Agreement for citizenGiven an Agreement citizen registration that exists in Consent BBAnd Healthcare Application has Citizen’s <ID> and authentication token for the registration sessionWhen Healthcare application fetches a Consent Agreement for Citizen registrationThen Healthcare application gets a valid Draft Consent Agreement associated with Citizen's IDAPI EndpointsStep 2: The health Application introduces to the citizen the Consent Agreement for fetching the relevant details from the Population registry (Should it check with EHR also?) for verification and appropriate use with the health application and captures signature to the Consent Agreement from the citizen.Feature: Sign Consent RecordBackground:Given Health Application has the Draft Consent Agreement associated with Citizen's ID and authentication token for the registration sessionAnd Citizen has read the Draft Consent AgreementAnd Citizen approves to sign the Draft Consent Agreement associated with Citizen's ID (What language and what if the citizen does not agree?)Scenario: Sign Consent Record on PaperGiven Health application has captured the consent in a digital form (for example: scan of a paper form)When Health application sends digital Consent Record payload to Consent BBThen Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Citizen has been successfully signedScenario: Sign Consent Record DigitallyGiven Citizen has capability to sign Consent Record digitallyWhen Health Application sends the Draft Consent Agreement to Consent BBThen Consent BB creates a paired ConsentRecord and Signature objectAnd Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Citizen has been successfully signedAPI EndpointsStep 3: The Health application form submits the national ID number to the Population registry hosted in the IDBB/Digital Registries BB seeking relevant details of the Citizen, by invoking the API “Data read value” on the Govstack Digital Registries BB.This scenario uses a set of features:
Feature: Verify Consent RecordHealth Application verifies if Citizen has signed Consent Record to fetch the needed personal data from Population registry for Health Application user registrationScenario: Retrieve valid Consent RecordGiven Citizen has Signed Consent Record stored in Consent BBWhen Health Application makes the request to population registry API to fetch Citizen's personal dataThen Health Application makes prior request to Consent BB API to retrieve Citizen's Signed Consent RecordAnd Consent BB sends the signed Consent Record to Health ApplicationFeature: Imports client personal data from a registryImport Citizen's personal information from Population Registry to the e-service formGiven Citizen has entered <ID> in the Registration e-service registration form, national ID number fieldAnd Health Application has received Signed Consent Record from Consent BBWhen the Health Application user pushes a button "Import Citizen's information"Then the Health Application makes a request to Population Registry APIAnd Population Registry returns requested data to Health ApplicationAnd Health Application fills the form on the screen with Citizen’s data <ID>,<first>, <last>, <age>Examples:|ID|first|last|birth||53|Sowmya|Krishnamurti|2023-02-14|In response, the Govstack IDBB/ Digital Registries BB is expected to return the following: Data returned from Registry<How do we know whether a citizen is entitled for a health benefit or not. For example, No fee for below poverty line; Low fee for a cancer surgery> |
Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the Citizen does not possess a national ID, the registration application needs to provide an alternate mechanism for <>GetIdentityProfile – elaborate
“GET /dataconsumer/consent/” |
Data output | The successful completion of the citizen registration process will result in confirmation and issuance of a program-specific ID that can be used by the citizen for future interactions with the program.Expected data from Registration BB |
Post-Conditions (the success criteria) | The citizen has registered in the Health Application registry. |
Exceptions(error situations) |
|
Related BBs(working groups related to this example implementation) |
|
G2P-UC2-ORS-S2-HospitalStaff Registration
USE CASE: Booking a doctor’s appointment on a Government healthcare platform
Use Case Step | Hospital Staff Registration by a system administrator |
Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The staff is an identified and registered person with a hospital; and is registered in a national identification system (IDBB) with a unique electronic identity number.· The role of the staff is clearly pre-defined and is mapped to a department by the hospital. For example, a doctor, a diagnostic officer, radiologist, document uploader, bill clearance officer etc.· Good internet connectivity, access channels (web/mobile/kiosk) shall be available.· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (consent) and respective REST API services in Information Mediator have been opened to Registration BB. |
Data inputs | · Name, Age, Gender of the Staff· National ID number of the Staff· Registered mobile number· Captcha Chat/non-robot verification· OTP· Permanent address details (Door number, Lane, PIN, City, State, Nation) |
Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Staff membersSystem:· Healthcare platform application· Digital Registries BB (Hospital staff)· Registration BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB· National Population Registry (Digital Registries BB or Identity BB) |
Normal Course (what happens if the event is triggered and the preconditions have been met) | The registration form screen for the Healthcare application provides a list of initial details required to proceed with the registration (eligibility verification, required documents such as national ID/Staff ID).Step 1: The staff enters the required initial details, including, but not limited to the following:1. Staff’s National ID number / Staff’s ID in the hospital2. Name of the Staff3. Date of Birth4. Gender at Birth5. Address details6. Mobile numberThe application shall seek the consent of the staff to retrieve additional data from multiple registries.Feature: Get Consent AgreementScenario: Healthcare Application retrieves Consent Agreement for StaffGiven an Agreement Staff registration that exists in Consent BBAnd Healthcare Application has Staff’s <ID> and authentication token for the registration sessionWhen Healthcare application fetches a Consent Agreement for Staff registrationThen Healthcare application gets a valid Draft Consent Agreement associated with Staff's IDAPI EndpointsStep 2: The health Application introduces to the Staff the Consent Agreement for fetching the relevant details from the Population/Staff registry for verification and appropriate use with the health application and captures signature to the Consent Agreement from the Staff.Feature: Sign Consent RecordBackground:Given Health Application has the Draft Consent Agreement associated with Staff's ID and authentication token for the registration sessionAnd Staff has read the Draft Consent AgreementAnd Staff approves to sign the Draft Consent Agreement associated with Staff’s IDScenario: Sign Consent Record on PaperGiven Health application has captured the consent in a digital form (for example: scan of a paper form)When Health application sends digital Consent Record payload to Consent BBThen Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Staff has been successfully signedScenario: Sign Consent Record DigitallyGiven Staff has capability to sign Consent Record digitallyWhen Health Application sends the Draft Consent Agreement to Consent BBThen Consent BB creates a paired ConsentRecord and Signature objectAnd Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Staff has been successfully signedAPI EndpointsStep 3: The Health application form submits the national ID number to the Population registry hosted in the IDBB/Digital Registries BB seeking relevant details of the Staff, by invoking the API “Data read value” on the Govstack Digital Registries BB.This scenario uses a set of features:· Verify Consent Record by Consent BB· Import data from a registry by Registry BB·Feature: Verify Consent RecordHealth Application verifies if Staff has signed Consent Record to fetch the needed personal data from Population registry for Health Application user registrationScenario: Retrieve valid Consent RecordGiven Staff has Signed Consent Record stored in Consent BBWhen Health Application makes the request to population registry API to fetch Staff's personal dataThen Health Application makes prior request to Consent BB API to retrieve Staff's Signed Consent RecordAnd Consent BB sends the signed Consent Record to Health ApplicationFeature: Imports client personal data from a registryImport Staff's personal information from Population Registry to the e-service formGiven Staff has entered <ID> in the Registration e-service registration form, national ID number fieldAnd Health Application has received Signed Consent Record from Consent BBWhen the Health Application user pushes a button "Import Staff's information"Then the Health Application makes a request to Staff Registry APIAnd StaffRegistry returns requested data to Health ApplicationAnd Health Application fills the form on the screen with Staff’s data <ID>,<first>, <last>, <age>Examples:|ID|first|last|birth||32|Aparna|Vijay|2023-03-17|In response, the Govstack IDBB/ Digital Registries BB is expected to return the following:Data returned from Registry |
Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the Staff does not possess a national ID, the registration application needs to provide an alternate mechanism for <Enrolment>GetIdentityProfile – elaborate1. If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB“GET /dataconsumer/consent/” |
Data output | The successful completion of the Staff registration process will result in confirmation and issuance of a program-specific ID that can be used by the Staff for future interactions with the program.Expected data from Registration BB |
Post-Conditions (the success criteria) | The Staff has registered in the Health Application registry. |
Exceptions(error situations) | · A Staff can be only registered once in Health Application. The system must prevent multiple registrations.o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actorso· If the Staff has entered incorrect information then the Health Application inform the Staff to check/validate the same.o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actorso· If Identity BB or Consent BB is not available (service outage), then …..o Mitigation steps: Describe steps to be taken by the actorso· If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.o Mitigation steps: Describe steps to be taken by the actors |
Related BBs(working groups related to this example implementation) | · Identity BB· Consent BB· Registration BB· Digital Registries BB· IM BB |
G2P-UC2-ORS-S3-BookingDoctorsAppointment
Use Case Step | Booking a doctor’s appointment in the Health Application |
Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) |
|
Data inputs |
|
Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: CitizenSystem:
|
Normal Course (what happens if the event is triggered and the preconditions have been met) | Once the user logs-in, the user should be able to search for list of hospitals, different services under each hospital, select the health service, upload documents (if necessary) and get a confirmation of the appointment.Step 1: The citizen enters the required initial details, including, but not limited to the following:
Feature: Verify and validate the citizen account detailsScenario: Healthcare Application retrieves citizen details from Health Application Registry.Given an Agreement citizen registration that exists in Consent BBAnd Healthcare Application has Citizen’s <Health Application Account ID> and authentication token for the registration sessionWhen Healthcare application fetches a valid Health Application Account IDThen Healthcare application successfully logs in the citizenStep 2: The citizen searches for health care providers in a particular cityThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government.The validated citizen ID/session ID fetches the details from <Cities Registry>, and <Hospitals Registry> with multiple filters.Feature: Catalogue Search for identifying cities and healthcare providersBackground:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Search for CitiesGiven Health application account ID/Session ID has been presented with catalogue of citiesWhen Health application account ID/Session ID selects a city from the Cities RegistryThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Cities Registry details are fetched successfullyScenario: Search for Hospital/ClinicGiven Health application account ID/Session ID has been presented with catalogue of citiesWhen Health application account ID/Session ID selects a city from the Cities RegistryAnd the <Hospitals Registry> fetches all the hospitals and clinics under the selected citiesThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital and Clinics details under Cities Registry are fetched successfullyStep 3: The citizen views a catalogue of hospitals and clinics in the city and selects the department for which the appointment is requiredThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government.The validated citizen ID/session ID fetches the details from <Departments Registry>, <Services Registry>, with multiple filters; which are under <hospitals registry> and <cities registry>.Feature: Catalogue Search for identifying departments and services (for example: Department of Neurology associated with Brain, Spine, Peripheral nerves, muscles related services etc.), with multiple filters.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in session ; and has been presented with details of <cities registry> and <hospitals registry>Scenario: Search for Departments in a hospitalGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitalsWhen Health application account ID/Session ID selects a hospital from the Hospitals RegistryThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Departments Registry details are fetched successfullyScenario: Search for a serviceGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departmentsWhen Health application account ID/Session ID selects a service from the Services RegistryAnd the <Services Registry> fetches all the services under the Departments in a hospital in a city.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services details in a City are fetched successfullyStep 4: The citizen views available appointment slots in the calendar published by the particular hospitalThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government. The citizen selects a city, health provider, department and a service.The validated citizen ID/session ID fetches the details from <Cities Registry>, <Departments Registry>, <Hospitals Registry>, <Services Registry>, with multiple filters.Feature: Catalogue Search for appointment slot and its selectionBackground:Given Health Application/Session ID has the Health Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Search for appointment slots in the catalogueGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departmentsWhen Health application account ID/Session ID selects a service from the Services RegistryAnd the <Services Registry> fetches all the services under the Departments in a hospital in a cityAnd a Catalogue of Appointment slots <from Scheduler BB> are fetched successfully.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Scheduler BB time slots details in a City are fetched successfullyScenario: Citizen selects and confirms a slot.Given Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, servicesWhen Health application account ID/Session ID selects a service from the Scheduler BBs catalogue/Time capabilityAnd the < Scheduler BB> fetches all the available slots for a service under the Departments in a hospital in a cityAnd a slot is selected, the details are communicated to Messaging BB successfully.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details are communicated to Scheduler BB, “Messaging BB” through IM BB.Step 5: The citizen receives appointment details and the quoteThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals, departments, services, appointment slots.The validated citizen ID/session ID fetches the details from <Cities Registry>, <Departments Registry>, <Hospitals Registry>, <Services Registry>, with multiple filters.Feature: The “Appointment” details are fetched from Scheduler BB and a quote (to submit additional information/time confirmation/pre-validation by citizen) is provided for citizen’s confirmation.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Receive appointment details on Application UI/UXGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, services, appointment/time capabilityWhen Health application account ID/Session ID selects a service time slot from the Scheduler BBsAnd the < Scheduler BBs > is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB.Then IM BB fetches the payload from Messaging BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details from Scheduler BB are communicated to “Messaging BB” and then to UI/UX BB.Step 6: The citizen accepts the quote and shares the medical information history required for the appointmentThe citizen has been provided with appointment details, a quote to share additional but optional information.Feature: The “Appointment” details are fetched and a quote (to submit additional information/time confirmation/pre-validation by citizen) is provided for citizen’s confirmation.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Citizen shares additional details and then confirms the appointment.Given Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, services, appointment/time capabilityWhen Health application account ID/Session ID selects a service from the Scheduler BBs catalogue of appointment slots.And the <Appointment slot in Scheduler BBs> is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB for validation and to share/affix additional details. Citizen updates the details (optional) and confirms the appointment details.Then IM BB fetches the payload from Messaging BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details are communicated to “Messaging BB” and then to UI/UX BB. The Registration BB is updated with new data (quotes) through Messaging BB and IM BB. Scheduler BB is updated. Appointment ID is updated in Health Application Account ID. The session is closed.Step 7: The hospital staff validates the citizen’s appointment and consultation with the doctorThe citizen has been provided with appointment details, a quote to share additional but optional information. The citizen confirms the appointment and receives the appointment details via paper or SMS.Feature: Citizen visits the hospital on the scheduled time and the “Appointment”, received through a paper or SMS, is utilized.Background:The hospital staff members cross checks the Appointment ID, Account ID, Citizen ID using UI/UX BB, Scheduler BB, Registration BB, Registries BB.Scenario: Citizen visits the hospital and hospital staff checks the appointment detailsCitizen shares the appointment details (Paper/SMS) with the hospital staff. The Staff logs-in to the portal and verifies and validates the appointment, citizen details.When Staff ID/Session ID selects an appointment ID from the UI/UX, Scheduler BBsAnd the < Appointment slot> is selected; the appointment and citizen details are communicated to IM BB and Scheduler BB and then to UI/UX BB for validation. Staff confirms the appointment details.Then IM BB fetches the payload from Scheduler BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Staff account ID/Session ID confirms to Staff Account that Citizen Health Application Account details, Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details and citizen details are validated successfully.Step 8: The Hospital updates the prescriptions, diagnosis to the citizen in the Health ApplicationThe citizen has visited the doctor and was advised some measures, medicines, diagnostics. The prescription and the in-house diagnostic services results are updated by the hospital staff in the patient registry associated with hospital account application ID of the citizen.Feature: The hospital staff uploads the prescriptions and diagnostics results of a citizen.Background:Given Staff ID/Session ID has the Health Application Account ID associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Citizen shares the prescription with the staff after undergoing in-house diagnostic services with results.Given Staff ID/Session ID has been presented with the Patients RegistriesWhen Staff ID/Session ID selects a Hospital Account ID/Citizen IDAnd the < Patients Registry> is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB. Staff updates/uploads the medicine advise/test result details (optional) associated with patients.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Staff ID/Session ID confirms to Health Application that Health Account ID associated with Citizen ID are fetched successfully and the test results (optional) and prescriptions are communicated to “IM BB” and then to UI/UX BB. The Registration BB is updated with new data (prescription/test results) through Messaging BB and IM BB. Patients Registry is updated.In response, the Govstack IDBB/ Digital Registries BB is expected to return the following: Data returned from Patients Registry |
Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the Citizen does not possess a national ID, the registration application needs to provide an alternate mechanism for <>GetIdentityProfile – elaborate
“GET /dataconsumer/consent/” |
Data output | The successful completion of the citizen appointment process will result in confirmation and issuance of a Appointment ID that can be used by the citizen for future interactions with the hospital.Expected data from Registration BB |
Post-Conditions (the success criteria) | The citizen has booked an appointment successfully in the Health Application. |
Exceptions(error situations) |
If the citizen does not find a required department/services then either “general physician” or “This service is not available at this hospital” message shall be displayed.If the appointment slots in a day are over the application and or Scheduler BB should make a suggestion such “There are no slots available for today” / “Please book your appointment on the next available day” |
Related BBs(working groups related to this example implementation) |
|
Last updated