Archives

Twas the night before a new release of FDA guidelines
Not a developer was stirring waiting on the sidelines;
The keyboards were hung by the monitors with care,
In hopes that interoperability soon would be there;

The physicians were nestled all snug in their beds,
While visions of Vinod Khosla danced in their heads;
And UX with their wire frames, and agile scrums
Had settled down with new problems but did not succumb.

When out in the office there arose such a clatter
New healthcare policies that really do matter
Away to the window I could only deduce
Tore open the shutters – hey meaningful use

The moon on my mobile phone my fingers did tap
Gave me comfort in seeing a new treatment app
When what to my wonderment a transformation
A process and method for new innovation

With a lots of health challenges and new informatics
I knew in a moment it was solved with mathematics
More rapid than standards and new care models
And a whistle and shout – no more waddles or dawdles

Now ONC, now PHI, and EHR
On HIT, on HHS and EMR
To the top of the challenges and problems we face
Now dash away, dash away and let us keep pace

Their eyes — how they twinkled, the patients did say
New help and better outcomes now that’s the way
Technology enabling and helping with costs
Payers and providers the message not lost

They sprang to their iOS, Android and Windows 8
Away they all flew new apps, wow that’s great!
And the delivery team exclaim as they moved with great stealth
Happy Holidays to all and to all Good Health!!

The challenges in healthcare are big -

• 5% of patients accounting for 50% of costs
• FDA regulatory is continuing to evolve
• Improving outcomes and reducing cost are key performance measures
• Security and privacy concerns exist
• Interoperability and the development of standards continue to stifle progress in some areas

2012 brought lots of change and 2013 promises to bring much more. In this holiday season we are reflecting on the work we’ve done and the work that is to come and find ourselves humbled by the impact that we’ve had with our customers on the lives of millions and the healthcare eco-system. We look forward to working and collaborating with others that are tackling the big and important healthcare problems because it makes a difference in the world.

On behalf of the Pathfinder team, we wish you and yours a blessed, peaceful holiday season.

Poem by:  Ted Wallhaus

I attended the 2012 mHealth Summit in Washington DC earlier this week and came away impressed with the how fast things are moving in this space.

The conference itself, now in it’s fourth year, has grown to over 3800 attendees and over 300 exhibitors. Major players like Kaiser Permanente, Intermountain Healthcare, Aetna, United Healthcare, Mayo Clinic, Qualcomm and Johnson and Johnson were well represented, as were startups, service providers, physicians and government agencies. These organizations are beginning to recognize the transformative power of mobile on the healthcare sector and are putting serious money and manpower into their mobile efforts.

A couple of trends stood out to me from this year’s conference:

Changes to Reimbursement are Here Already

Just before the conference, a study came out claiming that 31 million patients were already enrolled in Accountable Care Organizations (ACOs) in which reimbursement is tied to population health. While there is some debate about the findings, they certainly brought home that changes to reimbursement models are not purely theoretical, or something for the distant future.

There was a lot of discussion on readmissions, the patient centered medical home, and meaningful use. Whether patients are in an ACO or not, changes to reimbursement are are already here and impacting hospitals, clinicians and patients, and those changes will only accelerate.

Reimbursement Changes Spurring Innovation

These reimbursement changes are spurring outcome and cost focused innovation both inside and outside the hospital. While much can be done to improve effectiveness within hospitals (see Atul Gawande’s recent analogy between healthcare and the cheesecake factory) there is likely even more opportunity outside the hospital, through patient behavior change and earlier, more frequent feedback between physicians, patients, and machines. More on the machines part later.

The Promise of Mobile

This is one area where Mobile really shows a lot of promise:

• A lot of health issues can’t be scheduled. They can happen at any time. For patients and physician, the ability to share anywhere, anytime makes sense – it fits into how they live and work
• iOS and Android smartphones and tablets fit the bill: They’re personal, always on, always connected, and really easy to use.
• Penetration of iPhones and Android smartphones in United States is now at 48%, with 50% year on year growth as smartphones crowd out feature phones.
• There are over 2 billion Bluetooth enabled devices, and 1.5 billion wifi enabled devices. Many of them are wearable and more and more are healthcare related. New types of sensors are being invented that capture more and more diagnostic information and transmit them via mobile devices to the cloud.

