Five Attributes of a Successful Healthcare Solutions Architect

During HIMSS 2009, and lately as well, I have been asked by several people what qualities or attributes would help a healthcare solutions architect be successful, so I decided to initially list at least five key attributes that I consider extremely valuable:

1. Be technology agnostic:

The Healthcare IT scenario is plagued with a myriad of solutions of disparate technologies and they will continue in the landscape for many years to come. Healthcare interoperability is a huge concern and anything you design has to be able to integrate with whatever is out there. You can't be picky by going down the path you feel comfortable with.

In a hospital facility you may find current and legacy applications such as: MEDITECH, Emageon, Lawson, etc., and all of these are based on different technologies (e.g. Magic or MUMPS, Java, RPG 4).

If you are in an Integrated Delivery Network (IDN) scenario you may find that many facilities have differing technologies. One might be a MEDITECH shop while another one may be a SIEMENS one. The reason for this is that many IDNs merge new hospitals into their network and they can't swap their Health Information Systems (HIS) applications overnight. Some migrations can take several years from start to finish. Some never take place because the clinicians of the newly incorporated facility actually like, or are accustomed to, their applications or they fear the unknowns of a new information system. Most likely implementing their HIS was a painful and long process and they may not want to go through that again.

What you design will have to live inside this Tower of Babel so you may find yourself creating pieces consisting of various technologies (e.g. Java, .NET, native C++, etc.). Your products will most likely have to exchange information with legacy applications and silos are no longer welcome in the healthcare domain so be ready to create loosely coupled interfaces to the outside world.

2. Know the standards:

HL7 and DICOM have been around for over 20 years and don't think they will go away anytime soon to give room to the new industry wide standards. In many of your creations you will encounter these standards in one way or another. Don't start complaining just because you don't understand them or they seem different than more generalized standards out there. HL7 has been out in the playing field longer than XML and DICOM has been kicking the ball around before the Object Management Group (OMG) came into being. Both HL7 and DICOM have been adopted by major players in the healthcare IT domain worldwide.

HL7 goes beyond messaging. HL7 has defined other useful standards such as CCOW (Context Management) and the CDA (Clinical Document Architecture). All of these standards will gain momentum during this healthcare modernization era.

3. Know the harmonization initiatives:

IHE and HITSP are organizations that have been formed to be able to sort out the mess mainly created by the excessive flexibility of HL7. DICOM is a more rigid standard although it is also afflicted by the different interpretations given to it by the various vendors that implement it albeit in the last several years this has been largely normalized.

IHE and HITSP are all about interoperability. Both create profiles for implementation that are based on real world use cases.

Personally I recommend that if you are new to healthcare IT and software development you should start learning the standards through these harmonization processes. Learning HL7 from ground zero can be tortuous and understanding DICOM is a career all by itself.

ELINCS is another harmonization process, albeit of smaller scope, that was created by the California Healthcare Foundation to unravel the complexities of the exchange of information between Electronic Health Records (EHR) and Laboratories. If you are going to deal with EHRs and laboratory interoperability then here you will find peace of mind. ELINCS has been adopted by HL7, IHE, and HITSP so it is not a standalone effort as many believe.

4. Understand the CCHIT process:

Certification has become a big deal. You will not survive if you don't deliver products that meet the "Meaningful Use" criteria or that when they play in a healthcare setting they at least contribute to this criteria. CCHIT is defining 3 different certification processes and your product will most likely fall into one of those. Modules have been accounted for for the certification and even in-house developments have been considered. This change in CCHIT's processes is indeed welcome by many of us.

CCHIT has held its position of owning the EHR certification process. There are no indications that other organizations will perform this role. Anyways, if new organizations participate they will most likely follow the same approach CCHIT has created.


5. Get the hang on clinical workflow:

If you want the product you are creating to survive the battle of implementing it in a given clinical setting then you must understand clinical workflow in the various use cases that exist out there. Most applications fail during implementation because they are obtrusive, invasive, and detrimental to the workflow.

This is one of the main reasons that EHRs get launched and then after a short period of time they get tossed out the door, and by the way, not through the front one it came in.

Lack of understanding of the clinician's workflow by many software developing companies has been a major factor of having generated the apathy that exists in clinicians towards information technology.

Almost all softwarel UI paradigms have been designed to be used by people who sit in front of a computer all day long with a keyboard and a mouse pretending to be working at all moments. These input devices are unsuitable for someone who is treating patients in real time. Get the difference? Would you like the doctor or nurse to be sitting in front of a computer while they have an encounter with you? I know I wouldn't!

Biometrics has come a long way and so has artificial intelligence. Investigate how these can aid in creating solutions that augment the workflow. You must start thinking out of the box. Don't think in technology terms but think in solutions to real problems. You would be surprised of how many complex problems have been solved by thinking simpler.

If you want your product to reach the whopping 80% of the unattended healthcare delivery market that's out there waiting for you with their arms closed, and the remaining 20% of the highly unsatisfied current user base then you have to cause a paradigm switch: Think workflow and make the shift!

Coming soon: 5 More Attributes of a Successful Healthcare Solutions Architect

The EHR Guy