It's years ago, but I still remember the reception I received when during my first large-scale NHS IT implementation I suggested that doctors might like to record outcome information. I can still recall the smell of my singed fingertips. Until recently, the NHS has been obsessed with recording process data fitting an organization with its roots still in the mid-twentieth century.
I have this guy I hired about a year ago named Max. Max is awesome not only because of the work that he does on our marketing team, but also for things like his family (his mom is the super-woman Judy whom I love), his bow-ties, his ability to handle strange travel delays and his stories and wise sayings. In honor of Max, and to make up for, in some small way, that his whole family is in London and he had to stay home because he has a JOB, this is a blog post about one of those bits of wisdom. Somehow his single sentences hold clarity and meaning in a way that only Max can convey. Why is it number 501? Because it can’t be his first (it's way to insightful) and I know it is one of many.
Recently we were working with a client and we had trouble getting them to be in the present. There was all this talk and focus around what their system USED to do. No one wanted to think about what it was STILL doing or needed to do in the future. No one was able to see that the goals of the retiring system were different now that it has been replaced by Epic. It was quite frustrating.
Then Max says:
it's like looking in the rear view mirror to drive forward
And that is EXACTLY what it was. When you put it like that, everyone lights up because THEY GET IT. While looking in the rear view adds value, and lets you reflect on where you have been (which is important), you CANNOT look in the rear view to drive forward. You have to be looking at the front window in order to move on and get to where you eventually need to be. You HAVE to face the reality of the road in front of you. You have to remember that you have an ultimate destination and place you need to be. Everyone needs to put away the map of what the old system used to do and get out the Archive Strategy Map. It can hold some of the same sights, back roads, and detours of the original map, but it needs to be one that is driving your archive strategy forward.
Portuguese and Spanish researchers in the field of social robotics are working on the use of robots to interact with children who are hospitalized for the treatment of cancer, thereby providing emotional support.
The researchers are keen to take robots out of the laboratory and place them in a real environment. Until now, most of the research on social robotics has taken place in very controlled environments. As Professor Salichs from UC3M points out, 'The introduction of a group of autonomous social robots into surroundings with these characteristics is something new, and we hope that the project will help us to advance in the development of robots that are able to relate to people in complex situations and scenarios.'
Another cause for guarded optimism about health care robotics? My hope is that it will augment the efforts of often overworked staff and allow them to better prioritize the focus of their precious attention and energy. In addition to their potential social value, robots could act as in situ surveillance devices to watch for nascent or emergent health crises. My fear is that they will be used as justification for cutting costs through staff reductions, as self-checkout lanes have done in supermarkets.
If you are reading my blog, you know what my company does. Being the guys that are handling the “go dead” of an application, we are dealing with what is, agreeably, the most difficult and disappointing time for the vendor being retired.
I get it. The customers have passed you over. Putting you out to pasture. Picked someone younger, fresher, nicer, better suited to their business. Your revenues are impacted. Your market position is threatened. It makes a statement about where you are in your product lifecycle.
What I DON’T get is the attitude that comes along with it. Most HIT vendors today sell more than one product for more than one solution. Why would you treat a customer badly just because they are choosing to de-install ONE of your products at their work site? Raising their support fees? Refusing to help them? NOT GIVING THEM THEIR DATA? I just don’t get it. Its like you are 12 years old and breaking up with your first girlfriend.
Do you actually think this is the right way to treat these customers? That this WON’T come back to haunt you later? Do you know how much these customers talk to each other? Have you READ HISTalk?
Think about the bigger picture here. If you are a vendor that plans to stay in business, you had better treat each and every customer or potential customer like you would want to be treated. The good old Golden Rule applies here.
The decisions have been made. You were or were not asked to present or even attend the party. Suck it up. Do the right thing. Help your customer transition to the other vendor in a positive and supportive way. Make their data accessible and understandable. Help them through technical issues. Use the opportunity to find out what you can do differently next time to be the vendor that is chosen. MAYBE, just maybe, you will get a chance to present or sell something to this customer again. And MAYBE, just maybe, they will remember the positive and professional way you handled the prior system “end of life” and take that into consideration.
Because I can promise you this – the way some of these vendors are acting – they won’t even get in the parking lot, much less a ticket to the dance, even if they are the very best at what they do or sell. They are not only burning those bridges, they are nuking them.
Robot Aids in Therapy for Autistic Children
Wall Street Journal (05/01/13) Shirley S. Wang
University of Notre Dame researchers will present study findings at the annual conference of the International Society for Autism Research showing promise in the use of robots for teaching social skills to autistic children. The study, involving 19 autistic children, is believed to be the largest trial to date using robots in this way. The children interacted with a two-foot-tall robot therapist that was programmed to ask novel questions and engage children in conversation. The study participants showed greater conversational improvement with the robot than with a human therapist alone, and parents reported more significant improvement at home as well. Children interacted in six sessions with the robot as well as with a human therapist, who provided instruction on specific skills when interacting with the robot, such as making eye contact or taking turns talking. Simplified social interactions with a robot might be beneficial to children with autism, who tend to be very interested in technology but find complex social interactions challenging. The researchers hope the children will carry over the social skills to interactions with people as well, rather than just interacting with the robot.
Monday's ACM TechNews produced this very brief but tantalizing summary of a Wall Street Journal article.
This is one of those stories that leave me very ambivalent. In some ways, my automatic reaction to our collective desire to depend more on automation in direct patient care is fear. I am afraid we are going to abandon our elderly and otherwise hopelessly disabled kin to the unfeeling arms of robots, androids, whatever. This will spare us the feelings aroused by an out-of-control psychotic spouse, an incontinent and demented parent, or a profoundly developmentally disabled child, when we must intervene and our interventions are resisted, not appreciated, or insufficiently effective.
With this story, I see the situation is not so simple. Autistic children have difficulty relating to humans with whom they are intimately involved, and their difficulties are often reflected in others' responses to them. Machines are insensitive by nature, and can be programmed to reward positive behavior and ignore the negatives. This may be a situation, as the investigators assert, where robotic intervention is not only appropriate as an alternative but can even improve the patient's situation holistically.
I don't have a WSJ subscription so I can't follow the link ACM provides to the full story, and I don't have time at the moment to poke around on the Web for alternate sources of information about this research project. I would like to learn more, and will try to pursue this when I have more time.
1. I am loyal to a fault. You want me on your side. Even if you are wrong.
2. Don’t Wrong Me. That loyalty thing being said, don’t do me wrong. You don’t want to deal with that.
3. I take it to heart. All of it. I have a tremendous sense of right and wrong, and if I have Wronged You, I am devastated. I will do anything to make it up to you. If I am Right, you better be ready to convince me why you might be too.
4. That being said, don’t take advantage. See #2.
5. You can trust me. But be able to handle the truth, because I am going to give it to you.
6. I love my dog. She is a Cavalier king Charles Spaniel and she is fat and I love her.
7. I love my kids. More than my dog, most of the time.
8. I love life and adventure and change and the next thing. I am always looking to learn more, do more, be better. And there is nothing wrong with that.
9. I worry. All the time. You can stop worrying, I have you covered.
10. I love Prosecco.
A significant portion of the physician market has still not adopted an EHR, despite the lure of government incentives and the fear of the penalties looming on the horizon. The stock prices of most publicly traded ambulatory EHR companies are down sharply, as sales are lower and earnings projections have not been met throughout the industry. How can this be, when the EHR incentive program has successfully increased EHR adoption and was expected to be such a boon to EHR vendors?
I know why, and it is not—as commonly thought—because the initial EHR-adoption rush fostered by the incentives has ended. Rather, it is because of rampant physician dissatisfaction that has reached a more-than-palpable level. I have noticed a dramatic change in the tenor of conversations with physicians, most recently at professional society conferences, where physicians who have not yet purchased an EHR are frozen in their tracks. They are worried by the horror stories they hear from colleagues—even from those who have succeeded at meaningful use—because many of those physicians continue to experience major workflow disruptions and significant productivity losses from which they see no potential to rebound. Recent surveys point to the number of physicians looking to replace their EHRs, and based on my company’s experience in the replacement market, that number is growing. A recent article summarized the findings of a large study on EHR satisfaction and presented an insightful analysis of the potential reasons for these disappointing results.
This heightened level of frustration has resulted from frantic, insufficiently researched EHR purchase decisions by physicians and rushed, inadequate implementations conducted by resource-strapped vendors. Massive EHR failures are exactly what I predicted in an EMR Straight Talk post on the unintended consequences of the EHR incentive program in February 2010:
After an initial peak in implementations, long-term EHR adoption will slow—particularly among high-performance specialists—and the current failure rate will escalate. Many factors will contribute to this: (1) Some physicians will rush into EHR purchases without conducting proper due diligence. (2) Products that were overly complex and did not work in busy specialists’ practices in the past will surely not succeed now, particularly since these same products must now be used in an even more structured and demanding way. (3) Sorely needed implementation and training will be provided by inexperienced and rushed implementation teams, further reducing the likelihood of success with providers, many of whom are less technologically savvy than the early adopters. (4) Where there was never a convincing economic justification in the past, the addition of data-collection requirements will further lessen the economic feasibility of traditional, point-and-click EHRs. . . . The result? The high failure rate will leave physicians “holding the bag” after investing large sums of money, failing to earn the anticipated incentives, and owning a system that doesn’t meet their needs.
So, what can physicians do to avoid falling victim to EHR failure, and to instead reap the benefits of successful EHR adoption—government incentives and practice productivity? I have written extensively about the importance of physicians doing thorough and objective reference checking—that advice is as valid now as when I first wrote about it, and perhaps is even more critical today. For guidance on how to conduct a thorough and fair evaluation of an EHR, read EMR Selection: How to Uncover the Truth or 100% EHR Success – A Clinical Approach.
Well I have done it. My book Stop Saving the NHS and Start Reinventing it has been published in Kindle and paperback. It's aimed at NHS leaders and managers, but will probably interest anyone who is interested in the shape of 21st century healthcare.
The FAQ related to the Implementation of EN 62304 with respect to MDD 93/42/EEC was released by Team NB, the association of Notified Bodies.
You'll find in this FAQ many hot subjects I already mentioned in this blog:
This FAQ shows that the state-of-the-art is still evolving. But I think that it has reached a point of consistency and stability. Many questions in the FAQ hadn't clear answers one or two years back.
This week, six senators released a white paper, Reboot: Re-examining the Strategies Needed to Successfully Adopt Health IT, that argues that there is no evidence that the $32 billion in taxpayers’ money being spent on meaningful use is returning the results it was designed to deliver. Although it would be naïve to discount the political motivation of the authors—all six being Republicans—they raise some of the same criticisms and concerns that I have written about in the past. They also make some claims that I feel compelled to dispute.
The senators have it right on these issues:
I vociferously disagree, however, with the senators’ criticism regarding interoperability. Of course, we are not there yet—and clearly they are frustrated by that fact—but progress is underway toward that universally supported goal. Contrary to their claim that there are no meaningful use measures that require interoperability, there are in fact several in Stage 2, including the requirement that physicians electronically send a patient care summary for 10% of patients transitioned to the care of another physician or provider. This exchange is facilitated by the fact that all certified EHRs must communicate using the same formats.
Not only does interoperability relate to provider-to-provider communication, but it also allows for easy integration between products of different vendors, without requiring additional programming. I was recently speaking with another HIT vendor about a potential partnership arrangement, and we both talked the same language—XDR Direct for transport protocol and CCDA or HL7 in terms of content. This conversation would neither have been possible, nor would we be able to create a tight, simple interface between our products, were it not for the standards promulgated by the EHR incentive program. This kind of interoperability will ultimately be better for physicians and for their patients. The EHRA (EHR vendor association of HIMSS) hit the nail on the head: the appropriate role for government is to set the standards, but then the vendors should be free to innovate and let the market take over from there.
I am writing a critique of a health information system for an academic essay. I am thinking about Cerner software. Any suggestions on where to get information on operational challenges on the deployment of Cerner in other countries?
In the previous post, we've seen when it's mandatory to be compliant both with IEC 60601-1 and IEC 62304, and when IEC 60601-1 alone is enough.
But some manufacturers don't apply IEC 60601-1, mainly because their devices are not in contact with the patient or cannot be qualified are medical devices. We find in these categories in-vitro diagnosis instruments and laboratory instruments.
These instruments usually fall in the scope of IEC 61010-1. Let's see now the relationship between IEC 61010-1 and IEC 62304.
IEC 61010-1 3rd edition was published in 2010. We're still in the transition between the 2nd and the 3rd edition. IEC 61010-1 3rd edition will become mandatory in Europe by october 2013.
A new section was added to the 3rd edition: Section 17 Risk Assessment, along with the informative Annex H. No risk management method is mandatory to address risks, but ISO 14971 is quoted in Annex H.
That makes the IEC 61010-1 closer to what medical devices manufacturers know. While ISO 14971 is mandatory for manufacturers of IVD instruments, it is fairly likely that manufacturers of laboratory instruments for medical purpose address risks with ISO 14971.
But that doesn't tell how to manage software.
Section 16 of the standard, titled Hazards resulting from application, requires to manage risks arising from software-based controls or ergonomics. And Section 17 requires to manage any other risks not addressed in the rest of the standard (including software, by extension). Here we are!
What is the standard that requires to manage software risks with ISO 14971, and contains other specific requirements to manage risks of software fro medical purpose?
IEC 62304, of course!
So, section 16 and 17 of IEC 61010-1 3rd edition advocate for IEC 62304. Yet, it is applied on a voluntary basis by manufacturers which instruments are for medical purpose, other than MD and IVD.
The diagram below represents the relationships between IEC 61010-1 and IEC 62304, inspired form the diagram shown in the previous post.
IEC 62304 is more straightforward about IEC 61010-1. In Annex C, the sub-clause C.5 makes it clear about the relationship between both standards.
It states that if IVD instruments contain software that can lead to a HAZARD, then IEC 62304 must be taken into account. A flowchart is given that helps manufacturers deciding wether IEC 62304 is required or not.
Once again, this is an informative section of IEC 62304. Thus, it is applied by IVD and laboratory instruments manufacturers on a voluntary basis. It provides "food for thought", at the very least.
The relationship between IEC 60601-1 and IEC 62304, on the one hand, and IEC 61010-1 and IEC 62304, on the other hand, is not based on the same criteria:
Denials are a big problem faced by both healthcare facilities and individual physicians. Even though they take concerted efforts on medical claims processing, claims do get denied by the payer for several reasons. Claims can be re-sent to the insurance company but only on learning the status of the denied medical claims. Till recently, physicians and healthcare practices had only the option of making calls to learn for what reason their claims got denied. However, this situation changed with recent technological enhancements in the internet and medical insurance billing domain. Now, checking the status of the denied claims is just a few clicks away! Let’s do a detailed analysis on both traditional and modern ways,
Traditional Method: As discussed earlier, physician practices and healthcare facilities made calls to insurance companies to learn the status of their rejected claims. Calls can be made only during US business hours and some of them might consume a lot of time to reach the right person in charge. However, one can still enjoy the benefits of this traditional method by disregarding the above mentioned facts. Individual physician practices and healthcare facilities get an elaborated explanation on their denied medical billing claims through the calls. It highly helps them in performing their medical claims processing perfectly next time.
Modern Method: In recent times, most insurance companies maintain their own websites in which they update denied claims and their status. Therefore, a physician or healthcare facility registered with the particular insurance payer’s website can login to their account and view the status easily. It takes only a few minutes to check, however if the reason stated is not clear, then the physician has to take up the traditional of calling to ascertain the exact reasons. Once the clarification is made through call, further steps in medical claims processing can be taken.
Thus, the traditional way of making calls and the modern way of checking on the web to learn the status of denied claims go hand in hand. Using both methods can help physicians and healthcare facilities get a better understanding on where they went wrong in the medical insurance billing process. For exceptional denial management, outsourcing a part of medical claims processing to an offshore company like e-Care India that does a ‘full-court press’ will be a great idea.Tweet
Manufacturers of medical devices often ask themselves the obvious question:
Is it mandatory to be compliant both with IEC 60601-1 and IEC 62304?
Similarly, manufacturers of in vitro diagnosis devices ask themselves:
Are my devices in the scope of IEC 62304?
Obviously, medical devices (MD) with electric or electronic components are in the scope of IEC 60601-1. And in-vitro diagnosis devices (IVD) with electric or electronic components are in the scope of IEC 61010-1.
Do MD and IVD that embed software, fall in the scope of IEC 62304?
This is not so obvious.
You probably have already seen this diagram:
It comes from annex C.1 of IEC 62304 standard. It aims at explaining the relationships between IEC 62304, software design, and other standards.
It tells that both IEC 60601-1 and IEC 62304 influence the design of software medical devices.
For sure, both standards are about software design:
Having a quick look at section 14 of IEC 60601-1, you will see that it's pretty much like IEC 62304. It contains sub-sections about software design, risk management, problems resolutions, and so on. But, at the same time, it references IEC 62304 for software development.
So, when is it enough to be compliant with IEC 60601-1 and when is IEC 62304 mandatory?
There are two interesting diagrams in IEC 60601-1: Figures H.1 and H.2 in annex H (an informative annex), which are, uh, very informative.
They more or less tell that IEC 60601-1 "sees" software as black boxes (components in Annex H) that are designed and integrated during the PEMS development lifecycle.
If it is necessary to split software into software elements and software units, to show how:
Then IEC 62304 is mandatory.
On the contrary, if it is only necessary to address software as a black box, to show how:
Then IEC 62304 shouldn't be mandatory and it should be possible to apply IEC 60601-1 standard alone.
So, the big difference between IEC 60601-1 and IEC 62304 is the work of software (not system) architectural design and software (not system) integration.
IEC 62304 ensures that this work is consistent by reviews and traceability between requirements, risks mitigation actions and tests.
If you have both standards, have a look at Figure C.2 of IEC 62304 and compare it to Figure H.2 of IEC 60601-1 to see the difference.
Quick answer: apply IEC 60601-1 only.
Although hardware description languages can be seen as source code prone to error, they're not software.
Quick answer: apply IEC 60601-1 only.
There's possibly a tiny C program (or another language) limited to a small source file, running on the hardware. Both elements (hardware + software) can be seen as a black box. They don't require software architectural design.
There can be a phase of tests of hardware alone, followed by unitary tests of hardware + software. But tests of software + hardware integrated (seen as a black box) are enough to demonstrate that requirements are fulfilled by the component.
Quick answer: apply IEC 60601-1 if program is tiny enough, otherwise apply IEC 62304.
If hardware is big enough to have a program running on it, and if the source code of the program is more that one source file, then we have a borderline case.
It's up to the software and hardware designers to decide if IEC 62304 is applicable or not. It depends, once again, on the complexity of software. To give a help, if the answer to one of these questions is "Yes":
Then IEC 62304 is probably yours.
Quick answer: apply IEC 62304.
If the answer to one of the above questions is frankly yes, if there are dozens of software requirements, if your software requires more than one person to design it, or if your thumb tells you to do so (you'd rather need experience), then IEC 62304 is yours.
Deciding whether or not it is necessary to apply IEC 62304 + IEC 60601-1 or IEC 60601-1 alone has a lot of consequences on the amount of work to do. IEC 62304 requires many processes and is rather time-consuming.
If you're still doubtful and want to sell in the US, read also the guidances on software made by the FDA to see if what they recommend is relevant for your case. I gathered the links on these guidances in my essential list of guidances for software medical devices. At top priority, see on this page the link to the guidance about General Principles of Software Validation.
In the next article, we'll ask the same question about IVD, with IEC 61010-1 and IEC 62304.
 Note: Section 14 of IEC 60601-1 3rd edition is the former IEC 60601-1-4 collateral standard of IEC 60601-1 2nd edition.
As discussed in the previous posts, the nodes use the CP Split’s patented process in template models to:
This process differentiates the CP Split from all other technologies used for the distribution and presentation of reports. Following is a discussion of these differences and the benefits of using the CP Split technology.
How Does the CP Split Differ from Database Report Writers?
The CP Split technology differs from database report writers in the following operations:
Compared to database report writers, the CP Split has distinct advantages when disseminating interactive reports containing numeric values and related visualizations (e.g., charts/graphs, etc.). This is because the CP Split technology keeps the numeric content "live" – i.e., the numbers are not embedded in markup tags or converted to text – so they are ready for reuse immediately. This means there is no need to re-entry the data, use screen scrapers, or do time-consuming data parsing and transformations when using the CP Split. Furthermore, the CP Split enables content to be transmitted in its most efficient form, i.e., in delimited formats (such as in CSV files) that contain no formatting instructions, markup tags, or programming code.
How Does the CP Split Differ from Spreadsheet Reports?
To understand the CP Split more fully, it is necessary to compare it to technologies beyond database report writers.
For example, it is possible to distribute entire spreadsheet workbooks filled with the content, formatting instructions and macros. This is a very inefficient approach because every time the content is updated or used by a different model, new workbooks must be distributed, which can be very large (many megabytes). This approach also makes it difficult to track changes made to the content or models over time - for auditing purposes for example - since multiple version of the workbooks must be stored, which can require complex versioning controls.
A more sensible and elegant method for delivering report updates is to use the CP Split to distribute the content, and only the content, in delimited text Content Files. These files are a tiny fraction of the size of entire workbooks because they do not contain formatting instructions, code, or markup tags. In addition, they provide easy auditing (through change management methods) and file management (by using ID numbers to maintain the proper association between Content Files and the template files that produce and consume them). The workbooks containing the models are only redistributed if the models represented in the templates changes, which may me necessary, for example, if the schema of the source data changes.
Benefits of the CP Split Technology
The benefits of this unique approach are realized when content is shared between nodes using different template models to generate different reports, or between different nodes with the same template model to generate the same report.
The CP Split technology, therefore, offers this unique set of benefits: