mchasemd:I have to respectfully disagree.
This will be fun as I agree with Matt on 99% of what he writes.
mchasemd:Even Microsoft is recognizing the problem. It released Silverlight.
Don't even get me started on why MS introduces products and their ulterior motives (their response to Flash???). They want developers and the public tied up to their OSs and languages to the point none of their developers even understand the underlying core architectures (e.g. Javascript, HTML, DHTML, etc.) so they will be totally dependent on MS.
mchasemd: It will take 1-2 minutes and it's a one-time download.
How many times a year do you update the client app? What happens to computers that were turned off? Do customers ever have different versions of client apps running in their office? With an ASP model, the change is made on the server and everyone immediately has the latest software.
mchasemd:The common complaint that we hear from customers migrating from an ASP model to Medtuity is the speed of the ASP model is poor
No doubt code running on a client connecting to a local database is faster than an ASP model. But "poor" is relative. Our ASP product and server delivers sub-second response times (with DSL or faster). The difference between 10ms and 300ms is imperceptible.
mchasemd:Medtuity is particularly well suite to a multi-tier environment--- everything comes out of a database
Is Medtuity client-server or n-tier? If you changed databases from MS SQL Server to say Oracle, would you have to change ANY code in the client app? If so, then you are client-server and not multi-tier.
mchasemd: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
Well, it takes a different mindset to do the same things you describe. Multiple users accessing the same patient is really trivial in an asynchronous environment compared to all the table locks and such with a client-server app. Dozens of folks can work on the same patient at the same time because all the data from the patient is not retrieved and frozen for use by others when different sections of a chart are updated. In your example of BMI calculation, once ht and wt are entered in the database, database triggers can generate the BMI and store it, or can dynamically calculate and display it with each request.
mchasemd:Physicians want to be power users of a tool that works
Power-users drag-and-drop, right-click all the time, constantly adjust preferences, tweak configurations, etc. This type of early-adopter power-user may be self-selected to Medtuity but most physicians are in the 80% holding the early and late majority (i.e. Crossing the Chasm). Pointing and clicking on a blue underlined link is about all they can handle and is what they expect now in applications (again, the EMRUpdate crowd is not typical).
mchasemd:If a simple browser-based EMR is the model for the masses of physciains, then why hasn't it happened?
I believe it is happening (it certainly has NOT happened with client-server applications). eClinicalWorks, e-MDs, Cerner, Epic, etc. are all moving toward that (and away from fat clients) or have already done so. That's because customers are asking for (or demanding) it.
Donald W. Miller, Jr., MD, FACOGeNATAL, LLCwww.eNATAL.com
Definitely slower than Citrix.
Combat games can pass data quickly because they are not passing the graphics but rather actions and coordinates.
It is not ready for primetime.
When given a fast programming language, a fast local network, and fast SQL Server, that speed can be abused without degredation of the user experience. Who cares whether it takes 10msec or 40 msec? When you intersperse the Internet, there is a much more significant degredation of speed and those little things that might have caused an unnoticeable slowing, now become noticeable.
So we chip away at the calls to SQL Server and be as parsimonious as we can in our calls. We're putting in metrics to determine a hierarchy of most time consuming to least.
By the way, when Al Gore invented the Internet, he hadn't yet invented the USB keychain to carry an executable capable of connecting through the Internet.
So why do you need to pass graphics? Just pass the text data between the server and the client whether it be local or over the internet. The amount of data being passed in a game where over 100 hundred people may be on a raid attacking numerous mobs has to be a lot. Every player is moving and attacking plus they are casting spells and using other abilities all in real time. They are also controlling any pets they have and giving the pets orders on how to attack. Sure the video graphics are local but what is being done by every player on the raid has to be sent to the client as you have to adjust your attacks based on who may be killed, etc. Plus you are receiving orders from your raid leaders either in text or using voice chat programs. How is the amount of data being passed in an EMR which is almost all text based more than the amount of data being passed in these games? I guess I don't understand the difference. You make calls to the game's database when you are doing tradeskills and the response it instant without lag. How are EMR databases different?
Bryan D. Uslick, MD CFCDD (Gastroenterologist) eMDs user since 3/3/2006. Currently using version 6.1 (Prior Praxis user.)
Provation MD endoscopy report writer
Don,
Thank you for your reply.
Regarding multiple tiering, client-server is already two-tiered (the client, the server). We add another tier (and semantics come into play) to this..a middleware piece that intercepts the calls to and from the SQL Server component, checks for authentication, does any required compression/decompression/ encryption/unencryption. The SQL Server can be on the same tier or another. Multiple tiering is not problem.
Regarding connecting to another database, such as Oracle, with our current "database connection" layer in Medtuity, we simply change providers. That "database connection" layer allows us to connect to diverse databases currently. We don't connect to a Medtuity database on Oracle or MySQL because we want one provider- MS SQL. It's simply easier to respond to customers when we know how to use the database management tools. Technically, it's not difficult. You would simply in the startup settings put in the Oracle provider, not the OLEDB or SQLNCLI provider. Medtuity would take care of the rest.
Regarding power users and Medtuity, it's all in the definition. Most Medtuity users simply log in and start documenting. They know how to click on the tracking board to bring up their pt, they enter data usually by pointing and clicking/sometimes by typing, and they go on to the next pt. They don't write scripts, compose letters, review labs or a myriad of other tasks. They do what medical assistants do. Another level of user is, for example, an radiology or other tech. They click on the pt, click on the imaging order, enter sometihng ("Pt denies pregnancy. Moved per wheelchair.") if needed, and show the order was completed. The next level up is the RN. They click on the pt, document, and fulfil orders (administering a parenteral med, for example). The highest level is the doc who does much more, but most of our users, even at the physician level, have little interest in fiddling.
Using the example of a user with >120 employees, there is only one guy capable of entering the administrator's role and changing all sorts of options. Where users are given the ability to change options, they are usually allowed only by virtue of the administrator turning on and off that ability, on a case-by-case basis. Most of our users truly just want to document and not fiddle. Some are given the priviledge to change models.
Regarding new versions and the Internet model, this would not be like an ASP where all users must use the same version. Instead, in our case the executable is held in the database and the user is updated on startup with the new version, if there is a new version. Thus, a practice can decide when it wants to upgrade. Having one version for all customers is a nightmare, quite frankly. Can you imagine having to have to train thousands of users for a new version, all scheduled to go to the new version on the same day (because there is no other choice). Our model is better- upgrade when you want (and by the way, skip many versions when upgrading).
Regarding the asynchronous model, there is no doubt in my mind that a synchronous model is superior for an EMR. I'm not saying it cannot be done asynchronously, but it is a nightmare requiring more programmers, more money, more time, more testing. We handle many users documenting on the same patient simultaneously without a hitch. There are no locks on the encounter to prevent another from documenting on the same pt at the same time. You don't need a browser's asynchronous model to achieve that.
Adding to the database connection layer of Medtuity to accommodate an Internet model was not a simple task-- It meant writing sockets client and server code, all the threading, event handling on the new threading code, etc, etc, but its been a generally good experience. Now to find more speed.....
mchasemd: Adding to the database connection layer of Medtuity to accommodate an Internet model was not a simple task-- It meant writing sockets client and server code, all the threading, event handling on the new threading code, etc, etc, but its been a generally good experience. Now to find more speed.....
It is a very interesting challenge. I can run PatientOS client on a local laptop, then the middleware (JBoss using HTTP+SLL and database securely over the internet.
Initially the performance was poor due to the amount of data passed between the client and the server.
I spent a day or two implementing caching on the client, which is a good thing in any mode since it lessens the burden on the application servers and the database.
I got ok performance but I cannot match the performance of Citrix or the running on a LAN due to one word
Latency
Over the internet each call to the server goes from 5 ms overhead to 200 ms (something like that). 10 calls from the client is not noticed on a LAN but over the internet... shudder... Of course this is in part due to having a regular high speed connection to the internet - not a data center quality connection - no doubt that would help - but what doctors office has that? Hospitals yes...
Citrix and NX (for unix client) are amazing technologies that make ASP possible for rich/fat clients. Not sure how you are going to get your speed without a ton of engineering (asynch calls, queue, packed and compressed - work not worth the distraction in my view).
Greg
http://www.patientos.org
Greg,
On startup, let's say that there are 100 SQL calls made to the database. If these can all packaged up into one message and the results returned as one message (with lots of subsets), then the latency of (400ms X 100) drops to 400ms.
That is why we need metrics-- what is the latency, what is the trasmission time, etc?
Don Miller: 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.
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.
There are millions of people who use "native" internet applications which do not use http .... including file sharing software such as torrent clients, and multiplayer games. Email of course does not use http, but pop, or imap protocols. In fact, I suspect that the majority of traffic is not http based upon what the ISPs say.
Graham http://www.synapsedirect.com/ Synapse - the EMR for smart users
mchasemd: Regarding the asynchronous model, there is no doubt in my mind that a synchronous model is superior for an EMR. I'm not saying it cannot be done asynchronously, but it is a nightmare requiring more programmers, more money, more time, more testing. We handle many users documenting on the same patient simultaneously without a hitch. There are no locks on the encounter to prevent another from documenting on the same pt at the same time. You don't need a browser's asynchronous model to achieve that.
Synapse EMR is a fat rich internet application that does not use http, and is completely asynchronous.
Web browsers are moving from synchronous http to asynchronous because it provides a better user experience.
If you feel that a synchronous model is superior for an EMR, you'd better do some metrics before going down the wrong path!
Graham,
The fact is, Medtuity uses both asynchronous and synchronous communication and there are benefits to both.
For those who don't call themselves propellar heads, sending a request asynchronously implies that you don't expect an answer, and if an answer comes, you can live with it coming unexpectedly. Synchronous is like a cell phone conversation-- you say something into the phone and the party at the other end responds. You expect a response and if one does not come, you believe your connection has died. Asynchronous is like yelling into the night. Maybe a neighbor will yell back "Shut up".
Again, we use both.
The problem with asynchronous is if you hover over the top placed med in your pt's med list and you expect to see a popup of how many times/dates/quantity that you have prescrived in the past, but the popup doesn't appear, you move on. But you move to the second med and then your popup appears....but the popup was really about the first med, not the second. Confused? Don't be. With asynchronous the message can appear when it's ready.
With synchronous. the software will instead expect a reply (a prompt one at that) and if it doesn't get one, it will provide a message (Server slow, server down, cannot respond now....something). So if you're expecting to see the pt's meds list, or better yet, allergies, either you see them or you get a message.
For Graham, Medtuity uses multiple threads assigned to different tasks and as you know, these are asynchronous, but some things should not be asynchronous and given the choice, I would rather make it than the browser.
mchasemd:The problem with asynchronous is if you hover over the top placed med in your pt's med list and you expect to see a popup of how many times/dates/quantity that you have prescrived in the past, but the popup doesn't appear, you move on. But you move to the second med and then your popup appears....but the popup was really about the first med, not the second. Confused? Don't be. With asynchronous the message can appear when it's ready.
I can't see how being asynchronous is any different in this respect .. it should be the same speed in both ways, but the asynch model allows you to do other things while you are waiting.
Your analogies are also incorrect to my mind .. async is not yelling into the night, and possibly getting an answer back. I always expect an answer back, and I have a callback that deals with it.
Perhaps you're confusing it with UDP where you do broadcast to the night and may or may not get a response.
I am with Bryan, WOW is much more sophistaceted a IT application then any EMR/EHR. It has literally 10's of thousands of users at any one time concurrently. As he points out it is banged hard all the time and works. On the flip side name a EMR/EHR company with 9.3 million users and over 1 billion dollar in continous revenue on a hosted application.
http://www.joystiq.com/2007/11/15/world-of-warcraft-hits-9-3-million-subscribers/
Bottom line, EMR/EHR products are much more on the Sales and Marketing and a lot less on the R&D. They don't compare to the investment and ROI of a game like WOW. ON the flip side number two has yet to get 1 Million Subscribers, and 100's of other geniuses cannot duplicate it.
That is because it is something special, Bryan.
Have a good evening ladies and gentleman.
My nephew is a C++ Internet game programmer. I'm sure he can provide some insight into the aspect of speed.
The last time I played a computer war game was in the mid 90's. We had a heck of a setup in our house, as a physician friend recently reminded me, with a LAN and bunch of PC's for the kids and their friends (and parents, at times). Trouble is, the kids always won.
My nephew, now a programmer, constructed a program back then and placed it on my PC. It allowed him to bring up an image of the "blue screen of death" on my computer. So during a game, he would just flick some software switch and the blue screen would appear, I would swear under my breath, reboot, and lose the game. Only later did he tell me it was simply a graphic.
Matt,
Your nephew is not working on World of Warcraft. It is not the norm, it has 1 Billion Dollars coming in annually in subscriptions at $15 per user per month and over 9 million, probably 10 million subscribers now.
This is not in the same league as EMR/EHR software, where even the largest vendors don't have the resources and expertise that is invested in WOW.
It is a unique product, but as Bryan has pointed out well, it shows that huge volumes of realtime data could be handled by Servers and work with a large audience. The EMR/EHR software is not so complicated that it cannot run fast over the web, but it would take a lot better development that is typical in many of the applications. WOW is a very sophisticated product.
The number of requirements for a hospital and the complexity of the domain dwarfs WOW - however many dwarves it has running around a battlefield.
WOW biggest technical achievement is performance with many users.
WOW does not have to worry about the sequence of actions, and it can afford to drop data for slow connections. You cant drop meds from the patient profile when the nursing is performing reconcilliation because they have a slow PC.
Cerner and other systems have 1000's of concurrent users - but each user is not limited to the WOW's (relatively) small number of discrete actions that they can take.
Perhaps a clinic is not on the same scale as a hospital, but the workflow and behind the scenes requirements are still considerable. Maybe if WOW developers had to plan for users transcribing their castle blueprints on paper it would help them get a feel for healthcare... :-)
I disagree. I do many more things per second playing WOW than I do on my EMR. My choices of things to do in WOW are much larger than my choices in eMDs. Sure the game server does not care if a single player goes linkdead but that single player could make or break a raid so the game server is not usually the thing that goes down, rather it is the players computer or ISP goes down. The game itself is very stable. In addition these games are often updated several times a week. Every time you log in your client gets patched. eMDs is lucky to release a major upgrade once a year. These games release major new expansions up to 3 times a year with smaller patches done all the time. In addition the data integrity of these games is amazing. They have never lost any of my data/items. EMR developers could learn a lot from these internet game companies.