Full-Stack Healthcare Operations System

Biomedical Equipment Records Management System (BERMS)

From biomedical clerk work at The Medical City, Clark.

The process comes from biomedical clerk work at The Medical City in Clark, from March to June 2023. Health informatics coursework is the layer that treats that file as something a report can be built from. The rows in the working example are a fresh setup, not an export from the hospital.

• The file

  Equipment documents, correspondence, and the maintenance paperwork the department ran on.

• The monthly report

  Reports and transmittals were prepared from those files and checked against the source before they went out.

• The retrieval

  Another department could ask for a device status or a document. The record had to answer without reconstructing the file.

• What BERMS holds

  Inventory, a calculated preventive maintenance status, maintenance history, service requests, and a CSV for the report. No patient information.

The clerk work used equipment inventories, preventive maintenance schedules, operational status, and service documentation. The record is built from those same facts: device name, asset tag, serial number, model, manufacturer, category, department, operational status, and maintenance schedule. Each service visit and each service request stays attached to the device. The rows below are sample records for a fresh setup, not an export from the hospital.

• Device identity

  Name, asset tag, serial number, model, manufacturer, category, and department. Creating a device records an asset registration, so later service stays on that device.

• Operational status

  In service, in repair, out of service, or decommissioned. This is separate from the preventive maintenance status.

• Maintenance schedule

  Monthly, quarterly, semi-annual, or annual. The next due date is what the status is calculated from.

• Service visit

  The visit, the operational status after the check, and the findings. Findings are required when the device is not returned to In Service.

• Service request

  Who reported it, the priority, the problem, and the status. Closing the request records the closed date.

Each device has one record. Operational status and preventive maintenance status stay separate. Preventive maintenance status is calculated from the next due date every time the record is opened. It is not stored as a value someone types in.

1. 01

   Not scheduled

   The record has no next preventive maintenance date.

2. 02

   Overdue

   The next preventive maintenance date is before today.

3. 03

   Due

   The next date is today, or it falls within the next 30 days.

4. 04

   On schedule

   The next date is more than 30 days from today.

The last preventive maintenance date changes only after preventive maintenance, an incoming inspection, an electrical safety test, or a calibration. A corrective visit can change the operational status. It does not change either preventive maintenance date. Decommissioned devices remain in the inventory totals and are excluded from the preventive maintenance counts. A service request does not reset those dates.

The useful part is what a reviewer can see before a count is used in a report. These are consequences of the record rules and the sample rows, not findings from the hospital's live inventory.

• In service and overdue can both be true

  IMG-017 is out of service and overdue. A different device can stay in service while maintenance is overdue. A single status would hide one of those facts.

• The follow-up row is specific

  IP-014 is on a quarterly schedule, assigned to the Emergency Department, and overdue, with supplier follow-up already noted and request SR-1001 still open.

• A filter must not change the total

  The counts above the table stay on the full inventory. A department filter cannot be read as the whole biomedical inventory.

• A repair does not reset maintenance

  Corrective work can change whether the device is in service. Only a qualifying visit moves the preventive maintenance date. A service request does not move it either.

• Waiting for parts is its own fact

  DF-033 is in repair, preventive maintenance is not scheduled, and SR-1002 is waiting for parts. Availability, maintenance, and the open request answer different questions.

The same records support the report, the retrieval, the service workflow, and the next maintenance cycle. This is the work that often stays in spreadsheets and paper files.

• One status is not enough

  Availability and preventive maintenance answer different questions. Storing them as one value hides one of the facts.

• A repair must not reset maintenance

  Corrective work and a service request can change whether the device is usable. Only a qualifying visit moves the preventive maintenance date.

• A filter must not change the total

  If the count above a filtered table shrinks with the filter, a department list gets reported as the whole inventory.

• A typed department name splits the report

  Two spellings of the same department are stored as two departments, so the breakdown is only as clean as the name.

• Equipment inventory

  • Asset registration, with category, department, and operational status.
  • Search by device name, asset tag, serial number, model, manufacturer, or department.
  • Filter by preventive maintenance status, operational status, category, schedule, and department.

• Preventive maintenance

  • Monthly, quarterly, semi-annual, or annual schedules.
  • Due and overdue status calculated from the next due date.
  • Maintenance history kept on the device, newest first.

• Service requests

  • A request is opened against a device, with a reporter and a problem description.
  • Priority is Low, Medium, or High.
  • Status moves through Open, In Progress, Waiting for Parts, Completed, or Cancelled.

• Operations dashboard

  • Fleet counts, equipment availability, and preventive maintenance compliance.
  • Department and category breakdowns.
  • Open work, request age, and devices that keep drawing service.

• Reporting center

  • Inventory, preventive maintenance schedule, service request, and operations summary reports.
  • Each file is a CSV, generated when it is downloaded.

Four views share the same records: the inventory, the operations dashboard, service requests, and the report center.

• Search and filter the inventory. The counts above the table stay on the full set of devices.
• Open a device for identity, operational status, preventive maintenance status, and history.
• Record a service visit with the status after the check and the findings.
• Open a service request and move it through to completion or cancellation.
• Read availability, maintenance compliance, and support demand on the dashboard.
• Download an inventory, maintenance schedule, service request, or operations summary CSV.
• Take a device out of use by marking it Decommissioned. The record is not deleted.

I designed the records, the database, and the tests. The maintenance rules do not depend on the framework. The working example is a page that calls a JSON API. The server checks the input, applies those rules, and reads and writes the database with parameterized queries.

Working example: HTML, CSS, JavaScript, Node.js, Express.js, MySQL, Node.js assert tests.

Screens from the working example. Sample devices only. No patient information, and not the hospital's production system.

BERMS comes from biomedical clerk work at The Medical City. Equipment availability, preventive maintenance, and the service already on file stay on one record, so a monthly report and a department request follow the same rules.

• Healthcare operations
• Information management
• Reporting support
• Data validation

The work is the equipment lifecycle at The Medical City: what is in service, what maintenance is due, and what service is already on file. A report and a department request use that same record.

• Data Analyst
• Operations Analyst
• Healthcare Analyst
• Business Analyst
• IT Analyst
• Application Support
• Systems Analyst
• Junior Software Developer
• Backend Developer