Shahid's healthcare IT, EMR, EHR, PHR, medical content, and document managment advisory service. Enjoy.

I had the privilege of working with Dr. Peter Levin as an outside technology strategy adviser while he was the Chief Technology Officer (CTO) of Veterans Affairs during the first Obama Administration. Peter’s a hard-charging, fast-moving, take-no-prisoners style senior technical executive; he was an entrepreneur, professor, and engineer long before he came into government so it was no surprise that he was able to accomplish a great deal during his tenure as the CTO of VA. Two of his most enduring accomplishments that affect the healthcare world writ large are his inaugural deployment of the Blue Button at the VA and helping spin out the VistA EHR source code into OSEHRA. He’s too modest to say it himself but I like to refer to him as the “father of the Blue Button” because I don’t think it would have taken off the way it did without his design leadership and his ability to knock heads together (including mine) both in and outside the VA to make it happen. Recently I asked him why he thought, beyond the obvious reasons of high value to veterans and other patients, that Blue Button took as fast as it did. Here’s what Peter had to say:

One of my favorite books is “Too Big to Know”, by Harvard University’s David Weinberger.  If you have a chance, jump to page 145, under the heading “when scientists disagree with scientists”, which is a brilliant exposition on the enormous technical impact and societal (yes, I mean everybody’s) benefit of a very simple concept called “the namespace”.

While Veterans Affairs was struggling with the nuances of the implementation of the Blue Button personal health record, and while the VA and the Pentagon are wrestling the Health Data Dictionary to the ground, we lived – and lived through – the hell of multiple rigid conventions described in Weinberger’s book.

The rock soup of medical databases is born of three bitter ingredients:  first, the natural human tendency, especially among scientists and technologists, and fully bloomed in the healthcare industry, to a) believe you’re right at all times and b) to defend your turf at all costs against all comers, including those just meandering by, with no intention of spending the night.

Second, the “standards bodies” were more corporeal than standard.  In contrast to, say, the world of semiconductor manufacturing (which created a multi-hundred billion dollar industry based on standard lithography techniques) and electric power distribution (the plug-and-socket distribution system that has worked so well) to name just two of my many favorites, there is scant little agreement between hospitals, between vendors, and between systems about how to get medical data from one place to another.  Still.  Today.  And let’s save for another time about what we’re doing – and not doing – to keep the digital pipes clean of cybersnoops and other digital detritus.

Finally, we had not heard of, and were a little slow to embrace, the concept of a namespace.  This crazy simple idea is the Shakespearean notion – sorry, there’s no other way to say it – that we do not need to agree on the names of things to agree on what they are.  Weinberger, for example, quotes John Wilbanks, formerly head of science at Creative Commons, in a gentle explanation that I love to share: “There may be fifty or sixty names referring to any particular gene.  A database of yeast genes has a lot in common with a database of fish genes, but they were written by different people who gave them different names.  If you want to retrieve everything we know about a gene, you can’t . . . unless someone tells the computer that all those different labels refer to the same thing”.

Exactly.  Like what we mean by first name, last name, place, medicine, allergy, and problem.  Regardless of how you code yours and I code mine.  A rose is a rose by any other name.

In fact, it is a rose in all languages, and we should quit wasting time, money, and lives arguing about it.  To quote Weinberger again, “[n]amespaces enable people to disagree about how to classify and name things, while allowing computer programs to pull information together from both of them, so long as the computer knows how to map names from one namespace to another”.  Now, I do not mean to trivialize how easy it is to do that.  But it’s not rocket science either.  We just have to sit down and get started.

My good friend Roger Baker is fond of saying, “there’s nothing that wins an argument quite like customer facing software”; Levin’s corollary is “delivered on time and below budget”.  It’s why ideas like email, lithography, and the ubiquitous household socket and, yes, Blue Button took off:  we spent our time figuring out how to connect the protocols and databases to each other, and saved our shekels for applications – for instance computer chips and kitchen toasters – not make-believe standards that everybody wanted but nobody had.

{ 0 comments }

I first started using and mentoring developers on agile software development techniques like eXtreme Programming (XP) and Scrum over a decade ago. Often called “lightweight” methodologies, agile software development lifecycles have been generally misunderstood as lacking enough rigor and sophistication to be used in safety-critical systems. Many have erroneously assumed that Agile, Scrum, and related methodologies can’t really be implemented in risk-focused “important” industries like medical devices because they believe only classic waterfall will be accepted by the FDA.

