Uncategorized

What if I Had To Do HIT All Over Again?

This post is aimed at serving as an interlude to the “public option/death panels” discussions. No matter what healthcare reform bill, if any, is passed this fall, HIT will be part of the program.  Four short years ago I was involved in the creation of a comprehensive, some would say monolithic, EMR/Practice Management/Billing system. This new product was built in reaction to the very large, very expensive and very clunky systems already on the market.

Remembrance of Things Past – The driving design considerations four years ago

  • The problem – Paper charts are causing inefficient workflows in physician offices. It is hard to find pertinent information in a big chart and it is hard to analyze that information. Charts can only be accessed by one person at a time and cannot be accessed from outside the office. Charts are sometimes misplaced and may be lost during a fire or natural disaster. Every new chart costs money to create, store, pull and maintain.
  • The solution – Application software that provides a computerized version of the paper chart – an Electronic Medical Record. Computers are great at storing and arranging data in all sorts of ways and formats. Computers can analyze, graph and report on enormous amounts of data. The software should be web based so it can be easily accessed from anywhere by multiple users simultaneously. No more misplaced charts and no more wasted office space and a SaaS solution would make sure the records are disaster proof.
  • Constraints – The application must be pleasing to the eye, easy to use, customizable and economical to purchase. It should include standard practice management and billing features, or be able to easily integrate with such software. The application should ensure that all patient data is secure at all times.
    • Insights  – Medical records, whether they are stored on paper or ellectronically, are dispersed across multiple care systems. If the medical record is to be of any value, it must be comprehensive. Any provider, care giver or patient must be able to access data aggregated from all those  disparate sources, either “just in time” or from a centralized location.Evidence suggests that the few providers with EMRs in their practice are having difficulties using these systems. Aside from clunky features and bug infestations that plague the majority of EMRs out there, there seems to be one common complaint: cumbersome data entry and quality of resulting documentation. Last, but not least, is the cost issue. Most EMRs are still too expensive, particularly for small practices. There are two components to cost: upfront investment and loss of productivity over time due to the complicated nature of the software itself.
    • Perspectives – Any attempt to mitigate the lack of continuity in the medical record must begin with standards. Terminology and data standards, as well as communications standards. This does not necessarily imply one monolithic standard. There is room for many different ways of storing and transferring data, as long as the standards are documented and understood. There could be an industry niche for translation gateway providers (similar to the Star Trek universal translator). Of course, all standards should be open and free.Once the vast majority of providers, payers and patients have electronic capabilities, an addressing system should be created to allow “Just In Time” (JIT) access to medical records, no matter where the information resides. The aggregation should occur at the point of request and the translation gateways may fulfill this function as well. Some argue that it is better to aggregate all data in a centralized massive storage system. Building and securing such a “database in the sky” is a monumental task and the recent NHS experience suggests that this may not be the right approach. I am, by no means, discounting the logistic difficulties involved in JIT medical record aggregation, but technology is bound to advance and attenuate such difficulties.
  • Musings – The other day I was doing laundry in my basement. I found myself staring at the washer and dryer thinking that we tried to do too much with our EMRs and the technology was not there to allow it. Think about washers and dryers. You wash the clothes in one, manually move them to its neighbor to be dried and neither one sorts or folds laundry. Yet every household has a washer and dryer. Nobody is missing the old vats of boiling water and the big old wringer. The washer and dryer industry did not insist on a perfect, complete and seamless automated process.So why are we shooting for a paperless office? Because it sounds good? Let’s face it, no other industry has paperless offices. Not even the banks.Maybe we just pick a few things that are important and do them really well, instead of doing a mediocre job for everything.Maybe we computerize only data that is both pertinent to patient care and easily captured, codified and standardized.Maybe the EMR should neither sort or fold laundry. Maybe it shouldn’t attempt to create prose while physicians are required to painstakingly click on a multitude of little boxes.Maybe we take a step back and provide simple, basic, robust and really useful tools instead of one big unwieldy glob of software.Maybe one day technology will advance enough to obviate the need for manually collecting data at the point of care. Maybe the EMR will just sit there and quietly observe the patient/doctor interaction, while continuously processing and recording pertinent data on its own. The perfect scribe. It sounds like sience fiction, I know, but so did many other things that we now take for granted, like washers and dryers.

