There is a table of diagnosis codes (codes), this will have to be extended to include a new field - REPORTABLE
The field REPORTABLE will be marked true if the diagnosis code is a reportable code for public health reporting
There are tools to add diagnosis codes to the codes table. These tools will need to be modified to allow the field REPORTABLE to be set / edited when adding / editing diagnosis codes. This is for reporting to public health registries.
There should be a table that lists all diagnoses associated with a patient (links)
It will need to be extended to include a field reported and a date stamp for reporting which will be a date field
When a new diagnosis is added to a patient (medical problem). if the diagnosis is reportable, the table with diagnosis codes is updated to indicate that this is a reportable diagnosis but has not been reported yet. if the diagnosis is not reportable, that
should be indicated in the table.
When it is time to report, the table of diagnosis codes that are linked to patients will be ‘scanned’ and all reportable problems
that have not been reported will be reported via HL7 messaging. The table will be updated to indicate that the problem has been reported along with a time/date stamp of when it was reported.
The programmer I have assigned to this task should have it completed in 5 weeks.
Does this concern diagnoses entered into just issues, or entered into the encounter for billing purposes, or both?
In either case, these diagnoses are already linked to the patient and you should avoid creating a new table with redundant information. It’s unclear to me if you were planning to do that.
It does seem desirable to make a new table for recording when reporting is done, and for what; it may be awkward to put that information into existing tables (“billing” and “lists”) because many rows may not use it, and because you may find that you need to record more information about a reporting event than just the date.
Q : Does this concern diagnoses entered into just issues, or entered into the encounter for billing purposes, or both?
A : It only will deal with diagnoses that are entered into as issues, though in my opinion every diagnosis that is entered for billing should automatically become an issue. It may be self limiting and then be de-activated on the next visit. But in order to properly track a patients medical problems and history all diagnoses past and present should be in the issues.
Q: In either case, these diagnoses are already linked to the patient and you should avoid creating a new table with redundant information. It’s unclear to me if you were planning to do that.
A: No new tables are being created, two tables will have additional fields added to them for tracking of which diagnoses are reportable, and which ones have been reported
Q: It does seem desirable to make a new table for recording when reporting is done, and for what; it may be awkward to put that information into existing tables (“billing” and “lists”) because many rows may not use it, and because you may find that you need to record more information about a reporting event than just the date.
A: That is an approach, though we would still have to somehow link back to the existing tables. I would like to see other peoples thoughts on this.
I agree with Rod here, a separate table for logging the reporting status and even who it was reported to is a better method. I wonder if it might be something that could be part of the Audit Logs, perhaps a new log type called ‘Reported’. There are other MU requirements for reporting that may be able to leverage this, either way it is done.
-Tony
If you go with a separate table, which also makes the most sense to me, you can use foreign keys to “link back” to the existing tables. MySQL doesn’t always enforce foreign key constraints, but the technique is still sound. Just have one column in the new table be the same type as the primary key in the foreign table (i.e. the one you a “linking back” to) and store/use the value there to indicate which row in the foreign table is relevant.
What I suggest (based on my limited understanding) is to create a new table for recording the reporting events, and then add a foreign key field in the issues that link its diagnosis to the reporting table. That way it’s a many-to-one relationship and will support multiple diagnoses per reporting event.
By the way issues (recorded in the poorly named “lists” table) were originally created to record medical problems that are ongoing and likely to concern multiple visits. It’s probably not useful to create an issue for a one-time event like, umm, removing a splinter.
In reference to issues for one time issues, I would disagree with Rod. The reason is patients often come into my office with self limiting problems but for some reason are recurrent, for example ingrown toe nails. I can treat and remove the ingrown toe nail, but it is useful to know that the patient tends to get this problem on a recurrent basis. Therefore having it in the problem list and knowing that it is recurrent can aid me in planning treatments to prevent future re-occurances of the problem, or even locate an underlying problem that is the root of the simple symptom. (just putting on my doctors cap for a moment).
Well I’m not a doc but surely we can report on diagnoses from prior visits in addition to just those from issues. If you create an issue for every visit then you’ll have a lot of redundant information and extra work with no obvious benefit.
I don’t think this discussion actually effects the MU reporting one way or the other. If a diagnosis is reportable, then it should get reported and logged as reported. Whether it’s added as part of a visit, a transaction or an ‘issue’. We need to identify the places in the system that should be checked, since not all clinics/drs use billing modules. I wouldn’t burn much time on that.
Use of issues/medical problems tools and it redundancy or not would just be a users choice thing.
Agreed, But from the standpoint of practice management this is an important issue. When a new problem is billed, or a problem that has resolved in the past is billed, the physician can bill for both the E and M code (99xxx) with a 25 modifier and a procedure code. So to maximize billing and reimbursment software management of issues / problems can be a very useful tool. But as you mention this goes beyond meaningful use.
The second patch has been added to code review.
As of now you can mark a diagnosis as reportable,
You can add that diagnosis to a patient as an issue
You can view a report of all patients who have issues that are reportable.
Next Step is to generate the HL7 file that can be transmitted to a ESS Registry.
My recall of acceptable electronic transmission to public health agencies of reportable diseases is HL7 messaging … OR … the technical interface requirements of the public health agency.
NJ has a web-based system for physican reporting of disease (https://cdrs.doh.state.nj.us/), and it seems silly to recreate this UI, not to mention the near impossibility of agreement from the state agency to bypass it.
It seems that, for NJ, the solution is for OpenEMR to launch the NJ CDRS website in a new window when an “ESS- flagged” diagnosis code is saved. Would be nice to have a record in the patient file and an entry in the OpenEMR user to-do-list (if there is one? what is it called?) of ESS reports still to be made, and an OpenEMR Audit record of reports transmismitted and acknowledged. For local agency telephone reporting, a time-senstitive entry in the physican to-do-list?
My recall of acceptable electronic transmission to public health agencies of reportable diseases is HL7
messaging … OR … the technical interface requirements of the public health agency.
NJ has a web-based system for physican reporting of disease (https://cdrs.doh.state.nj.us/), and it seems
silly to recreate this UI, not to mention the near impossibility of agreement from the state agency to bypass it.
It seems that, for NJ, the solution is for OpenEMR to launch the NJ CDRS website in a new window when an
“ESS- flagged” diagnosis code is saved. Would be nice to have a record in the patient file and an entry in the
OpenEMR user to-do-list (if there is one? what is it called?) of ESS reports still to be made, and an OpenEMR
Audit record of reports transmismitted and acknowledged. For local agency telephone reporting, a time-senstitive
entry in the physican to-do-list?
For the purposes of passing certification, OpenEMR must send a file in HL7 format to CCHIT.
CCHIT needs to be able to parse the file and see the appropriate information in the file for ESS.
There is little to no standardization among states as to the way they will receive the ESS info.
I have my programmer developing the module in such a way that it passes certification.
At this point I do not see it as an appropriate use of resources to develop State specific tools for reporting,
since this is beyond what will be required for ARRA certification.
Michael,
Send me an email at brady.g.miller@gmail.com to figure out most ideal mechanism for your programmer to finishing/maintain/improve this code. If this was all done by a single programmer whom is gonna continue to work on OpenEMR, then would make sense to consider cvs access for him/her (if Rod also agrees).
-brady