The Human Computer

Recently I was asked to review an article about IBM and the Mayo Clinic's recent decision to release natural language processing or NLP code to the open source community and comment on how likely the open source development model and delivery mechanisms like Software as a Service (SaaS) or Service Oriented Architecture (SOA) will become the preferred models for delivering healthcare IT solutions. I've pasted my response below...

Alright, here are some observations but be prepared, it's a bit out there......

I think that it's kind of important to draw a distinction between the FSF/OSF development model and SasS/SOA etc... as delivery model. Linux was sort of special in that it really set a new visible standard for collaborative development in a community. That's not to say that it never occurred before. DARPA/ARPA and the military contractor/technical academic community were the real pioneers for this in many respects. Think of BSD UNIX vs AT&T System V for example. You basically have academia, big R and D shops in new markets (Bell Labs) and military contractors setting up collaborative environments with tons of freedom for brilliant people who want to use their creativity. Richie and Thompson invented UNIX almost in their spare time. Ritchie invented C because he couldn't write UNIX in B (true story) and C was the great grand daddy of a ton of 4th generation languages and definitely set the standard for compilers.

The point is that Linux wasn't the prototype model. It's just that over time the companies that fostered these communities got a grip on their intellectual capital and switched the focus to selling them. Once money is attached to an idea it's no longer psychologically possible to maintain an open flow of ideas and creativity around that idea. This is a system that rewards true brainstorming where no idea is a stupid idea and the person who helps his brother/sister find an answer is more valuable than the person who builds a silver bullet to feed an ego. This I think is a key concept, more on that below.

Linux and GNU revolutionized things by understanding that a large number of brilliant creative people care more about the free and open flow of creativity and ideas than making money. CPA finance best practices don't seem to mix easily with people who are wired to understand things and solve them because it's satisfying. It creates a kind of cultural dissonance and a myth that there is a choice (albeit a suckers choice) between having either the open flow of ideas/creativity OR the efficient and effective financial principles of selling in a market. There are more and more companies though who recognize this as a suckers choice and know that it's not an OR but an AND to be successful. Red Hat supports the open source community, fosters and respects it while making buck. IBM's transformation from big iron hardware vendor to services company was enabled by their willingness to embrace the FSF community, contribute generously and then fill a niche helping their business partners deploy these far cheaper and high quality solutions to a variety of business problems. I suspect their real target in considering a purchase of sun is MySQL (the fabled open source database that does 80% of what you need a database for REALLY REALLY fast) and Java. I can imagine them turning Java loose in the FSF community and watching it blossom into capabilities that make their consulting services that much more valuable.

We're moving from an industrial age and economy into a knowledge and information age. The winners are no longer going to be defined by who can protect and sell "things" or products. Instead it's going to be more effective to foster people's built in desire to be creative, productive and, well, human. I think this is an important concept and yes, more on that below.

