How would your fix your EMR?
December 12, 2013 4:32 PM Subscribe
Medical Professionals: If somebody gave your office $20,000 to improve your medical records systems, what would you want done? What don't you like about the way your office's system works now? What are features you do like and want to keep?
I'm mostly talking about within the U.S. healthcare system, because that's where I live and work, but if you think your non-American perspective is applicable, please let me know. Also: Is $20,000 too little to make any real impact on even a modestly-sized office now days?
I'm mostly talking about within the U.S. healthcare system, because that's where I live and work, but if you think your non-American perspective is applicable, please let me know. Also: Is $20,000 too little to make any real impact on even a modestly-sized office now days?
Ours is pretty good as it stands, from a functional perspective. Honestly the thing I'd like most is more options for individual user personalization, both in the color themes and in the way various menus are organized (e.g. let me pick what order things show up in, so I can put my most-used items at the front of the list). I have no idea what the cost would be for such modifications. We use an EMR product that seems to have a huge market share already, though with some organization-specific modifications and ongoing support for such changes. I'd be curious to know how many facilities actually use a one-off EMR system that would benefit from a one-time modification.
posted by vytae at 4:54 PM on December 12, 2013
posted by vytae at 4:54 PM on December 12, 2013
Multi location practices routinely complain about the difficulty of scheduling appointments across locations.
This means things like, a patient calls location A and wants to be seen at location B because B has an opening sooner, or is closer to their house but they only have location A saved in their phone because they used to live near location A, or location B is the only office with appointments on Tuesdays which is the only day a patient can take off work. (that sounded convoluted because it always is)
But location A has to tell the patient to call location B, because location A doesn't have access to location B's computer.
Or if Location A does have access, it screws up location B because neither office refreshes often enough, so spots get double booked.
All hell breaks loose if for some reason Doctor X is usually in location A on one day but needs to be at location B that day.
Scheduling. Seriously, ask lots and lots of practices what problems they currently have with scheduling software. You will get mountains of information. Don't ask the doctors, they don't usually schedule patients. As the person who sits at the front desk and takes the phone calls and schedules people when they leave their appointments. That person will have the horror stories and the requests.
posted by bilabial at 5:35 PM on December 12, 2013 [2 favorites]
This means things like, a patient calls location A and wants to be seen at location B because B has an opening sooner, or is closer to their house but they only have location A saved in their phone because they used to live near location A, or location B is the only office with appointments on Tuesdays which is the only day a patient can take off work. (that sounded convoluted because it always is)
But location A has to tell the patient to call location B, because location A doesn't have access to location B's computer.
Or if Location A does have access, it screws up location B because neither office refreshes often enough, so spots get double booked.
All hell breaks loose if for some reason Doctor X is usually in location A on one day but needs to be at location B that day.
Scheduling. Seriously, ask lots and lots of practices what problems they currently have with scheduling software. You will get mountains of information. Don't ask the doctors, they don't usually schedule patients. As the person who sits at the front desk and takes the phone calls and schedules people when they leave their appointments. That person will have the horror stories and the requests.
posted by bilabial at 5:35 PM on December 12, 2013 [2 favorites]
Interoperability/interfaces between different EMR systems with different vendors. I want to be able to send an order from one system into another and be able to schedule that procedure. I then want to send those results back to the other EMR system electronically and have it stored in that chart without printing, scanning, and uploading PDFs. I want to be able to pull over patient demographic data from another system and check it against ours for patient registration. Etc etc.
Epic has CareEverywhere to do Epic-to-Epic chart sharing, but even that has its limits.
Anyway, that's more like a $20,000,000 request, but there you have it.
posted by Maarika at 8:32 PM on December 12, 2013
Epic has CareEverywhere to do Epic-to-Epic chart sharing, but even that has its limits.
Anyway, that's more like a $20,000,000 request, but there you have it.
posted by Maarika at 8:32 PM on December 12, 2013
I wasn't aware that you could throw $20K on a problem like this - I thought you pretty much pay for whatever system you choose and then you get updates on it if you beg for them or if the vendor decides they feel like it. But I work for hospital systems and not in an office, so my perspective may be different. I have, however, had in-depth experience with 4 different EMR systems, so I've seen a lot of things both good and bad.
- Minimize number of clicks, as latkes said. I also rage when there are extra clicks.
- Ease of use of macros and macro-type features (Epic has "Dot Phrases" for free text sections), these are key to getting charting done in a timely manner. One of the EMRs I've used did not have a macro feature - that boggled my mind.
- Agreed with interface between the EMR and other software, i.e. radiology, EKGs, labs. You need to be able to see everything in the same place without opening multiple programs.
- Make it hard to screw up. In one EMR I've used, you had to always free text in medication doses and routes instead of the formulary being programmed in. It was an extremely poor design from the safety perspective. Also, EMRs with too many pop-up warnings just end up with annoyed users who click through popups without reading them. Make sure testing results screens highlight the abnormal results so that tired providers don't just scroll by them and miss them, for example.
posted by treehorn+bunny at 9:01 PM on December 12, 2013 [1 favorite]
- Minimize number of clicks, as latkes said. I also rage when there are extra clicks.
- Ease of use of macros and macro-type features (Epic has "Dot Phrases" for free text sections), these are key to getting charting done in a timely manner. One of the EMRs I've used did not have a macro feature - that boggled my mind.
- Agreed with interface between the EMR and other software, i.e. radiology, EKGs, labs. You need to be able to see everything in the same place without opening multiple programs.
- Make it hard to screw up. In one EMR I've used, you had to always free text in medication doses and routes instead of the formulary being programmed in. It was an extremely poor design from the safety perspective. Also, EMRs with too many pop-up warnings just end up with annoyed users who click through popups without reading them. Make sure testing results screens highlight the abnormal results so that tired providers don't just scroll by them and miss them, for example.
posted by treehorn+bunny at 9:01 PM on December 12, 2013 [1 favorite]
Also: Is $20,000 too little to make any real impact on even a modestly-sized office now days?
To do any serious amount of workflow customization of an EMR system, yes, especially if you don't have the IT resources in-house to do it, which a mid-sized physician practice certainly would not. Depending on the market, a decent Epic analyst working on short-term contract, for instance, bills in the neighborhood of $165-$185 an hour. That's three total weeks of labor at most.
For most of the suggestions here, you would need multiple analysts too. For latkes' suggestion around streamlining the discharge workflow, for instance, you would probably need both an orders analyst and an admit/discharge/transfer analyst, and possibly a couple of hours of a pharmacy analyst's time too to clean up the discharge meds.
posted by strangely stunted trees at 9:05 PM on December 12, 2013
To do any serious amount of workflow customization of an EMR system, yes, especially if you don't have the IT resources in-house to do it, which a mid-sized physician practice certainly would not. Depending on the market, a decent Epic analyst working on short-term contract, for instance, bills in the neighborhood of $165-$185 an hour. That's three total weeks of labor at most.
For most of the suggestions here, you would need multiple analysts too. For latkes' suggestion around streamlining the discharge workflow, for instance, you would probably need both an orders analyst and an admit/discharge/transfer analyst, and possibly a couple of hours of a pharmacy analyst's time too to clean up the discharge meds.
posted by strangely stunted trees at 9:05 PM on December 12, 2013
I'd need more information about where the money is coming from and how it can be used before I could make suggestions.
Is it just for development on the EMR and IT system? Is it the money itself or is it a contractor donating $20,000 worth of developer time? Does the money cover support and training when the improvements are done?
Could it be used to hire a medical scribe? Could it be used to pay for a scanning service and other non-EMR improvements?
$20,000 seems like a small amount to provide real improvements to an entire system or an EMR app (especially if it's an external one like Epic or Centricity and not an in-house one where someone could come in temporarily and do development work on it).
Maybe this amount could cover creating a mobile app that the practice could use or distribute to their patients, separately from the EMR.
posted by cadge at 8:17 AM on December 13, 2013 [1 favorite]
Is it just for development on the EMR and IT system? Is it the money itself or is it a contractor donating $20,000 worth of developer time? Does the money cover support and training when the improvements are done?
Could it be used to hire a medical scribe? Could it be used to pay for a scanning service and other non-EMR improvements?
$20,000 seems like a small amount to provide real improvements to an entire system or an EMR app (especially if it's an external one like Epic or Centricity and not an in-house one where someone could come in temporarily and do development work on it).
Maybe this amount could cover creating a mobile app that the practice could use or distribute to their patients, separately from the EMR.
posted by cadge at 8:17 AM on December 13, 2013 [1 favorite]
I used to be a clinic manager outside the US; but none of this is national system dependent.
1. Have good checks and warnings in place to flag missing parts of a file--so when the person who works at the front desk on Tuesdays throws all of the referrals into a drawer instead of scanning them and attaching them to patient files in the system, someone finds out about it on Wednesday instead of two months later.
2. Have an incredibly simple "save this appointment time" function. Most systems seem to require full patient information to reserve an appointment, but this is a problem because the person who works on Tuesdays is not a fast typist, so when she is busy on the phone, she takes notes on paper and then enters the appointments into the system later. Except sometimes she doesn't enter them later, and they get double booked. It would be better to have a mystery appointment with no details at 10:30 on Friday, rather than two patients unexpectedly showing up at 10:30 on Friday.
3. Make sure all of the software allows importing and exporting of data. A big part of my time was spent transferring medical report data from the software the doctor and technicians used into the appointment-scheduling, report-distributing software. Neither program made it possible for us to transfer the data from one to the other digitally, so it had to be done manually.
4. On that note, make reports customizable. One reason we spent all of that time manually transferring data was because the doctor didn't like the report format in the clinician-side software. But the software we used at the front desk didn't have the clinical features we needed. Customizable reports in the clinical software could have made a big difference.
(It's been a couple of years since I was in that role, but I would be surprised if these issues have been fixed in that time. The person who works on Tuesdays is a fictional character and any resemblance to real clinic staff is coincidental.)
posted by snorkmaiden at 9:22 AM on December 13, 2013
1. Have good checks and warnings in place to flag missing parts of a file--so when the person who works at the front desk on Tuesdays throws all of the referrals into a drawer instead of scanning them and attaching them to patient files in the system, someone finds out about it on Wednesday instead of two months later.
2. Have an incredibly simple "save this appointment time" function. Most systems seem to require full patient information to reserve an appointment, but this is a problem because the person who works on Tuesdays is not a fast typist, so when she is busy on the phone, she takes notes on paper and then enters the appointments into the system later. Except sometimes she doesn't enter them later, and they get double booked. It would be better to have a mystery appointment with no details at 10:30 on Friday, rather than two patients unexpectedly showing up at 10:30 on Friday.
3. Make sure all of the software allows importing and exporting of data. A big part of my time was spent transferring medical report data from the software the doctor and technicians used into the appointment-scheduling, report-distributing software. Neither program made it possible for us to transfer the data from one to the other digitally, so it had to be done manually.
4. On that note, make reports customizable. One reason we spent all of that time manually transferring data was because the doctor didn't like the report format in the clinician-side software. But the software we used at the front desk didn't have the clinical features we needed. Customizable reports in the clinical software could have made a big difference.
(It's been a couple of years since I was in that role, but I would be surprised if these issues have been fixed in that time. The person who works on Tuesdays is a fictional character and any resemblance to real clinic staff is coincidental.)
posted by snorkmaiden at 9:22 AM on December 13, 2013
Major changes in EMR? Oh, don't even get me started. Just to scratch the surface:
Minimize the degree to which the mouse is necessary.
Every time you have to take your hand off the keyboard, position it on the mouse, find some dumb dropdown menu or popup dialogue, move the cursor, and make a selection, you're wasting tons of effort on a task that could probably be better completed with judicious use of the Tab key.
Stability, stability, stability.
I've worked with EMR in both office and emergency care settings in a couple of hospital systems, and a lot of the systems I've seen (especially the ones for emergency care reports, oddly enough, since those should be time-sensitive) are complete dogshit: they crash, they have long page loads and login times, they lose data between screens, etc. Which brings us to:
Make it local.
Sure, you're dealing with a Big Data situation, and you want to store your records in a central location, but for god's sake make the client stuff live on the user's terminal, not in a web browser. If you're constantly downloading forms, rather than just their contents, you're wasting everybody's patience.
Also, a side point on the keyboard/mouse issue:
Don't force users to entry data into fields unless it's absolutely necessary. The EMS systems especially tend to force us to spend most of our time ticking boxes to confirm defaults one by one. Instead, it would make more sense to focus on users noting differences from the norm, and then confirming the status quo on the rest as a slate. (Again, without goddamn dropdown menus.)
Lastly, compatibility and interoperability.
One of my first jobs involved consolidating medical records from a practice that was being brought into a larger hospital system. They used an older version of the same EMR software that we used, so there was this assumption that we could automatically import their data into ours. Not so: it turned out that the software developer had set the fields for ICD9 codes to ignore decimal points in the previous version. When we imported the data, it was impossible to tell, say, foo.bar and fo.obar apart.
Hence 17 year old me wound up tasked with manually reading each record, checking that all the fields were filled, and then filling in the right decimal points based on their written medical history: if the record said "540," for instance, I would have to read the records to tell whether that really meant 054.0 (Herpes NOS) or 540 (Acute appendicitis.) And, of course, since this EMR system had recently been "upgraded" to make full use of keyboard and mouse, there was no way to advance between fields without using the mouse.
None.
I had to click, wait for it to open an editor popup, enter the data, and hit a button to close it. Text fields opened up in Word Viewer 2003, which we had to install on every system, even if they already had a newer version of actual Microsoft Office, and despite the fact that it should have been trivial to code an in-app text editor. (Incidentally, I was told that the version they'd been using up until that time had relied instead on Word Viewer '98; when the EMR package was "upgraded," it was to require a payware dependency that was only seven years old, instead of twelve.) All in all, it took nearly six weeks of eight hour days for two RNs, another guy from the tech support office, and myself to finish the job, and this wasn't even a particularly large doctor's office.
Moral of the story: make sure your EMR system can talk to other versions of itself, at the very least. Ideally, it should talk to other companies' EMR systems as well, at least to the extent that those other EMR systems will let it. Encrypt your data, but make sure that records are stored within those containers as parseable plaintext so that your users aren't reliant on doing huge bulk tasks through the GUI.
So, OP, if you're designing an EMR system, don't be that developer, please?
posted by fifthrider at 9:42 AM on December 13, 2013 [3 favorites]
Minimize the degree to which the mouse is necessary.
Every time you have to take your hand off the keyboard, position it on the mouse, find some dumb dropdown menu or popup dialogue, move the cursor, and make a selection, you're wasting tons of effort on a task that could probably be better completed with judicious use of the Tab key.
Stability, stability, stability.
I've worked with EMR in both office and emergency care settings in a couple of hospital systems, and a lot of the systems I've seen (especially the ones for emergency care reports, oddly enough, since those should be time-sensitive) are complete dogshit: they crash, they have long page loads and login times, they lose data between screens, etc. Which brings us to:
Make it local.
Sure, you're dealing with a Big Data situation, and you want to store your records in a central location, but for god's sake make the client stuff live on the user's terminal, not in a web browser. If you're constantly downloading forms, rather than just their contents, you're wasting everybody's patience.
Also, a side point on the keyboard/mouse issue:
Don't force users to entry data into fields unless it's absolutely necessary. The EMS systems especially tend to force us to spend most of our time ticking boxes to confirm defaults one by one. Instead, it would make more sense to focus on users noting differences from the norm, and then confirming the status quo on the rest as a slate. (Again, without goddamn dropdown menus.)
Lastly, compatibility and interoperability.
One of my first jobs involved consolidating medical records from a practice that was being brought into a larger hospital system. They used an older version of the same EMR software that we used, so there was this assumption that we could automatically import their data into ours. Not so: it turned out that the software developer had set the fields for ICD9 codes to ignore decimal points in the previous version. When we imported the data, it was impossible to tell, say, foo.bar and fo.obar apart.
Hence 17 year old me wound up tasked with manually reading each record, checking that all the fields were filled, and then filling in the right decimal points based on their written medical history: if the record said "540," for instance, I would have to read the records to tell whether that really meant 054.0 (Herpes NOS) or 540 (Acute appendicitis.) And, of course, since this EMR system had recently been "upgraded" to make full use of keyboard and mouse, there was no way to advance between fields without using the mouse.
None.
I had to click, wait for it to open an editor popup, enter the data, and hit a button to close it. Text fields opened up in Word Viewer 2003, which we had to install on every system, even if they already had a newer version of actual Microsoft Office, and despite the fact that it should have been trivial to code an in-app text editor. (Incidentally, I was told that the version they'd been using up until that time had relied instead on Word Viewer '98; when the EMR package was "upgraded," it was to require a payware dependency that was only seven years old, instead of twelve.) All in all, it took nearly six weeks of eight hour days for two RNs, another guy from the tech support office, and myself to finish the job, and this wasn't even a particularly large doctor's office.
Moral of the story: make sure your EMR system can talk to other versions of itself, at the very least. Ideally, it should talk to other companies' EMR systems as well, at least to the extent that those other EMR systems will let it. Encrypt your data, but make sure that records are stored within those containers as parseable plaintext so that your users aren't reliant on doing huge bulk tasks through the GUI.
So, OP, if you're designing an EMR system, don't be that developer, please?
posted by fifthrider at 9:42 AM on December 13, 2013 [3 favorites]
There is also a free (ad supported) EMR system available: Practice Fusion
posted by duckus at 7:07 PM on December 13, 2013
posted by duckus at 7:07 PM on December 13, 2013
« Older Should I keep my resignation secret? | Can I eat this? Expired treacle in Christmas... Newer »
This thread is closed to new comments.
Here's an example:
At my hospital, after the doctor writes a discharge order, I have to take the following steps:
1) Go to Orders window
1) Acknowledge order from doctor
2) Go to charting screen for patient
3) Chart that I gave the discharge instructions (Even though I haven't given them yet - so I save as "incomplete")
4) Go to the patient record screen
5) choose "Admissions/discharges" from a drop down menu
6) Click to the print icon at the top of the screen
7) Choose to print "Discharge instructions" from a drop down menu
8) Preview the instructions
9) print them
10 Go back to print menu and print the discharge meds
11) manually fax the meds to pharmacy
12) Go back to the patient record, click on the admission history
13) Click on the patient belongings
14) Preview, then print belongings
This goes on and on... I can't bring myself to keep typing all of them, but you get the idea.
If Steve Jobs had designed my hospital EMR, I would have a button, accessible from any page of hte patient record, that says something like, "print patient data", and I could choose, "Discharge instructions" or "belongings" or whatever, and it would print in 2 clicks. DIscharge meds would automatically be communicated to pharmacy as soon as the doctor orders them and I verify them.
Another annoying thing is when there is stuff I have to do in multiple places in the EMR AND on paper. For flu shots, I have to complete a screening process on paper, and in my EMR. Then I have to chart when I give the flu shot in two different places in the EMR. It's exhausting and ridiculous.
posted by latkes at 4:49 PM on December 12, 2013 [2 favorites]