Recently I ran across a great presentation by the folks at Pathfinder Software entitled “Agile Development for FDA Regulated Medical Software.” Pathfinder’s engineers help explain why the FDA doesn’t know or really care about what software methodology you use as long as you ensure that the output of your development approach results in high quality, safe, reliable software. The explanation that Michael and Tavi from Pathfinder gave about “formal” versus “casual” is quite effective and it reminded me about how often I’ve had to give the same lecture. I’ve been involved in the development of Class I/II/III devices since 1995 and I’ve had to clarify confusion about the use of agile and non-waterfall software development methodologies in almost all of my projects. The confusion has only increased with the introduction of MDDS and the proliferation of mHealth and modern mobile software performing roles traditionally performed by dedicated medical devices.

The FDA’s 21 CFR Part 820 Quality System Regulations (QSR) and the numerous other regulations that derive from it (in both the USA and other countries that follow the FDA) does dictate quite a bit but detailed software development approaches are neither described nor prescribed in the QSR. Waterfall, one of the original plan-driven methodologies, became the standard not because the FDA prescribed it but because that was the norm in the latter half of the 20^th century when developing extensible software was expensive and time consuming. It was a time when hardware and software were tied together and programming languages, frameworks, components, and platforms offered little forgiveness when requirements changed. This was world in which everything was custom – from purpose-built operating systems written for specific devices as well all other software components needed by a medical device. Back then it was believed that unless you wrote everything yourself you couldn’t test and depend on the code.

Much of that changed in the 90’s and then upended even further in the early part of the 21^st century; we should no longer weighed down by the baggage of the past.These days even our hardware is agile and extensible, real-time operating systems are plentiful, software platforms are malleable, mHealth is well established, and programming languages are sophisticated so we need to be open to reconsidering our development approaches, especially risk-based agile.

Why should we use “risk-based” agile? Because not every single line of code in software can or should be treated equally – some parts of our medical device software can kill people, many parts merely annoy people, but most other parts simply aren’t worth the same attention as the safety-critical components. When you treat every line of code the same (as is often true in a plan-driven approach) and you have a finite amount of resources and time you end up with lower quality software and less reliable medical devices. It’s not fair to blame the FDA for our own bad practices.

Our focus in safety-critical systems is high reliability with a short time to market and excellent functionality that meets ever increasing sophistication of design. In an age when even NASA uses agile techniques to get spacecraft reliably into orbits of planets millions of miles from earth, we need to recognize that agile has a place in medical device and FDA regulated environments.

{ 0 comments }

I’ve been invited to give a keynote talk at the Tenth Annual Healthcare Unbound Conference taking place in Denver on July 11-12. Healthcare Unbound is the “granddaddy” of recent Health 2.0, Connected Health, and similar Health Tech conferences. What I love about this specific conference, which I’ve only spoken a few times, is that for a decade now it’s focused on patient engagement, consumer-centric health, and connected health well before it was sexy and fashionable.

My talk will be called “Getting beyond the hype of disruption in healthcare and focusing on actionable innovation” because I think there’s more B.S. going on these days about disruption in healthcare than actual disruptions. I’ll be trying to answer the question of what’s really needed for healthcare technology innovation in a value- and outcomes-driven model.

There’s a ton of hype surrounding disruptive technology innovation in healthcare but nothing is truly making a dent in the healthcare industry the same way as disruptions have benefited  other industries like retail, travel, and financial. The slow but sure march from Fee For Service Based Care to Outcomes Driven Care has certainly started but it’s neither fast enough nor substantial enough to bend the cost curve or improve value to patients in the short term. Join me at the conference as I  talks about how we can get beyond the hype by focusing on actionable innovation. Specifically, I will try and answer the following questions:

• What does innovation in healthcare mean?
• Where are the major areas in healthcare where innovation is required?

Important takeaways for the attendees of this session will include:

• Understand PBU: Payer vs. Benefiter vs. User and how it must influence design
• Understand why healthcare businesses buy stuff so you can build the right thing

I hope you’ll meet me in Denver on July 11th or 12th – registration is open.

By the way, if you have some of your own thoughts about why disruptive innovation isn’t really happening in healthcare as fast as it should, drop me a line or send me a private email. I’d be happy to put your ideas (with attribution of course) into my presentation!

{ 0 comments }