We just did our version 11 upgrade from 9.5. A couple things I can't seem to figure out if anyone has the answer....
When adding a new diagnosis, if you click the approximate checkbox, it grays out the save and continue or save button. It is required that you have an onset date. I think this must be a setting somewhere but I can't seem to find it.
Dragon causes random chart crashes, what are other users doing to get past this? We use the headset microphones, and mouse controls.
I would appreciate any help, suggestions, answers, etc!
I'd love to hear a solution to the "Approximate" issue. We'd have a lot of happy people if we could leave it blank again.
Out Users have either been placing 0 in the box or manually typing unknown. Not the greatest solution, but better than listing an incorrect date.
Yes you still can hit the approximate and then free text in the box but something has to go in the box to be able to save and continue
You need onset date for a lot of reporting. When we first went on MQIC, our providers were saying "We have a lot more diabetes patients than this is showing" but it was because they hadn't put onset dates on the problem and MQIC wouldn't count those patients because they didn't meet the criteria having to do with how long the patient had diabetes.
David,
Do you mean a specific date or just something in the box, such as years, unknown, etc.
Would probably depend on the reporting being done, but I would at least put a year. From a purely reporting viewpoint, a true month/date/year is always preferable. The most important thing is to just be as consistent as possible to minimize data that might have to be coded for as an exception when reporting.
When we report for diabetes, we base our denominator off of the number of office visits in which the patient had diabetes assessed. The population is typically something like patients who have had a diagnosis of diabetes addressed in at least two office visits within consecutive measurement years (one of which is the current year). That's been fairly standard for our payers, academic and/or pharmaceutical research studies, quality recognition, and so on. In most of these cases, if the patient has had diabetes for several years, but you've only seen the patient for it once, they aren't included in your denominator. We've found that our numbers are more accurate and cleaner using this approach.
Here is the info from the MQIC reporting document:
Data objects and reporting definitions based on the DOQ-IT guidelines for Diabetes The criteria for diabetes patient population and metrics used to generate the Doctor's Office Quality - Information Technology (DOQ-IT) Diabetes Quality Improvement reports are based on the guidelines specified by DOQ-IT. Please visit http://qualitynet.org/dcs/ for more information on the DOQ-IT guidelines. The quality improvement reports translate DOQ-IT's criteria into query specifications that allow calculation of the metrics based on the data from the EMR. The criteria and query specifications are listed below: Searches for patients with Diabetes Mellitus, Type I or Type II during the measurement period. The search criteria is based on the following: • Problem ICD9 Code like '250*', '357.2*', '362.0*', '366.41*','648.0*' • Diagnosis type is 'Diagnosis of', 'Minor Diagnosis of', 'History of', 'Note', 'Recurrence of', 'Status post' or 'Hospitalized for'. • Patient should have had at least two office visits in the measurement period. The patient's current status in EMR is not considered. • Patient age should be greater than or equal to 18 years and lesser than or equal to 75 years at the start of the measurement period. • Diagnosis start/create/status date will be used to determine if the patient was diagnosed as diabetic during the measurement period.
For MQIC, yes. For quality measure reporting in general, onset date isn't a requirement because you can use other means to identify the patient had a condition in the measurement period (e.g., problem assessments, medications, claims).
Having worked through a number of implementations, preloading problems with approximate onset dates can be challenging. It's often difficult to determine the correct or even approximate date from paper documentation, and the more digging a preloader has to do, the longer it takes. Not to mention, preloaders don't always have the clinical background to make a good decision on dates. Before, it was easy to preload with a blank onset date and then correct it during the visit. It's less obvious that a correction needs to be made without the blank space in the problem list.
I'm not saying that's right - entering an onset date should be best practice - but it's the reality of a practice trying to remember everything it has to do when going live on the EMR. I've seen people guess at a year just to put something in the field, and to me, that's worse than having a blank.