The Rubi! EMR is made by the JETLYT Corporation. (pronounced "jet light")

1. To provide your large, busy, medical clinic the highest degree of business continuity and control through maximum independance.
2. To facilitate rapid patient flow through your clinic, by displaying all relevant information as fast as a user can click.

Sub to the second item: The goal is to eliminate "browser lag" and incessant scrolling as experienced in products like MedAccess and Connect Care. Also the overall layout has to be simple, more like a "map" than a bunch of click intensive rabbit holes found in products like HealthQuest and Oscar. (Side note on MedAccess: If "everything is a task" then, why is YOUR first task to organize all your tasks? The software should do that.)

Rubi! is the only EMR in Canada that uses the "Stream" concept. A Stream is a little bundle of documents, events, and agreements, that track a patient's temporary relationships with the clinic, from first request for service, to final disposition. Using Streams facilitates the quick and orderly presentation of RELATED items. Chronology is only a small part of your patient care record.

Most Used Features:

GPS ("Guidance and Processing System")

Allows clinic staff to track patient movement through your clinic by using only three panels: Expecting, On-Site, Released. Patients can communicate with the GPS system via the Client Web Portal running in their cell phone browser even before they arrive at the clinic, and when they are outside in the parking lot.

Staff can send text messages to patients to enter the clinic when an exam room is ready. A demographics form can be sent to the patient's while they are still in their car, so they can fill it out and submit it before entered the building.

Once a patient has completed their visit the GPS reminds the staff of Post Service Tasks, like cleaning scopes, entering billing codes (Using "Code-By-Question"). GPS also has an instrument/scope reprocessing system that times the reprocessing steps, so staff do not have to manually watch the clock or carry a pocket timer.

Booking Wizard

One of the most time wasting activities for staff is manually hunting through an image of a calendar looking for an opening of the right length of time for a service, especially when that service is only allowed on certain days, and has shared resources with other services provided by other providers (For example: single laser machine, single procedure room).

The Booking Wizard eliminates manual hunting and just provides a list of open booking slots. The Booking Wizard takes into account: Service availability time slots, lenght of service, extra minutes if needed, booking constraints, shared resources, extra days or extended clinic times. Software needs to provide answers not just information.

The Booking Wizard also acts as a "call coordinator", allowing multiple callers to book multiple patients sequentially from one list, preventing two different staff from calling the same patient twice.

Dial

Staff will love the fact that they can one-click dial a patient phone number on their desktop computer and have it ring on the desktop phone beside them. This integration reduces staff fatigue. It utilizes the RingCentral telephone system API.

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.

They are:

1. Data 24/7: Phone number lookup. Allows the differentiation between cell phone numbers and land lines. Cost is about $20 per month.
2. CDYNE: Allows the sending of text messages to cell phones. Cost is about $20 per month.
3. Off-site Canadian based server data backup: Recommended: eazyBackup. Cost is about $20 per server per month. You may choose your own off-site data backup provider, but having an off-site nightly backup is a requirement.
4. NetCare: Allows physicians to look up lab results for patients. Rubi!'s has "NetCare" buttons that start your browser and, after you log into NetCare, finds the selected patient. You may have multiple copies of Rubi! running, and they will all share the same instance of your open and logged in NetCare session. Cost is zero.
5. RingCentral: Sold by Telus. Allows Rubi!'s "Dial" button to dial a desktop telephone from a desktop computer. Cost is site dependant.
6. Web Browser: Used to graphically display provider schedules and certain logs. Usually included with every Microsoft Windows operating system.

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:

1. Windows Server hardware and software, for 5 to 50 doctors and up to 75 support staff: $6,000 one time charge, plus about $50 per month hardware maintenance (Expected useful life: 10 years)


2. Uninterruptible Power Supply for server: $4,500 one time charge (Expected useful life: 10 years)


3. Multi-User access to server:
   Options include Remote Desktop Computer Access License, Citrix, or WebDAV, or combination thereof.
   Exact configuration will depend on clinic needs.
   Cost will be clinic/configuration specific


4. Subscriptions to Data 24/7, CDYNE: About $40 a month


5. RingCentral telephone system: Not required if you don't need the "Dial" feature, otherwise, get a quote from Telus. Telus usually is able to work a deal where there is no capital expenditure on your part, you just get them to change your phone system.

Costs will be less for a smaller clinic and more for a larger clinic. Many clinics in Alberta, in the past few years, learned the hard way, that being down for one day, due to a failed cloud system cost more than Rubi!'s server and UPS cost combined.

Historical note: As part of their business continuity plan, cloud based systems vendors who applied for certification under the Physician Office System Program in Alberta, had to include an on-site server.

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.