Experiments in Patient Engagement.

Mobile provides great tools for patient engagement, but most organizations are in the early stages of grappling with how to use them, and there’s a lot of confusion and conflicting information out there. For example, one panelist claimed that it was impossible to get more than 11% of patients over 65 to use mobile apps to engage, only to be immediately contradicted by an audience member from Montana who suggested that in his experience providing financial incentives like copay reimbursements worked wonders with seniors.

The good news is there are lots of data driven experiments and learnings being shared, including work in persuasive design and the dynamics of social networks, so I expect lots of progress in this area.

Platforms and Big Data

Of course you need better integration to get all of this data together, analyze it and provide meaningful information where it’s needed.

Integrated groups like Kaiser Permanente and Intermountain have a head start on all of this – they’ve been dealing with patient engagement and reimbursement for population health, have data on this, and are actively using that data to improve outcomes for their populations.

But there’s lots of room to improve on the current state of integration. That’s where platforms like Qualcomm Life’s 2net and Aetna’s CarePass come in.

The 2net Platform is a cloud-based system designed to be universally-interoperable with different medical devices and applications, enabling end-to-end wireless connectivity while allowing medical device users and their physicians or caregivers to easily access biometric data, with two-way connection capabilities and a broad spectrum of connection options.

Aetna’s CarePass takes this one step further. The platform enables consumers to share information across apps and create a personalized, coherent experience to manage their whole health, from getting care to staying well, all with one sign-on. Aetna has integrated a number of their own apps, like iTriage, Medicity and ActiveHealth Management.

For Aetna, this fits into their vision to build out the infrastructure platform for ACOs and get as many providers and consumers onto the platform as possible.

Which brings us back to reimbursement and regulatory changes. The MHealth Summit provided a great look at the state of MHealth in 2012, a glimpse of where we are going, and of the challenges we still face. I can’t wait to see where we go in 2013.

It’s been a whirlwind year at Pathfinder. Our focus on bringing innovative solutions to the healthcare space has continued to bear fruit. We’ve added Fortune 500 clients and innovative startups in the device, diagnostic and health insurance industries.

Mobile
Our clients continue to innovate in their use of mobile technology. Many of our projects now involve developing mobile applications on iPhones, iPads and Android smartphones and tablets. Projects this year have included:

• Heart monitoring solutions involving wearable sensors, bluetooth communication to android devices, cloud based predictive analytics and real time alerting
• Apps for patients managing chronic diseases
• Apps and devices providing clinicians with diagnostic support in operating rooms and on the hospital floor.

Staying Agile in an FDA Regulated Environment
Our approach to making extraordinary healthcare apps relies on a few key ingredients:

• Developing a deep understanding of customers, users and their problems
• Applying great technical and design talent to solve them
• Using analytics and fast feedback cycles to continuously improve engagement and effectiveness.

Quite a number of the products we develop are considered Class II and Class III medical devices and require clearance or approval by the FDA. Applying an agile approach in this environment poses significant challenges, but carries great benefits for quality, speed and market viability,

We’ve met these challenges by developing a quality management system that conforms to the IEC 62304 standard for software development supported by the FDA, and have integrated our process to our clients quality management and hazard analysis processes.

This effort culminated in a series of passed audits on our quality management system this summer.

Scaling Lean Innovation in the Enterprise
2012 saw tremendous progress in our lean innovation practice. Our summer lean startup teaching program, the Chicago Lean Startup Challenge taught 107 teams how to accelerate from Idea to traction. The videos from our Semifinalists tell a great story of how much you can accomplish in 8 short weeks.

We’ve been collaborating with a number of enterprise customers to apply the lean innovation approach at scale, using innovation accounting and stage metrics within a portfolio management approach. This approach allows our customers to make better investment decisions on their innovation portfolio and develop more disruptive innovations faster. We’ll have lots more to share on this in the coming months.

We’re proud of what our clients have been able to accomplish in 2012, and are excited about what we can accomplish together in 2013.