After all the customary trials and tribulations, a software product was born. Features were added, directions were changed, certifications were obtained, and like all software applications, the EMR kept on growing and progressing on a predictable trajectory. I was fairly pleased. But, what if…?What if I had to do it all over again? What if I was starting today with a blank piece of paper (or whiteboard) trying to design the perfect EMR? Would my considerations be different than four short years ago? Would the design principles be the same? What about the implementation?  Would today’s technologies be able to provide solutions to yesterday’s insurmountable problems?

Prelude to a Philosophy of the Future – Insights, perspectives and musings

So if I had to do it all over again, I would take a hard look at Microsoft Office. I would build multiple useful applications, like Word, Excel, Power Point, etc. I would make sure I can export data from one to the other. I would make sure that the user interface is consistent between them. I would allow others to create templates and integrate their software into my tool bars. I would borrow from Google and make it all web enabled and capable of communicating with all interested parties. And if I had all the money in the world, I would make it open source and free.Yes, I know, it sounds an awful lot like Clinical Groupware.

Margalit Gur-Arie is COO at GenesysMD (Purkinje), an HIT company focusing on web based EHR/PMS and billing services for physicians. Prior to GenesysMD, Margalit was Director of Product Management at Essence/Purkinje and HIT Consultant for SSM Healthcare, a large non-profit hospital organization.

Livongo’s Post Ad Banner 728*90

Categories: Uncategorized

Tagged as: ,

45
Leave a Reply

45 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
14 Comment authors
FedererJohn Haughton MD, MSJonThe EHR GuySTOPGdnshipAbuse Recent comment authors
newest oldest most voted
Steve Beller, PhD
Guest

I appreciate your point of view about XML and CSV. I believe the conflict typically stems from how CSV is commonly viewed, i.e., just an array of data in which fields (columns) are separated by commas and records (rows) by line breaks. People are surprised to discover that all the elements, attributes, and hierarchies from an XML file can be conveyed more simply in a specially constructed CSV or spreadsheet file, which can also be pre-serialized and whose data elements are able to maintain “live” numeric values without transformation. Nevertheless, this is not relevant to html presentation. Instead, CSV has… Read more »

The EHR Guy
Guest

Well, well, Just thinking about going from XML to CSV is ludicrous. Please pardon my characteristic bluntness. XML is based on a principle required for efficient information interchange: It is structured data that can be easily validated. CSV is difficult to validate in a universal sense. XML derives from the very succesful HTML. Billions of succesful information exchanges are performed every second with HTML. XML is in high use in every industry that uses information technology. CCR and CCD leverage XML for this reason. CCD derives from CCR but it also leverages the HL7 RIM, so in essence they are… Read more »

Margalit Gur-Arie
Guest
Margalit Gur-Arie

Dr. Beller, click on the common network tab at that site. Every flow chart element has an associated PDF. There is a wealth of information in each one, including network communications.

Alexander Saip
Guest

I hope you may be interested to read my today’s post at http://betterhc.blogspot.com/2009/09/health-it-goals-concerns-and-choices.html , where I mentioned some challenges of creating comprehensive patient health record, among other topics.

Steve Beller, PhD
Guest

Thanks, Margalit. I knew Carol is with Markle’s Connecting for Health, but I’m uncertain where she discusses P2P pub/sub architectures. Concerning CCR/CCD, I believe one thing making CCR simpler is that a CCD contains embedded html tags and much more tagged metadata in addition to XML data & their markup tags, whereas the CCR is just the XML data and their tags. A corresponding CSV, on the other hand, has no such tags and converts immediately into a basic data grid that can be rendered, for example, in a MS Office-based report that contains (conditional) formatting instructions. XML-based CCDs and… Read more »

Margalit Gur-Arie
Guest
Margalit Gur-Arie

