Apple’s recent announcement on the new iPhone Developer agreement is making waves in the technical community; HealthCare IT should be paying attention as well.

Essentially, Apple has mandated that any applications for their iDevices be written, from scratch, not ported over, in one of 4 languages – Objective-C, C++, C or JavaScript. No third party API calls of any sort are allowed – no Flash, SilverLight, ActiveX. While web applications should be exempt, those apps can’t leverage any plug-in’s themselves on the iDevice – unless those plug-in’s are written from scratch.

Quite simply, unless your iApp complies, it doesn’t get deployed to an iDevice.

This has effectively increased the barrier of entry. While on the one hand this could ostensibly be seen as a quality gate, in reality the same could be achieved with less restriction – mature software development shops do so every day.

But what does this mean for HealthCare?

If you don’t already have docs beating on your door for iPad and iPod support you’re in a deep bunker somewhere.  Not only do they want these devices supported, but they want to access their EMR, their Imaging, etc system via those devices. Quite reasonable, right?

Most hospitals IT staffs are now faced with not only supporting these devices, but also working with HIT vendors, some of whom are also notoriously behind the technology adoption curve, in getting their application, be it an EMR or a PACS Web Viewer, to comply. Support at the desktop is challenging enough with a lot of these apps requiring an older Operating System, browser, version of Java, etc. Now add the challenge of supporting, or creating from scratch, these same clinical applications on what is essentially a closed platform.

Apple isn’t going to change its mind – it doesn’t need to. While physician’s can certainly be educated as to the challenges involved with their iDevices, at the end of the day this support will end up happening. So, yes, I’m taking a shrug and deal with it approach here. The HIT vendors and HIT staffs writing software are going to have to make a conscious decision to support and resource custom versions of their apps for iDevices. Or not. If the same can be accomplished with web apps, so much the better.

One approach might also be to wait and see what the next generation of HP, Dell, HTC and Android smart phones and devices bring to the table. How effectively will they compete with Apple and how open will those platforms be?

Regardless, this raises two glaring prospects. First, HIT vendors probably have their hands full between CONNECT, HITECH, Meaningful Use and whatever else is screaming down the pipe. I shudder to think of the quality that could be sacrificed to meet those time-boxed needs alone, much less clamor from the consumer space for mobile device support.

Second, and more pertinent to Healthcare in general, is that this will only serve to expose just how fragment HIT and the back office is. There is no silver bullet or fairy dust that will solve this and there really isn’t a turnkey vendor offering that will make up for decades of trying to run integration via HL7. This is going to be a lot of heavy lifting – it’s not technically complex, but it’s still a lot of grunting, heaving, sweat equity required to bring about real world data or even application interoperability to HealthCare.

Fundamentally it comes down to HealthCare recognizing that mature, real world enterprises a) own their data b) have access to that data anytime, anywhere.  The first can be resolved with some system of record data source – whether this is federated, consolidated, backed with an EMPI or not. The second can be resolved with a technology architecture that allows access to that data – preferably some sort of Web or Service Oriented Architecture (WOA or SOA)

Towards that effect the Enterprise SOA and Operational Data Store (ODS) that I’ve evangelized and campaigned, begged, pushed, pulled and sometimes just bullied through where I work lays the foundations of solutions for not only the challenges of data ownership but also those of data integration.

 If Apple is one of the catalysts that brings about the realization of the importance of such foundational works, so much the better.

Had we started on that work effort three years ago, we would have two of the keystones necessary to rapidly launch whatever the heck you can dream off on whatever platform you want.  That client interface is typically the easiest to do once you square away your User eXperience (UX). I can right iPhone, Web, desktop clients all day long once I a) have the data somewhere b) have a consistent interface.

But for now I’m doing a lot of grunting, heaving, sweating and more than a little cursing (sorry mom!)

Mind you, I’m not stating this is THE solution, I’m stating this is A solution. There’s at least one marketplace solution I could think of.  But, still, there will be time, money and resources that are required.

