Not to beat a (very) dead horse... My organization is doing this now. I work for a public health agency where the funding is state, federal, fee-based from insurance, grants, you get the picture. We have many programs and there are many different data/record keeping requirements, thanks to Virginia's ever-changing requirements, local requirements, and federal requirements. Public health is very complicated in this way. Our current system is okay, but our agency was looking for a product that really is the "electronic record", or as close to it as we could define. We spent over a year defining needs, requirements, reviewing demonstrations, looking at product flexibility, such. IT was involved as well at doctors, clinicians, licensure specialists, and supervisory staff. While IT manages the current system and will manage the new system, we didn't want it to appear like IT was forcing a decision and it was important for us to discuss only IT related topics. Only recently did we sign a contract with a vendor and we estimate it will be another 1 -2 years until we fully are migrated to it. I think the product was selected will suit us well. It's not the product as far as I can tell but: - failure on many levels to provide a working and realistic definition of what comprises "electronic medical record". - failure on many levels to provide guidance and what guidance there is can be conflicting between agencies. - failure on many levels to provide funding of any type to implement and EMR. - constant change in terms of data collection requirements from federal, local, and state agencies. - failure to realize that small entities cannot afford an EMR or may not have the technical/clinical resources to implement and EMR. So we are doing as best as we can with what we have. Our new system is SQL based (old was AIX/proprietary) and we will have the ability to export records in a variety of formats. We expect as time goes on we will adapt our system to whatever new and improved direction comes from our regulatory agencies. For me and my team (infrastructure) we look forward to this. For us this is something new. For the software team that does the programming they are sort of dreading it. Customization eats up time and staff resources. Tom Miller Engineer, Information Technology Hampton-Newport News Community Services Board 757-788-0528
>>> David Lum <david....@nwea.org> 1/12/2009 9:43 AM >>> I can’t imagine the hurdles involved, but if this comes to fruition (which I actually doubt), it would sure make all of us suddenly more valuable: http://money.cnn.com/2009/01/12/technology/stimulus_health_care/index.htm We would be in even higher demand than now and have a huge leg up on the folks who wanted to work in healthcare IT that aren’t already in IT. Not that I want to work in healthcare IT, but it might force other employers to raise salaries a little to keep their IT guys from jumping ship… David Lum// SYSTEMS ENGINEER NORTHWEST EVALUATION ASSOCIATION (Desk) 971.222.1025// (Cell) 503.267.9764 Confidentiality Notice: This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
