Medsphere Settles with Cofounders
For those of us interested in new business models and open source software, Modern Healthcare has a nice overview story the evolving relationship between Medsphere and the open source movement.
in Orange County (Calif.) Superior Court against the Shreeves and 20
other unnamed defendants, alleging – among various
complaints – misappropriation of trade secrets, breach of contract,
breach of duty of loyalty, violations of the Racketeer Influenced and
Corrupt Organization Act, commission of computer crimes, intentional
interference with contract relations and unfair competition. The
Shreeves' employment at Medsphere also was terminated, though Steve
Shreeve remained on the board.
In November, the Shreeves filed a countersuit against the company, its
then-CEO and board chairman, Kenneth Kizer, and other officers.
At issue was the posting in early June of Medsphere computer code to
SourceForge.net, a popular Web-based platform for open-source
development projects. At the time, in addition to his position on the
board, Steve Shreeve was the company's chief technology officer and
Scott Shreeve was its chief medical officer.
You can read a history of the company that Steve Shreeve, posted here
after the Medsphere lawsuit against him and his brother
was filed. Brother Scott Shreeve said after the settlement,
open-source company, dedicated to a transparent development process, a
transformative business process and a clear commitment to openness so
as to engender trust in the community and the marketplace.”
The Schreeves' position aside, there is no litmus test for open source software vendors. All such enterprises derive most of their revenue from services. Some offer software that is fully open source, and some offer software that is mostly open source while withholding some “secret sauce” as proprietary.
When I met with Ken Kizer (former Medsphere CEO and now Chair) at HIMSS 2007, we spoke about Medsphere's tiff with the Schreeves. He noted Medsphere's commitment to open source and the company strategy to retain product differentiation through keeping some software proprietary.
Balancing open source and proprietary software is not easy. A product must be open source enough to attract a community of developers who will contribute to the code base. Your resulting solution, including services, must be sufficiently commoditized (i.e., priced lower) than conventional solutions, otherwise the market will stick with conventional vendors.
The barriers to entry for the software business are low. The biggest barrier to health care IT is the investment required to develop big applications like EMRs and other key hospital information systems. If an application is purely open source, that primary barrier falls away. A fully open source solution also presents product differentiation challenges to a vendor. As an open source vendor, you want reasonable competitive barriers to entry and sufficient differentiation to provide a basis upon which to compete with other's in the open source community.
The question frequently comes down to how much is enough, and when do you go too far?
Web site devoted to open-source healthcare IT where much of the debate
about the Medsphere approach to software development has been argued.
Valdes said Medsphere needs to open up more of its software to be
considered a true open-source developer, including several applications
“that were intended by the Shreeves to be open source.”
“One of them was JUMPS, a Java implementation of MUMPS,” the
Massachusetts General Hospital Utility Multi-Programming System, Valdes
said. Both the VA's VistA system and the WorldVistA version run on
versions of the MUMPS database and programming language.
From the rumors he has heard, Valdes said JUMPS “would be a pretty big
bridge between the MUMPS world and the Java world. If that's going to
be open-sourced, that would be a significant event.”
According to Medsphere's complaint, however, the source code to JUMPS
was part of the June 2006 release to SourceForge that triggered
Medsphere to let loose its lawyers on the Shreeves.
Is the creation of a new development platform on Java an irresistible incentive to attract open source contributors to the VistA code base, or an important product differentiator for Medsphere? Of course, there is no one right way to draw that line. What matters is the result, commercial success or insufficient adoption.
Is Microsoft HealthVault Safe?
Many have criticized HealthVault regarding privacy and security concerns, or perceived limitations of HV as a personal health record (PHR). I suspect that HV is challenged more by the market's perception of Microsoft's long running security issues than with any actual shortcomings of that type in HV. And since HV is not a PHR, but rather a “platform,” criticisms about any lack of PHR features is not relevant.
One topic I've not seen addressed is the safety and effectiveness of the data within HV – and I don't mean “safety” as in the data is secure from unauthorized access or misuse. I mean “safety” as in the utilization of data stored in HV by other applications won't result in an unsatisfactory patient outcome, you know, like death or injury.
Certainly at first blush HV does not fall under the FDA's purview, but things could end up that way. (More on this later.) A key tool mandated by the FDA's Quality System regulation (QSR) to ensure quality and safety is the risk analysis. Any kind of connectivity needs to be thought of with risk analysis in mind – what can go wrong and how can those risks be mitigated?
If HV is more than just an interface engine, pushing data from one application to another, the risks are narrow. Sample risks include: data corruption during transfer into or out of HV, and data corruption during conversion of the data from one standard format into another. Mitigating these risks is straight forward; common data communications techniques to ensure data quality, and design and testing of the HV platform itself to verify data conversions are done accurately and reliably.
What if HV is more than a translator, but a repository of patient data? Most applications have a database that is written, updated and controlled by that application. It is the application that ensures that the data in the database is correct and valid. It is the application that provides the workflow to safely and reliably validate, edit and update data.
How is data quality ensured when various applications can read and write that resides on HV? Let's say data is edited or a calculated value is generated and then rewritten to HV. Does it overwrite the existing data? If there are multiple sets of the same data, how do you know which set is the best and most accurate data? Do you assume that the most current values are correct? What if they're not? What if that “better” data is not rewritten to HV but remains in the clinical information system in which it was generated – and another application comes along and uses the “wrong” data?
HV does track the properties, history and sharing of patient data. It also logs the time received and the source of the data. (You can see more detail in this page from the HV Developer Center.) Is this sufficient? Perhaps. What seems to be missing is the logic that controls the workflow between various applications, both what they do to the data and how they use it. Also needed is a formal verification process to ensure that any logic concerning HV data is implemented properly between applications, which is not mentioned on the HV Going Live! page.
The first red flag for the FDA regarding HV is the Connection Center (CC). Here data is acquired from medical devices, and if that data is to be used in rendering a diagnosis or guiding therapy (clearly the case with hypertension, diabetes and other chronic diseases) then CC meets the legal definition of a medical device. Presently, the FDA does not actively regulate products like CC, although there are examples of standalone connectivity products and features similar to CC that are built into broader based products that have received the FDA's premarket approvals. The regulatory risk for Microsoft is that the FDA could change its position and recall the product until it receives premarket approval. This change could result from political pressure (Congress or advocacy groups), adverse publicity from reports of patient injuries or deaths, or if Microsoft markets HV (or HV CC) in a way that gets the FDA's attention.
Regardless of the FDA's potential interest, the real issue is provider confidence. If Microsoft cannot demonstrate its ability to ensure the safe and effective use of data on the HV platform, then HV will never see much adoption. Such uncertainties could also dissuade vendors from incorporating HV if they feel that providers won't adopt.
There are many important contributions that HV can make to health care, and Microsoft is off to a good start. As a beta product there are still a few gaps to fill.
See previous Microsoft HealthVault posts here and here. Pictured right is the futuristic HealthVault logo.
New Qualcomm Chip Swings Both Ways
Qualcomm released a new 3G chip that supports both EV-DO (Verizon and Sprint) and HSDPA (AT&T and T-Mobile). This will result in radio cards that will run on either technology and provide the greatest choice in selecting carriers.
The chips are apparently targeting laptops and should appear in new laptops by the second quarter of 2008.
The latest technology to join the 3G alliance is WiMax, which the Qualcomm chip (called Gobi) does not support. In the US, Sprint is the first carrier to announce plans to deploy a nation-wide WiMax wireless network.
Pictured right is Qualcomm's QSC6240 chip with integrated radio
transceiver, baseband modem and multimedia processor – together with
power management functionality into a single chip for WCDMA (UMTS)
and HSDPA handsets.
FDA Raises Bar on Medical Device Software Testing
Blog Medical Devices Today did a post last week on the FDA’s adoption of a relatively new software testing technology in the CDRH’s software forensics lab.
In the past year or so, the forensics lab, housed within the Office of Science and Engineering Laboratories, has used high-power instruments and techniques to analyze “source code” in roughly a half dozen medical devices whose software was thought to be responsible for causing serious adverse events.
The analysis, which employ tools routinely used in the automotive and aeronautical industries, exposed several software design errors linked to the adverse events and at least one latent error that had the potential to cause an injury, according to Al Taylor, the Director of OSEL’s Division of Electrical and Software Engineering.
The story hints strongly about the FDA’s keen interest in seeing medical device vendors adopt this technology as part of their verification test in product development. Why is this a big deal? In 1996 10% of medical devices recalls were caused by software-related issues. In June of 2006, software errors in medical devices made up 21% of recalls.
The problem with testing software is that even very basic applications can have so many variables and permutations of outcomes that they become virtually impossible to test with conventional means. This is one of the main reasons that the FDA has focused their regulations on ensuring that vendors follow accepted design processes that maximize resulting quality, rather than focusing on verification and validation testing. The Quality System regulation is the manifestation of this approach.
But about a decade ago, another potential approach emerged. In 1996, a European space rocket, the Ariane 5, exploded just after launch because of a computer bug. Scientists made quick use of a sophisticated programming tool called “static analysis” to figure out what went wrong.
That experience validated the strategy as a useful tool for automating the search for hard-to-find coding vulnerabilities in complex software. It has since been embraced by the aeronautical and automotive sectors to help minimize errors and accidents. Now FDA is trying to bring medical device manufacturers into the fold.
A number of recent recalls (St Jude Medical Merlin PCS/Identity pacemakers, Baxter Colleague infusion pump, Difibtech’s AED) were all software related. Right now the CDRH software forensics lab is used to test vendor’s proposed fixes for recalled devices. In addition to verifying the vendor’s fix the static analysis also uncovers previously undiscovered software bugs.
According to the Deputy Director of the Division of Electrical and Software Engineering, Brian Fitzgerald, “No manufacturer wants to be in a position where FDA [is] finding bugs in his code,” he said. “And so we treat these very, very privately.” Indeed.
The story goes on to emphasize the value static analysis would have on premarket analysis. The story suggests that if medical device vendors don’t get with the program and adopt static analysis and/or other more rigorous software testing methodologies, the FDA might have to start doing premarket static analysis themselves – would very probably adversely affect premarket approval time frames.
This past summer I attended the workshop, Improving Patient Safety Through Medical Device Interoperability and High Confidence Software, in Boston. Much of this conference dealt with the challenges and solutions available to better test medical device software. Static analysis was discussed in a number of sessions. The bottom line from the conference is that the medical device industry has not kept up with other high reliability industries, especially aviation. (You can read posts from the conference here, here, here, here and here.)
I fully expect static analysis and other similar techniques to play an increasing role in medical device product development – mainly because it seems the FDA has similar expectations. Certainly the big vendors will adopt these techniques to:
- Differentiate their products (claims of improved safety),
- Avoid the considerable costs of preventable product recalls, and
- Better influence time-to-market schedules by removing the need for the FDA to do their own static analysis prior to premarket approval.
These advanced testing methods will also be promoted and offered by contract engineering firms. Firms like HighRely, that work in both aerospace and medical devices, can offer static analysis and other high confidence software testing methods. This will enable smaller medical device firms to benefit from these testing methods without investing in the overhead to do it in house.
Pictured right is a graphic report from a static analysis of software from the Centre for Software Engineering in Dublin, Ireland.
Microsoft Health Vault and Telehealth
Vince Kuraitus and I have a blog post up at the Center for Connected Health, a division of Partners HealthCare. Titled, What Will Microsoft's HealthVault Mean to the Telehealth Community?, the post explores the role Health Vault's Connection Center software may play in the commoditization of remote monitoring solutions.
Today, telehealth applications are based on point to point
relationships: home health agency to patient; disease management
company to patient; health system to patient.
Telehealth devices and their connectivity are similar. There is a
proprietary chain of key components for a remote patient monitoring
(RPM) solution: 1) the RPM device; 2) a gateway — which could be
mobile like the Biotronik Cardio Messenger
or static like a personal computer — to aggregate data from multiple
devices and move data to a server-based application; and 3) the server
application that stores and manages the data in accordance with the
application, e.g., glycemic control, medication compliance, etc.
Be sure to read the whole thing.