The piper, ladies and gentlemen, will be paid, one way or another, before he plays.

Reference Reading:

iPhone Developer Agreement Reaction Posting:

http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler

Key Point:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Follow-up Posts:

http://www.taoeffect.com/blog/2010/04/steve-jobs-response-on-section-3-3-1/

The “insightful” response mentioned by Steve Jobs: http://daringfireball.net/2010/04/why_apple_changed_section_331

This may be heretical.

This may also tick off a lot of current HIT workers. It shouldn’t but it may.

For those it does, please realize that this is not casting fault on your capabilities, your skill sets, your accomplishments – nor those of your organizations or managers or management chain. I’m not holding any of you culpable, simply because you didn’t know better and given the peculiarities of HIT and HealthCare culture and general HealthCare professional and management education – you were not taught better and did not experience the necessary.

So, this is just a little tough love from someone who cares.

Basically, HIT must embark on engaging more technically capable folks on their teams and utilizing clinical expertise more as subject matter experts. Extending their skill sets with deeper technology skills is another approach. There needs to be a de-emphasis placed on clinical experience for HIT workers – in so long as you have a core of clinical workers you can draw on or hire as Subject Matter Experts (SMEs).  Yes, you’re going to want more geeks and nerds around; trust me, we’re way cooler now than we were in high school and we’ve developed some great social skills since.

Many verticals have established as best practice the merging of technically skilled individuals with SMEs. Fundamentally, any modern enterprise – which HealthCare must become if it is to survive – must have an intrinsic ability to detect, assess and implement technical change – which is only coming faster – at the speed of or slightly lagging but not lagging behind from a few years to a couple of decades.  Having the right people with the right technical skills on-board – as part of your brain trust – is necessary.

There are two sidebars here.  The first is that certain regulations could also be decoupled, for example, making it easier for a vendor to support recent browsers instead of being stuck supporting browsers from 3 or more years back. Second, a more technically competent customer can better compel their vendors to deliver technology adept, open solutions. This goes for the patient-hospital relationship as much as it does for the hospital-vendor relationship.

The current inability of HealthCare organizations to leverage modern technologies, assess technological change or otherwise take control of their technology - is unique to HealthCare and one of the fundamental brakes on HealthCare’s ability to efficiently grow. It is, respectfully, insufficient to insist that a HealthCare system is unlike a technology company. Many enterprises rely heavily on IT, as does HealthCare. Unlike other organizations, HealthCare has the least amount of understanding of technology and the technology it uses – too many things are a blackbox in IT. Does every Clinician need to know how a message queue works? Definitely not. But your pertinent HIT staff should know enough about message queues to know the difference between and applicability of synchronous vs. asynchronous, for example.

In HIT the typical HIT worker likely has a clinical background ranging from RN on up and has just enough technical skills to implement a product or work it’s configuration switches. Some of those workers are  more technical when it comes to writing custom scripts or other geegaws to extend or enhance a particular product. As important, while they bring a process-centered mindset from their clinical backgrounds, they lack the process focus on IT.

Who does the Hospital depend on currently? Vendors – consultants or big box vendors whose clinical system they buy.  The vendor comes in and does a turn-key install, their level of involvement being driven by how much the investment the Hospital has put into IT. Again, same 80-20 rule, sometimes a shop get’s more technically capable from the experience, too often it doesn’t, but fundamentally your brain-trust is left anemic.

Note that buying and installing a product is not an investment in IT – it’s a capital cost, a one-time outlay. An investment, for example, is training your HIT folks so that you need to supplement your talent pool when needed, not essentially bring in another layer to your team to get an implementation done. There’s a time for vendors – it shouldn’t be every time.

More technically capable workers in your HIT department are necessary to ensure you’re making the right product choices and laying a good strategic, roadmap for your IT & IS future. Your current, typical HIT worker has grown up in a silo – they should be given the opportunity to evolve certainly but realize  the best approach may be to take advantage of reform efforts and add more technically focused skill sets to your system, and leverage your clinical workers as a critical interface, say as Business Analysts, for example.

