Check out photos of this project
Check out architectural diagrams of this project
What was the problem to be solved?
Qualis is a DME Management company that brokers deals with Hospices across the country to lower their bills and streamline management of medical equipment provided by third-party DME vendors.
In many situations, a Hospice nurse would use Qualis' mobile app to order medical equipment for one of their patients.
This order would notify the corresponding vendor, who would then deliver the equipment and then is supposed to update the order once it is delivered, which would start the billing cycle.
Similarly, when the equipment was no longer needed, the nurse would use the app to request that the equipment be picked up, which would notify the vendor who then picks up the equipment and (supposedly) denote the pickup in the application, thus ending the billing cycle.
The problem is that the vendors would often neglect to update the orders thus messing up the billing which would have to be reconciled after the fact.
Furthermore, there would be discrepancies between the hospice nurse, who would claim equipment was never dropped off and vendors who would claim the equipment was dropped off.
What was the proposed solution?
As there is no standard barcoding or numbering structure (hospices use different vendors and vendors serve many hospices all with their own SKU structure), there was no way to scan in delivers allowing the nurse or the vendor to scan items in upon delivery.
The app was completely reliant on someone remembering to go into the app and manually updating the order.
To solve this, we built OBD-2 devices that can plug into any vehicle built after 1998 (which, in this case was all of the delivery trucks).
The devices would broadcast the truck's location and notify the app when it broke a certain geographic distance (either in miles or expected delivery time).
For example, the nurse would get a notification when a vendor was en route for a delivery and was within 10 minutes or 3 miles of the facility.
Additionally, we used an Algorithm to determine if the vehicle stopped at the address long enough that a delivery was likely to have occurred.
We also broadcast this information to the app which could then mark the order as delivered (or picked up).
What challenges arose during the project?
There were two big challenges with this project and they kind of went hand in hand.
First, cellular data is not cheap. Well, it can be, but only 2G cellular data which was unreliable at best and being phased out.
This meant we had to bite the bullet and put 3G sim cards in all devices, which cost a significant amount when the number of trucks began to add up.
We had to optimize the data in transit so as to use as little bandwidth as possible and also limit the number of HTTP connections.
What was the technical approach to the project?
Internally, the embedded devices were Arduino UNOs that ran off of constant power from the OBD2 port.
The DynamoDB stream would forward the data to another Lambda function which would decode the NMEA string into GPS data coordinates and broadcast the notification to any software that registered a point of inteREST within a desired distance of those coordinates.
The existing software would also register a callback URL which the above Lambda function would notify via a POST request.
This left the software to handle the data in anyway it saw fit.
What was the project management approach to the project?
Finding the right data plan and device was a huge unknown, so we ended up starting the project with four Research Sprints to determine the best combination.
After we had a functional device prototype, we begin working on a standard sprint schedule until release:
1) One week function sprint where we added new functionality
2) One week QA sprint
3) One week bug fix sprint
Repeat until finished.
What did you learn from working on this project?
We were reminded of the difficulties of releasing custom-built hardware.
Our early devices failed in hot locations like Florida and needed to be redesigned.
We also learned the challenges of pushing firmware updates to remote devices, however, AWS' platform made this a lot simpler.
How did this project benefit the client?
Qualis was able to nearly completely automate the pickup and delivery process, removing the reliance on nurses and vendors to provide the data.
This meant far less time at the end of the month reconciling billing, which allowed Qualis to lower clients' bill by nearly 6% on average and allowed them to provide a further service to their clients, which aided in their Business Development efforts.
Why was Gunner selected for this project?
Gunner had been working with Qualis since 2011 as their technology provider.
We had developed their entire software stack, so we were intimately aware of some of the problems.
Our primary engineer on the Qualis account noticed this problem and proposed an IoT solution, which Qualis greenlit.
What tools, techniques and methodologies were used on this project?