One of these days I’m going to get to programming.
Here’s the situation :
An employer has a bunch of remote employees that spend time on their clients site. The employer needs to track when they start, end but only when they are at the site (GPS?), they need to ask questions of the employer before they start.
This information has to be transmitted to the employers database for tracking.
I get the database on both sides, but how do I assure the employee is at the site when entering the information?
How do I get the information from the employee to the employer?
Seems like client-server but I’ve never done that. This would be an app that I would sell so I would like to keep expenses down. What is the best way to accomplish this?
Are there any third party tools to make this easier?
Any ideas or input would be greatly appreciated.
Jerry
If the employees live in a different city to the clients you can avoid GPS (major privacy issues!) by recording the employee’s IP address when connecting in from the client network. You can get a free database (ip2location.com) to lookup the city of that IP Address.
IP location outside a data-centre is famously unreliable, in the UK at least. Connections through an ISP network will show the source as the ISPs Point of Presence. Currently my own fixed IP indicates I’m 180 miles away and regularly shifts between three cities, none within 50 miles of my actual location.
GPS has it’s own reliability issues especially indoors and around densely built areas.
Well your requirement is a little short on detail. Based on what you have said. It’s probably a mobile phone client app communicating with a web application hosted by the employer utilising an RESTful or similar API. A mobile client will give you the best cheap rate location tracking and can communicate with the server using https over mobile internet or whatever is available. The server can sit onprem at the employer if they have the infrastructure or in the cloud if they don’t.
Its conceptual at this point. The idea is for an App to sell to home health aide companies.
The company pays their employees to visit sick patients at their homes and pays them by the hour. The companies have to track if the employees are sick or not, make sure they are where they say they are and then of course have the hours so they can input them
I’ve never done client/server - only local databases. I’m just trying to figure out feasibility. These companies are not big - just a few employees. I wouldnt think they would know how or want to host a server.
I assume there would be no direct communication and there would have to be a server of some sort between the two. If thats the case, I would need to set that up for multiple employers.
I just dont know where to start looking for the tools, where or how to set up the servers, etc.
I’m sure somehwere there are third party tools that help with the database and the servers, just dont know.
Appreciate any help.
You would need GPS to do this, which without a cloud server would mean only Mobile apps (no Web app option).
You could have the Mobile apps communicate to a central Desktop “employer” app over the local network when the employees return to the office, if that’s part of their routine.
If you choose the cloud-server route you will be paying server costs for the lifetime of the product which is not recommended unless you are operating a subscription product. If you are going subscription, a cloud server and a central Xojo Web app to act as a data synchronization API is quite feasible.
You should be able to do LAN communication, the devices and systems themselves can, but I don’t honestly know if Xojo includes features for that.
That’s just a matter of proper database design.
If you are going the cloud server route: Xojo Mobile apps + Xojo Web as a central data-sync server + Lifeboat to host your server.
If you wanted to investigate LAN networking, that would be a cloud-free option, but I am not as familiar those and can’t make recommendations. Finding out if LAN communication is possible from Xojo Mobile would be a start.
There’s a ton of reasons GPS isn’t the right approach here. As noted above, it isn’t reliable from a whole host of reasons - one being that it really struggles in cities with tall skyscrapers. It’s not hard to imagine that it might completely fail in some apartments, or underground, etc. Also - what about neighbors? GPS isn’t good enough to tell one apartment from another. What if the patient moves, or needs to receive treatment at an unexpected address? The issues really start to pile up.
Here’s an approach that might make more sense: give the patients QR codes that the in-person provider scans. They’d have one for “treatment started” and another for “treatment ended”, and using a custom app on the provider’s device would automatically create entries in the database. The codes themselves could be accessed via an app on the patient’s phone, or via their email, or delivered to them on paper via the snail mail. This could even be coupled with pulling up the patient’s records on the provider’s device, removing the process of looking up the patient manually.
This approach really puts the patient and their treatment at the center of the process, instead of linking treatment to a specific location.
Others will give you excellent advice on how to use Xojo to accomplish your goals. I’ll just toss in that this is a classic use case for Filemaker, a server-based database system with excellent support for mobile apps and web access; in fact, it’s probably easier and faster to do in Filemaker than almost any other tool.
To me that seems like it puts unwanted burden on Patients. Imagine: Patient loses QR code because it means little to them and suddenly Employee can’t confirm their whereabouts.
As a patient, I wouldn’t like this process as part of my service.
Have you ever done physical therapy? They often use apps to coach patients on the exercises to do in between appointments. And they also frequently issue paperwork to patients.
Any of these approaches will have strengths and weaknesses… getting QR codes to patients is a small challenge that could be overcome, I think.
Well, I would weigh the development time savings against the cost; Filemaker development can proceed very rapidly and is also easier to revise later. FM takes care of so much of the tedium of implementing and maintaining a UI for a database that it really can be the best solution costwise. Client-server functionality is inherent in the design and it handles complex database structures with ease.
The tradeoff is that FM isn’t a complete development environment in the Xojo sense and there are some complex tasks that would require plugins or overly complicated setups. But overall, given what you’ve said so far, I would seriously map out a FM solution and see what the cost differential would be.
If I had to guess, I would say that a large percentage of FM usage falls into two categories: inventory, and job/time tracking. As a result, FM is well-suited for those use cases and there are many, many examples of these types of solutions. That’s why I’m leaning so hard on recommending it.
Is the intent to use the location for automatic time billing, or just a back-end audit of the time submitted by some other way by the employee? I.E. start visit and end visit buttons. I think automatic billing based on location is going to be unreliable.
If the later, why not a simple photo of building/address at beginning and at end of service and parse out the EXEIF data from the image, which contains date and time? You could also capture the GPS location, if available and store that in the time record as a secondary piece of data, if available. Between the two, the employer can have some level of confidence in the employee’s time submissions.
I think Eric’s idea of a QR code is a good one but as it seems part of the original brief was trying to make sure the health visitor was actually with the patient ( hence the use of GPS ) the code should be a session token rather than just a simple patient id.
The idea would be that there are two modes - one for the patient and one for the health visitor. When the consultation starts the patient uses their app to request a QR code / session token which is then scanned by the health visitor using their app and then you have confirmed they are both in the same place at the same time…
I thought about that as well but was puzzling over why make it so complicated. What are we trying to prevent by creating session-specific codes? Perhaps we’re worried that a provider will try to defraud the system via fake barcodes? It wouldn’t be easy to create copies of the codes in such a way that they could be scanned later. You’d have to photograph them and print them out, or transfer them to another device and scan the screen using the provider device.
Session-specific codes also require quite a bit of actively maintained infrastructure and access to it by the patient, from a server to generate/track/transmit the codes all the way down the wire to the patient needing to make sure their device is working and able to access the code server at the right moment. It really starts to add up.
There’s a larger question here of how much trust is placed in the provider. How much future fraud risk are we trying to mitigate? How much fraud do we suspect is happening under the current system? And how complex a tracking system are we willing to implement and maintain as a result?
In my experience, a little goes a long way. The act of implementing even a very simple system has a tendency to keep people more honest. Yes, there will always be people sufficiently motivated to game the system, but they’re always going to figure a way to do that. If you can mitigate a large amount of fraud risk with a modest system, that can often be enough.