SaaS and SOA can be thought of as architectures. What people generally call Web 2.0 are also. They're the next layer of abstraction in the evolution of computing. Just as punch cards evolved over time into 4th generation languages each evolution brings ease of use to computing and generally amplifies our ability to solve problems more naturally. I think it's easy to forget just how unnatural it is that we rely on a bunch of signals traveling through solid state logic gates to synthesize meaning on a CRT or LCD display truly is. The real work is done at the end of the day by the person who reads and interprets those images and uses the most powerful computer known (the human brain) to translate those abstractions into action. While SaaS, SOA and Web 2.0 types of technologies can ease the burden of that translation and make it easier for us to use technology to communicate they are still terribly crude compared to the richness of human interaction. There will be successors to SaaS and SOA. So I think the REAL benefit that they provide is in simplifying the common understanding and language of how we interact with computers. Music is a pure and natural human language in many respects. Emotion and meaning can be conveyed in a very real and raw state through composition and arrangement. SaaS and SOA help us get closer (even if we're still light years away) to that quality of communication by giving us standard mechanisms to arrange how we interact with each other through technology. I think this is the link between SaaS/SOA and the cost of technology. As technology evolves towards allowing us to spend more time on the message and less time on constructing it the flow of ideas becomes easier. This is a key concept.

If the keys are that creative collaboration is becoming more valuable than proprietary protection, fostering creative collaboration will be the key to being sustainable in the future and that the evolution of technology is moving towards enabling the communication required for collaboration then where in the heck is healthcare as an industry and healthcare IT going to have to go? Here are my predictions...

1. Healthcare's cost is driven by it's complexity and variability. The need for standardization in healthcare will be both drive and be driven by the need for easy interoperable exchange of patient information across the continuum of care.
2. SaaS and SOA are most effective when dealing with the standardized exchange of data (think RSS) so if standardization continues to gain traction via HITSP, IHE etc then they will become even more viable delivery options.
3. The need to exploit our most efficient and powerful resources, the minds of countless doctors, nurses, technologists, patients and other stakeholders, will drive us to converge on technologies that simplify the creative process.

I think that the end-point is likely to be SaaS, SOA or something that comes along later that fits this bill. Creative collaboration (aka the FSF model) is gaining momentum and will reach a tipping point once the pain of doing it the way we've always done it is greater than the pain of what will come next. I think that we're on the cusp.

So here's the deal. You can't just let me ramble like this without giving me some feedback. Help me develop this idea into something useful....

P.S. I think that NLP technology (as referenced in the article) has a ton of potential and could even break down some of the barriers and challenges associated with traditional business intelligence. In the short term though structured data and standards will serve us better since they help drive down the variability that is the root cause of our countries high cost of healthcare. The decision to open source it's development is both intelligent and responsible.

Is Buy to Build as David is to Goliath???

In the January CIO Connection (the CHIME newsletter, no I'm not a member but a friend is) there was an interesting article on some questions asked by Insurer Executives at a Healthcare IT Summit. One of the questions was "Should our organization take a build versus buy approach to BI?". This is a good question.

When I first came to my organization it was literally in the basement as an operator changing tapes and printing UB94s. Well, before that I was a dialysis equipment tech but that was before my IT days while I was still in college. Once I got out of the basement I started working as a UNIX admin and that's how I got involved in a custom clinical portal development project. Basically two developers, a DBA and a UNIX admit had built a system that slurped up DI and Medical Records dictations in HL7 messages, dumped them to a UNIX box, loaded them into an Oracle database and presented them on the web via Cold Fusion. There were some other interesting apps that enabled physician to physician messages (almost a pre-twitter twitter really) and the ability for a MD to grab a rounding list from a Kiosk when they walked in the door. All of this before cascading style sheets and widespread use of XML. It was cool!

Until one of the key developers left and those of us who stayed behind were left the legacy of several undocumented VB4 programs running on an NT4 server that used a weird set of spaghetti like database links and PL/SQL scripts. For a long time we were afraid to touch a lot of it until we rewrote the pieces that we wanted to keep and a few years later we implemented our preferred vendor's physician portal product with great success. Now we spend some time customizing that portal so that it integrates well with some other apps that the physicians need.

So the CIO Connection article went on to point out pros and cons of both the build vs buy BI approaches. In a nutshell, build gives you depth and control while requiring more business engagement and solid processes. Buy gives you shorter time to value with less flexibility and more risk of creating information silos. Analysis like these make deciding the right path about as clear as mud. It also makes the article pretty accurate.

I've rolled the connundrum around in my head for a long while. Given the emerging maturity of the HITSP standards for integration (considered a "glimmer" on the Gartner Hype Cycle), accelerated adoption of EMRS, economic pressures and moral obligation to continue improving patient care I've fallen on the customize/build side when it comes to Business Intelligence. The need to understand, care for, manage and secure our organization's data REQUIRES that we have high levels of business engagement/sponsorship and effective process. The deep expertise required to customize/build that environment forces the issue and the facilitation in a way that "packaged" tools don't. Plus the addition of the packaged tool vendor adds a third relationship to an already complicated mix.

I feel less strongly about building other key functions, web and collaboration tools aside. The thing that might change the game over time would be widespread adoption of HITSP standards as the glimmer brightens to a beacon. Then the art of integrating systems or delivering information to the right stakeholders becomes much easier. The interfaces between systems become predictable and the data that passes in between is better defined. Organizing the components using techniques like SOA and SAAS improve flexibility and ability to respond without sacrificing supportability.

Then build would be to David and buy would be the Goliath...

Warning - Propellerhead Update - Twitter

Alright, I decided to try Twitter out. Inspired by John Halamka's blog I setup a Twitterfeed account too. The goofy part is that I'm twitterfeeding posts from this blog to my twitter account and then using a blogger widget to display my latest tweets at the bottom of my sidebar to the right. This might be fascinating. On top of that I'm also twitterfeeding my Facebook status updates to twitter too.

We'll see how well all of this bailing wire a duct tape works shant we!

P.S. I'm adding a label for propellerhead updates to my blog so that these are easy to identify as notes on tinkering with technology from an ex Oracle DBA.

Why Business Intelligence is a Bad Word

We're off and running with discovery (in depth evaluation) of an initiative that could be termed Business Intelligence or Analytics but we aren't going to call it that. Business Intelligence has become a bad word and in the never ending quest to support the needs of our hospital administrators we can't afford bad words. The challenge of communication between the clinical and IT communities is much too important. I was once told by an ex-boss that "why?" is my favorite question. Actually "how?" is my favorite. I like to understand things sooooo....

How is it that Business Intelligence became a bad word? In looking back I think there have been a variety of factors.

• Business Intelligence (BI) is a technology label and technology labels are usually dreamt up by salespeople to make product offerings sound cool. Over time best practices cause the labels to refer to some sort of architecture or other anatomy that is recognizable. The label endures however and lacking the newly evolved context suffers.
• Recently in reading an enterprise architecture text the difference between deploying IT solutions vs IT capabilities was highlighted. Deploying IT capabilities is a more forward looking and strategic endeavor. The difference however isn't always clear and when (as I have on occasion) heard IT folks talk about deploying a "robust business intelligence application" the wrong picture emerges. BI is an IT capability and should be treated strategically. Individual projects should focus on solving problems.
• When working with business leaders on developing IT capabilities it's extremely easy to fall into the "solution looking for a problem" trap. Unless the value of the capability can be defined in terms of business value or mitigation of risk it's like telling a joke and forgetting the punchline.

So again the challenge of communication between the clinical and IT world highlights itself. So if you want to start being pro-active and develop IT capabilities you best watch your language.

Value Proposition

On Friday I sat through a very cool vendor demo about a really cool new data product. The product itself is pretty innovative ad would have some really important applications in our environment right off the bat.

The topic of cost came up at the end of course. For a 500 bed hospital we'd be talking a highish 7 digit pricetag. This seems to me close to the cost of a DI instrument or two that some of our facilities are looking for. What might a better model be? One where the vendor shares the risk of delivering an roi methinks...

At the Tipping Point

The Tipping Point is a great book about the factors that cause an idea to "tip" over and become widely adopted. It's the difference between feeling like you're pushing a noodle uphill vs trying to keep up with the tire rolling downhill. There are several factors that create a tipping point. Some, like the "stickiness factor" can be synthesized by creating messages, communication and even marketing that "sticks" to the target audience naturally and organically. Other pieces are less easy to coordinate like the need for people to network, understand and sell the ideas (all different roles).

Today I caught myself telling someone that I really didn't expect our Business Intelligence initiative to start taking off so quickly. After working for nearly a year with my team and colleagues to research, test and market the value of the technology I'm spending a full 50% of my time now preparing charters, steering committees and presentations to secure resource commitments. It's as though a glacier doubled in size overnight or a snail traversed a county in a day. It's stark.

I'm also surprised at it's lack of isolation. As one sponsor is positioned to support and sell the initiative, dedicating her own resources to make it happen, another is beginning to emerge with a different set of requirements and a new found mandate for long awaited change from his CFO. Other parts of our organization are pursing similar paths and barriers to collaboration are evaporating. Information is beginning to flow across silos and saturate. Fear is being replaced by excitement.

So while winding down this afternoon I decided that perhaps I'm witnessing a tipping point under way. I'm not sure how much of it's due to the work of my colleagues, the current business landscape at work or the passion of our new found sponsors for the utility of this technology but it's exciting to switch from educate and sell to prepare for launch.

T minus 60 minutes and counting....