** Feel free to remove that gosh-awful subject line ** The threads seem to be merging; and that's a GoodThing(tm). Joseph's post appears to be an invitation to provide a kind of project summary in regards to the issue of 'not operating in a vacuum'. Background: (Caution! US centric viewpoint) This very broad subject is somewhat based on the point of reference/view of the participant. The goal of my project is to produce an EMR & practice management system that meets or exceeds the functionality / price point of the small physician practices, usually found in rural areas. These practices are typically 1 - 15 physicians that operate from 1 - 5 physical locations. Their current options for an EMR range from the low end single user or LAN based systems to the mega $ Epic's. The low end doesn't provide the connectivity/mobility they need and the high end systems cost too much. This leaves a huge middle-market (+90% of physicians in private practice) still unserved by the EMR. Virtually every practice has an installed practice management system. They may or may not be using all of it's functionality but they at least use it for billing purposes. (As I understand, most of them fall short on actual data drill-down for business decision making). Anyway, in spite of the name we determined that it was more beneficial to build an EMR (the data collection begins with the provider/patient interaction anyway) and have the flexibility to connect to existing PM applications. Being one of those people that saw the world in 3NF most of my adult life I promptly chose a good open source RDBMS and, wanting as many people (domain specialists) to contribute as possible I determined that the application should use a scripting language probably augmented with some C when necessary. PostgreSQL and PHP, a great combination behind an Apache server would allow access from almost any client hardware as well. The more we massaged the ERDs, the bigger the holes got to be. No wonder these system cost so much, this medical stuff is hard to model! Now, I had poked around OO design stuff for a few years but it was VERY strange. Just didn't seem to be very practical. Besides, you had to store the objects somewhere, usually in a RDBMS. I read a little more about object persistence and OODBMS'. When I read a mention about Python and Bobobase it lead me to a product called Principia that the company was combining into what we now know as Zope. I saw some pretty impressive web sites that Digital Creations had built with this stuff but every time I tried to use it, it broke in very strange ways. Persistence (pun intended) paid off. The Zope/Python/C combination is powerful! Now: Right now. Today. FreePM-1.0b1 is on the server ready for download. It is also on the demo site ready to be tried out. This is the electronic medical record application that most of you designed. I did not do this in a vacuum. I know far to little about medicine to have built this application. Each physician here will find something they don't like about it. The reason is because each of you have slightly different perspectives on what 'practicing medicine' involves on a daily basis. A little over two years ago I started asking questions. Many times I had to make a decision based on available technology or the majority of comments. Sometimes I made decisions based on what I thought was sound design principles or a gamble on which future technology would win over another. Many times I scaled back features (some may say requirements) in order to maintain flexibility. I did this because you (or someone) can always add them into YOUR installation. What does this have to do with inter-operability? Gambling & flexibility. I admire the work done by OpenEMed. Two years ago I was certain that CORBAmed was the solution. I still think it will play a KEY role in the solution to the world-wide federated electronic medical record system. I'm just not so sure it'll happen in my lifetime. (It's a political issue not a technology issue). When that WW-EMR is unfurled, it will be passing archetyped data, because that will already be the proven inter-application communication methodology. Right now, FreePM can directly exchange data with FreePM. How exciting!? But, the infrastructure is designed so that it can pretty easily exchange data with all RDBMS' that I'm aware of (except native DB2 and we are internally working on that one) and anything with an ODBC interface. FreePM can export XML files and import them as a DOM tree. There is no XML-EMR DTD defined to export as; yet. Can we all concede that the WW-EMR is a few years away? Then, every EMR needs a home. Not only for technical reasons, but privacy ones as well. Although a case COULD be made for privacy through distribution I suppose <g>. I believe 'that home' should be on a server in the primary care physicians office. FreePM provides the ability to grant external logins via an http (and other protocols) connection. This can be the patient with access to only their EMR. Or a specialist that you often refer patients to can be granted access to all of those records. If you choose, it could be read only access. Tell me, which is the more privacy aware and cost efficient situation; (a) specialist logins in to review patient record & adds encounter note, (b) you give the record to a clerk to fax pages to the specialists office where a clerk (hopefully) picks them up and passes them to your nurse for you to review. Hopefully you sent all the info the specialist needs. Then the specialist dictates a note. Once it's transcribed they give it to a clerk to fax to the clerk in your office where it may or may not get filed promptly and correctly after you review it or (c) both offices have FreePM and the specialist exports the Encounter and emails it to you after reviewing the EMR on your server. You then import the encounter into the patient record. BTW: Imported encounters do not affect the patient account but it does become part of the history. At least initially, specialists will continue to maintain their separate medical records system. But, in the ... Future: All patient data will adhere to GOM_v15 and encrypted archetype packets will be sent to GOM routers that can resolve the destination url and validate the transmitting authority. I would expect that each application would perform a caching function and particular archetypes might cary their own persistence level. So a specialist might maintain patient data for three months or two years or ... Then if they needed to refer to that data after it had expired, they could retrieve it from the master patient record. Summary; Now I know that our resident security specialists (meant with the utmost respect, btw) are having a coronary about right now. We accept, with all of it's vulnerabilities, SSL as a secure electronic communications standard. Balancing all of the trade-offs, this has to be GES (Good Enough Security). Granted we may create a whole new class of criminals (the EMR-Vandal, steals EMR info and markets it to the highest bidder or uses it for blackmail). But; look at the clerk to clerk to clerk scenario that happens now. Is that REALLY secure? I also acknowledge that the AMOUNT of data at risk in swoop is very different also, but Our other option is to, wait... and wait.... and ... Joseph, aren't you glad you asked? <vbg> -- Tim Cook, President - FreePM,Inc. http://www.FreePM.com Office: (731) 884-4126 ONLINE DEMO: http://www.freepm.org:8080/FreePM
