New site, new organization

I have not had much time to update this blog recently.  Work has been busy.  I have also been working on a new way of organizing my blogging entries.

One of the things I am doing is migrating off wordpress.com to a hosted wordpress.org instance.  There might be hitches and problems as I get going with this.  As of today, you can see the old postings on health IT or healthcare IT under http://svfruitstand.com/healthit. I hope to add more posts to it soon.

I also have not abandoned commenting on what’s new in IT and trends in social media and software.  Those blogs have been migrated over to http://svfruitstand.com/swblog.

Database as a Service – from Force.com to Amazon RDS and SQL Azure

These days, those who are building internet applications have many choices for database.  Traditionally (i.e. up to the last few years), you have the usual commercial and open source solutions such as Oracle, Microsoft SQL Server, MySQL, PostgresSQL to store user and application data.  Usually, these databases run in the company’s own data centers or a co-lo facility managed by AT&T, Verizon or the like.  However, offerings from Force.com (from Salesforce.com), Amazon Web Services and Windows Azure are changing this landscape.  In fact, in some cases, they start to converge despite their differences.

I started thinking about database as a service not because I was building one or looking for a DBaaS solution.  In fact, I was building a full stack internet application based on open source technology.  However, the offering from Force.com was rather intriguing as they claim to offer faster development time, easy to use language and secured infrastructure as this InformationWeek article indicates.

However, when you dig a little deeper, you will find that if you do not want your UI to look like the Salesforce.com form based interface and instead you want a rich interactive user experience, Force.com offers limited options.  The reason is because Force.com only offers a database driven form application UI or a heavy client written in Adobe AIR and Flex.  The former is reminiscent of web application from the late 1990s and the latter requires significant processing power on the client desktop.

Now you may say Force.com supports Java, Ruby and every other language under the sun.  That is indeed true though it is also where Force.com veers from a Platform as a Service provider into a Database as a Service provider.   If you want to use Java, Ruby, PHP or another language to build your application logic and client interface, you essentially have to host that code yourself.  You would be using the Force.com infrastructure for database and maybe stored procedures.  Sure you can host your application code at AWS or even Azure cloud but does it really make sense to have multiple vendors hosting different tiers of your technology stack?  It is tough enough to satisfy your SLA for applications that you run fully in-house.

In short, if you see a need to contract with multiple hosting vendors for the database, application and client technologies, you may well start looking at Force.com, Amazon RDS and SQL Azure as similar solutions.  Each has its strengths and drawbacks.  Here is an article comparing RDS and SQL Azure that you can start with.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Why do doctors hate EMRs?

While trolling the web, I found this great article written by a physician about why doctors hate EMRs.  Electronic Medical Records, or its cousin EHR and even PHR, are supposed to help physicians provide better quality care to patients, ideally at lower costs to the society.  However, as you can see in this article, http://www.dillingerkovach.com/accusourcecareers/?p=10501, the adoption rate is abysmal.

As a software guy, and having studied cases of why Business Intelligence and other other enterprise software systems suffered poor adoption among their intended users, I can almost predict the usual barriers to adoption.  What makes the EMR case more interesting is that in small clinics, the physicians tend to be the buyers of the software too.  If they are unhappy with the product, they would simply not buy an EMR or abandon it after paying for it.   Those who are in larger enterprises (aka large clinics or hospitals), the unhappy docs will find anyway they can to get out of using it.

Why, you may ask, are these doctors so recalcitrant about technology?  The author said technology was not the problem.  According to him, docs use much more sophisticated technology everyday – MRI, cyro-probes, laser, etc.  Instead, it is because “It slows them down!”.   It isn’t the first time I hear this from a doc.  If you are in the business, I am sure you know this tune too.

Most EMRs, similar to ERP and other enterprise software, suffer from the same shortcomings.  Told poignantly by the author in this excerpt, the consumers suffer from a sign at a dry-cleaner’s shop reads: Low Prices, High Quality, Fast Service: Pick One. I am optimistic that we can get to a place where EMRs not only contribute to better care, lower costs and also user satisfaction (physicians’ and patients’).  It wouldn’t be trivial.  Some vendors won’t make it through.  If you have answers to the questions that the author raised in the article, I would love to see your comments.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine