June 2,2013


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.

May 28,2013

(Editor's note: This guest blog was written by Cindy Doyon, RHIA, vice president, coding and client audit services, Precyse.) As the Oct. 1, 2014, ICD-10 compliance deadline looms, many providers are readying their coders for the magnitude and pervasive...(read more)

May 26,2013


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.


Categories: All , News and Views

May 24,2013

(Editor's Note: This guest blog was written by Vicki J. Brown, director of HIM Solutions Marketing, Nuance Communications.) As we reflect on National Medical Transcription Week, May 19-25, 2013, I can't help but think about the waves of transition this...(read more)

May 21,2013

I’m sharing one of the slide deck which I used recently to introduce Product Management to few aspiring product managers.. Welcome your feedback & discussion on this. Product management shadzlog from Shadzlog
Source: Shadzlog
Categories: All , News and Views

May 20,2013


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.'

via cordis.europa.eu

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.

Thanks to ACM TechNews for the pointer to the CORDIS story.

Source: FutureHIT

May 18,2013


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.

Categories: All , News and Views

May 15,2013


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.

via technews.acm.org

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.

Source: FutureHIT

May 11,2013

(This is a preview of a talk that I am going to give next week at Healthcare::Refactored, with Karen Herzog) There are two definitions of the word “Hacker”. One is an original and authentic term that the geekdom uses with respect. This … Continued
Source: Fred Trotter

May 10,2013


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.

Categories: All , News and Views

Physicians Spooked by Failure StoriesA 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.


Stop Saving the NHS cover (small).jpgWell 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.

May 3,2013

(Editor's note: This guest blog was written by Julie A. Dooling, RHIA, AHIMA Director, HIM Practice Excellence.) People are powerless to control unexpected events. What we can control is our response. When an unexpected event occurs in healthcare, instincts...(read more)

April 19,2013


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:

  • When software is medical device,
  • What is software validation,
  • SOUP and legacy software,
  • Software risk assessment.

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.

Keep going!

Categories: All

Senators Say Meaningful Use Program Needs RebootingThis 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:

  • The success of the EHR incentives program should not be measured by the amount of money spent, yet every month CMS issues a report boasting how many billions of dollars have been paid in incentives. This is, of course, a proxy for EHR adoption and meaningful use attestations, but it says nothing about the impact on quality or cost of care—the motivation behind supporting EHR adoption.
  • The program is being propelled forward too quickly. It was the right move to delay Stage 2 for a year, but the requirements were set in stone long before a detailed evaluation could be made of the successes, challenges, and failures of Stage 1.
  • Program sustainability will be a challenge. The costs of participation are increasing for providers, given the added demands of Stage 2; for example, they will have to pay for interfaces to registries and HIEs and they will need to purchase a portal, if one is not provided by their EHR. As out-of-pocket costs rise, incentives decrease. This, combined with the challenges posed by the program moving too fast, will cause many physicians to abandon participation, which will threaten the program’s ability to deliver results.
  • There is no question that the proliferation of government programs with which physicians must contend has made compliance a challenge. The legislation is so complex and the requirements so cumbersome that they are diverting physicians’ attention from patient care.

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.

Privacy considerations don't necessarily need to be a barrier to the use of big data in healthcare and can be respected as long as a transparent framework is established and the onus for remedying data breaches is put on the collector rather than the subject, a privacy expert said. Emma Hossack,
Categories: All

April 18,2013

The OIG released an updated self-disclosure protocol this week, about ten months after putting out a call for comments on the old protocol. The new protocol imposes some new burdens on the disclosing entity, such as a shorter timeline for...

You should follow me on Twitter: @healthblawg

David Harlow
Source: HealthBlawg
HealthBlawg is moving its RSS feed. If you ever read HealthBlawg in a feedreader such as Google Reader (which, by the way, is being shut down by Google July 1, so it's time to pick a new feedreader and migrate...

You should follow me on Twitter: @healthblawg

David Harlow
Source: HealthBlawg
“This is the end of the beginning,” Department of Health and Ageing deputy secretary Paul Madden told the Big Data 2013 conference in Melbourne during an update on the implementation of the PCEHR. Mr Madden, also DoHA's chief information and knowledge officer, was in a buoyant mood and excited about the
Categories: All
Former minister Kim Carr has opened the Health Informatics Society of Australia’s inaugural Big Data conference with an impassioned speech about freeing up public data, urging the nation not to “squander” the “great compact between government and researchers”. “I have taken the view that this should be an area in which
Categories: All

April 17,2013

The Royal District Nursing Service (RDNS) has won the Outstanding ICT Innovation award in the Asia Pacific Eldercare Innovation Awards 2013 for its Healthy, Happy and at Home telehealth project. The project involves nurse-led video conferencing with RDNS clients
Categories: All
Monash University and its partners in the Telephone-Linked Care (TLC) Diabetes (http://www.tlcdiabetes.monash.org.au/) program are looking at ways the technology can be offered to the broader community following the publication of successful results from a randomised controlled trial. The TLC system is an interactive computer-assisted telephone system that has proven successful
Categories: All

April 15,2013

The American College of Physicians (ACP) Ethics, Professionalism, and Human Rights Committee, the ACP Council of Associates, and the Federation of State Medical Boards (FSMB) Special Committee on Ethics and Professionalism spent eighteen months developing a policy statement on online...

You should follow me on Twitter: @healthblawg

David Harlow
Source: HealthBlawg

April 13,2013


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?

Categories: All

April 12,2013


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.

New Risks Section

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.

When software appears in risks

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.
Software in Medical Devices - relationships between IEC 62304 and IEC 61010-1

On the IEC 62304 side

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:

  • Hazards arising from software is the most important criteria to apply IEC 62304,
  • IEC 60601-1 adds the notion of software complexity in its informative section:
    • If software is very simple, then IEC 62304 is not necessary,
    • If software is complex enough to design a software architecture, IEC 62304 becomes mandatory,
  • IEC 61010-1 requires a risk assessment process with:
    • Specific software hazards in Section 16,
    • General-purpose risk assessment in Section 17 (including software),
    • Thus making IEC 62304 relevant for instruments with a medical purpose.

Categories: All

April 11,2013

I'm quoted in the current issue of Medical Economics, on the subject of the Medicare PQRS: Physician Quality Reporting System. I'm not a big fan of PQRS, since it rewards reporting of process measures, not outcomes, and the amounts at...

You should follow me on Twitter: @healthblawg

David Harlow
Source: HealthBlawg

April 6,2013



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.


Categories: All

April 5,2013


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.

Medical Devices - IEC 60601-1 and IEC 62304

You probably have already seen this diagram:
Software in Medical Devices - relationships between IEC 62304 and IEC 60601-1
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:

  • IEC 62304 is all about software lifecycle,
  • Section 14 of IEC 60601-1 3rd edition is about Programmable Electronic Medical Systems (PEMS).[1]
Section H of IEC 60601-1

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.
Software in Medical Devices - PEMS decomposition into hardware and software subsystems
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.

Software architecture: the big difference

If it is necessary to split software into software elements and software units, to show how:

  1. system requirements are translated in software requirements,
  2. risks mitigation actions assigned to software, are translated in software requirements,
  3. software requirements are allocated to software elements or software units,
  4. software interfaces are implemented by inner software elements,
  5. unit tests and software (not system) integration tests are necessary to demonstrate that:
    1. software units and elements work unitary,
    2. software requirements (including risks mitigations) are fulfilled,
    3. software units and elements work integrated together,
    4. software interfaces work with the surrounding system,

Then IEC 62304 is mandatory.

On the contrary, if it is only necessary to address software as a black box, to show how:

  1. system requirements are translated in software requirements,
  2. risks mitigation actions assigned to software, are translated in software requirements,
  3. software interfaces are implemented,
  4. tests of the software entity as a black box demonstrate that software requirements (including risks mitigations) are fulfilled,

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.

Some examples


Quick answer: apply IEC 60601-1 only.
Although hardware description languages can be seen as source code prone to error, they're not software.

FPGA, ASICS, plus a tiny C (or other language) program

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.

System on a Chip (SoC), Micro-controllers and C (or else) programs

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":

  • Is it relevant to split the software component into smaller components to show how requirements are allocated?
  • Is it relevant to split the software component into smaller components to show how risks mitigation actions are allocated?
  • Is it relevant to split the software component into smaller components to show how requirements about software interfaces are allocated?

Then IEC 62304 is probably yours.

Everything of higher complexity

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.

To go further

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.


[1] Note: Section 14 of IEC 60601-1 3rd edition is the former IEC 60601-1-4 collateral standard of IEC 60601-1 2nd edition.

Categories: All

April 4,2013

Financial Burden of Medical Spending by State and the Implications of the 2014 Mediciaid Expansions is the latest report from the Affordable Care Act implementation monitoring and tracking initiative funded by the Robert Wood Johnson Foundation. (Direct link to PDF...

You should follow me on Twitter: @healthblawg

David Harlow
Source: HealthBlawg

March 29,2013


As discussed in the previous posts, the nodes use the CP Split’s patented process in template models to:

  1. Create Content Configurations in a Content File Production Grid (CFP) Grid using spreadsheet and third-party applications
  2. Transfer these Content Configurations into a Content File for storage and distribution
  3. Transfer the Content Configurations from the Content File into a Content File Consumption (CFC) Grid where (a) formatting instructions from spreadsheet and third-party applications present reports by rendering each content element based on its location within the spreadsheet and (b) the content elements may also be sent to populate databases.

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:

  • Database report writers and the CP Split differ in the way they retrieve the content for a report:
    • With a database report writer, the end user/client (i.e., a Subscriber node) must query a database, and indicate how the returned data are to be analyzed and formatted. The user selects predefined report formats or creates new ones.
    • With the CP Split, the end user does not query a database when generating a report. Instead, a Publisher node does any required database querying, as well as any required data analyses and other non-formatting manipulations of the data returned from the queries. It then organizes the resulting content into Content Configurations in its CFP Grid. The framework (grid-based structure) for organizing the content into configurations are created when the Publisher and Subscriber/Presenter Templates are developed and assure that the Content Configurations in the Publisher's CFP Grid correspond to their Subscribers’ CFC Grids (the next post discusses best practices for building the Content Configurations). Like the database reports, the queries, analytics, and formats may be predefined for its Subscribers, or new ones may be created via instructions from Subscriber nodes.
  • Once the data queries and analytics are done, the resulting content must be formatted for report presentation. Types of report formats include columnar, crosstab, form, label, and OLAP/pivot table, and their views may include graphs/charts, lists, tables, text boxes, and more. Database report writers and the CP Split differ in the way they manage and format content for presentation:
    • Database report writers render queried content through instructions that format content elements based on their fields (and possibly other attributes). Reports can be published to a variety of file formats for distribution, including XML, PDF, HTML, RTF, Word, Excel, text, and more.
    • With the CP Split, the Publisher node places the Content Configurations from the CFP Grid to Content Files for storage and transmission, and then sends the files to its Subscriber nodes. Upon receipt, each Subscriber node places the Content Configurations from the Content File into its CFC Grid and formats the content elements for presentation through formatting instructions applied to particular content elements based on their cell locations in the CFC Grid.

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:

  • Content from diverse sources can be integrated and stored in a uniform structure for use across multiple platforms and applications, which provides a simple, transparent (human readable), and auditable interoperable architecture

  • Different audiences can receive different portions of the content and have it rendered in particular ways based on what they need for personalized reports

  • Content can be integrated from different sources easily for distributing composite reports

  • Portions of a Content File can be sent to different data stores (e.g., to populate a data warehouse)

  • Content can be manipulated (e.g., analyzed, adjusted, transformed) without costly conversion from appearance-based text representations

  • Content can be repurposed quickly and easily for different presentation media

  • Content is transported in smaller files that consume less bandwidth because they do not contain formatting instructions, markup tags, or code

  • Exceptional speed and efficiency is achieved when dealing with numbers and computations, and when generating charts and graphs, because the Content Configurations can be distributed in their proper "serialized" order, which enables rendering engines to generate charts and graphs more quickly and easily

  • Different models with different formulas can be used to calculate the same set of data from a Content File, and sets of data from Content Files can be modified on-the-fly to accommodate different computational models (e.g., when doing real-time "what-if" scenarios, when slicing & dicing aggregated data) -- all without complex or time-consuming pre-processing, e.g., there is no need for database queries, for XML parsing and XSLT transformations, and for online analytic processing (OLAP) by the client.

  • Changes can be made to the data in a model and those changes distributed as necessary, which is important when (a) editing out mistakes or updating sets of data, (b) creating and analyzing what-if scenarios, and (c) computing the same set of data using several analytic models because these activities may require somewhat different data.

  • Data can be added to a model and those additions distributed when necessary, which is important in collaborative situations when (a) different people must input data to complete a data set, (b) automated (unmanned) nodes supply data, and (c) several analytic models are used to compute the same set of data, and certain models require additional data

  • Portions of a data set can be restricted from being accessed by particular models, which is important when different users with different roles require only a portion of a data set; it helps assure people get to see only the data they need to minimize information overload and protect data from being viewed by unauthorized persons

  • Content can be "scrambled" for a unique form of security that is forever immune to brute force attacks (see MultiCryption).

Follow Us: