On 8/14/07, Thomas Lord <[EMAIL PROTECTED]> wrote: > > Mitch Amiano wrote: > > There exists a general market (and a size-able one at that) for > > content management systems which do not deal with code "source as > > lines of text" as it were, but rather as networks of elements inserted > > as XML. The XML provides tree structures through various interfaces, > > mostly but not only document editing interfaces. A quick look at > > http://xml.coverpages.org/healthcare.html shows a plethora of activity > > in this area. > > I agree about that market and thank you for the link to what looks a > useful resource.
pb: yes, although I have not dug to the root of the initiative, and any potential bias (but http://xml... is my first clue). As a Fellow of AAFP, the first link I read was here: http://xml.coverpages.org/healthcare.html#ccr specifically, some highlights: The Continuity of Care Record (CCR) is a core data set of the most relevant and timely facts about a patient's healthcare. Data sets for extensions of the CCR to address such areas as clinical specialties and disease management are not included in the specification. Whether this initiative has the support of other standards bodies and potential primary and secondary users or if it can be aligned with other efforts, such as the EHR Functional Model, open EHR, the HL7 CDA and so forth remains to be seen. >From my experience, working on the 'core data set' is missing from most if not all EMRs. Many promised it would happen, but it has not yet materialized. EMRs utilizing RDBs are working from the top down and have not yet reached bedrock. > > > The value to the user, if I can read into Thomas' response, is the > > ability to use the system to query and retrieve on the basis of the > > structures, not just to store and seal it. > > > > That's an example of a benefit to the user. Other benefits of an > XML-based format include: exchange formats "for free", directly > executable data type (aka schema) definitions (also in XML), generic > stores and processors, etc. I realize that that list starts to sound > more like "benefits to the programmer" rather than "benefits to the > user" so, another way to say it is that XML-based approaches give > customers a lot of liberty to invent new database structures because, > from just a definition of the new structure, the customer can get a > working database, working exchange format, and to some extent a working > UI pretty much "for free". > > The medical record standardization efforts you link to above are a good > example: domain experts in medicine concentrate on applying their > knowledge to things like translating a paper Continuity of Care form > into an XML type. Increasingly, we should expect the results of such > efforts to be more and more "directly executable" -- those guys are > doing the heavy lifting of writing entirely new applications. pb: Lawrence Weed first published a paper on EMRs in the late 60s. WEED LL.<http://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmed&Cmd=ShowDetailView&TermToSearch=14160426&ordinalpos=31&itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum> MEDICAL RECORDS, PATIENT CARE, AND MEDICAL EDUCATION. Ir J Med Sci. 1964 Jun;17:271-82. No abstract available. PMID: 14160426 [PubMed - indexed for MEDLINE] Later, he wrote a book Medical records, medical education, and patient care;: The problem-oriented record as a basic tool- I read it cover to cover in 1992. In the book, he gave fresh perspective on the linking of medical literature to the patient in the office in front of the physician. Today, he is founder of www.pkc.com However, there still is not a EMR capable of 'linking' knowledge. Proprietary code and profiteering prevent real progress envisioned by Dr. Weed. I paid a consultant to link www.pubmed.gov w/ a website in my office - because I didn't know how to do it. It works and I think is the information gathering arm of the 2 armed beast of knowledge coupling. But, it remains unlinked from the EMR I was using. > Doesn't a HIPAA compliant system also have to restrict access on the > > basis of roles and privileges? So you'll need some sort of access > > control lists or other security controls to even get in the door. > > It's even worse than that. To really get anywhere you not only access > controls based on roles and privileges, but you need to innovate a > little bit about how to implement those. The problem is that, as an > industry, health care needs to learn to maintain widely distributed, > portable records. Yet, during transport from one end-use to another, > we should expect this data to pass through plenty of untrusted > processes. Therefore, I predict (not very boldly -- it's obvious), > that standards for encrypting XML content, standards for signing XML > content, standards for distributed management of "identity", and > standards for managing public cryptography keys are going to become very > important in the near future. pb: Security innovations are as old as the hills, but became a software problem when computers developed the capability of partitioning user information (R. Stallman knows this better than anyone). In the 'real world' trenches of medicine, security of a properly configured LAMP server surpasses "paper" and all EMRs. Security is not the EMR's role, although they think it is. Although GNU/Arch may not provide the security level needed, proper configuration of the LAMP server hosting GNU/Arch can provide more than enough security for HIPPA, and plenty more. In fact, a LAMP server will probably raise the bar for HIPPA as to computer security. IME, opening a MS server to the internet for tech support is risky. Most RDB companies provide their service accross the internet (and it's a booming business). MS Windows is a terrible security risk and I know if first hand. In 2002, tech support logged in and infected my network w/ nimda. I never found the smoking gun, but it was a wakeup call as to what HIPPA really means for binary data; nothing. Frankly, HIPPA amounts to nothing more than simply verifying the user and restricting roles. That's old school for LAMP. HIPPA is not a deal breaker for GNU/Arch. from the CCHIT website: CCHIT was founded in 2004 with support from three leading industry associations in healthcare information management and technology - The American Health Information Management Association (AHIMA), the Healthcare Information and Management Systems Society (HIMSS) and The National Alliance for Health Information Technology (Alliance). In September 2005, CCHIT was awarded a contract by the U.S. Department of Health and Human Services to develop, create prototypes for, and evaluate the certification criteria and inspection process for EHRs and the networks through which they interoperate. More information on CCHIT and a list of CCHIT Certified products is available at www.cchit.org. > One last comment - where's the money for it going to come from? > > Are you asking me or Patrick? > > > Health records are not my primary focus -- I'm aiming for a bigger > target with health records as a potentially tasty application. I'm > doing "lower level" work that "enables" stuff like health record > applications. > My plan, such as it is, is to try to make money "on the margins" of a > distributed, anarchic build-out of an important new open source > technology. Right now, the work I'm doing is an investment being made > by fiance and I -- I leverage some of this work for my part-time day job > and we invest some of our household income in my spending plenty of > additional time on this "practical research". I think that when I > "release early" the open source results, astute people in the open > source community will likely want to use the code, probably fork it and > improve it on their own, turn into direct-to-customer products of their > own, etc. By making money "on the margins" I mean that I intend to > charge small amounts for the download of some (GPLv3) components, charge > for documentation downloads, charge for a la carte consultations, > etc. That's chump change per transaction but, for a family business, > chump change can quickly add up. Of course, I'll also keep my eyes > open for unique direct-to-customer niches that, by luck, I'm the best > positioned to pounce on, build some equity, sell a company (or just > operate one), and "win big". This being open source, the "big" investment building out this new > technology is likely to occur (if it does at all, knock on wood), in a > distributed, incremental way. My job as an open source researcher is > basically just to create the "frame" -- to create the new market for > that incremental, distributed investment by "shaping" the technology the > right way. > > > -t pb I hope you join in... https://sourceforge.net/projects/medsystemsgnu/ , or at least lob some advice when you see me struggle. 5 years ago I dropped 8k into Praxis EMR www.infor-med.com with the understanding that I would be provided 'lifetime' support. For me, that meant 25 years of practice before retirement. That 'lifetime' support has been shifting horizons for the last 24 months and 2 weeks ago, after a hard crash of a dual AMD64 running 4GB, MSwindows server, I was locked out of 5 years worth of patient information. Without getting into the nasty details, I informed my staff to utilize PraxisEMR only for archiving information, and sent the following email to the company.. Hello Mr. Gutierrez, > > I am using Praxis only for retrieving archived data and have returned to > paper charts again. > > Unfortunately, Praxis does not have the capability of printing the entire > chart at once; it never has and continues to crash (softly now) when more > than one visit is selected for printing. So, as we require the information, > it is carefully selected from Praxis and printed for the new paper chart. > > As you know, I have over 5 years of paient information archived in Praxis. > > Your suggestions for developing a successful exit strategy from Praxis > would help. > > Thank you, > > Patrick Blanchard, M.D. > Board Certified in Family Medicine > Fellow, American Academy of Family Practice > > > -----Original message----- > From: "Martin Gutierrez" [EMAIL PROTECTED] > Date: Mon, 06 Aug 2007 08:32:07 -0500 > To: [EMAIL PROTECTED] > Subject: praxis don't open > > > Dear Doctor Blanchard, > > > > > > > > By the time our team got to your practice, your office was closed. > > > > > > > > Please have your staff call us at 818 592 2900. We'll like if you could > > restart Client 32 on your server and let us know, so we can log in an > check > > how is running after the last recovery > > > > > > > > Warmest Regards, > > > > > > > > Martin Lucas Gutierrez > > Director of Customer Support > > Infor-Med Corporation > > 6271 Variel Avenue, Suite A > > Woodland Hills, California 91367-2512, USA > > Phone: 818-592-2900 > > Email: <[EMAIL PROTECTED]> > > URL: http://www.infor-med.com > > <http://www.infor-med.com/><http://www.infor-med.com/%3E> > > > > So, no response, and I don't really expect one, and I'm on my own. Where is the 'lifetime' support?'. As to my business, it's like yours Thomas, and I hope you the best. Your motive are admirable. FWIW, I donate every now and then, but not near as much as what I recieve in return. Frankly, I don't think MedSystemsGnu will be a money making machine, but thats not its point either. But look at CUPS, and we will never know the details, but someone somewhere is financially better off; http://apple.slashdot.org/apple/07/07/12/1342258.shtml OK, today when I woke up, a goal of mine was to get GNU/Arch running on a PII w/ 128MB RAM. So, it's back to the salt mines, to round at the hospital and also to finish my paperwork from yesterday's clinic! Patrick
_______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
