Home
Make-Easy HMIS Technical Implementation Sample data model : https://docs.openmrs.org/datamodel/ Sample Modules breakdown: https://www.vertikalsystems.com/en/products/pm/features.htm
Technical Implementation TA high level presentation of the system is shown below;
Users: The system will have four different user groups, DOCTOR, NURSE, LAB_TECH, or SYS_ADMIN and PATIENTS. Default user group is PATIENT, this will avoid public registration endpoints from asking the Role. We will create a custom Django user model called CustomUser. This model has a role field that can be set to one of four values: DOCTOR, NURSE, LAB_TECH, PATIENT or SYS_ADMIN. We also will create five profile models, one for each type of user. These profile models can be used to store additional information about each user, such as their license number, department, or specialty.
Handling Navigation for different users: Doctors - dashboard, referrals, lab queues, admissions, triage Nurses - dashboard, phlebotomy, lab queues, triage Lab techs - Lab screen, Pharmacists - pharmacy screen System administrator - superuser, can CRUD users, can access all screens
To create a new user, you would first create a CustomUser instance and set the role field to the appropriate value. Then, we would create a profile instance for the user and populate it with the necessary information. Once we have created a new user, we can assign permissions to them by adding them to groups or by directly assigning permissions to them. For example, we could create a group called doctors and assign all doctors to that group. Then, we could assign permissions to the doctors group, such as the permission to access patient records.
- Patient Registration: Three names (Two Mandatory), Age, Date of birth, Gender, Telephone No, Email address, Residence, Guardian if Minors and Next of kin for adults, Insurance information (rovider name, card number, package)
- Selection of payment mode - Consultation fee, Test Fees
- Retrieval of patient file
- Bill Patient Consultation fee
- Que Management The receptionist will be able to view booked appointments and assign them to doctors. The patient will only select a category/service ie, a Laboratory, or general consultant but not the exact Doctor.
- Triage Room Information: Bp, Weight, BMI (Calculated), Height, Temp, Pulse, Respiration
- Consultation Room
When a patient is sent to the lab by a doctor they first go to the phlebotomy room. Here, a new dataset is created containing the patient_id and lab_number. This is stored in the test_request table. From the phlebotomy room, the sample is attached a barcode that will have the patient’s info including the lab number. The sample is then given to the lab techs. The lab_number is what will be identified in the system as it relates to the patients later on in reporting.
A test will have a unique lab number. If a patient has more than one tests, each of the tests will have a different lab number. The laboratory process will be as follows; a) Sample collection and billing - Phlebotomy. Associated table- patient_identifier The phlebotomist will see which tests have been requested by a doctor, get the patient, collect sample and check that sample has been collected, add cost and send to Lab. b) Processing - The LabTech will schedule/send the test to the appropriate equipment. c) Validating - after the test has been run, the LabTech will see the results in the equipment interface and validate. d) Posting results - the results will be sent to the system/database.
Lab equipment can be classified into two categories depending on how they communicate; Those with an inbuilt computer and those connected to a external computer. An example of the latter is the HumaStar 100 which reads and writes to a shared directory. One implementation would be to have a module run locally on that computer that communicates with the database and the shared directories. Most equipments that have an inbuilt computer communicate with the HMIS over the network using TCP/IP. A more complex set up for lab equipments with inbuilt computers is for those that use RS232 serial connection. These will have to be converted to TCP/IP hence connecting them to the network. An important thing to note is that both the equipment and HMIS host should be identified over IPs.
The main integration mode however will be TCP/IP. This means the system has to be able to identify specific equipments over the network.
All lab test requests will go into a table once confirmed (triggered by SendtoLab). An entry to this table will trigger the function that converts the test request to HL7/ASTM then sends to Equipment IP.
Notify patients when their medications are ready for pick-up.
Drug Information and Interaction Checking
Generate reports on medication usage, dispensing trends, and inventory levels.
Check for potential drug allergies and interactions with other medications.
The prescription workflow is as shown below:
Goods are purchased then go into the purchase orders. From here they are sent to each department where they get used/dispensed/consumed and go into the OrderBill table. Each item that goes final order ie a test should be reflected in the inventory. A full hemogram test for example will take a certain reagent, syringe, swab etc, this items should reflect in the inventory. An approach to this is to have an Item table and have its Foreign key in each item’s table ie Drug, LabReagents,
To track items on which section they were sent to, we can have a section field per item, or create a separate table to track sectional-disbursed items. a) Main W/H i. LPO to suppliers ii. Receive goods iii. Issue to sections b) Sectional W/H i. Requisition to Main W/H ii. Receive goods 9. Dental Module Referrals Module (to external labs, Hospitals, Doctors)
Invoices can be generated after every monetary transaction. There are three points, at the reception when a patient pays for consultation, at the phlebotomist when samples are collected and test requests are sent to the lab (the test requests are generated originally by the doctor ), and at the pharmacist when drugs are dispensed (prescriptions originally from the doctor). Each test or drug has to have the option to choose the mode of payment ie insurance or cash. The final invoice will compute items per payment model. If a patient chooses to pay after every stage, i.e they decide to pay at the reception for consultation, the final invoice should reflect that payment even if other items later i.e at the phlebotomists are added. Appointments, LabTestRequest and PrescribedDrugs have Item IDs, these Item IDs have a price tag, however, the fields are editable at the point of recording those interactions. If they are not edited, they're picked as the price in the invoice and computed.
| appointment | PrescribedDrug | LabTestRequest |
|---|---|---|
| patient_ID | prescription_id (Patinet_ID) | patient_ID |
| appointent_date | dosage | note |
| status | frequency | sample_collected |
| reason | duration | test_profile_Id(name, cost, Item_Id) |
| fee | note | requested_by |
| assigned_doctor | Item_ID | equipment |
| Item_ID |
The billing module has two main tables, Invoice and InvoiceItem. The InvoiceItem is what stores the records above and links them to an Invoice. The Item_ID is what contains the pricing info by default of not provided.
