An Internet model- first experiences

The Internet Model

Recently, we've had more and more non-Medtuity users describe how they would like to see an Internet model of Medtuity.

First, a little background. When Dr. Winn described many months ago how eMD would go to the Internet model, it got me to thinking...lots.  MedtuityEMR already had a rich GUI, something that I did not want to give up, and it had lots of intelligence built in, another item I did not want to remove. So how could we approach an Internet model...

With an Internet model, the application data is hosted centrally on a server and access is close to ubiquitous.

The differences in how that model is programmed falls into two camps

• browser based where the server does everything, serving up HTML pages with which the user interacts, or
• rich application based where the server serves up the data, but the application has a rich GUI and lots of intelligence

Which is better?  Clearly for the mild mannered "application" that has no complexity, the HTML/ASP solution is great.  All the user needs is a browser.  Ordering on-line goods and services is a good example.

For the heavy-duty application, such as an EMR, a model that is better is the rich application model.  That is, an application is provided which has a rich interface and is capable of performing complex tasks, allthewhile connected to the database via the Internet.

Because the Medtuity application stores everything in the database and nothing locally (except a couple of registry settings to know where the database lies), it is already a candidate for the Internet model.  Because it has a rich GUI and is able to perform complex tasks, its better as a rich application model, not browser based.  The only thing lacking is the ability to retrieve data through the Internet.

To test the Internet model concept, we enhanced our database access layer within the Medtuity application so that, located on any computer, it could communicate with the server to gets its data.  In the database world, only a few things are essential--  they are referred to as CRUD -- to Create, Read, Update and Delete and so we added that ability on the server side.  All MedtuityEMR had to do was to marshall the data to the server, have the server perform CRUD, and to marshall data back.  With that in place, I was able to start Medtuity from my home, without a VPN, and run it with the server located miles away.

Here's what I now know from the experiment:

The Internet is either too slow or  Medtuity requires too much data for this to work at the speed that our users are accustomed.  Nevertheless, the concept is good-  the only data passing from client-to-server and server-to-client  is data that is required. The server is freed of the duties of creating complex HTML pages.

I'm excited enough by this model that we will continue to work on this technology to create more speed in hopes that one day it can provide an alternative to hosting the data locally, but still allow a rich GUI and real intelligence built into the application.

Matt,

Why don't you just use Citrix (or a cheaper RDP based solution) as other vendors do?  Its much faster than trying to optimize passing data from the client to the server, and then potential clients do not need to upgrade their workstations.  I plan to offer it as the windows option for PatientOS 1.0 ASP. 

It is obviously not free and so (cough, plug...) hence the nice thing about writing in Java is that it can also be deployed as ASP on fast and economical platforms that do not require Windows .... :-)

Greg

http://www.patientos.org

Greg,

Easy. We already have clients using both Citrix and Remote Desktop.  I wanted to investigate another solution where many clients can be connected.  We have clients running RDP + SQL Server on their server and maxing out with about 10 Medtuity sessions concurrently.

Regarding language, C++ is much faster than C# and Java.

Do you connect directly to SQLServer or I thought you had middleware.  Not sure I understand why go for disconnected remote clients.   I have been asked similar questions but I am missing the point - more management overhead.  So you have 10 Citrix servers and SQL server on an 11th ?  Is it the cost of additional servers or where is the performance bottleneck?

C is faster than C++ but there was a reason C++ superceded it ...

The client connects to a small middleware program on the server.  The middleware connects to SQL Server (which can be hosted on the same machine, if needed.)

C++ is a great language and far faster than C# or Java.  I love C++.  Our customers never complain of speed issues.

C# continues to be heavily promoted by Microsoft because it allows almost anyone to program.  It has automatic memory management (placed there because poor C++ programmers would forever forget to give heap memory back to the OS).  It was never a problem for the experienced C++ programmer though.  C++ is a tougher language to learn and use. Nevertheless, comparing C++ to C# is like comparing a Corvette to a Ice Cream truck-- the latter has some bells and whistles which attract young programmers-- treats...but no speed.

My brother programmed in C++ for years.  He now programs under Silverlight using C#.  He laughs about the drastic loss of speed.

The thing is that as hardware speeds up according to Moore's Law, such differences will disappear with any advantages.