Here’s one real word example why. A healthcare system recently bought a web-based decision support system (DSS). The decision was made to feed it data from a particular HL7 stream. The vendor required that this data be formatted (keeping it simple here) as Red-Blue-1-2-Sky. No other format was acceptable; no other data elements were acceptable. So, the already overworked integration team had yet another interface to implement, test, monitor and roll-out.  When a technical resource looked over the project details months later, they discovered that the interface engine the vendor was using was a very well known multi-format, best-practices based system quite capable of consuming a message, say Blue-Sky-1-2-Red-A-Dog, and converting it for the DSS’s needs.  Yet no one had challenged the vendor or pushed back or found a more technically viable and cost effective solution because, at the time, no one had the appropriate technical skills to contribute to that decision. A decision that cost both in capital and on-going operational costs and maintenance! Once it’s in production you also have heightened customer expectations to work through, make it a much more expensive mistake to fix – at which point the mistake is left, adding costs that should not otherwise be there.

There’s other examples I can pull from, ranging from hardware load balancing setup on an extremely rudimentary level but paid for as if it was 5 9’s of uptime,  to a persistent insistence that a particular internet traffic router absolutely, positively could not re-route traffic a specific way – when there were at least 2 How-To’s easily found online.

A compliment of IT workers with deep technology skills that interface within your HIT system can provide the technology guidance necessary to truly leverage IT. Note, by the same token, this would imply dedication by the health system to that goal and a change in how HIT is approached within a system – not as a service, but as an integrated business partner.

HealthCare IT workers are raised and live in a silo where they are experts in their own rights, in their own fields. Unfortunately, that’s not enough, especially not these days with the new focus on HIT for healthcare reform savings and the push to hire gobs of new HIT workers. The right systems and the right technical skillsets that bring a deep understanding of technology are critical if the pitfalls of the past are to be avoided – and new, exciting, productive mistakes made!

Otherwise, we’re all just making the same mistakes over and over and expecting new efficiencies – and isn’t that defined as insanity?

In dealing with my frustrations around healthcare IT – if ever a topic from government driven reform to the state of the industry was guaranteed to require me to make use of Healthcare – and as is my wont, I got creative describing the challenges we were having in one meeting.

Launching off a comment by a peer where he, rightfully, stated that we do great tactically, but there is a weakness in our strategy and a failure to communicate and have understood said strategy in a partner like relationship with the business (see it’s not just me) I came up with an analogy. 

Here it is.

HealthCare IT is a doctor. The system is the patient.

“Doc, I got this dull pain in my head.” Doc looks over patient, notices nail sticking out of patients head, blood freshly flowing.

“You’ve got this nail in your head,” he starts out helpfully, “and –“

“Nail? What nail, I told you my head hurts why are you telling me about this nail, just give me something for my head”

“Look, I should really try to get you on a treatment plan and get his nail-“He’s been here before.

“Look doc, just give me something for my head won’t you?” interrupts the patient.

“Take two aspirin. I’ll see you in the morning.” Doc shrugs. He’s been here too.

Next day, predictably, patient is back. Nail still in head. Crusted over.

“Doc, that pain is getting fierce, why didn’t you fix it?” Doc looks at the patient quizzically.

“We should really do something about that nail in your he-“

“Will you stop with the nail! I don’t know anything about a nail, I told you my head is KILLING me.” Doc shrugs, writes out a prescription. Familiar territory.

“Here’s a prescription, take two super duper pain killers and  I’ll see you in the morning’

Again, predecitably, the patient show’s up. Puss is seeping around the nail, patient is feverish.

“Doc, I don’t know what third world country you learned to be a hack in, but you’re just not helping my head!”

“Look, I really need to get that n-“

“Don’t say it! Don’t you dare say anything about this nail! I’m paying you good money to get this pain taken care of!”