I came across this infographic earlier today that illustrates how quickly physicians are embracing mobile devices and mobile healthcare solutions. Presented this way, it’s suprising how much faster demand for mobile healthcare solutions is rising than in other areas. But if you look closer, it’s not surprising at all. Healthcare is an almost perfect setup for mobile: Physicians usually don’t sit at desks, but are at the side of the patient, in the operating room, doing rounds, or taking call from home. In all of those situations, they need information at their finger tips, clearly presented, in context, and in real time. We see this every day in our work with physicians, hospital systems and medical software companies.

Hat tip to the fine folks at Airstrip and the creators of the infographic at spinabifidainfo.com.

The FDA regulates software for medical devices, and may in future regulate mobile medical software as well. Can you speed up time to market with Agile development in an FDA regulated medical environment?

We shared our experience developing software using lean ux and agile software development best practices for medical devices and mobile medical software at a recent joint Health 2.0 and Product Management Association meeting.

This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:

Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren’t working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don’t discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it increases the likelihood that you will produce a better product. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with business and marketing? Here are the difficulties you will likely face:

• Goals are different
• The phases and corporate dialect are different
• The time frames and processes for decision making are different
• Required documentation will be different and address different goals
• Stakeholders will feel comfortable giving verbal requirements, but you must document them, get them formally approved and finally build them into working software

How do you partner with the business and still meet your commitments? Follow the practices we presented earlier and stick to the following principles:

• Consistent focus on activities that add business value
• Build trusted partnerships
• Constant customer engagement
• Continual process and practice improvement
• Be collaborative and transparent
• Work together: No heroes, lone wolves, or cowboys
• Pay attention to the team and adapt as needed

Very few people in the software development community have issues with maintaining good attention to the details. However, I bet those who live in the regulated software community view the “normal” software world as quite sloppy. Attention to detail is a matter of life and death for a medical device. Because of this, the entire software community does a good job maintaining checks and balances. I have three suggestions that will make a tremendous difference when you start a regulated project or when you finally get near to releasing your medical device.

Photo by: myguerrilla

#1 Plan to get audited

It is a good bet you are going to get audited sooner or later. Its even possible to get a product out into the market only to have it get audited a second time. An FDA auditor will keep asking “why do you think that works?” type questions and continue to drill down until they find something or are satisfied there is nothing to find. If they find something you are going to get a warning letter and start the expensive process of FDA remediation. Getting past this will cost you a significant amount of resources and likely delay new product development. Usually just in time for your competitors to catch up. Keep good records.

#2 Do Test Driven Development (TDD) Well

By well I mean do all of the normal activities that are part of TDD … and do one more thing. Create self documenting code that also lends itself to traceability directly back to product requirements. Imagine telling an auditor that you can prove that you tested every path of the code EVERY time you checked your code in…thousands of times.  All of these tests can be directly linked back to product requirements. That would make an audit pretty easy.

#3 Create a Traceability Matrix

This may seem obvious. However, I know of many, successful, software shops that have stopped doing this. Ask a developer with 1-2 years of experience why they would need a traceability matrix and you will know what I mean. If you are planing to get audited and want to show that all of your requirements have been tested thousands of times, you need a traceability matrix.

Next Up: Partnering

Image credit:  MIT New Media Medicine group at the MIT Media Lab

The New Media Medicine group at the MIT Media Lab suggests a key to solving healthcare problems lies in establishing new kinds of collaboration between patients and practitioners. Traditionally, the relationship has been one of “inequality” where practitioners and medical experts monopolize access to information. This leaves the power of the people and the ability to collaborate untapped. The New Media Medicine group is creating projects that offer innovative user experiences that can drive change. Let’s take a look at two.

Avatars To Assist Patient-Physician Collaboration
One of the most frustrating things when care is needed can be the delays of getting an appointment or someone to talk to. The I’m Listening system uses an avatar to conduct a pre-office visit interview. The avatar-based interview is meant to enhance, not substitute for, the doctor’s own interview of the patient. The avatar can be used to provide, with a sense of immediacy, educational materials, care suggestions and information to better assist the patient in working with the doctor. The information from the interview can help save the doctor time in terms of getting a basic understanding of the patient’s condition.  watch the video

An Open Source Stethoscope
Imagine an inexpensive and easy to use stethoscope that you could use yourself to take readings that could be streamed over the internet to a physician. This is the result of the IDA project, an open source effort to create an inexpensive stethoscope that is not only easy to use but also easy to manufacture all over the world. MIT’s New Media Medicine group points out such instruments could have an impact in developing countries where the physician to patient ratio is 1 to 200,000.  watch the video

