Healthcare IT is in fierce flux, it's evolving and at lightning speed and losing track isn't something you can afford at this moment unless you want many fingers to be pointed at you for being the culprit of hefty penalties and lost incentives within a couple of years from now. Two years is very little time to straighten things out in a hospital IT environment and yet alone if you are responsible for an Integrated Delivery Network (IDN). Career switching isn't a sound option during these times so you definitely need all the advice you can get!
If you are a Chief Information Officer (CIO) or a Chief Information Technology Officer (CTO) there are a minimum of five things that you must be on top of:
1. Follow "Meaningful Use": "Meaningful Use" criteria will definitely have an impact on your application environment and your technology infrastructure. You will have to comply if you want your organization to receive the incentives and avoid the penalties. Inpatient settings will have viable options with the new criteria that is being defined.
The U.S. Department of Health and Human Services maintains a website named Health IT and here you will find quick links to both the HIT Standards Committee and the HIT Policy Committee and both are responsible for the definition of "Meaningful Use". On this blog I have also placed a special page named EHR Meaningful Use with all the links you will need to visit from time to time for your convenience. The HIT Committees also publish their agendas and their respective documents regarding their advances at their HHS website.
2. Follow CCHIT: CCHIT is defining several different processes for certification that aligns with "Meaningful Use". The 2 newer ones named EHR-M and EHR-S can apply to one or several of your scenarios. Read the blog I posted titled "Midwest Interoperability Crusade, HL7 CCOW, EMPI, and Single Sign-On (SSO)" on July 1st, 2009, this will give you one of many possible scenarios to ponder on.
3. Follow the Standards and Harmonization Initiatives: Integrating the Healthcare Enterprise (IHE) and the Healthcare Information Technology Standards Panel(HITSP) harmonization initiatives will evolve drastically in order to define profiles based on use cases that will be spawned by the "Meaningful Use" definitions. HL7 will most likely become very active since this standard will maintain its stronghold in the interoperability domain. There is no way new standards can emerge in the near future. Standards take time to develop and you can't catch up with a 20+ year endeavor that easily. I don't expect DICOM to change too much and probably if it does it will be aimed towards goals for the year 2015 or beyond.
4. Form a Team to Monitor Events and Trends: Everything that is occurring is almost impossible to be tracked on your own, unless you have the superhuman attributes that Dr. John Halamka, CIO of Harvard Medical School, has. But then, if that is the case you wouldn't be reading this since you don't need any advice. Forming a team where each member is assigned a different activity to monitor is a vital step. One member of the team may monitor "Meaningful Use" events while another one monitors what's going on with CCHIT and yet another may follow HITSP and IHE and the standard developing organizations such as: Health Level Seven (HL7) and the Accredited Standards Committee (ASC X12). How you organize your team is up to you but do make sure that you keep informed of trends that may impact your objectives.
5. Follow the blogs: There are great blogs out there that are constantly being updated with valuable information of what is going on in the Health IT domain.
Dr. John Halamka constantly posts information regarding the policy committees on his blog space named Life as a Healthcare CIO. He is Chairman of HITSP and Co-Chair of the Healthcare Standards Committee. You can't get any closer to the inside scoop! The Health Care Blog (THCB) is also a very popular and a highly commented space. Here you can find health care thought leaders, such as Dr. David Kibbe, posting their blogs, comments, and also interacting with other commentators. Dr. David Kibbe has his own blog named Kibbe and Klepper on Health Care that he shares with Dr. Brian Klepper another healthcare IT thought leader. Brian Ahier is a healthcare IT blogger and also a twitterer that is really on top of things and his space can be found here: Brian Ahier - Healthcare IT. If you don't have time to go to all of them then you should visit this last one. And don't forget to come back to my humble blog where you received all this free advice!
Thanks for reading!
The EHR Guy
Coming soon: 5 More Things a Healthcare CIO Must do ASAP
Saturday, July 4, 2009
Wednesday, July 1, 2009
Midwest Interoperability Crusade, HL7 CCOW, EMPI, and Single Sign-On (SSO)
It's been a great week! I also have to admit that I am happy that it's coming to an end by tomorrow. Yes, I said tomorrow since I'm heading back to Arizona to celebrate the 4th of July with my family and friends. But I still have pending 2 more stops: one more in Detroit and another one in Ann Harbor, Michigan.
I never thought I could visit so many cities in such a short period of time. The good thing about the Midwest is that all the cities are relatively close to each other.
In this trip my favorite visit has been to the Wind City, Chicago, Illinois. During the past RSNA, the Connectathon, and HIMSS09 I didn't get to enjoy it as much as I wished, mainly because of how wicked cold it was during the first 2 events and then for the latter I was too busy. By the way, in Maine wicked means extremely good but I am using the opposite definition of it!
I've been exhilarated by the enthusiasm I find among everyone with the new challenges that face us. It's been mainly lengthy meetings where people keep asking me what "Meaningful Use" is about, how we can plan for the new CCHIT certification processes, and what should be the most immediate actions to take that guarantee that they will be going in the right track. I am also amazed about how mislead some are with all the information that is going on out there. I have to admit that even keeping close track of it can be overwhelming at times.
The CCHIT certification has become a concern for many hospitals that have best of breed environments mixed in with some in-house development and some wonder if they are going to have to change everything in such a short notice. They were very relieved when I explained how CCHIT has come up with 3 different certification models and that the 2 newly introduced ones would resolve their concerns and frustrations.
The EHR-M is the certification process that the vendors of the different BoB (Best of Breed) applications they have installed should request directly to CCHIT. This certification process is aimed specifically for modules (e.g. Laboratory applications, ePrescribing, Computer Provider Order Entry or CPOE, Patient Charts, etc.) Most hospitals that I have been to have applications from various vendors (e.g. Cerner, AllScripts, MEDITECH, etc.) and they are going to have to get their functionality harmonized in a way that in unison they act as an Electronic Health Record (EHR).
The EHR-S is the certification of a sites' functionality. This is entirely in the hands of the facilities. They have to demonstrate that there home-brewed solutions integrate and perform as an Electronic Health Record. Most will most likely have to play together with BoB modules.
Something that I have noticed is that this combination of certification processes will trigger the interest in HL7 CCOW and Single Sign-On. Reasoning: You can virtually present to the clinician an Electronic Health Record on the point of care delivery workstations by binding together the disparate applications that reside on them. If you have ever been involved with a Clinical Context Management implementation you have certainly witnessed some magic.
Single Sign-On comes to the aid in helping CCOW manage the User subject (this is how the standard names the user of the applications). Most applications, having been implemented by different vendors and at different times, enforce their own credential management practices. This resulted in clinicians having to carry a piece of paper with many user names and passwords on them. Huge security breach isn't it?
Enterprise Master Patient Index, or EMPI, technology implementations will also be on the rise. This technology addresses a resolution to a huge problem many IDNs and standalone facilities face. Many have been deploying applications throughout the years, each module having been implemented in different times and with different technology paradigms, and mainly when these paradigms were in the period of rapid growth and evolution. This caused many facilities to create patient identifiers that conformed to the uniqueness of each application. Now that information is breaking out of the silos they have lived in for a long period of time they have to be able to unravel this mess. The EMPI helps match the differing patient identifiers from the various applications into a universal or unique identifier.
Thanks for reading!
The EHR Guy
I never thought I could visit so many cities in such a short period of time. The good thing about the Midwest is that all the cities are relatively close to each other.
In this trip my favorite visit has been to the Wind City, Chicago, Illinois. During the past RSNA, the Connectathon, and HIMSS09 I didn't get to enjoy it as much as I wished, mainly because of how wicked cold it was during the first 2 events and then for the latter I was too busy. By the way, in Maine wicked means extremely good but I am using the opposite definition of it!
I've been exhilarated by the enthusiasm I find among everyone with the new challenges that face us. It's been mainly lengthy meetings where people keep asking me what "Meaningful Use" is about, how we can plan for the new CCHIT certification processes, and what should be the most immediate actions to take that guarantee that they will be going in the right track. I am also amazed about how mislead some are with all the information that is going on out there. I have to admit that even keeping close track of it can be overwhelming at times.
The CCHIT certification has become a concern for many hospitals that have best of breed environments mixed in with some in-house development and some wonder if they are going to have to change everything in such a short notice. They were very relieved when I explained how CCHIT has come up with 3 different certification models and that the 2 newly introduced ones would resolve their concerns and frustrations.
The EHR-M is the certification process that the vendors of the different BoB (Best of Breed) applications they have installed should request directly to CCHIT. This certification process is aimed specifically for modules (e.g. Laboratory applications, ePrescribing, Computer Provider Order Entry or CPOE, Patient Charts, etc.) Most hospitals that I have been to have applications from various vendors (e.g. Cerner, AllScripts, MEDITECH, etc.) and they are going to have to get their functionality harmonized in a way that in unison they act as an Electronic Health Record (EHR).
The EHR-S is the certification of a sites' functionality. This is entirely in the hands of the facilities. They have to demonstrate that there home-brewed solutions integrate and perform as an Electronic Health Record. Most will most likely have to play together with BoB modules.
Something that I have noticed is that this combination of certification processes will trigger the interest in HL7 CCOW and Single Sign-On. Reasoning: You can virtually present to the clinician an Electronic Health Record on the point of care delivery workstations by binding together the disparate applications that reside on them. If you have ever been involved with a Clinical Context Management implementation you have certainly witnessed some magic.
Single Sign-On comes to the aid in helping CCOW manage the User subject (this is how the standard names the user of the applications). Most applications, having been implemented by different vendors and at different times, enforce their own credential management practices. This resulted in clinicians having to carry a piece of paper with many user names and passwords on them. Huge security breach isn't it?
Enterprise Master Patient Index, or EMPI, technology implementations will also be on the rise. This technology addresses a resolution to a huge problem many IDNs and standalone facilities face. Many have been deploying applications throughout the years, each module having been implemented in different times and with different technology paradigms, and mainly when these paradigms were in the period of rapid growth and evolution. This caused many facilities to create patient identifiers that conformed to the uniqueness of each application. Now that information is breaking out of the silos they have lived in for a long period of time they have to be able to unravel this mess. The EMPI helps match the differing patient identifiers from the various applications into a universal or unique identifier.
Thanks for reading!
The EHR Guy
The Open Source Software Dilemma in Healthcare IT
I have nothing against open source software, as a matter of a fact I am a fan of it, and I use many applications developed under this paradigm for my daily activities, I even enjoy them as weekend projects (e.g. ClearCanvas, PatientOS, Mirth Project, OpenDICOM, etcetera), but I just don't see them fit for the demanding and critical healthcare IT domain.
VistA is not an example of the typical open source application so let's not bring it to the table for this discussion.
CCHIT's step to support the FOSS realm is indeed laudable, Mark Leavitt has proven to be a nice guy, this is a genuine gesture which gives you (the open source guys) the opportunity to certify your Electronic Health Record (EHR) products. But this isn't the gateway to success since you may still have a long stretch to go.
Let me explain why:
Healthcare IT is extremely demanding and it requires discipline a discipline which can only be delivered by highly organized and structured entities.
Companies such as: GE Healthcare, HP, McKesson, MEDITECH, Philips, SIEMENS, and similar others have for many years devoted themselves to the development of highly reliable clinical applications and medical devices. Most of these aforementioned companies have strict product development methodologies and strategies that they have had to implement in order to meet with the ever increasing and strict requirements of the FDA for the verification and validation (V and V) of medical devices and related software.
Many may argue that for the software product development process they don't use the same guidelines as they do for the manufacturing of their medical devices, but knowing how these companies operate, and I have worked closely for and with them for many years, I am absolutely sure that they do.
Maybe the adventurism into the healthcare IT domain taking place by Google, Novell, and Sun Microsystems (soon to be part of Oracle), among many, and albeit this latter one at one point in time built very sophisticated medical image viewing workstations based on their SPARC technology, are probably giving you an over optimistic perception.
In my opinion these companies currently just don't have the culture to fit into this rigorous process. Undoubtedly, they are extremely successful organizations in their activities but just not in this one. You see, this is a different beast.
And maybe you do a great job at creating software, perfect software. But this is not the only piece of the puzzle since there is the rigid documentation process required for clinical product development. Only the documentation process will overwhelm your budget if not drain it completely.
The very laid back and lax nature of open source development is the antithesis of what is required to develop critical clinical applications.
The FDA has formed a working group to determine whether or not Electronic Health Records should be regulated and to what extent if such is the case. Let's say that they do decide to regulate them, and then this would be your demise in healthcare IT. The costs involved in meeting FDA requirements go beyond those that the most daring venture capitalists are willing to risk. Only companies with an infrastructure and logistics similar to those of GE Healthcare and SIEMENS can actually survive and strive in a scenario described here.
My recommendation to you, open source developers, is that along with the FOSS community members, you continue pouring your energies into your projects but don't expect to take the industry by storm. It just won't happen, sorry.
Stick with trying to overcome Microsoft Office some day in the remote future, maybe by 2021, or by creating a user friendly operating system that is not tailored "only for geeks", like Linux is. Did you know that almost 90% of the workstations currently used by clinicians are Microsoft technologies based? You see, open source is "only for geeks" and not for the real world, the real users.
And I am not referring to geeks in a derogatory way since I consider myself one as well. But I do have a professional maturity level to understand that I have to create solutions for real world users and not savvy information technology experts.
Once you break out of your silicon shell then let's sit down and talk seriously.
Thanks for reading!
The EHR Guy
VistA is not an example of the typical open source application so let's not bring it to the table for this discussion.
CCHIT's step to support the FOSS realm is indeed laudable, Mark Leavitt has proven to be a nice guy, this is a genuine gesture which gives you (the open source guys) the opportunity to certify your Electronic Health Record (EHR) products. But this isn't the gateway to success since you may still have a long stretch to go.
Let me explain why:
Healthcare IT is extremely demanding and it requires discipline a discipline which can only be delivered by highly organized and structured entities.
Companies such as: GE Healthcare, HP, McKesson, MEDITECH, Philips, SIEMENS, and similar others have for many years devoted themselves to the development of highly reliable clinical applications and medical devices. Most of these aforementioned companies have strict product development methodologies and strategies that they have had to implement in order to meet with the ever increasing and strict requirements of the FDA for the verification and validation (V and V) of medical devices and related software.
Many may argue that for the software product development process they don't use the same guidelines as they do for the manufacturing of their medical devices, but knowing how these companies operate, and I have worked closely for and with them for many years, I am absolutely sure that they do.
Maybe the adventurism into the healthcare IT domain taking place by Google, Novell, and Sun Microsystems (soon to be part of Oracle), among many, and albeit this latter one at one point in time built very sophisticated medical image viewing workstations based on their SPARC technology, are probably giving you an over optimistic perception.
In my opinion these companies currently just don't have the culture to fit into this rigorous process. Undoubtedly, they are extremely successful organizations in their activities but just not in this one. You see, this is a different beast.
And maybe you do a great job at creating software, perfect software. But this is not the only piece of the puzzle since there is the rigid documentation process required for clinical product development. Only the documentation process will overwhelm your budget if not drain it completely.
The very laid back and lax nature of open source development is the antithesis of what is required to develop critical clinical applications.
The FDA has formed a working group to determine whether or not Electronic Health Records should be regulated and to what extent if such is the case. Let's say that they do decide to regulate them, and then this would be your demise in healthcare IT. The costs involved in meeting FDA requirements go beyond those that the most daring venture capitalists are willing to risk. Only companies with an infrastructure and logistics similar to those of GE Healthcare and SIEMENS can actually survive and strive in a scenario described here.
My recommendation to you, open source developers, is that along with the FOSS community members, you continue pouring your energies into your projects but don't expect to take the industry by storm. It just won't happen, sorry.
Stick with trying to overcome Microsoft Office some day in the remote future, maybe by 2021, or by creating a user friendly operating system that is not tailored "only for geeks", like Linux is. Did you know that almost 90% of the workstations currently used by clinicians are Microsoft technologies based? You see, open source is "only for geeks" and not for the real world, the real users.
And I am not referring to geeks in a derogatory way since I consider myself one as well. But I do have a professional maturity level to understand that I have to create solutions for real world users and not savvy information technology experts.
Once you break out of your silicon shell then let's sit down and talk seriously.
Thanks for reading!
The EHR Guy
Sunday, June 28, 2009
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
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
Subscribe to:
Posts (Atom)
