Re: [openhealth] Mirth Project: FOSS HL7 interoperability.
2006/3/23, Ignacio Valdes [EMAIL PROTECTED]: The goal of the http://www.mirthproject.org/ Mirth Project is to develop an open source cross-platform HL7 interface engine that enables bi-directional sending of HL7 messages between systems and applications over multiple transports. By utilizing an enterprise service bus framework and a channel-based architecture, Mirth allows messages to be filtered, transformed, and routed based on user-defined rules. Interesting project I am downloading it rigth now. I developing my own cross platform HL7 LLP and message framework that you can find at: http://projects.cristoforocolombo.net/projects/pyhl7 ASAP I will release a beta version tested in my application. Bye Stefano 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/
Re: [openhealth] Demonstrations Standards.
David Forslund wrote: I think there is an intermediate position here. In my experience these standards, far from perfect, are good enough to gain experience and see them work in practice. The resulting models and infrastructure are actually rather easy to change into new paradigms, I believe. I can't wait until the standards are the best they can be, which probably will never happen. By using some of these standards, one still opens up transition to the future, as the need to migrate to something better will be ubiquitous and paths will become available for the transition. The fact that code may need to be re-written is no big deal. Agree. This thinking is why I am happier to work on openEHR which is an evolving thing that the 5 year lock-in cycle of most standards. But regardless - the original version has to at least be based on proper modelling principles and be internally coherent. - thomas 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/
[openhealth] Re: Demonstrations Standards.
This continues to be a good discussion. I highlighted some small snippets of previous replys because I think they get at two of the other significant factors involved in uptake of systems. Business models Clinical care models (My perspective is limited to the USA). Whatever else we might think about it, there is a business model around how a patient get's moved around the health care system. Usually changes in workflow (processes) change the resource (time, hardware) allocations for those processes. Some processes get less, others get more, some new ones get more at the cost of existing or replaced processes. Overall, the system may show a net gain, but if we have business models that separate financial (in general operational) accountability among the chain of care (most definitely true in the US, and I suspect elsewhere, the single payer does not lead to single operational accountability), it's very difficult to change the overall system and change proposals encounter stiff resistance. In the clinical care model, at every process, I think the issue is not so much how much data is available or missing, but how much trust should be put in the data that is required for this particular encounter. My personal observation in the US is that clinical staff just assume that critical data is missing and have built a care model and it's accompanying business models around that missing data. Clinical staff are just as unhappy with systems that present 'everything' as they are of systems that don't have critical data, in fact, I think they dislike too data more than not enough. That's because the system can easily be activated to make up the missing critical data (not all the time in chronic disease) but it's not so easy to pick out the relevant bits from the haystack of data. From my perspective, both of these issues are the behind the scenes landscape into which what I have called a practical demonstration of need will play out. If you can demonstrate the need and the gain to most (maybe all?) of the people held operationally accountable, then your chances of changing technology increase dramatically. From: rschi2006 [EMAIL PROTECTED] Subject: Re: Demonstrations Standards. ... how a continuity of care for a patient is maintained so the patient gets to see the right doctors in the right order, etc often times this is supported by proper scheduling, data sharing and departmental communications. - From: David Forslund [EMAIL PROTECTED] ... Today the clinician acts without all the data in front of them, so providing more data than before should hopefully improve (and not confuse) things. This will require in the US incentive from the payer side of the house that their costs will be reduced by providing this and overseeing it even when the payer changes. In the US one's PCP can change yearly if not more often. 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/
Re: [openhealth] CCHIT biased towards proprietary software??
The current CCHIT pricing module seems biased against any GPL based system. 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 I couldn't tell from your message or the article which jurisdiction is proposing this certification plan. 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/
Re: [openhealth] CCHIT biased towards proprietary software??
This is a US initiative... [EMAIL PROTECTED] wrote: The current CCHIT pricing module seems biased against any GPL based system. 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 I couldn't tell from your message or the article which jurisdiction is proposing this certification plan. YAHOO! GROUPS LINKS * Visit your group openhealth http://groups.yahoo.com/group/openhealth on the web. * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service http://docs.yahoo.com/info/terms/. . 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/
Re: [openhealth] CCHIT biased towards proprietary software??
[I hope you don't mind if I copy this to Hardhats. I think it is a topic of interest to both communities.] I have mixed feelings here. It seems completely reasonable to want to have an accreditation/certification process for health information systems (though the jurisdiction issue is certainly a tricky one), but I believe you are right that the current model is problematic for open source software. The issue is controversial, but it doesn't seem right that open source software should essentially receive a by in this area. After all, such systems are used for the same types of safety critical applications as proprietary software. Sure, there is community review, but is tht really enough? What seems logical for is for some organization (perhaps OSHCA, but more likely an independent entity) to establish criteria for certifying open source systems. How would it all be funded? Good question. I don't think I really have any good answers, but one possibility is that vendors that support open source product suites would pay for accreditation (albeit using a different model and/or provcing criteria). Another possibility is to formalize the review process and make all relevant artifacts publicly available. The problem here, of course, is that there is no real incentive for an official agency to review (or audit) that process and provide accreditation for the software. Tough one. === Gregory Woodhouse [EMAIL PROTECTED] It is foolish to answer a question that you do not understand. --G. Polya (How to Solve It) 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/
Re: [openhealth] CCHIT biased towards proprietary software??
You are right we should not receive a by we do need to make concrete suggestions as to how the same organization can accomplish open source evaluations... Here are the suggestions from emrupdate.com emrupdate 1. Markedly decrease your up-front fees and eliminate the percent royalties provisions. In most other certification arenas, the cost is usually ranges from about $150-$300 (Verisign-like certificates) to slightly over $1000 (Board certification for physicians). The government should pick up any shortfall in revenue since they stand to gain through future Medicare cost savings. 2. Eliminate the all or nothing certification process. Consider a tiered certification process, s.a. Gold, Silver and Bronze. Alternatively, EMRs can be certified as having certain listed features, s.a. 150/328 features, allowing the buyer to know exactly what they are purchasing. EMRs should be verified that the EMR pricing is truthfully represented, eliminating the element of surprise in delivery of purchased goods and services. 3. The certification features should be pared down to a dozen of the most important features, especially those features that deal with interoperability and the making of the CCR universal. All other features would be suggested, but optional. 4. Self-testing should be reassessed. The EMR products should be independently tested for the items that are advertised. Consideration should be made for running speed and reliability. Does the software even work outside of the laboratory? 5. Certify financial responsibility and exit strategy to make sure that no user will ever be at risk of losing his medical data due to lack of same. 6. Vendors should not in any capacity be involved in the certification process as evaluators. 7. This initiative introduces us to a slippery slope of arbitrary item inclusion, all of which should be removed or made optional. Today, that decision to include peds-specific content effectively removes those EMR's going after internal medicine, geriatric, adult endo, gastro, uro, and other specialty markets. 8. CCHIT should define criteria for a lab interface so that every EMR did not need a separate interface for every lab vendor. We need to define a set a lab names/codes so that a CBC is a CBC on both coasts and in between. emrupdate If you agree with these then you should sign there letter. So here is what I would propose regarding FOSS software. 1. Reduce by 90% the costs associated for certifying any product that is published under an Open Source (as defined by OSI) or Free Software License (As defined by the Free Software Foundation). Software released under these licenses contribute directly to the public good, unlike proprietary software. Since there is no profiting party like a proprietary software company, there is no source of funds from which to pay the standard fees. 2. Instead of certifying software alone, vendors-software pairs should be certified. So B-Mas supporting FreeMED would be a Open Source CCHIT certified instead of just FreeMED. That encourages B-Mas to pay the fees, and gives them specific benifits once those fees are payed. Also it means that the same software can be certfied by different vendors several times. This benifits projects with multiple vendors, like VistA and MirrorMed/ClearHealth. It gives us a way to pool resources as a community to get multiple certifications that benifit individual vendors but does not break the bank for each vendor. This also serves to supply the cash needed for the CCHIT process (which is very person intensive). Does this sound like a reasonable proposal? If it does then I will write a formal version and then request signatures -FT On 3/24/06, Greg Woodhouse [EMAIL PROTECTED] wrote: [I hope you don't mind if I copy this to Hardhats. I think it is a topic of interest to both communities.] I have mixed feelings here. It seems completely reasonable to want to have an accreditation/certification process for health information systems (though the jurisdiction issue is certainly a tricky one), but I believe you are right that the current model is problematic for open source software. The issue is controversial, but it doesn't seem right that open source software should essentially receive a by in this area. After all, such systems are used for the same types of safety critical applications as proprietary software. Sure, there is community review, but is tht really enough? What seems logical for is for some organization (perhaps OSHCA, but more likely an independent entity) to establish criteria for certifying open source systems. How would it all be funded? Good question. I don't think I really have any good answers, but one possibility is that vendors that support open source product suites would pay for accreditation (albeit using a different model and/or provcing criteria). Another possibility
Re: [openhealth] [Fwd: Re: [n-gaa] Is Open Source Good for Innovation?]
Thomas Beale wrote: Tim.Churches wrote: Why Wikipedia doesn't have one is a mystery to me. Why it is as good as it is (however good you think it is) is also a mystery. It is wrong to think of wikipedia as an open source/open content project. In fact, it is about 1 million separate open source/open content projects (that is, articles), each with their own project team. All the good projects (articles) have a small editorial team, often just one person, which really cares about them. If someone else makes a worthwhile contribution, it is allowed to stand. If someone else degrades the content, then the editorial team changes it back to its former state. Often content goes through many cycles of degradation and restoration, but the editorial team usually wins through sheer doggedness. And the overall, average direction of change across the 1 million articles is towards the better, although it is easy to find examples of articles which spiral down. But most get better. but as far as I know there is not even a signalling mechanism for the editor (how does she know she's the only one) to know about changes? See http://en.wikipedia.org/wiki/Help:Watching_pages Where is the editorial group proclaimed? I made some additions once and never ran into any editorial mechanism. There is no proclaimed editorial group - but as I said, most good articles do have at least one person who really cares about the content of the article - often the person who wrote it originally. This editorial team is, as I said, self-appointed, unproclaimed and entirely de facto - it exerts influence by persistence and doggedness in correcting what it feels are retrograde changes to each article. And yes, it is not uncommon for there to be multiple editorial teams (often just different individuals) at war over an article - hence the conflict resolution procedures: http://en.wikipedia.org/wiki/Wikipedia:Conflict_resolution However, if wikipedia articles were not based on the wiki-wiki roll-back paradigm, the whole thing would collapse. As it is, the self-appointed editorial team for each article can roll back changes with a few clicks of the mouse. Self-appointed? Yes, just like the way in which leaders of almost all open source software projects are self-appointed. Both OSS and wikipedia are meritocracies in which power and position is gained by doing things - writing software or writing articles. Of course I agree with the sentiment, but I don't see where the editorial groups are constituted. They are not constituted, they are de facto. Perhaps team was the wrong word - more often there are de facto, self-appointed editorial guardians for articles. But quite often these guardians get together to back one another up. And yes, sometimes they fight. 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/
Re: [openhealth] [Fwd: Re: [n-gaa] Is Open Source Good for Innovation?]
The evolving work-social phenomena are sure interesting. Toyota, and agriculture research adopting the approach is pretty cool. I believe there are a LOT of companies incorporating open source work into RFPs and proposals to get a contract without even talking to the original developers - this is restricting the pool of talent and time going into open source projects, unfortunately. As the article suggests you have to control code submissions to keep the quality of the product high. And protecting the image/brand of an open source project is just as important as rejecting bad code submissions. Trademark, copyright, and making sure an author's contributions are advertised properly are all too important... Linus being a great example. Richard David Forslund wrote: http://www.economist.com/business/displaystory.cfm?story_id=5624944 is the link to the article I intended to post. David Forslund wrote: I thought folks might like to see this article. Any comments? -Dave Yahoo! Groups Links 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/
Re: [openhealth] Demonstrations Standards.
Can anyone post the link again to the files section? Thanks! Richard Will Ross wrote: oops. now i posted the document in the openhealth files section. [wr] - - - - - - - - On Mar 23, 2006, at 8:01 PM, David Forslund wrote: As you probably noticed, images (and attachments) are stripped off by the mailer, so the diagram isn't visible. :-( What is the communication between components of ClearHealth or with other systems? Thanks, Dave Will Ross wrote: Dave, Attached is a diagram which is part of a practice management software replacement project I am managing for a group of rural ambulatory clinics. This particular diagram maps the initial steps at one clinic as Reception interacts with the current software (HP) when a patient arrives for an appointment. These high level procedural diagrams completely map user interaction with the HealthPro software at this facility. The user centered workflows are grouped into procedural chunks to enable analysis and planning for migration to the replacement practice management software, which is ClearHealth from Uversa. Using these maps allows lead users in the key operations areas (Scheduling, Billing, Medical Records, etc) to step through the ClearHealth demo, creating a gap analysis to identify software features that must be added to ClearHealth. I anticipate implementation of ClearHealth at our first clinic site this summer. I started this open source project in February 2004 and have been fortunate to raise enough funds to aggressively and comprehensively add the necessary features to the base ClearHealth product. All the new code being paid with grant funds will be released under the GPL. The project portal is located here: http://www.phoenixpm.org/ With best regards, [wr] - - - - - - - - On Mar 23, 2006, at 6:44 AM, David Forslund wrote: I wholeheartedly agree with you, Will!Do you have some example workflow diagrams that you have found useful? Dave Will Ross wrote: Philippe, Actually, I am still talking about Wayne's focus on the user. As a project manager I spend much of my time in a balancing act by advocating for someone else's perspective. When I work with with IT developers and vendors, the most important missing voice is generally the perspective of the user. Workflow diagrams and use case narratives are excellent tools to bring the user back into the center of the technology planning process, and they also provide users with a convenient way to redirect well intentioned but inappropriate technology proposals. Until we have compelling informatics solutions that meet actual clinical user needs, adoption of new IT proposals will be minimal at best, which describes the current state of EHR deployment in this country (i.e., minimal). With best regards, [wr] - - - - - - - - On Mar 23, 2006, at 3:43 AM, Philippe AMELINE wrote: Any opinion on YAWL ( http://www.yawl.fit.qut.edu.au/ )? Tim C Hi guys, I very much like the way Wayne Wilson explicated the Big problem : The very first thing to do is to build a believable (to doctors and patients) scenario for needing to get information from one system to the next, preferably in real time. IF you don't lead with that from a demonstrably practical point of view and just assume a generic need justifies all (interchange is good and will save the world, etc.), then I suggest that this interoperability demo is no different than a vendor plug fest designed to show managers why they should keep buying the same stuff they have already bought. And how funny it was to see that 6 posts after, all this vanished into a workflow engines comparison (very interesting, by the way). From my point of view, Wayne is very right to ask for a scenario for needing to get information from one system to the next. And I think that such a scenario will be pretty much artificial if these systems are HIS since the genuine main reason to communicate is continuity of care, and that it is the very issue that hospitals don't address at all - and even rarely understand. This generic need that would justify a need for communication between HIS is a myth that became a religion when a sufficient number of people started to make a living by building standards for it. This is not an issue for the citizen. My 2 € ;-) Philippe [wr] - - - - - - - - will ross project manager mendocino informatics 216 west perkins street, suite 206 ukiah, california 95482 usa 707.272.7255 [voice] 707.462.5015 [fax] www.minformatics.com - - - - - - - - [wr] - - - - - - - - will ross project manager mendocino informatics 216 west perkins street, suite 206 ukiah, california 95482 usa 707.272.7255 [voice] 707.462.5015 [fax] www.minformatics.com - - - - - - - - -- - - - - - - - - [Non-text portions of this message have been removed] Yahoo! Groups Links [wr] - - - - - - - - will ross project manager mendocino informatics
Re: [openhealth] CCHIT biased towards proprietary software??
I'd prefer to assume that the CCHIT pricing model is simply biased toward software companies that can produce a viable product. And by that I mean a software product that stimulates revenue for a company at some point - which in our case is not through the sale of software licenses. Nothing wrong with that bias. CCHIT is obviously trying to stand as a self-contained, objective certification body. It can't do that unless it charges fees. It's up to people seeking a certification to determine if the investment into the certification will bring enough returns in the long run. I maintain open souce software is a path toward stimulated economies and innovation .. CCHIT doesn't owe anything to open source software and shouldn't be required to lower their fees. It's up to us to demonstrate that open source solutions compete on all fronts. As for giving other companies an edge if you release certified CCHIT software a open source, I maintain that risk can be managed. CCHIT fees, whatever they are, get back to the question at hand: can an open source software company produce a viable healthcare product? Richard Fred Trotter wrote: The current CCHIT pricing module seems biased against any GPL based system. 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. 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? -- Fred Trotter SynSeer, Consultant http://www.fredtrotter.com http://www.synseer.com phone: (480)290-8109 email: [EMAIL PROTECTED] [Non-text portions of this message have been removed] Yahoo! Groups Links 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/
Re: [openhealth] CCHIT biased towards proprietary software??
Rod Roark wrote: This is equivalent to ignoring the practical issues that Fred raised. I disagree. The practical issues Fred raised are real concerns, but the software companies we're competing against throw a *lot* of money into validation and certification - especially HIPAA compliance (in the U.S.). You may find that CCHIT's costs are insignficant in that light. Perhaps the problem isn't the cost of any certification, but rather the lack of a solid business that is able to properly support open source development. As an OpenEMR developer and supporter, there's no way that such a model would do anything useful for me. Well, if you're volunteering I think you have a point. But, you might agree with me if your sole job were to develop OpenEMR as an open source product and you were being paid US$70,000 per year. Nobody is going to pay thousands of dollars for certification of free software -- not to mention that such software by its nature will be continually evolving and so quickly rendering any given certification obsolete. And why not? I'm not being flippant. It's a serious question. What's wrong with doing that? What's wrong with going to the expense to show that your open source product meets the same quality controls as the big vendor products? If open souce leads to a viable business model, the money will be there. Richard -- Rod www.sunsetsystems.com Yahoo! Groups Links 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/
Re: [openhealth] CCHIT biased towards proprietary software??
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
workflow diagram Re: [openhealth] Demonstrations Standards.
Nice work flow diagram. One of the more difficult things I've encountered in 10+ years of health care software development is documenting the work flow. The hallmark of a good clinic hospital seems to be the ability to adjust the work flow to meet the need. There's the work flow the system expects, what's documented in the continum of care protocol, and then there's what happens on the day to day. Here's what I can offer for the benefit of the good: supplies -+---+---+ | | | v v v triage +-- intake -- treatment -- release | +-- administration -- billing -- payment we're having the same challenge at X12, documenting workflow that allows for the development/maintenance of the EDI transaction set. humor I think there's a game Sim City Hospital or something like that which is pretty fun to watch also. Health care work flows are so arbitrary from one place to the next you could probably document the work flows from the GAME and have something to work with too :-) /humor Richard 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/