These two projects and others at the New Media Medicine group at the MIT Media Lab show how rethinking the role of users and the possibilities of user experience can enable innovative and game-changing technologies and solutions in healthcare.

For more, visit the New Media Medicine group at the MIT Media Lab.

Its not what you wear. Its how you wear it.

Photo by country_boy_shane

I have to thank Tavi Scandiff-Pirvu for coining this expression as it relates to regulated software development. As long as you use industry standard methods, the FDA allows you to determine the rules that you are going to follow. If you want to have 15 exhaustive steps in order to build each piece of functionality the FDA will say, “Go do it. Just document each step as you go.” If you can reach the same quality in only 7 steps the FDA will say, “Go do it. Just document each step as you go. The FDA isn’t going to test your software in detail. They are going to test your process to ensure that you did what you said you were going to do. This may appear that the FDA is interested in the product but only the process! But, the FDA also wants to see (via documentation) that you built the product features you claimed you had.

The criminally minded will see an opportunity to claim they did more than they actually did via documentation, but in reality do less work. However, there is a natural equilibrium via the market. If you cut steps you will likely pay for it in your product via poor quality and sales. In the end the product has to work. Also, experience shows that it generally takes just as much time to design, create the documentation, necessary traceability and tracking support as to do the actual work. Inefficient? Slightly, but we are trying to sustain human life – not make a quick buck. Its not just about the money. Finally, a big picture analysis shows that it is cheaper for everyone to document what you did rather than pay somebody from the FDA to be a part of your project on a daily basis.

Don’t cut corners, or change your process, once you define it just to save time and money!

My final thought is that in order to do good process design (the 7 step version vs the 15 step version) and thorough documentation you will need to know your organization and team well. You will also need to know the product well so that you don’t design a seemingly efficient process that is blind to the needs of the market the product will be launched in.

Sorry kids. Nobody ever said it was going to be easy.

Testing is a crucial part of all software development. If you don’t believe this you are likely just starting your career or haven’t had to support an application in production with users.  It becomes doubly important in regulated environments like the ones for medical devices. This is because testing for regulated software serves multiple purposes. There is the usual software product development reasons to consider (i.e. professional integrity and no one wants a bug in production). But it is also because the FDA, in particular, wants to make sure you are performing validation and verification of the software. Verification (Was the product built right?) Validation (Was the right product built?)

While I acknowledge there are a number of useful and important ways to describe software testing techniques, I strive to keep things simple, and understandable, by the whole team. To that end, I split testing into two tracks: Functional and Technical. Functional is about bring business value to the stakeholders – the validation part. On an Agile project we are testing the acceptance criteria of each story. This validates we have realized the benefit to the business and end users. If some thing cannot be tested by an end user, it doesn’t exist or have significant value. This is of course untrue. However, to simplify things and keep the team laser focused on only working on tasks that provide business benefit I start with this ideal. All other testing activities are testing Technical requirements. Or, verifying that the software is correct. Some examples of these technical requirements are things like performance criteria, common libraries to the backend and data retention rules. Those who do testing for a living are looking at the screen sideways by now I suspect. I realize that these things must be done correctly or the system will not realize business value to an end user. Both ate needed. That’s why the FDA requires proof of verification and validation.

The common flow of testing in an Agile project is to create acceptance criteria for each story then do regression testing after each iteration:

On the other hand, tradition testing documents and verifies each step before it is performed. The goal is for planning to be exhaustive and cover all possible scenarios.

Traditional testing is expensive and often makes validation hard to do. On the other hand, the common Agile testing approach is going to make documenting verification activities difficult. Once you acknowledge both are needed you can find a way that works. The best tools we’ve found leverage and extend the automated testing you are already doing. Look at the software testing as having two “tracks”.

#1 Manual Functional Testing of acceptance criteria. All of the speed and simplicity of user stories. An efficient communication mechanism for stakeholders.

#2 Test everything else via automated tools. Ensures all gets tested. In our case we use unit testing and 100% code coverage.

Here is a graphic of how we can document that we are testing against pre-approved requirements – both functional (validation) and technical (verification).

Next up: Its not what you wear. Its how you wear it.