The Rubi! EMR is made by the JETLYT Corporation. (pronounced "jet light")
Busy clinics with many physicians or other providers, and many supporting staff. The bigger the clinic, the more likely the clinic has information technology infrastructure, such as servers and hardware maintenance people to look after them properly, already in place. If you don't have any of this in place, don't worry, it can all be purchased, installed and configured, for reasonable prices.
The term "Ease of Use" is not a state, it's a continuum. The phrase "Everything is easy if you know how" is apt in this case. There is "Easy to Use" for a beginner user, and "Easy to Use" for an experienced user. Beginner users need simpler screens with very few controls, a small amount of data, and a large amount of instructional text. This results in a lot of paging through different screens. That means a lot of mouse clicks, and total effort expended. Experienced users want more data and controls on screen, so they can see everything they need instantly. They need very little or no instructional text. This is the opposite of a beginner user. It is impossible to satisfy both types of user with one interface. A good start for Rubi! users, is to read the "Screen Capture Tour" document. User training is included as part of the Rubi! licensing agreement.
This slider bar shows where Rubi! was designed to fit on the "Ease of Use" continuum:
Several features in Rubi! depend on outside companies that the customer will need a subscription with. These dependancies, except for the data backup, are not mission critical, and will not prevent your clinic from using Rubi! if they are not implemented, or if communication with them fails.
Server operating system version should not be so old that it is no longer supported by Microsoft. The server should have a RAID system and backup software installed and running. Cost is server dependant. Qualifying servers already owned by the customer can be used, or JETLYT can help with the specifications for a new one.
Cost is implementation dependant. Contact us for a quote. If you already have an EMR, and you'd like a "competitive upgrade" price, send us the invoice for your current EMR. Rubi! does not have the lowest cost per month of many other EMRs. However, the overall lifetime cost of ownership will be the less when compared to a cloud based system that cannot be reached, due to long distance data transmission equipment failure (which has already happened in Alberta, several times) or unexpected termination of contract by the EMR vendor. Rubi! will also be the lowest cost, when compared on new feature implementation, new report creation, data export costs, and quickest interface response times, and the elimination of manual "hunting" for appointments, and automated patient interactions.
If you are currenlty a paper based clinic, here are some ball park figures for budgetary purposes:
This is required if you need to do AHS billing. Rubi! produces output files for you to upload to H-Link, and imports result files you download from H-Link. It involves filling out and emailing a form. Cost is zero. Private pay services do not need this feature.
NetCare has it's own prerequisites for a clinic that wants to upload data to NetCare. The maker of Rubi! has taken the required initial steps to build a custom made NetCare uploader for your clinic. Success will depend upon approval from NetCare, and the type of equipment that you have producing medical data files. If NetCare approves your clinic, and the data you have to upload is acceptable, the makers of Rubi! will build the intermediate "uploader" piece at no charge to you.
Rubi! exists because the makers of Rubi! were approached by the original customer (a clinic in Edmonton, Alberta) which had fully reviewed about fifteen other EMRs, then out of that group, in succession, fully committed to, and paid for, and fully implemented three well known name brand EMRs. The results were unexpected.
One was based on Java/Cloud technology from BC. It was so slow, users would click a button, then 20 seconds later, something would happen. Then click on another button, then there'd be a 20 second delay, then something would happen. This was on the very same hardware that was running competitor's EMR at acceptable speed (for a browser based application). That EMR had to be abandoned.
Another EMR tried was again, cloud based, in Calgary. It followed the design philosophy that "everything is a task". Upon implementation, it was discovered, that the first task, was to organize all the things that are now "tasks". This took a lot of time and labor. Rubi!'s documents are self sorting. Rubi!'s tasks are self sorting. All the meta-data is gathered when the document or task is first created. After that, everything is automated.
The second major problem with that EMR was that it could not accept scans of paper documents. Even though the customer clinic was not paper based, patients kept bringing in paper, which was part of their medical record. Plus the fax machine was producing a high number of .Pdf documents. Those need to be uploaded as well. The clinic had to upload about three hundred documents per shift. The web-based cloud-based EMR could not handle the quantity of uploaded documents. It kept failing. Telephone support told our customer to "not upload so many documents". This was not acceptable. To top things off, the EMR entirely failed during a busy Saturday clinic. Everyone was stopped and the ridiculous "business continuity backup server" was only one unit, and could not be used by all the physicians and staff that needed access to information. That EMR was cancelled.
A year after cancellation, our customer got a call from that EMR vendor, letting our customer know that our feature suggestion for improving their EMR was completed (it was simply adding a field), and now they would be charging our customer $200 a month extra for the extra "feature". It took three tries over three months from our customer, to the EMR vendor, to convince them that we were no longer a customer, and had all the legal paperwork to PROVE that our customer was no longer their customer, and did not owe them anything.
An EMR that the customer had in place was built in the late 1980s or early 1990s when computer screens were 640 x 480 in size. This one ran on a local server, so it was reasonably fast, which is why the customer ran with it. The EMR vendor had added a pretty splashscreen on startup to "modernize" it, but the interface was still pretty awful. Users had to navigate a bunch of isolated rabbit holes, that you could tell were all "tacked on" to an older system based on a design plan with insufficient scope for the need to which it was now applied. The system was not paper friendly, and it was a huge pain trying to import photos. When our customer told the EMR vendor that they wanted to export their data so as to upload to a different EMR, our customer was told they had to pay $6,000 per doctor. The EMR vendor held the doctor's patients records hostage. That problem was worked around, and that EMR vendor was left in the rear view mirror.
Our customer avoided the well known FREE EMR altogether. Hearing from other users who reported that they all got carpel tunnel syndrome from having to click so much to get anything done, made our customer realize that FREE doesn't always mean GOOD. (However, GOOD, or even EXCELLENT, is sometimes free) Bogged down patient flow, caused by fatigued staff with repetitive strain injury is not a welcome scenario. If the point of an EMR is to help patients, enable staff, and ensure the business viability of the clinic, our customer had to say "No" to that EMR.
Thanks to our original customer back in 2010, scoping, design and construction of the foundations and precursors to the Rubi! EMR were started, and now your big, busy clinic, can benefit from all the intervening years of building and refinement.