“Look, here’s a treatment plan, here’s everything I can do for you, we’ll have to give you some antibiotics, a tetanus shot probably by this point and some stronger pain meds” Patient looks at doctor like he’s gone mad

“More meds? Shots? You’re nuts, all I have is a really bad headache! Next you’ll tell me you need to run some tests”

“Well-“

“Forget YOU, buddy, I’m going to go see this out of network, really expensive specialist!”

“Ok, I’ll see you in the morning,” says the Doc, shrugging.

“Don’t bet on it buddy!”

The next morning the patient walks in, fuming mad. Nail, still in head!

“WHY DIDN’T YOU TELL ME I HAD A NAIL IN MY HEAD!!!”

“…”

“Well, get it out!”

“Ok, here’s the treatment plan, now, since we waited so long, it’s going to require more treatment and -”

“IT’S JUST A DAMN NAIL! HOW HARD COULD IT BE TO GET OUT!!! I’VE ALREADY GIVEN YOU ALL THIS MONEY TO GE THIS NAIL OUT OF MY HEAD!”

“Look, if you had just let me treat the nail, in your head, when you first came to me-”

“NAIL!? WHAT NAIL! I HAVE A HEADACHE!”

I could go on for pages, but I think you get the drift.

Let me first say I have the utmost respect for Dave DeBronkart and read his tweets and other writings with special interest. I am a strong believer in patient empowerment and portability of data – especially personal health information.

My favorite, to date, was “What part of “Give us our damn data” do you not understand?” over on e-paients.net which seemed timely given one of my long-running struggles in Healthcare IT as a long-time technologist and a relative new comer to this field.

Keep some things in mind as you read this – first, this is from a limited subset of experience – I’m not a travelling consultant, so I speak from personal and trusted second-hand experiences and from a deep well of understanding how to make technology work – hardware & software – within an enterprise business world.  Second, there are HealthSystems that are on the ball, adopting technology, spending time and money on software infrastructure that will get them there. Spectrum, Henry Ford, Duke, Mayo are 4 shining examples that pop in mind – and while I’m sure there’s more, they are the superlative minority in an ocean of myopic mediocrity.

With the exceptions mentioned above, making health data portable is going to be a bigger challenge than patients realize and hospitals are either working hard towards it (or already there, reference above) or patently ignoring the gorilla in the room. It’s an uncomfortable change for them and one that most of them don’t understand and don’t know where to start.

When they do start, there are impediments – here they are - and the solutions, as I see them.

First, HealthCare IT software infrastructure is broken. Each application, each product is stood up in a silo, some HL7 interface(s) are created and viola, interoperability, and once it’s there, it’s trivial to get a CCD or a CCR and viola, portable PHR! Right? Wrong.

Well we can just buy a third party product and pay them some consulting dollars and their product X drops into our systems and we can start generating CCD’s and CCR’s! Right? Yes, that will work, are you sitting down for sticker shock.

Because …

Having a mass of HL7 interfaces doesn’t get you to a CCD or a CCR if you don’t have solid, consistent documentation that deals with the inevitable mass of custom segments. Once you do have said documentation, you need to be able to quickly identify the sources of truth if you’re going to use HL7 – and depending on how fragmented your systems are that could be from a number of different streams. This is true regardless of your decision to build or buy. The more neglected your software infrastructure has been the longer, and more money, it’s going to cost you to get it organized.

Next, who’s going to work on it? Champion it? Each new application, each new facility requires some level of HL7 effort to integrate and exchange with. While a system might do a great job funding hardware infrastructure and upgrades and refreshes, I’ve only seen a handful that also do it on the software side. Capital is tight enough as it and getting tired as I’ve previously mentioned, imagine trying to build a software architecture when you’ve already got a mass of work to do.  There’s no business driver, there’s no business champion and in most cases there’s no technology champion – who then has to convince a myopic business on why it’s important to have a software architecture that supports interoperability and portability and challenge the assertion that just because you have an HL7 engine doesn’t mean you’re ready for interoperability or portability of PHR.

