-
Notifications
You must be signed in to change notification settings - Fork 2
System Concept
The following concept of operation (ConOps) provides a broad description of how the system is envisioned to operate. It is intended to provide some level of guidance without dictating a solution.
Individuals arrive at the site and complete the pre-registration process on their own personal device (1a) or at a designated pre-registration station (1b). The pre-registration process will generate a QR code that the individual will use to present their information to Registration + Admission. Once pre-registration is complete, individuals may line up for Registration + Admission (2). Registration + Admission will scan the individual’s QR code and confirm the information is correct before accepting the information for entry into the central database (this ensures restricted access and quality control). Once admitted, the individual will proceed to the Treatment / Processing area (3). During Treatment / Processing, a vaccine may be administered (for example) and the clinical personnel may again use the individual’s QR code to access the corresponding record and update it with an appropriate annotation. After Treatment / Processing, the individual will proceed to the Discharge area to be discharged (4). A printed QR code may be retained for disposal (or to serve as back-up documentation of who was processed).
Some of the key constraints and design considerations associated with this system are as follows:
- The likely bottleneck is going to be the registration process. Therefore, the system should decouple the registration process from the admission step as a means to ease that foreseeable backup; one way to achieve this is to have several instances of a pre-registration entity that is separate from the rest of the system.
- A barcode reader could be used to quickly scan information from licenses. However, not everyone has a license and not every license is up-to-date. This alone will not be a sufficient means to mitigate the registration bottleneck.
- The system should have an offline mode so that can be operable without internet access.
- The system will initially be geared toward a mass-vaccination scenario, but must also be applicable for other similar types of public health emergencies (e.g. natural disaster).
In order to alleviate the bottleneck on the registration process, the envisioned system concept provides a capability to have multiple instances of pre-registration nodes at the site. Whether this is implemented as a) a smartphone application that individuals may download themselves and use to create their registration QR code and/or b) an adequate number of equipped pre-registration stations at the site is to be discussed and determined. Regardless, the basic flow of the pre-registration process is outlined as follows:
- One family member optionally scans his/her state-issued ID to populate the first name, last name, date of birth, gender, and street address.
- Corrections (e.g. to address) are made as needed.
- Alternatively, the demographic information may be populated manually.
- The family member chooses to “add” the next family member. By default, the street address and last name are populated with the same street address and last name as the initial family member.
- A change to the street address may be made manually.
- A change to the last name may be made manually.
- First name, date of birth, and gender are entered manually.
- The family member may continue to “add” other family members until all have been entered.
- The family member reviews and confirms that the entries are complete and correct.
- The pre-registration subsystem generates a individual QR code for each family member (digital and/or printed – TBD).
This scenario assumes that the pre-registration has been completed prior to entering the line for registration and admission. As the registration and admission step in the overall workflow has the potential to be a significant bottleneck, the pre-registration step disperses that load.
- Pre-registered individuals line up for registration and admission.
- Each individual presents his/her QR code to the registration and admission station.
- The QR code is scanned, which populates the central database with the patient’s information (with default status of REGISTERED) and displays it to the operator for confirmation.
- The operator verbally confirms the information of the patient (e.g. name and DOB or age).
- The operator confirms the match and the system sets the patient’s status to ADMITTED.
This scenario assumes that the patient has successfully completed and passed the registration and admission process.
- The individual presents his/her QR code to be scanned (quick method) or the operator searches for the patient by name and age (alternative method).
- The operator verbally confirms the information of the patient (e.g. name and DOB or age).
- The operator annotates the patient’s record with a free-text entry or selects a pre-defined annotation (e.g. for a particular vaccine and dose).
- The operator reviews and confirms the entry.
- The system updates the patient’s record accordingly.
This scenario assumes that the patient has successfully completed and passed the registration and admission process.
- The individual presents his/her QR code to be scanned (quick method) or the operator searches for the patient by name and age (alternative method).
- The operator verbally confirms the information of the patient (e.g. name and DOB or age).
- The operator reviews any record annotations are as expected.
- The operator selects the command to discharge the patient (as well as an accompanying confirmation dialog).
- The system updates the patient’s status to DISCHARGED.
The context diagram included below provides a holistic overview of the system’s interactions with primary external entities (entities with which the system will interact).