The problem with a browser based RIA is that the server creates all the complex layouts and so all this stuff passes down the wire.  Whereas a decent fat RIA can just deal with data and will always be faster.  So, here the trade off is ubiquity vs speed.

mchasemd:

The client connects to a small middleware program on the server.  The middleware connects to SQL Server (which can be hosted on the same machine, if needed.)

C++ is a great language and far faster than C# or Java.  I love C++.  Our customers never complain of speed issues.

C# continues to be heavily promoted by Microsoft because it allows almost anyone to program.  It has automatic memory management (placed there because poor C++ programmers would forever forget to give heap memory back to the OS).  It was never a problem for the experienced C++ programmer though.  C++ is a tougher language to learn and use. Nevertheless, comparing C++ to C# is like comparing a Corvette to a Ice Cream truck-- the latter has some bells and whistles which attract young programmers-- treats...but no speed.

My brother programmed in C++ for years.  He now programs under Silverlight using C#.  He laughs about the drastic loss of speed.

I used C# for a couple of years, it is more than just bells and whistles.   Here is a nice comparison:

http://www.thinkingparallel.com/2007/03/06/c-vs-c-a-checklist-from-a-c-programmers-point-of-view/

C# evolved due to problems with C++  as a language.  Yes C++ is faster when running some simple tests but most performance issues stem from poor SQL and system design issues - which C++ does not help with enough to make a difference.

Good C++ programmers are good programmers - I expect they would be even more productive in C# - such a small learning curve for them.  And as Graham indicated with new PCs the performance difference is negligible.

Having said that at the end of the day the best technology is often the one you are most familiar with.

Greg

As my brother related to me, if you want application speed and flexibility, program in C++; if you want ease of programming but a distinctly slower application (on a fast machine), program in c#.  He programs in both and yes, he loves the ease of programming in c# but he frets that Microsoft has created such an easy environment with c#, that programmers will never really learn the art of programming....that they can throw together apps without really understanding what Greg alludes to-- good design.

mchasemd:

As my brother related to me, if you want application speed and flexibility, program in C++; if you want ease of programming but a distinctly slower application (on a fast machine), program in c#.  He programs in both and yes, he loves the ease of programming in c# but he frets that Microsoft has created such an easy environment with c#, that programmers will never really learn the art of programming....that they can throw together apps without really understanding what Greg alludes to-- good design.

He is right, thats exactly what happened with VB.

I know, I used to be a bad VB programmer until I studied comp sci.  Now I am just a bad C++ programmer :-)

Well, I have to disagree ... languages like VB lower the bar so that more users can program, but good programmers will know how to program no matter what modern language they use.

BTW, neuroscientists consider speech a form of programming because you create/modify data structures in the listener's brain - the human brain being the most complex computational structure in the known universe.

I'm sorry, but in my brain, there is only one camp that qualifies as an Internet model (your second camp is only for those who don't have the resources, or will, to change their approach and want to keep their custom client without any compromise - and a third camp is when companies use Citrix and completely "cheat" and call themselves Internet-enabled). A model that ONLY uses a browser as a client and nothing else is a true native Internet application (IMHO of course).

I wouldn't think a thick client application would ever scale to allow hundreds or thousands of concurrent accesses to a database (port 1433????), but that's a gut feeling only with nothing to back it up (except your reported experiences). Maybe you should think about other thicker clients like Flash or Silverlight???

If you have the will, and the DHTML, Javascript, and XMLHTTP skills, I believe most everything you have in your GUI can be replicated in an HTML-based Internet application. Many "heavy-duty" applications have already done this successfully (e.g. GMail, Salesforce.com, eNATAL, etc.), but I'm not quite so sure how faxing/scanning can be done from a dumb-client like a browser without some client-based helper app.

My two cents.

Don Miller:

A model that ONLY uses a browser as a client and nothing else is a true native Internet application (IMHO of course).

The internet does not depend upon HTML so I think your reasoning is flawed.

Don Miller:

I wouldn't think a thick client application would ever scale to allow hundreds or thousands of concurrent accesses to a database (port 1433????), but that's a gut feeling only with nothing to back it up (except your reported experiences). Maybe you should think about other thicker clients like Flash or Silverlight???

With middle layers you can do load balancing shifting to different ports and servers .. which of course is the benefit of a n-tier architecture.

Don Miller:

Many "heavy-duty" applications have already done this successfully (e.g. GMail, Salesforce.com, eNATAL, etc.),

