This recent article from Health Leaders media lists the top 6 ingredients to building and implementing an effective EHR. In short, they say:
- Realize that the EHR will not solve your problems.
- Identify EHR stakeholders and involve them in the implementation process.
- Keep it simple with as few systems as possible.
- Remember that communication is essential.
- Recognize that paper will never disappear completely.
- Keep usability in mind.
I had to smile at point 6 regarding usability. On the HIMSS discussion boards I follow, every few days someone starts a discussion about "What's the most important consideration regarding EHRs?", which inevitably starts a flame war over interoperability and which standards to follow.
And eventually, somewhere at the end of the heated debate, someone points out - "who cares what kind of interoperability you have if your system is not usable? HL7 v2, v3, CCD, CCR, Continua... does it really matter if the system doesn't meet your users' needs?"
So I smiled as I imagined the editor of the Health Leaders article looking through a draft of the top 5 considerations when implementing an EHR, and he had that same afterthought - "wait a second, we need a point #6 - usability!!"
Actually, the other 5 points all deal with usability and UCD (user-centered design) too, it's just a lot of people probably don't realize it. Point 2, for example, "Identifying and involving stakeholders" is a first step to uncovering user needs. Point 5, "Recognize that paper will never disappear completely" could be the result of interviews or user testing methodologies.
Don't get me wrong, it is great that the industry is slowly realizing the importance of usability, and that organizations like HIMSS are publishing whitepapers on EHR UI best practices. But usability isn't just a collection of best practices that can be summarized in a document.
It isn't just an afterthought to "keep in mind". It's an entire process, involving thorough communication and study.
Google Health is a website intended for patients to track their health online, including self-monitoring test results. Continua is a certification that proves your self-monitoring device is interoperable. So you would expect a Continua-certified device to interoperate directly with Google Health, right?
Unfortunately, it's not the case - Google Health supports a subset of the CCR standard, whereas Continua uses the new HL7 PHM standard.
But before you start to dwell in despair over the possibility that we'll never have 1 common document standard, there is still hope. When it comes to patient self-care tracking, Google Health really only stores and tracks a small number of fields, and mapping these fields to the PHMR standard is actually very straightforward (in fact, a skilled web developer could develop a .XLS converter in less than a day).
See our Continua to CCR to Google Health mapping below, an extension of the Google API documentation:
Unless you buy the Continua design guidelines document ($500 for non-members), understanding the standards the Continua certification is based on is not clear, even at a high level. With a bit of digging, I found this whitepaper gives a bit more detail.
The most interesting of all these choices is certainly the HL7 PHM standard. For one, to find out more about the requirements on the web, you really have to know where to look. Go to this HL7 repository and download the package entitled HL7 Implementation Guide for CDA Release 2: Personal Healthcare Monitoring Report, Release 1.
Second, PHM appears to have a large intersect with CDA and CCD. Logically, PHM, like CDA and CCD, may represent a lot of work to implement and be onerous for medical device creators to adhere to. A good start would be if there were a PHM.xsd - I haven't found one available yet.
In no other industry does the user experience play as important a role as in the health care industry. Products in a medical environment need to be durable, easy to sanitize, but most of all they need to be easy to read, understand, set, maintain, and calibrate within the environment they are used.
The environment is important to consider as there may be variations in light intensity, temperature, ambient noise, tactical sensory changes, and cognitive loads that must be accounted for during use of the product.
The methodolgy you choose to identify and design your medical device for the environment can be crucial to releasing a successful product. See our white paper - User Centered Design of Medical Devices: Managing Use Related Hazards
If you search for information on testing HIPAA compliant applications, youʼll find a number of overviews on HIPAA, but very little information on how to approach testing software to ensure that it will be HIPAA compliant.
Macadamianʼs QA Test Strategy includes HIPAA compliancy verification as an important part of its initial sanity testing and later full feature testing when we are testing and developing healthcare applications.
We decided to publish our test strategies to provide developers and software testers with a practical, hands-on guide to testing for HIPAA compliancy. We hope you find it useful, and please contact us with questions and comments.
In preparation for HIMSS10, I have been investigating the CPHIMS certification for Healthcare management professionals. How hard is it to pass the CPHIMS exam? How much weight and credibility does the CPHIMS certification carry? What does it bring to healthcare software development?
The program is still fairly new, and a number of managers I spoke with recently told me they were not sure yet what the importance of the certification would be in the industry going forward. To be fair, in addition to asking people who were unsure about the certification, I sought out the advice of professionals who had actually gone through the process.