7 responses

  1. Nick Orlowski
    August 18, 2010

    Ankhos uses the hybrid approach and it works quite well. It uses a web browser to access the application within our office. Our original plan was to do use the SaaS platform with an internet-hosted site but we decided that the security risks of going on the open internet were just too great.

    Ankhos is very fast and responsive and is in a class of web apps called Rich Internet Applications , which are coming very close to the usability of native desktop applications.

    Note that most native desktop apps are simply client-server interfaces… just like the browser and a web server. Microsoft outlook (a classic native client app) is only as fast as it’s servers can be.

    Like John said, the internal server setup is more complicated than SaaS, but it allows more control and security. Just make sure you get someone who knows what they are doing and be prepared to be more involved in the process.

  2. David Swink
    August 19, 2010

    If this were a hardware store, a client-server solution would be fine, because there is no need to share information. But the whole point of EMR is to make medical records easier to use, which means sharing information among other doctors and clinics. Updates to patient information should be done in-place at a single location, and that implies a web domain name to make it accessible in multiple locations.

    Think email. POP3 was OK in its day, but a webmail account is much more flexible and thus more useful — one can read one’s email from anywhere in the world. Whether I choose gmail, yahoo, or hotmail is irrelevant — my messages are globally accessible because they don’t reside on my computer.

    Of course, security issues must be worked out. But if one is making the tremendous effort to embrace EMR, why settle for merely more efficient storage of your paper?

  3. John
    August 19, 2010

    That’s a bit of a generalization. Some in house EMR software has as much or more information sharing capabilities as the SaaS EMR software out there. In fact, I’d say that most SaaS EMR software and in house EMR software still has a long way to go in information sharing. Is one easier than the other to share? Only if 2 people are on the same SaaS EMR is it easier to share.

  4. Jojo P
    August 19, 2010

    These are my technical remarks:

    > if you’re in a place where your internet connectivity is not reliable

    Do not make this condition the decision factor to consider SaaS. Even if your internet connectivity is reliable there are other factors why you may not want to implement SaaS with respect to internet connectivity. However reliable your internet connetivity is it still can fail. For most small-sized clinical facilities it will be cost un-affordable to subscribe to a highly resilient internet connection. I’ve seen internet (even frame relay) subscriptions go down for a long time (hours) even if they have an SLA (Service Level Agreement). So what would a clinic do if their internet connection fails ? Close shop for the hour and hope that everything goes back normal ?

    >…accessed using terminal server software as well, but that isn’t usually considered a SaaS EMR for purposes of this description.

    You’ll be amazed that most SaaS solutions is not web-based but RDP (Remote Desktop Client / Terminal Services). New Terminal Services technology can show you just the application (making the back-end transparent) making it look as if they were accessing the software program in-house. Don’t count this out, because if browser-based does not work, there is always a Terminal Server waiting for you to peruse.

    > Since a SaaS EMR uses a standard internet web browser, you will not need to spend time installing special software on each computer in your office. This is even more beneficial when your SaaS EMR does an upgrade to the software.

    When it comes to Java (most likely this will be the back-end technology used for browser-based SaaS applications) it is not true that there is no need for a client installation. The correct version of the Java client software is needed on the clinical desktop computers. Most versions of Java client are compatible to a specific Java back-end for the SaaS. The problem lies when the clinic’s IT department updates the client Java version (for some tehnical reason) without consorting with the SaaS provider (or vice-versa). The same issue lies with Terminal Server, Internet Explorer, Firefox and Flash players. What I am saying is it is not that easy to say that all that is needed is a browser which is already built-in with the desktop computer. Most software sales people will sell it this way, unknowingly there are client-based issues to fix during implementation.

    >Some SaaS EMR vendors will provide a backup copy of your data which you can store locally, but this is not very common and cannot usually be done at regular intervals.

    There is no use for a backup copy of the data as this is too raw. If there is no “SaaS” system located in-house the backup copy can not be used at all.

    > SaaS EMR vendors argue that there’s no need to store a copy of your data locally since the server where your data is stored uses enterprise level backup to avoid any loss of data.

    Data recovery and Business continuity are two different things. Data Recovery is for restoring data when lost. Business continuity is for (exactly) continued business functions regardless of where the data is.

    >Hybrid model

    My idea of a hybrid model is a SaaS that resides in both the SaaS provider’s location and in-house. Data is generated from the clinic and processed in-house. This will fix the latency (slowness) and connectivity issues with regards to the internet connection. When the processed data has reached a particular time (say 1 -2 minutes) the in-house data will be uploaded to the SaaS provider location as replicated data. This architecture allows business continuity when a computer disaster strikes in-house, but note that you still need an internet connection to access the SaaS. There are many variations of this type of business continuity and it will depend on how the software is modeled. It is important to say that the selection of EMR should encompass as to how the business continuity is designed either or both by the software developer and the IT implementation team.

    Cheers for my 2 cents.

    Jojo P

  5. Nick Orlowski
    August 19, 2010

    Email is one of the least secure protocols on the Internet, although most vendors are now using https to encrypt the traffic.. — The bottom line is that if it’s encrypted, it CAN be hacked (and sold/leaked). There needs to be a balance between risk and accessability, and we just don’t see the need to be on the public Internet yet if we can do everything for ourselves in-house.

    Also, Our EMR is not just about storing papers electronically. We are using our EMR to streamline the clinic oncology workflow. Workflow first, papers second.

    Good point about the “Meta” hybrid, where you have an in house and out -of-house server working together. I don’t agree with your Java remark though. Java should not be confused with Javascript; they are very different. Most web apps run in javascript which comes with all browsers, while as you say, Java does not.

  6. John
    August 19, 2010

    I could say much more, but a few comments.

    I’m definitely not counting out the various RDP/terminal service solutions. They have come a long way and are definitely options to consider. Just for definition I left them out of the SaaS versus in house discussion.

    People still code with Java? Ok, I know there are some that still do, but it’s becoming less and less so. Sure, some browser compatibility issues still come up, but not if the EMR is built right. Plus, it’s still easier to deal with than client installs.

    There’s certainly a use for a local copy of the data at your office. A nice XML export of all the data in your EMR would be incredibly valuable to have if you are using a SaaS EMR system. Sadly, only a few vendors offer this type of capability.

  7. Javier
    August 23, 2010

    I have been in the Puerto Rico IT industry for 30 years, specifically in the Network and Server arena. As you well know many of the Local ISPs (at some point or another and quite often) have connectivity issues. First evaluate that as your first point failure. Next and most importantly, Due diligence, Many EMR/EHR Vendors are misrepresenting Certification status and how the incentive program works in Puerto Rico.
    For starters we have Identified 4 companies claiming to be Certified. 2 are CCHIT certified (one preliminary), but until ONC completes the selection process, they are not HHS acceptable. The other two Claim to be CCHIT certified but are not.
    To add further, the majority of Puerto Rico’s Medicare population is under several Medicare Advantage programs. So as a provider if you do not qualify under the MA 80/20 rule you may not qualify for the incentives at all.

    Buyer beware.

Back to top
mobile desktop