Gmail is a pretty feature reduced application still .. don't have any experience with the others.

gchiu:

The internet does not depend upon HTML so I think your reasoning is flawed.

Well, if you want to get technical, you're right, the Internet is only a protocol (TCP/IP) and HTTP is only one of many applications. But if you want to be pragmatic, I'm guessing 99.9% of the population, including doctors, views internet content via HTTP with HTML. That's what they are used to, and that's what they expect when they use a computer based on their experience using eBay, Amazon, etc.

gchiu:

With middle layers you can do load balancing shifting to different ports and servers .. which of course is the benefit of a n-tier architecture.

I stand to be corrected, but it sure sounds like Medtuity is a pure client-server application where the fat client directly accesses the local database and not n-tier (which does scale as you suggest). Besides, fat-client applications are a pain to maintain and distribute.

gchiu:

Gmail is a pretty feature reduced application still

All in the eye of the beholder. I think a browser-based application is ideal for the general population as slick, power-user functionality only used by the few is eliminated (or not even possible) and the developer is forced to focus on the easy-to-use basics for the masses. It's the least common denominator but it works. Most doctors are not power-users (in contrast to those who frequent this forum).

I have to respectfully disagree.

A browser based app, to do the synchronous sort of activity of an EMR, is just about impossible to program when you ask it to perform what Medtuity does.

Even Microsoft is recognizing the problem. It released Silverlight.  What is it?  Essentially a rich client that can be downloaded and run within a browser to provide a richer experience.  Between now and the Olympics, there will be many millions of Silverlight downloads.  It is needed because of the deficiencies of the browser programming intereface. By Silverlight is totally asynchronous (not the best model for an EMR).

The download for Medtuity is smaller than the download for Silverlight yet who will complain when they must download Silverlight to see any video of the Olympics?  Not many.  It will take 1-2 minutes and it's a one-time download.

The one common factor when strolling through a Medtuity installation is that Medtuity is running on each client machine.  It runs all day, everyday. Why give up real estate to a browser and be artificially constrained by the asynchronous environment of a browser when a richer, faster, more logical interface is available.....unless one likes to click on submit buttons.

The common complaint that we hear from customers migrating from an ASP model to Medtuity is the speed of the ASP model is poor and there is little integration.

Medtuity is particularly well suite to a multi-tier environment--- everything comes out of a database.

A well-designed EMR must do many things in the background, particularly when you have multiple users documenting on the same patient at the same time, when you have granular data (thus, able to do simple things like calculate the BMI in the background once ht and wt are filled in, and far more sophisticated things like Health Maintenance Guidelines and dispatch agents to do big jobs (like print a letter, write a script, fill in a form, etc).  These all go away when you go to the browser-based application.

As for the ability the ability to duplicate in HTML and a browser anything that might be written in a fat client, only if you have enough money, enough server power, enough programmers,  users willing to have a really slow client with lots of clicks, and lots of years to develop it.

If Dr. Miller's statement is true (Most doctors are not power-users), then the average EMR demo should take less than 5 minutes-- type a pt's name, click on pt, and start typing in the history and physical,  Reality though dicatates the opposite. Physicians want to be power users of a tool that works.  Like any craftsman, a physician is willing to put in the time to learn to use a tool that will allow efficiencies for ever after.  Phsycians want mundane details to be automated.  If they turn to a computer to assist them, they don't want to simply write a script. No, they want to document an encounter, review labs, order labs, write scripts, review health maintenance, write a letter, review a consultant's note, fill in a form, review longitudinal info (HgbA1cs for example), eliminate tedium, and more.

The Internet model with a rich client is the direction we will continue to pursue because it is the right direction.  If a simple browser-based EMR is the model for the masses of physciains, then why hasn't it happened?  Because as soon as you give a physician a reason to turn to a computer, then that physician wants ALL THE TOOLS on the computer, not some small subset. That takes a rich client.

 So is your rich client alpha testing slower or faster than using Citirx as your clients were already doing?  I would be surpirsed if it was slower than Citrix.  If massive multiplayer internet games like World of Warcraft and Everquest and online first person shooters can pass data back and forth at speeds that allow real time combat in internet games then you would think an EMR with a rich client could pass data as speeds that are as good or better.  Maybe you should talk with the programmers at Blizzard or Sony Online Entertainment to see how they do it.