Keep in mind the typical, laudable, objectives of health system. Patient Satisfaction, Physician Satisfaction, make enough money to invest in more, better, expanded care.

What’s missing from there? An explicit or implicit understanding that a healthy HealthCare IT software infrastructure is just as important – not only does it help achieve those goals but it puts you ahead of the care curve when it comes to ensuring an effective continuum of care through a patient, not an encounter, lifecycle.

Unless you’re somehow fortunate to have one, monolithic install from one vendor, your software infrastructure is weak and needs help. You cannot look at systems in a silo, and in a multifacility setting you especially cannot further silo systems to one facility and bow to pressure for a second system in another facility. Just as you have one consistent network, hardware and server infrastructure, there too must be effort towards a consistent, interoperable software infrastructure.

Second, HealthCare Business leader myopia and a lack of collaborative, participative IT leadership leads to systemic inefficiencies. On the one hand HealthCare Business leaders have their hands full driving to their healthcare goals. Most IT leaders also have their hands full helping reach those goals. There’s typically a great strategic business plan. The Strategic IT plan? Sure it supports the goals of the business – and that’s great isn’t it? But if you take a close look at it, it’s half-strategic, half-tactical and typically missing a key component.

Having a three year plan to consolidate a clinical system or to upgrade hardware and infrastructure is great. Where’s the plan to establish a Service or Web Oriented Architecture? Where’s the Data Interoperability plan? The Enterprise Data Warehouse plan? Where’s the data portability plan? Where are the business champions, the technology champions for these components? Purchasing yet another solution isn’t a plan, it’s a Band-Aid.

While I think it’s unreasonable to expect most healthcare business leaders to just pick up on this, I point the finger squarely back at IT, workers and leadership, that has failed to evangelize the need to not only have a comprehensive hardware infrastructure, but to also have a software architecture that integrates and makes portable your data. We have to show the costs, the benefits, the savings, the ROI behind SOA, MDM, Data Warehouses – we have to evangelize to the healthcare business how they could be using IT better, not just servicing their needs. Having said that, when IT does do so, the business leaders need to listen and ask questions.

HealthCare IT has to have a new found honesty with ourselves about the state of what we’ve been given, forced to or comfortable with working with. Some change and paradigm shifts will be required of us.

For example, HL7 isn’t portable, and it’s far from semantic, lukewarm arguments for or against HL7 v3 notwithstanding.  Custom segments, lack of proper documentation and a technology platform that does little more than take data from point A, pseudo mash it up and send it to point B, is not interop. That’s moving food around on your plate.

Here’s a recent example from my own Operational Data Store (ODS) project.  We came across an ADT message with a custom segment. We did our research and diving in and discovered that no one quite seemed to know just exactly what that custom segment was. No documentation existed, nor was there clear recollection of what it was for (God help us when our current IT crew start retiring … starting this year!). The data wasn’t self descriptive, nor was its use in the message. Long story short, someone remembered what it was for, and you bet that went into our documentation\WIKI for the project.

On the one hand I don’t blame anyone for this, but I hold the entire organization accountable for it. You cannot continue to make system purchasing decisions based on whims and you cannot continue to fund purchasing and install of a system from vendors (the data is leaving my system fine, must be something on your end) and not also put aside effort to have a sensible, smart software infrastructure!

And, heresy, you are not special HealthCare. Your backoffice operations is no more or less different than a financial house (they have SOX, you have HIPAA). HL7 isn’t the only way to do interop. There are other interface engines out there. Your IT workers don’t always need clinical experience (more, way more on this in another post). More heresy, clinicians’ are not your customers, patients are.

Here’s how you are special. You take care of our kids, our grandparents, our friends, family and ourselves when we’re sick and we’re afraid. You have a deep responsibility to ensure that your systems can give you and me that view into more than just episodic care. That, that is how you are special and for that reason some of us care to fight this fight.

You have to integrate software planning and expend effort on software infrastructure alongside your hardware and business planning and, much like other organizations that have achieved success, IT is a participative partner who empowers you, not a service organization which you find yourself alternatively hating and wondering where the money goes.