Dr. Haughton, I find the work you are doing at DocSite very impressive. I have been working in the comprehensive EHR/PMS/Billing arena for quite some time, and as the article above implies, I am starting to wonder whether this is the only way, or even the best way.
It’s beginning to look to me that having a well appointed toolbox, may be more valuable then having a glitzy all-in-one big tool, and any mechanic would likely say the same.
I’m probably going to have to think some more and write some more just to clarify things for myself…..

Margalit Gur-Arie
Guest
Margalit Gur-Arie

Dr. Beller, Carol Diamond’s work is part of the Connecting for Health initiative of the Markle Foundation.
Here is the URL for that project:
http://www.connectingforhealth.org/
Regarding the CCD/CCR standards, I find the CCD to be unnecessarily complex. The CCR is rather simple and nimble, but that could be just a personal preference.

Steve Beller, PhD
Guest

Dr. Haughton: I’m interested in learning more about Carol Diamond’s call for use of a pub/sub node-based HIE / NHIN infrastructure. Do you have any links you can share? And concerning CCD vs. CCR, I think their reliance on XML makes them both more complicated and inefficient than is necessary. I say this because the data they contain can more easily be laid out in a comma separated value (CSV) file (including any parent-child hierarchies, although they are rarely, if ever, required for health data exchange). In fact, I’ve developed an open source app that uses an MS Excel VBA… Read more »

John Haughton MD, MS
Guest

Interesting thread… Some thoughts… 1) The last post about A and B getting translated by an intermediary pretty well describes the desire behind RxNorm (input Multum, First Databank or other and translate to RxNorm or one of the other systems) — Good idea, would be even better if the Government would create an open wiki or similar to create a crowd-sourced comprehensive drug-drug interaction system (Would cut about $20/Doctor/Month off the cost of e-prescribing, now paid to Drug Data manufacturers). 2)The Pub/Sub Node with some reporting central store – describes well Carol Diamond’s and lots of others architecture for an… Read more »

Jon
Guest
Jon

Check out this blog post – http://ourhealthcaresource.com/2009/08/18/physician-know-thy-patients/. Good article about a health care plan with a unique, digital tool that helps docs better manage Medicaid patients.

Steve Beller, PhD
Guest

“The interesting thing is that the only ‘standard’ that clinicians use in the daily care of people is English. I think this is unlikely to change, Dr. Beller.” Good point, Dr. Dussia. I’d go one step further: I believe our country should be engaged in international collaboration and research, so English isn’t even a universal standard. In any case, using a pub/sub node-to-node architecture, there can be one or more nodes between the publisher and subscriber that serve a data translation/conversion function via mapping methodology. That is, if the publisher uses a local terminology standard “A” and the subscriber uses… Read more »

Evan Earl Dussia, II, MD
Guest

Ms. Gur-Aire, you said, “However, in the more common situation where the ED has a totally different system, there is a need to somehow export/access the Medisyn records to/from the ED system. It will be almost impossible for the ED system to decipher and assimilate your very nice, but free text based, problem list and medications.” In my opinion, there is a big difference between the ED doc and the ED system. Since I am interested in taking care of patients, I designed the Medisyn system to allow the ED doctor (or any other clinician) to have necessary and sufficient… Read more »

The EHR Guy
Guest

I agree with the previous comment made by Steve Beller.
Thanks,
The EHR Guy

Steve Beller, PhD
Guest

I don’t think there’s a lack of standards … It’s more like there are many different standards (including technology/messaging standards, terminology/data standards, and care measurement and process standards), which continue to evolve over time. As I discuss at this link — http://curinghealthcare.blogspot.com/2007/05/art-of-health-knowledge-creation-use.html — standards can be a double-edged sword: While on the one hand they can promote interoperability, knowledge growth, and better understanding, they can just as likely impede creativity, increase costs, and inhibit knowledge and understanding. That’s why I argue that HIT tools should be agile enough to embrace all useful standards…the one’s that are currently mainstream, the ones… Read more »

The EHR Guy
Guest

Someone has been doing investigative homework. 🙂