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.
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. a) Patient Registration i. Three names (Two Mandatory) ii. Age, Date of birth iii. Gender iv. Telephone No v. Email address vi. Residence vii. Guardian if Minors and Next of kin for adults viii. Insurance information - provider name, card number, package b) Selection of payment mode - Consultation fee, Test Fees c) Retrieval of patient file d) Bill Patient Consultation fee e) Que Management The receptionist will be able to view booked appointments and assign them to doctors. The patient will only select category ie, a specialist, or general consultant but not the exact Doctor. 2. Triage Room Information Information to display: Patient history Patient in queue a) Take Vitals i. Bp ii. Weight iii. BMI (Calculated) iv. Height v. Temp vi. Pulse vii. Respiration b) Clinical notes- Typed
- Consultation Room a) Clinical notes – Typed b) Physical Examination c) Requests: i. Lab ii. Procedures iii. Pharmacy iv. Radiology v. Admission vi. Referral
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.
b) Registration of OTC c) Section commodity/inventory management 6. Radiology. 7. In Patients a) Receive patients b) Doctor ward rounds i. Clinical notes – Typed ii. Physical Examination iii. Requests:
- Lab
- Procedures
- Pharmacy
- Radiology
- Referral c) Periodic Monitor Vitals d) Give periodic Medications e) Do periodic procedures f) Nurse Handover i. Clinical notes
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 are 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). An invoice can generated that will contain the transactions at every stage. Each test or drug has to have the option to chose the mode of payments 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. A payment receipt will be generated from the final invoice. The receipt will have the invoice number that will link the invoice to the receipt. One option is to have a tracking entity in every entity that transacts or any entity that has a cost/fees aspect ie prescribed drug, appointment and lab test request. Each of these tables will have a OrderBill Foreign key referencing to a OrderBill table.
HR System
Medication/Clinical Flow Diagram After the patient has been sent to the doctor, what next? This Business Process Model and notation (BPMN) diagram serves to explain that. The process involves the laboratory. The doctor will examine and recommend diagnosis done for specific elements (ref by acute appendicitis in the diagram), if the element is found we go to treatment/surgery. If the element is not found, the process moves to a further assessment.
The diagram is a sample diagram that can be customized for our specific use cases.
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