You have 5 9’s of uptime but you have to remember 16 different, complex passwords. You have a shiny new EMR that you’re paying an arm and a leg for interfaces for each new system your buy.

It’s much like a failed human body. The hardware is the musculature and bones. The best body in the world doesn’t help if the software, the nervous system short circuits and the blood flow stutters. You’re a prime athlete, chair bound because you’re falling over every time you try to take a step.

This InfoWorld article on why running IT as a business is a train wreck waiting to happen couldn’t have come at a more appropriate time.

If it’s one thing I’ve grown despondent about changing is this pervasive attitude in most enterprise IT shops, but especially HealthCare IT, about how it’s all about making the customer happy – not the patient, but just about everyone else from clinicians to backoffice.

If there’s a more antiquated and downright utterly wrong attitude in IT I have as yet to find it.   It is not all about the customer, I am not a customer service organization, I do not serve the customer. I serve the business, and I partner with the business.

Not for nothing has my first question consistently been: What business problem are we trying to tackle – not – what do you want?

Yet we still persist in playing the masochistic role of Sisyphus, in between Scylla and Charybdis.

This is Heresy some will want to burn me at the stake for, but HealthCare IT and business leaders, as far behind the curve as it is, should especially read this, grok it and work it into their cultural change plans. I have oft been told HealthCare is not an IT business. That’s one of the attitudes that needs to be adjusted as you cannot run a business, any business much less Healthcare, without being plugged in or otherwise have a peer relationship with a trusted technology resource.

Everyone talks about how important HealthCare IT is to cost savings; what they neglect is that one of the root cause issues with HealthCare IT is that it’s culture and approach to problem solving is something that no amount of tangential legislation, or funding will solve – it is an attitude that needs to infect the organization. To be sure there are a handful of healthcare entities that are moving in the right direction with their IT. The vast majority, well over 80%, are either only gradually adjusting or remain stuck in amber.

Here’s some pertinent quotes that should encourage you to read the article:

“Your ticket to the promised land begins with this: No one inside your company is your customer.”

"IT should relinquish its increasing stance as an order taker, and earn and advance its intended role as the qualified engineer of what makes a business hum."

“To achieve a quality architecture, the internal customer of one project pays more so that a different internal customer, some time in the future, receives the benefit.” -- This, by the way, is something that is sacrosanct to me and has been very successfully  evangelized where I’m at – even if it’s not generally or widely understood, I have enough buy-in, and real world results, to backup the approach we’ve taken to architectural quality.

“Chargebacks are an attempt to use market forces to regulate the supply and demand for IT services. If that's the best a business can do, it means the business has no strategy, no plans, and no intentional way to turn ideas into action.”

Instead, they should say, "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done." -- This is one thing that my team has done since day one. It’s a HUGE culture shock, but we’ve stuck with it. The good news is that it works and with the business units we’ve dealt with the most they’ve embraced it – especially since the results have borne fruit. The disappointing news is that in a $2B/yr multifacility hospital system, it has become a non-cost-effective task to repeat the evangelize\adopt\show cycle with EACH business unit.

“That's what proper governance requires: effective leadership. It's the hard work of turning the company's top executives into a team that agrees on strategy and turns it into a plan for coherent action. IT's priorities are built into that plan. They aren't bought and sold by whomever plays the budget game best.”

“IT's job is to recommend better ways to operate, using technical capabilities business managers might not even know are possible.” – This again is something my team is well known for. The reception varies as does the reputation earned. Invariably some segment will see you as barriers to their success. Reference the points made here-in and through the linked article as to why this doesn’t bother me in the least.

So, you’re choices are this – or build a car with the accelerator and steering wheel in the back, brake in the front, 2 and a half gears in reverse, 3 forward –in other words, a typical healthcare IT solution.

I look back and am content
I look forward in hope
For I have you
My family, my friends and all the rest of you dopes =)

