Fred Trotter wrote: > The current CCHIT pricing module seems biased against any GPL based system.
Fred, you don't think that the CCHIT pricing is biased against software released under other types of free, open source licenses? > Joseph has already written about this, but I would like for us to consider > group action in the issue. > > The first issue is pricing. It will cost a $25,000 to $35,000 one-time fee > to perform the test. After certification, an annual fee based on sales will > be required which will be at least $5,000 a year. According to... > > http://www.healthcareitnews.com/story.cms?id=4639 > > This pricing assumes a proprietary business model. The "seal of approval" > model is also problematic. Suppose I pay the fee to have MirrorMed (my > project of choice) certified. There is no way for me to guarentee that only > I benifit from the "seal". My competitors which have full access to the code > that I would have certified would be able to correctly claim that the code > had been certified, and would benifit with me. As with the original pricing > there is no way to fairly spread these kinds of costs across a community. As > a result, FOSS medical software could face an environment where there > products could not compete against "certified" proprietary products. This is of interest because certification of medical and health software is a debate which we are about to have here in Australia. I think that the key question is: what does certification involve? How is it done? Is the $25000 certification fee required in order to employ a team of High Priests who use magical incantations and crystal balls to determine whether a particular software product should be certified, or is there an objective list of criteria which products must meet or fulfil? Hopefully the latter. Clearly these criteria should be published, and publishers of medical software should be encouraged to document how their product meets these criteria. The cost of certifying a product for which its vendor/publisher has done all the hard work for the certifying agency by documenting how it meets the certification criteria should cost a lot less to have certified than system without such documentation. The vendor/publisher-provided certification documentation might comprise things like reference to design documents, automated tests to demonstrate compliance with certain prescribed or proscribed behaviours, or reference to the source code for the product. Now, one can see why vendors of proprietary medical software would not want to make such certification documentation publicly available - it would reveal a great deal to their competitors about the engineering of their product and would probably require access to source code and a working copy of the product in order to be useful anyway - neither of which would be publicly available - so there would be little point. Hence, the certification documentation would need to be checked in secret by the certification authority or a trusted agent appointed or engaged by it. Secrecy costs money, hence the proposed certification charges. But there are no such impediments to publication of the certification documentation for open source health and medical software. Thus, in the case of open source software, the certifying authority could just require the publication of the certification documentation, and publicly call for objections to it. If no objections are received, the certification should be issued. This would be predicated on two (valid, I think) assumptions: a) that there are extremely strong disincentives for open source projects to cheat with respect to this certification documentation; and b) competitors to an open source product have an incentive to check the adequacy of the documentation and complain to the certification authority if they can show that the certification criteria are not met, or that the certification documentation is wrong in some way. Obviously there is still a high cost to certification for proprietary vendors and open source projects alike, but at least with the model described above, or variations on it, those costs can be distributed across a community of users and developers, and the certification can evolve and be maintained alongside the open source software itself, rather than having to be redone from scratch by behind-doors certifiers for each new release or version. And it is transparent. Transparency of certification and other quality assurance mechanisms is crucial for all health and medical software, I feel. > Free and Open Source EMR vendors are not the only one effected by this. This > will target any small vendor, open source or otherwise. www.emrupdate.com is > writing a group letter for the CCHIT feedback process which points this out. > > http://www.emrupdate.com/forums/thread/46564.aspx > > I think that we should consider also writing a group letter. I would be > willing to author this, if I knew that once it was written and reviewed, > that some of the influential people on this list might sign it. Another > possiblity is to piggy-back on the emrupdate letter. Thoughts? Then of course there is the question of what form the certification criteria should take, what their scope should be, how deeply they should delve into *how* a software product is engineered, rather than just *what* it nominally is supposed to do. But that is a discussion for another time. Tim C Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/openhealth/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
