2nd Annual AdvancedMD User's Conference - Day 1

We're just about to wrap up the first full day of our annual User's Conference, and it's been great. I'm pretty sure we have the smartest users in the world. I think I get a little bit smarter just from being around them.

From my perspective, one of the most valuable things about these user's conferences is the ability to separate the propaganda that we hear from the media and some of our vendors and partners from the real problems that real people face on a daily basis--the problems that AdvancedMD is designed to solve.

Sheridan heard a great story last night that illustrates one of the main advantages of the SaaS model. (I'll be vague in the details to protect the identities of the parties involved. With my poor memory, I'm sure I'll introduce some inaccuracies, as well.)

Basically, the office manager of a pretty good-sized practice found out that one of her adult children living in a different state had a serious disease--serious enough that she felt that she should move nearby to help out. In spite of that interstate move, she is continuing to function effectively as the office manager of that practice. That's made possible by the "anytime, anywhere" nature of AdvancedMD. All she needs is a Windows computer with Internet Explorer.

This is an example of technology making a real, positive impact on a family's lives, not to mention the success of the medical practice.

Our User's Conferences also give some of our talented employees a chance to shine, and for fellow employees to see them in action.

I attended a session this morning that was put on by a couple of our Support techs, about reading EDI reports. They did an absolutely phenomenal job. Without attending that session, I wouldn't have been aware of the wealth of knowledge that they carry. I plan to tap them as technical resources in the future.

I'm looking forward to learning a lot more from our users and other AdvancedMD employees during the next day and a half of the conference.

Cloud computing: Evolution of the species?

So I'm registering for the Gartner Web Innovation Summit, and I'm seeing two major, broad themes: Web 2.0 (which I understand) and Cloud Computing (which I don't).

From the look of things, everybody and their dog is "computing in the cloud"...except me. How did I get so far behind?

As I've studied up on the technology, I've been reminded of this classic (but obviously modified) drawing:




(I'm probably infringing someone's copyright, but I can't find out who the owner is...let me know if you find out.)

Here's how I see the (possible) evolution of application hosting (assuming that you manage your own servers):

1. Self-hosting
   Here, we get some Internet connectivity within our office space, grab some IP addresses, build some web servers, and announce ourselves to the world. When it's time to deploy or update the application, we sit on a stool in front of a keyboard and monitor and use an A/B switch to choose which server we want to work on.
2. Co-location (Phase 1)
   In this stage, we move our servers to a hosted environment, where the data center provides power and Internet connectivity. Aside from that, it all works the same: Every time a server needs to be refreshed, or the application needs to be deployed, someone drives to the data center, sits on a stool in front of a keyboard and monitor, etc.
3. Co-location (RDP)
   Now we're getting high tech: Instead of running to the data center all the time, we use RDP (if we're running Windows, or some equivalent technology if we're running something else) to hit our servers remotely. But we still own all of the equipment, and we have to get it in there somehow (perhaps using a 3rd-party IT resource).
4. Cloud computing
   Here's where it gets kind of...um...cloudy for me. Those nuts at Google, Amazon, and Microsoft (among others) are using virtualization on steroids to offer...well, heck, I don't know what! But instead of selling servers or hosting space, they're offering these funky units of computing time like "EC2 Compute Units". Wha...?

Is this where application hosting is going? The idea is pretty amazing: These huge players build megaservers that can host dozens or hundreds of virtual servers, and then they provision them out like web sites or SQL Server instances.

If your business suddenly doubles, you don't hop on a plane to install a bunch of blades in your data center. Instead, you fill out a form online asking for a bunch of EC2 Compute Units, then deploy your app. If traffic falls, you just decommission a few servers, and your invoice reflects the drop in usage.

Anyway, it's cool stuff. To be honest, I don't see AdvancedMD moving into this space any time soon, but it may be a fun spectator sport.

Who "owns" patient data?

One of the first hurdles that we had to clear as a SaaS company was the objection of providers who were accustomed to keeping their data within their offices. We called it "storing data in the broom closet", since in many offices the actual physical location of their server was no more secure than a utility closet. While the data was certainly NOT secure, it was accessible, or at least perceived as such.



In fact, there are many problems with that arrangement, among them:

• Dismal disaster recovery (DR) options. I once heard that 60% of magnetic tape backups are unusable, although that number may be high. More conservative estimates vary between 10% and 50%. Within medical offices, where there generally is no dedicated IT staff, I would lean toward the higher estimates.


• Lack of security. It would be easy for a disgruntled employee to unplug a few cables and carry the whole server out the door, or just bring in a laptop and wirelessly copy data from the server.


• Risk of physical damage. Hundreds of medical offices were devastated by Hurricane Katrina, for example, and permanently lost huge amounts of irreplaceable patient information.

So, over time, our customers have accepted the fact that they are better off letting AdvancedMD keep their data for them, as long as we provide methods (standard data exports, ODBC access, etc.) for them to get access to it.

Now doctors are being faced with more dispersal of patient information, in the form of electronic prescribing systems, RHIOs, HIEs, PHRs, etc. I'm not a doctor (obviously), but I have to believe that this new sharing of data is a little disconcerting for some.

In the Summer 2008 issue of JHIM, Richard D. Lang, EdD, writes in "Blurring the Lines: Who Owns the Medical Data Home?" (HIMSS membership required) about the very objection that we used to face, but applied in a slightly different way.

Dr. Lang says:

Healthcare IT is evolving from a physician-centric model to
a collection of disparate patient-centric applications where
all constituents contribute to a mélange of databases that
serve people and processes in many different ways. By electronically
diffusing the traditional patient record, this new model blurs
the long-established medical data home.

As a true SaaS company, AdvancedMD assumes ownership of the provider's physical data, even though conceptually the data remains the property of the provider. Similarly, if a practice contracts with a billing service, the lines of ownership become further blurred, as the billing service assumes ownership of whatever data it needs to effectively bill for the practice's services. In that scenario, the billing service contracts with AdvancedMD, not the providers, so we are an additional level removed from the actual healthcare practitioner.

For eight years, we've proven that this data model can work, and, in fact, it works extremely well. It almost seems natural that, over time, patient information will continue to be further dispersed among interested parties that play a role in the patient's care.

As a patient, I kind of like the idea of spreading my information around, as long as it's secure. The next time I need to see a PCP and can't even remember who I saw last, wouldn't it be great if my new doctor could access my medical history without me having to remember it?

I have to believe that AdvancedMD's customers are better prepared for this "brave new world" than those who are still stuck in their broom closets.

Events and Travel Plans for 2008 - Redux

Due to scheduling conflicts, I've had to make some changes to my travel plans for the year. Here's what I'm planning now:

HIMSS MS-HUG Tech Forum Redmond, WA, Aug. 26-27
I always learn something from these events in Redmond, beyond Microsoft's sales pitches. Most of the value comes from hearing about the challenges that other HIT people are facing, and how they are dealing with them.

Gartner Web Innovation Summit Los Angeles, CA, Sept. 15-17
I missed the Gartner Enterprise Architecture Summit in June, but this event seems more relevant to our business, anyway.

Microsoft Business Intelligence Conference Seattle, WA, Oct. 6-8
I'm really looking forward to this one. I don't know how they're going to make me more intelligent, but it's worth a shot!

Seriously, we've built our reporting strategy around Reporting Services, so I'd like to take a few days to find out what's going on in that area.

Health 2.0 Conference San Francisco, CA, Oct. 21-23
As the name would suggest, Health 2.0 (like "Web 2.0") is mostly about consumer-focused applications, but I'm interested in exploring how Web 2.0 technologies like mashups can be used within our offerings.

Construx Software Executive Summit Seattle, WA, Oct. 27-29
This conference comes highly-recommended by a business acquaintance who until recently worked for a local EMR company.

Alternate: Microsoft PDC Los Angeles, CA, Oct. 27-30
I really hate to miss this one, because Microsoft has a lot going on (HealthVault, Live Mesh, SQL 2008, etc.), and there's no better place to catch up, IMO. But it conflicts with the Construx summit.

Microsoft's "SaaS Maturity Level"

Microsoft has an interesting way of looking at SaaS-iness. They have a four-level "SaaS maturity model" that looks at an application's scalability, configurability, and "multi-tenant-efficiency" to determine what SaaS level it fits into.

This model has been around for a couple of years, but I was introduced to it in a "CTO P2P Forum" put on by the Utah Technology Council and featuring Nate Bowler, CTO of @Task.

It was obvious from Nate's presentation that they're doing some really great things there, but it was also clear that they haven't reached the 4th level of SaaS maturity, according to Microsoft's model. But that isn't necessarily a bad thing, as Microsoft clearly states.

But what's really interesting to me about Microsoft's SaaS maturity model is that it only seems to address the architectural aspects of SaaS...which, while fundamental to an overall SaaS philosophy, don't in and of themselves make a SaaS offering.

We learned years ago (before the "SaaS" acronym was coined) that there is a lot more to SaaS than software. If your Sales team isn't SaaS-oriented, or your client support teams aren't SaaS-oriented, then you're not going to have much success...because your salespeople won't sell, and your customers won't get adequate support.

For example, how do you price SaaS? If your nearest client-server competitor is selling their system for $50,000 with a 20% annual maintenance contract, do you sell your system for $49,000 with a 15% annual maintenance contract? Of course not. If you're truly SaaS, then you may (and probably will) charge an upfront fee for implementation and training, but your pricing should be a monthly (or annual) subscription model, of perhaps $1,999/month.

So, that brings in steady recurring revenue month after month as long as you can keep the customer. But then how do you pay the salesperson? I don't know the answer, but certainly it will be different from your competitor's compensation plan.

Anyway, Nate's presentation was excellent, but it was clear that their un-SaaSiness extended beyond their architecture into their deployment model and other business decisions. Again, that's not a problem, as it seems to work well for them.

I came to the conclusion that AdvancedMD is just about as SaaSy as you can get. That's pretty cool, considering that our archicture and business model predate the industry's fascination with SaaS by several years.

A face for radio...and a voice for blogging

You know, you really put yourself out there when you decide to blog. It scared me for a while. Still scares me, in fact. You never know when you're going to write something that sounds brilliant as you're writing it, but actually makes you look like an idiot.

Well, it could be worse. Actually, it is worse. In the absence of our uncommonly articulate VP of Operations, Ken Meyers, I was asked to participate in a Podcast put together by our PR company. The intention was to trumpet our recent AdvancedMD Version 5.6 release. The results speak for themselves.

Don't worry, I'm going to keep my day job.

Development checklists: It's all in the details

Healthcare is extremely complicated, and, consequently, the applications that we've built over the past 8 years are extremely complicated. There are so many buttons and dials and knobs that it's really easy to forget important, but arguably obscure, steps as we enhance and maintain the software.

It doesn't take too long to recognize the need to consolidate those obscure requirements into a single document (or, in our case, three separate documents), so that they can easily be reviewed during the development lifecycle.

We decided to create those documents as "checklists" that a developer can pass through at various points to ensure that, for example, user-level security and auditing requirements have been taken into account. Each checklist is limited to a single page, and applies to one of the following stages of development:

Analysis and Design: Since we're using SCRUM, most of the analysis and design for new features takes place during and shortly after a sprint planning meeting. It is generally at this point that the team is putting together screenshots and/or prototypes and thinking about what the database schema might look like (assuming that they are doing UI-first development).

Coding: These items help ensure that the developer is thinking about indexes and unique constraints on new database tables, commenting code, "leaving a trail of goodness", etc.

Finalization: At this point, the team is integration testing the feature, dotting the i's and crossing the t's, and communicating changes to IT and other teams.

Checklists can help developers to remember the details and avoid obscure bugs...as long as they remember to look at the checklists. We encourage our developers to keep the checklists mounted prominently in their workspaces so that they can be reminded of them, at least during code reviews and pair programming.

Why we're a Microsoft shop...and it's okay if you're not

[I've had this post sitting in my Drafts list for a while now, because I'm completely comfortable with the tone...but I'll let the reader be the judge.]

So, I was reading a really informative post on The Health Care Blog about how Kaiser Permanente is working with Microsoft to allow their employees (and, presumably at some later point, all 2 million + Kaiser members) to copy their health records into HealthVault. Seems like a pretty interesting venture, right?

Well, not everyone is happy about it. In particular, the fourth comment to the post lists all of the reasons why no one in their right mind would EVER embark on a project that doesn't feature Java/Open Source exclusively. The most compelling arguments: Microsoft isn't Open Source and Java isn't C#. That's what passes for logic in some circles.

I really didn't feel like such biased, ABM ("Anything But Microsoft") remarks should go unanswered so I answered them in the most respectful but pointed way that I could. Feel free to read my response if you wish.

My point is this: AdvancedMD was the first financially viable browser-based Medical Practice Management System on the market, and we use Microsoft tools and technologies almost exclusively in our development. So I know that it works.

Why do we use Microsoft technology? Well, there are several reasons:

1. The principal architects of the system (Sheridan Richey and myself) had more experience using Windows, Visual Basic, Microsoft C++, and Internet Explorer.



2. When we originally architected the system over 8 years ago, Open Source was still an adolescent, rebelling against authority and trying to figure out who it was.



3. We are Microsoft Gold Certified Partners. What that means is that, for a few hundred bucks and a few hours of effort each year, we get hundreds of thousands of dollars worth of development tools, OS and Office licenses, etc. In a small startup (which we were until just recently), that's a financial windfall.



4. Over the years, we've learned how to squeeze outstanding performance from MS SQL Server and COM+. And we can still squeeze out a lot more, dedicating the right resources to the effort.



5. Visual Studio is a one-stop solution for all of our code, from front to back, and its IDE paradigm extends to SQL Server tools.



6. Microsoft has been active in the healthcare community for a long time, in partnership with HIMSS (via MS-HUG).

So, that's why we use Microsoft technology, and I couldn't be happier. The proof is in the proverbial pudding.

What? You run on Linux? Using MySQL, Python and a collection of open source libraries?

Great...more power to you! Unless, of course the company you're working for is perpetually losing money, in which case...I'm sure you can find a job somewhere else.

Regarding the indisputable statement that "C# is not Java", I would (and did, in my response) make the equally useful comment that "Chocolate isn't butterscotch, and Ford isn't GMC".

Everyone has their preferences, and I'm certain that there are examples of successes that you can hitch your wagon to, no matter which platform and tools you choose.

But here's the important thing: Thanks to emerging (and largely well-established) standards, we can all get along now!

Back in the 90's, Don Box used to say that "COM is love". Well...maybe it was within its own world, but COM certainly wasn't particularly fond of CORBA, or vice versa.

It would be more correct to say that "SOAP is love", or "Web services are love". The comment I mentioned earlier claims that "developers must purchase Microsoft Visual Studio.NET to code HealthVault applications." Of course, that's absurd, because HealthVault is exposed as a Web service, so, by definition (assuming that it was implemented correctly), it can be accessed by any code that can consume a Web service.

(It is true that, so far, the only comprehensive SDK and DDK that Microsoft has provided for HealthVault is written in C#, but they do provide useful sample code for Java and Ruby, and they are working on providing more non-MS platform support.)

By the way, we interact on a daily basis with dozens of partners in many different lines of business and who use all kinds of different platforms and languages, and we get along swimmingly.

I guess that's just a really long way of saying, "I'm okay, you're okay. [Insert smiley here.]"