You are the light that shines the way
You are the comfort in the dark
I'm fortunate and blessed to know you all
Even if I don't know half of you half as well as I should like ...

Happy Chanukah, Great Kwanza, Joyous Festivus, Eid Sa'eed, Happy Dewali
And yes, even Merry Christmas and a Happy New Year
Be you safe and full of cheer!

Sam Adams

A lot has been said about the impact of technology on HealthCare and how 50,000 HealthCare IT jobs will be created as part of the healthcare reform debate.

Let me share an example of the reality of what is occurring due to the utter lack of transparency coming from D.C. around HealthCare reform.

Healthcare organizations are planning to run lean in 2010.  While the quality and quantity of care will continue to be emphasized and of paramount importance, the much touted impact on HealthCare IT is a different story. 

Capital expenditures are being scaled back to the absolute critical projects – and even there hard choices are being made. Maybe you can wait another year for new hardware or the next version of software.

New HIT jobs are being scaled back or eliminated directly; the money, rightfully so, goes towards clinical service and quality first. Maybe you can just buy a third party product, if you can get a pricebreak.

Healthcare Organizations just don’t know and simply cannot divine from the offal of entrails they are being thrown from D.C. as to what the impact to their bottom lines are going to be – and keep in mind, most of them struggle to stay in the black, and what profit is made is typically reinvested, not sent to line any pockets. Further many of these organizations genuinely emphasize quality care of their customers (aka patients!).

Gone is the talk of decoupling insurance, patient choice, portability standards and tort reform, replaced instead with an obfuscated miasma from the swamp that is already having a negative impact on that which can bring about efficiencies – information technology.

If healthcare organizations, even healthy ones, are scaling back on IT now, what, one wonders will occur when it finally becomes a reality?

In the process of designing and prototyping our Operational Data Store (ODS) for our Enterprise Products, we’ve noticed a couple of things that we expected but (vainly) hoped weren’t there.

First, a good number of our HL7 messages don’t follow documented standards closely. Most importantly, there are Z-segments (custom messages) in all sorts of places in a message instead of where they should be. This means our integration implementation has to be smarter and more defensive in handling these messages, such that the message transactions continue to flow when an unexpected or unanticipated message is consumed.

Second, we are replicating a lot of data with our HL7 messages. Say you change a zip code on a registration screen. You get the entire screen of data, not just the change, replete with whatever customized Z-segments. This means we’ll have some extra heavy lifting to do when consuming messages.

The key points here are two fold.

First, this is no one person’s fault – no one did a bad job – people work to their level of awareness.  What it does indicate is that HIT hasn’t evolved. We’re still making the same mistakes we’ve been making for the last few decades, and that is inexcusable.

Second, this only reinforces why HL7 and standard don’t ever belong in the same sentence.  It doesn’t matter than one vendor’s HL7 specifications may adhere to the standard, such as it is, the problem is that the HL7 message is too easily hijacked.  Z segments should be the exception, not the rule and they certainly shouldn’t cause a problem when it comes to consuming the message nor require defensive coding to accommodate it.

The only way this is going to be solved is if an alliance of HIT-centric entities, not vendors, not the government, work together to force industry adoption of standards and practices that are common place across most enterprises else. In short, HIT needs to evolve out of its current calcification by having the people that feel the pain the most do something about it

For our project needs, we knew these would be problems, we planned and allocated for them. For anyone else embarking on similar ODS or Data Warehousing projects in HIT – caveat emptor, a standard isn’t always a standard in HIT.

