Active Forum Topics | Getting Started | Interviews | EMR Forum | Medical | Billings | Press & News | Voice Recognition | The Water Cooler
I finally got an invite to Google Wave. Here is a wave about EMRs:
Electronic Medical Records (EMR) and Medical Information Systems: Is Wave the future of electronic medical records?
I believe that Google Wave could form a great platform for recording patient case files in the next generation electronic medical record.
In the real world of medical practice, things do not happen sequentially and more than one person is involved in managing patients and there are different kind of data including sonograms, lab reports, CT/MRI images, monitoring data as well as history examinations, opinions and consultation records.
It is important to know the chronology of events and the ability to replay events would be a great facility. While Wave as we have it today have major limitations, it could be the base platform for building the Next Generation Medical Record.
Each Patients record will be a wave with different entries being blips. As each patient visits different healthcare facilities, then the wave can be shared. Here the patient and the healthcare providers and third party service providers (eg private labs) can participate in the wave (EMR)
The challenges will be to incorporate the demands of structured informaion to make the data sentient and to enhance security in a controllable fashion.
This requires a lot of conceptual thinking now and it is high time that some body starts working on this.
I am looking forward to likeminded people joining me in developing this idea further.
Google is perhaps the best ecosystem for such a revolutionary idea
Basic Structure of Medical Wave Federations
Wave : Each patient has a wave to him/her with a unique wave id which is to be assigned by the primary service provider or the government agency or Insurance.
Wavelets: Each hospital admission or patient visit will form a wavelet. All transactions within that admission or visit will done through that wavelet. Care providers (doctors) will have read/write access for their wavelet (depending on the hospitals or clinics delegation policy, individual or multiple doctors within that service -which may be at the level of clinic/hospital or unit level or individual doctor level).
Doctors will have read only access to older waves and will not be able to see subsequent wavelets unless the patient comes back to their care through consultation or admission. To seek clarifications from previous doctors they will have to initiate wavelets where others will have view access on need to know basis.
Patient Centered Medical Records
Currently the medical record systems are centered around the databases (by the database for the database) with everything else configured around this. Choice of the database/vendor determines everything else. In Wave, we have an opportunity to make the databases to make them invisible and peripheral, them to the background. Multiple databases residing in different service providers (or in the cloud) can do their job, ie store and make available relevant data to the patient's wave or wavelet.
Data Servers: Primary clinical data (investigation reports), DICOM images, administrative transaction records including accounting and process controls will be hospted by their own separate servers. The intention is to disaggregate all services to small manageable sizes. [Since waves will talk to multiple database servers, it does not matter how many servers are there in each hospital]. These data servers can be the current legacy databases or future databases where it would be possible to "playback" data states of individual patients based on time. [We doctors need to know more than the latest state of knowledge but want to know what was known at a particular point of time when a certain decision was made ie the context]
Gadgets: The doctors or other staff access the servers and data bases through gadgets and robots. For example. There will be one or more applications which connect to a given database. Every database will need at least one application to render its data. You can have multiple gadgets that talk to the same server to accoumplish different tasks in different contexts. The gadget development and mating with the servers should be standardized so that one can quickly customize the gadgets to different functions and servers. Different specialists and "roles" can have their own gadgets which most suited to them (I liked your argument for mac specific softwares although I dont like the idea of closed systems like that of apple)
DICOM Renderer - an example gadget: An example of a gadget would be a DICOM reader which retrieves DICOM images for that patient and renders them within the wave. This gadget should have the following functions and attributes.
a) Retrieve and show images (there wont be any need to select the patient since the gadget would automatically populate the images and modalities available for the patient.
b) Display and view the images in a way as to be able to study, manipulate and analyze and report
c) Display image selections and insert them into the main case sheet to illustrate points and make the story meaningful [So it is more than a dicom reader - It helps in creating the final medical record which will be in a format familiar to doctods but based on a structured data which makes sense to machines]
d) Image data itself will not be stored in the wavelets but in dedicated PACS servers (as it is today) but the wave will store the operations done on these images and will "recreate" the documents based on the primary source files on the servers and the record/history of operations (just like wave does other things)
e) Since the gadget only retrieves and present data based on a primary source resident in the image/PACS server the security of the primary source is not compromised, and it would be compatible with legacy systems.
Clinical Photograph viewer: Stores and renders clinical images and automatically inserts relevant images into the narrative of the electronic medical record. You insert the images into the document just like you do in a word document but the wave itself does not store these images. Principles and elements of Picasa can be adopted here. Only the manipulations are stored but the primary source data is preserved in a secure server.
Hematology/Chemistry Lab report viewer: Retrieves presents Laboratory data in the following ways
a) Snap shot view (multiple reports within a narrow time window or instant)
b) Longitudinal view Serial records of one or more repeated tests presented preferably in a graphical format which is integrated with other customizable elements.
b) Mixed view
Specialist/clinic customizations: Each speciality have their own ways of functioning and needs including ways of thinking. All of these can be met by designing custom gadgets to improve speciality productivity. I can create gadget specific to my Rheumatoid arthritis clinic or Lupus clinic or another one for New patients in the general rheumatolgy clinic
Uh, do I know you? I mean, I like the idea… it is yet another great use for Wave, but… I’m just curious how you knew I had anything to do with medical systems. It’s not a widely-known fact.
In any case, the best way to implement this, would be custom payloads in a walled federation garden (you don’t want to open the system to security issues, HIPAA and all that… well, I just discovered that you’re in India, so maybe it’s not an issue there, I don’t know… but it certainly is, here in America). And for that to be useful, you need custom medical Wave clients… and for that, the client/server protocol has to be finished. Which is my primary goal at the moment in any case.
So, yeah, I probably won’t be too involved with this at the moment, but once all of the XW protocols are implemented to some extent, I’d be willing to come back and take a closer look at implementing some medical systems on top of Wave.
I did not know that you were involved with medical informatics but, I noticed your deep enough understanding of issues and your work on client server system which (as you have correctly mentioned and I realized was possible from your blips) made me realize that you might perhaps get a an idea of what I was thinking about. I never intended the wave in its present form to be useful for medical records. In fact I was excited by the possibilities of integrating the diverse viewpoints and workstyles in the medical world. I have been greatly frustrated by the limitations of present and even under-development medical information systems. I have a dream about how these systems should be like and is aware of the challenges (although a doctor, I have interacted with people during Medical Informatics conferences and with the engineers implementing the system hand over in my hospital (I am the nodal person for my department for the system implementation developing and approving the custom workflows and department specific requirements).
There is very little penetration of EMR in India. Our hospital has a legacy (custome designed but later became the basis for C-DAC HIS) system from 2000 and is going in for a customized HIS by SRIT. As such there are no stringent regulations and we have relatively open system where records are accessible to all doctors in the hospital. I strongely believe that security issues can be sorted out if you can implement ACL based purely on Medical functions. ie hospital process centric rather than IT centric. Delegation of authorities should be centred on the medical functions. It definitely has to be a federation of Medical Specific waves.
However there is a need to increase awareness and develop the tools necessary to accelerate the development and implementation of such systems. I can even foresee the nucleus of a new Oracle like company even (It is possible). Ever since I saw the wave, I realize that the technology allows sufficient flexibility to capture the complexity of medical thinking work styles while preserving the order necessary to make sense of the data
I shall outline my vision for the basic architecture for a possible future Medical system which function in a wave federation environment
You can periodically read whatever I write and can give your inputs at your leisure. Meanwhile, your current work is very important for this mission. If you know any one, who could be able to give inputs or contribute, kindly introduce them to this wave
Sorry for my convoluted un ending sentence style
Able, first we need to define what we want - may be a wishlist. Let start with bullet points and then expand each bullet.
I am on it. My mental picture is running on steroids. I will slowly populate this with my condensed thoughts
I think the following must be considered before time, knowledge and effort is placed into this opportunity:
Review existing Health software and how well it is being used, and what technologies are being used within departments related to the software.
Review IT-related business practices and requirements against industry best practices.
Conduct high-level assessment of processes to identify those that were beneficial and detrimental to Health Care implementation and how they can be improved.
The majority of the information can be gathered from hospital management and IT staff. Team interviews can be conducted with hospital management in order to ascertain overall effectiveness of the existing IT solutions, and the support related to those systems.
Individual interviews should be implemented and department walkthroughs to gain a deeper understanding of IT system usage, workflow processes, staff roles and skill levels, and IT support structure.
Please “Ping” should you care to discuss additional implementation procedures.
I think the existing softwares are centered around the requirements of hospital managers. These systems tackle the demands of the managers very well. [It satisfies the people who decide on the budget]
In my view, the software must be centered around patient care. How different doctors go about managing patient care, social and cognitive processes involved in patient care rather than on the rather mundane aspects of adminstration and control of cost and revenue. I do not say that these things are not important, but they are assumed. Ultimately, healthcare is about treating patients in efficient and effective ways. How can IT contribute towards that.
What I am interested is in getting to the next higher level. Patient decision support systems. There is considerable resistence to the use of IT by doctors (not without reason). Current systems are a nuisance and actually hamper productivity and are a drain on doctors time. More over, the requirements of efficient databases and that of doctors in clinics and rounds are very different. So talking to hospital management will be a problem rather than solution. Current industry offering already meet the administrators requirements but do not come anywhere near the requirements of doctors.
Interviewing doctors also wont help since most have no idea about the potential of IT.
I already have an idea of how (all) these things should be. I am a doctor who became one by accident (moment of madness). But I have aleays thought about things the engineering way. Even while treating patients I do that.
I would like to convert this wave into a blue print or wish list for sketching how the future wave based EMR should be implemented. Broad outlines of architecture at this time. If we know what we want, technical solutions can alwas be found. What we have to keep in mind is the limitations and well as the strengths of the wave federation protocols. [We should not be bothered about the limitations of the Googles wave implementation which has been created for a specific purpose - as a laboratory to explore the potential of wave and to spur creativity and push the envelope]
I would like to participate. I noticed your wave in the public feed. Here are my initial thoughts.
Wave model for medical records.
1. Master Demographics wave per patient
2. Each encounter is a new wavelet (not wave)
a. Link from encounter wave to master
b. Link from master to encounter
3. Create Patients Folder (the sub-folders would equate to the medical record tabs)( No folders please. There is no need for folders. Each patient will have a single master wave with a unique id)
a. Create Encounters folder
I like the point that EMRs tend to make an encounter longer, so there needs to be efficiency not data bloat. (If you read what I wrote earlier, you will see that the wavelets should not form the primary source data but the place where these data are viewed, manipulated and presented so that meaning can be made out of these events)
My observation is to not add complexity to the structure which seems to already be inherantly unique.
Medical Decision making is complex. The freedome of Wave allows the complexity to be captured. Current systems are either simplistic or too unwieldy and time consuming whenever attempts are made capture complexity. What we need is a flexible system based on interoperable standards where you can select from a bouquet of gadgets to serve your unique needs
Dr, I don't come at this from the medical perspective. I created an EMR about 6 years ago based on letting doctors focus on medicine not on the process. When I set the system up it was based primairly on scanned documents and records that doctors normally interact with, but limiting it to access to the records. Thus saving time. All documents could be created and filed automatically. Interaction via keyboard or tablet pc.
There are two conflicting demands from doctors. One is the need to be intuitive and to follow a narrative style which goes with the thinking style. The other is the need for structured data which can be analyzed and presented properly. The power of visual information has not been explored fully in medical interfaces. I am a rheumatologist and treats patients with rheumatoid arthritis as well as connective tissue diseass. I have set ways of thinking when I see patietns of each disease which I can define formally. I know what information I am looking for. I want this information presented in very succinct manner with minimum waste of time and space. In my field I am actually interested in temporal and spatial information. Temporospatial information can be presented visually.
The space/time distribution of involved joints can be presented like a movie.
It can be supplemented with graphs of patient functional metrics and I can make decisions in a snap. Lots of the rest are checklists. which can be programed to give red flags
I ran into a similar situation with Penn Vet University where the additional need for analysis and training existed.
I know about set ways my first client was a surgen, and very set in his ways.
The requirement to aggregate across paitients was handled through the coding of billing information and then linked to the actual document.
Yes this goes back to your original requests for multiple gadgets and robots that doctors can mix and match to acheive their particular style.
There is another major problem with todays systems. They are designed to be closed and operate within closed environments. The future of health information system has to be such that, the systems of different hospitals and indeed even the general practitioners have to talk to each other. The wave federation structure would be very suitable
Absolutly agree, no one seems to be working on standards. Without standards the only one that I am currently aware of is HL-7 all of the money being spend on EMR is really a (hate to say) waste.
Every one is re-inventing the wheel and the wheels dont fit any other car
There is bound to be inherent resistance from service providers and above all big IT companies towards itneroperabilty. Every one wants to lock all hospitals into their (future) legacy systems
Yes all of the developers of software want doctors and hospitals to be tied to their product. AMEN
The developers don't, the big box vendors (bizfolks) in the US do... There's a lot of work being done in a lot of places to unfetter data :)
Even hospitals are not interested in having interoperable systems
Hospitals are very cheap in some strange ways. Care is good but what about the systems involved they can be 1000s of times better. And save money as well most hospitals are only focusing on 1 QTR out.
Two fold issue. First, most hospitals don't have good technology managers that can help them make technology decisions - they are GREAT at operations, but operations isn't everything.
Second, the impetus in the US is to buy from a big-box vendor (hey another HL7 stream, hooray! not). Unfortunately, most of these vendor's are at least one to two decades behind the curve and not catching up.
As an side, antiquated certification methods at the US FDA for certification of what they deem as medical devices is also part of the problem.
Would say that they know operations, but not human factors and process definition to come up with efficient ways to do what's right for patients.
As a side note, most software vendors have far too much functionality. When I implement most of them I spend more time dumbing down functionality so that end users can focus on their task rather than all of the functionality (noise) of the application
That is a point people forget until you are "down" with your new system. Every one wants their own little added function but forget the more important aspect of inactivating unwanted functions. Actually we want to quickly move from point A to point B without having to click umpteen number of times. We traverse the same routes so many times in predictable ways. There are quite a few set routine, What is needed is flexibility to customize.
I see the way forward as a system that will at first develop software which can link together small practitioners and clinics in an open ecosystem. It can even pay for itself. I believe that an IT system that can meet the need of diverse small practices and integrate private service providers (independant labs for example) can ultimately service the whole nation
My plan would be to develop something that can come from the grass roots. But even that is hard because selling a system into a practice is in direct competition with their billing companies. Which (billing systems) drive most decisions.
Todays systems are developed top down. I would prefer a bottom up approach, the kind of approach that has led to the creation of wave itself. Yes we are on the same wavelength now
I have a revenue model which will work in India (I dont know if it will work in US because of the unique regulatory demands). I think a open public service (free for doctors and patients) can pay for itself
The HIPAA issues can be solved through primarily policy, which in the US is constantly evolving. [I dont think they are insurmountable issues since the issues are well known.] Let us try to define new ways of working to maximize efficiency and be ergonomic for the brain.
We have to conceive of a system where patients, hospital based doctors, private service providers and even GPs can function together seamlessly.
All privacy and security issues are solvable technologically. Even Wave which at present is left wide open does not exclude a more secure implementation in the future. The protocol is not restrictive and would support security
Have already worked with them and have existing models that can be applied to new technology.
Good. I think things must be met half way. The problem is that most doctors dont understand the possibilities of IT so that it cannot be explained properly to the engineers. Then the so called "consultants" who come to intereact with doctors to develop systems are in reality some IT low life with no real perspective on the big picture
haha. Did I just read you calling consultants IT low lifes? You've won points with me there. Also, keep in mind, that at least half the issue lies with not having a plan or competent managers who understand the business of IT and the technology of IT, partnering up to deliver.
While everyone has to get paid, no doubt, that's not the only thing at play.
There are issues from both sides (IT, medical side)
There is so much demand for good IT people these days that any Tom *** and Harry can get higher than deserved position in IT industry. While there are a lot of highly intelligent people here in this forum, most of them I meet in the field are indeed low in IQ and conceptual thinking or in the ability to think out of the box or even comprehend anything beyond their daily grind. Alas if only there were more like Elliott in this field
Hey! I’m one of those consultants. d-:
In any case, I know what you mean about the doctors not being able to articulate their desires, when it comes to infrastructure. My clients have been using horrible GE DICOM systems for years, and they never realized how much they hated it until I showed them OsiriX. They were blown off their feet by each simple feature I showed them; things they’d wanted to do for years, simple things, but they had never known how to articulate them.
Interesting discussion, and quite thought out. This is the kind of thing I was hoping I would find on Google Wave. Well done! I've started a healthcare IT meta wave to list to other waves related. I've linked this wave and think the conversation is quite interesting. The healthcare it meta wave is Health Care IT Professionals - The Big Meta Wave
I can already see some benifit to wave when it comes to EHR. I'm picturing a tablet PC that can go with me anywhere
Netbook sized tablets are the way forward. However, they must have the capacity to handle a lot of DICOM images and may be with multi touch it may have a break through. As for me I am comfortable typing
Certain aspects of wave appear very usefull for an EHR. However, I fear that a much more "basic" version would need to be used to enable the digitally challenged health care practicioner (and patient) to use it. Perhaps we could start a mock wave to try and establish how this would work?
I think that is a great idea to start an example wave. Possibly based on the structure outlined by (I'll have to look for it it's in another wave will update this when I find the link
I believe that wave may not replace the database servers but will become the "arena" where the "players" including doctors, service providers, patients and even the databases themselves interact and transact business.
Wave will capture that interaction and becomes the document which is accessible as Electronic record.
At the same time, the legacy database servers will hold the source documents for accounts and investigations or other well circumscribed data which are already well served by present systems
I tend to agree with you that the legacy repositories are necessary for now, and we need to develop gadgets that allow interfaces to those systems. Eventually though it maybe worth looking toward a newer technology that lives in the cloud. Let me cite the announcement from Google today where 16TB of storage can be bought for roughly $5k per year.
I think the wave record should work equally with cloud depositories or legacy databaser or anything else even local records. It should be open. The configuration of the extensions will allow access to appropriate resources depending on your identity.
India is working on a "Universal ID" project for India residents. Such projects have to become "universal" for wave to reach full potential.
Mr J.
Ok, I've created the start of a patient wave; I invite everyone to add, following the descriptions as described earlier in this wave. Be creative!
I disagree with you regarding functionality.
While many doctors may not be well versed with technology, actual health care related activities are way more complex than other areas and wave can actually help capture the complex social aspect of health care decision making.
Current technology platforms ignore the social interactions that underpin medical work setting.
I started thinking about the possibility of a Wave EMR when I first watched the hour and a half intro video. I posted some things on emrupdate forum but no one there seemed interested. I finally got a wave invite and found this Wave. How secure is Wave data? Would it be HIPAA compliant? Would it be able to meet reporting criteria for P4P?
Bryan D. Uslick, MD CFCDD (Gastroenterologist) eMDs user since 3/3/2006. Currently using version 6.1 (Prior Praxis user.)
Provation MD endoscopy report writer
Google health wave on YouTube:
http://www.youtube.com/watch?v=7dOBeaD9gdg&feature=player_embedded#
I wish they would have given me some invites to invite some emrupdate people.
I arranged for Jason to get an invite .. didn't know anyone else was interested.
Graham http://www.synapse-ehr.com/ Synapse - the EMR for the superior physician
See if Matt Chase is interested in getting into that EMR wave. His background in granular data and XML would be helpful in fleshing out requirements for an EMR extension for Google Wave.
Google Wave could excel at communicating information but it clearly needs some basic health data structure which isn't there.
Data Federation in Google wave is the most impressive EMR feature.
However, other Core Google Wave features like real time (see each other type) communication are not really needed for EHRs - or even wanted.
I dont want to have anyone watch me type
In the end, well before Google Wave, there exists technology today to make an EMR that will propel medicine into the next generation.
Why is progress so slow ?
It's not a technology problem and Google wave predominantly shows off new technology.
The main barrier to EHR is who is going to pay for it, who's going to pay for the productivity hit doctors will face using EHR, will electronic records going to improve anything, will patients be happy with EHR security, will an EHR ever be usable and useful ?
Google Wave doesn't address core reasons why patients don't have a robust structure for digital medicine information.
Thus, it's Google Wave's "EHR prospects" are "not really that impressive".
IMO.
Even if Google created a great EHR, would doctors use it ?
email:
uslic001: See if Matt Chase is interested in getting into that EMR wave. His background in granular data and XML would be helpful in fleshing out requirements for an EMR extension for Google Wave.
Written in Java. I wouldn't touch it. Don't want to be snobbish but .........
As I wrote earlier, there are features of Wave which I found useful years ago and wrote in C++ in Medtuity. I particularly like the granularity of messaging, the contemporaneous collaboration on a record, the ability to reconstruct the record from the granules, the ability to remove granules, to show their origin, to pass them among computers, the ability to involve any number of users simultaneously, xml, xml, xml, among other features. We've added the additional layers needed for an EMR including "controls" capable of efficiently recording granules. These controls include simple checkboxes, radiobuttons, right/left/bilateral, calendar, draw-upon-images, numeric values, and many more; content specific to medicine, rx formulary, etc.
mchasemd: the ability to reconstruct the record from the granules
the ability to reconstruct the record from the granules
How are you using this ? I see this as important, especially as I enter things into the patient's EMR - not associated with a visit.
WIth XML, much information can be included with a granule, or very little. That is the power of XML.
So you can imagine how a granule can have a patient identifier, maybe an encounter ID, and perhaps an visit ID (when an encounter is appended again and again).
Similarly a granule can have a time/date stamp; an originating Medtuity instance ID (you may have multiple copies of Medtuity running on one computer-- such as a terminal server, or perhaps you have multiple facilities and you put one copy of Medtuity on one screen and have if accessing one database, and another copy of Medtuity on your other screen accessing another database as in a corporate health facility where the occupational charts are separated from the general medicine charts); a authenticated user ID; etc.
A granule also has a payload-- the stuff being documented in that granule. The payload might be an image that is drawn upon to show where that suspicious looking mole is, or the location of a breast lump. It might be a simple "(+) RLQ tenderness to palpation".
The granule can also carry formatting information, if appropriate, on how to format it in the note. The "(+) RLQ tenderness to palpation" becomes, for example, in the note, "On palpation of the RLQ of the abdomen, tenderness was noted." Allergies might be printed in a red font.
What really separates this from Wave is the hierarchical information. Most granules contain information about location. Maybe the granule originated in the HPI -- Examination -- Vital Signs section. That hierarchical information is always passed when appropriate. That's how planning is planning, and testing is testing. More importantly, that urine dip granule, the one done in the office, "understands" that it is "in-house" and not a "send out" and so when you chose to send your lab order to LabCorp, only the send-outs get sent. Included with the granule are also codes. The part doing the lab ordering looks into the granule for its LabCorp code. If not there, then it cannot be ordered electronically. Similarly, CPT, ICD9, NDC, SNOMED, and other codes can be identified in each granule, as appropriate.
While you might say you don't care about such a hierarchy-- you want your note free form -- there is utility in typing in the name of a med and the system understanding that it belongs in a particular area (HPI -- Medications) for example.
Frankly, this stuff could not be done without XML, at least not as elegantly. The reason is quite simple-- as the XML schema changes, it breaks nothing from the past, but allows new (more) information to be included.
Matt,
How are these granules different than any data element in any relational database?
Maybe XML is the format in which you package the underlying data, but data is data.
And I think I can break quite a bit by changing an XML schema . Just like RDBMS, when changing schemas, you have to be mindful of backwards compatibility, or it will break.
Margalit Gur-Arie
My brand new Blog: On Healthcare Technology
The primary format for saving the chart is not the granules. The granules hang around until the chart is closed-- maybe hours, maybe days-- and then the granules are consumed permanently into that encounter.
One of our customers updated yesterday and they had not updated in a year. There were many hundreds of schema changes to the database in the last year. (They had not updated because they were happy with it but they wanted a new feature, and that new feature had been put in some months ago, and so they updated.. The tracking board had maybe 40 patients on it. They were updated in about 10 min to the newest version. Not a single patient's record was harmed. Pretty much the same thing took place with another customer the day before (but they waited until the close of the day, not during lunch to update).
So I have to disagree with you on the XML schema or Db schema changes breaking things.
When a user updates to the newest version, it brings the schema changes along too.
We probably make schema changes once a week and we do it without worry because of the robustness of XML. It is exceptional in allowing change as our product improves.
There is a reason that Google chose it for Wave.
mchasemd: The primary format for saving the chart is not the granules. The granules hang around until the chart is closed-- maybe hours, maybe days-- and then the granules are consumed permanently into that encounter. One of our customers updated yesterday and they had not updated in a year. There were many hundreds of schema changes to the database in the last year. (They had not updated because they were happy with it but they wanted a new feature, and that new feature had been put in some months ago, and so they updated.. The tracking board had maybe 40 patients on it. They were updated in about 10 min to the newest version. Not a single patient's record was harmed. Pretty much the same thing took place with another customer the day before (but they waited until the close of the day, not during lunch to update). So I have to disagree with you on the XML schema or Db schema changes breaking things. When a user updates to the newest version, it brings the schema changes along too. We probably make schema changes once a week and we do it without worry because of the robustness of XML. It is exceptional in allowing change as our product improves. There is a reason that Google chose it for Wave.
I wish all EMRs had the foresight to design their database like you did Matt. It is frustrating to ask for a feature change and be told that it is not possible due to database constraints.
I think I may have not been quite clear in my comment.
Schema changes don't HAVE to break things. If not done carefully, they CAN break things. It doesn't matter if it's XML or RDBMS.
As long as you make your changes judiciously, as obviously you are doing, there is no inherent advantage to XML storage versus RDBMS storage, solely based on ability to modify schemas.
uslic001: It is frustrating to ask for a feature change and be told that it is not possible due to database constraints.
It is frustrating to ask for a feature change and be told that it is not possible due to database constraints.
Whoever is telling you that, is just providing an excuse. Some things may take longer than others, but databases can be, and routinely are, changed to accomodate new functionality.
The problem is not simply schema changes alone, but how easily those changes are made to a client's system. Is there a strong download mechanism? For example, no matter what the version number of your current product, will the download mechanism consume all the changes to provide a seamless upgrade to the newest version? No matter how many intermediary version are being skipped? Are those changes applied to all working copies (ie, each computer running the EMR)?
Can it be done by the end user without intervention from the home office? For example, we had many, many thousands of updates to the newest version with hardly ever a phone call from the end user. (I'm not suggesting that we have thousands and thousands of servers being updated with the latest copy of Medtuity; rather, users update frequently, exaggerating the number).
How are really lengthy updates applied, for example, where all old charts must be reviewed and data posted to a table? (This might occur with changes in Health Maintenance Guidelines or Longitudinal tracking). Is there a background process which can run on each computer to do the heavy lifting without causing the user to wait hours for this to be processed? What about the local cache on each computer-- Is it also updated?
There is no doubt that the combination of XML and relational database is extremely efficient in conquering these problems.
Again, there is a reason it was chosen by Google.
This is just a problem of writing the sql correctly.
A synapse database from 4 years ago has no problem of being updated to last week's schema.