Fair warning, this is more of an internalized discussion written down, appropriate caveats on Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} .MsoPapDefault {mso-style-type:export-only; margin-bottom:10.0pt; line-height:115%;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> misinterpretations apply.

While I feel that American Exceptionalism is being apathetically eroded into guilt-ridden mediocrity, this post is going to focus on the beginnings of a sort of depressing epiphany that I’ve stubbornly fought against for the better part of my nearly 2 decade career in computing, far preferring a bloody head over what I, personally, deem an ethical compromise of commitment.

Until now.

Based on personal observation and comparison of peer experiences, exceptionalism is neither encouraged nor rewarded in corporate computing.  I’m sure the odd corporate computing environment exists out there where this may not be the case, but a very odd duck it will be.

HealthCare IT, regardless of talks of reform and funding, sadly suffers from the same issue that cancerously gnaws at the heart of ingenuity and innovation in corporate computing, but writ larger.

Unfortunately, HealthCare IT seems to have further devolved into purchasing disparate solutions and cramming them into weak integration platforms, repeated ad infinitum with insufficient focus on first, defining the problem, then designing the solution, before creating or purchasing or integrating anything. The tumor has spread to the extent that few things seem possible without the intervention or resources of a third party vendor, from defining the need to delivering the solution to supporting and training.

We’ve achieved 100% de facto outsourcing! The counterpoint of course is that you have a body of knowledge workers who have been robbed of the opportunity to gain the knowledge they need to replace that vendor mentality.

Healthcare organizations: the consultants you want are the ones who will not sell you a single license or product until they have helped you define the problem and design the solution; expect to pay for their time.

Fundamentally, this is no one person’s fault, per se, nor should this be seen as an assignment of blame, but rather a general reflection that, for all the books, talks, discussions, groups, whitepapers and consultants, corporate computing will remain mired in a necrotic momentum that seeks to continue to survive instead of thrive and grow, learning the same wrong lessons from each ancestral generation and imparting it on to each successive descendant generations in situ. What mold-breaking successes that do come, stagnate and seem to not develop into behavior that can be consistently repeated.

In considering root causes, there is one key, very lacking, cornerstone. Accountability - the accountability that speaks to a pride in ownership and a desire to excel, to step up instead of cleave to the accepted status quo, in particular by those very same computing professionals. This isn’t just a management problem, this isn’t just a business problem.

There are many understandable, wholly justifiable reasons, mostly rooted in fear and lack of support, as to why this doesn’t occur. While the parable of the tortoise and the hare teaches that slow and steady get’s you there, I have to wonder if what’s missed is that the hare likely only lost the race once, then learned a valuable lesson and modified its behavior. That tortoise is welcome to that singular gold medal, hanging lonesome on its mantle, it’s only true testament that it lead to another’s success, another who wears shades from the overpowering brilliance of its accolades.

Now replace speed with accountability in the above story. Dig deeper and realize the other lesson here is that a lesson was learned and applied.

The lesson learned for me has been that it’s not for me to expect nor to demand, except in myself and those I lead, mentor or raise, a level of accountability that I hold myself to.

For me the this leads to my epiphany. I have defined myself by my work for the better part of two decades, the cornerstone of which is accountability – from which I am convinced all other things such as delivery, flows. I can no longer afford to do so, largely for my own sanity but also because of the perception this sets.  While I take at least half of the responsibility in setting that perception, it appears that the balance of the half remains looking for a home. Sound familiar? Yes, there’s accountability (or lack thereof) again.

So, where the balance of my career in corporate computing is involved, it would appear that a reset of expectations is called for and the balance to be sought is contentment, not satisfaction nor happiness.

The sub-conclusion here is that as risky as entrepreneurial endeavors’ are it would appear that my happy professional place is there, which leads me to considered thought on my future professional growing exercises. I’m still ruminating on that; been there, got the t-shirt(s), if I’m unwilling to return to that fertile ground …

Certainly, I will not allow qualities to neither suffer nor erode, instead, they will enjoy a tighter scope!

There is comfort in this, in a way; it’s the self-inflicted globe off Atlas’ shoulders. There’s certain liberation in looking forward to not being defined by work and expelling those same energies into other avenues too long neglected.

While this still has legs to run around and finish baking, I can honestly say that I am breathing easier now than I have in years.

I will, however, shed a tear, but not for myself, but rather for the endurance of mediocrity where it already existed rather than the desperately needed elevation of excellence.

The loss here, is not mine.