Programmatic insertion of dictations - yes?

Management and Administration
1

pfwilliams wrote on Tuesday, December 11, 2012:

I’m hoping someone could pass over my plan of action below and either give me a thumbs-up, or prewarn me of impending disaster.  During our long-term transition period, we are still maintaining concurrently running EMR systems.
Dictations entry is still being input (via Dragon Medical) directly into our old system.  Providers and/or assistants have then been doing the redundant work of cutting-and-pasting each dictation into OpenEMR.  This extra work has put them on the warpath, and ignited in me a strong desire to eliminate these extra steps they’ve been saddled with.  We are not yet ready to dictate directly (and only) into OpenEMR.

So, I’ve begun digging into OpenEMR tables to determine what is required to use and external program to insert dictations.
I’ve had to make a couple assumptions, but have come up with what seems to be an appropriate method.

The assumptions I’ve come to are as follows:

1. The table heirarchy, as relates to my “project”, is as follows:
….FORM_ENCOUNTER table - (queried on PID and DATE, returns ENCOUNTER number)
………FORMS table - (queried on ENCOUNTER number, returns FORM_NAME’s and FORM_ID’s)
…………FORM_<FORM_NAME> tables (tables for the remaining FORM_NAME types from the REGISTRY table, keyed on FORM_ID)

I was a bit confused at first thinking that the FORMS table was really the master of all the other FORM_xxx tables, but I see that it is driven off of ENCOUNTER number, and I see no where else that that field can originate other than in the FORM_ENCOUNTER table. I decided to logicaly think of FORM_ENCOUNTER as the top-dog, and consider the rows in the FORMS table that reference back to the FORM_ENCOUNTER table as useless information.

2. The FORM_NAME “New Patient Encounter” can be easily misconstrued.  It has nothing to do with a “New Patient” as every encounter generates such a form.  I’ve decided to ignore that the word “New” exists in the FORM_NAME (I might have voted for placing the form ID from the REGISTRY table into the FORMS records rather than repeatedly duplicating long text strings like 'New Patient Encounter" or “Review of System Checks”)

Having made those assumptions, my plan is as follows:
1. Use our unique external CHART_NUMBER field to query the PUBPID column (which we’ve populated) of the PATIENT_DATA table returning a PID.
2. Use that PID and the service date of the dictation to query the FORM_ENCOUNTER table, returning an ENCOUNTER number.
3. If the OpenEMR ENCOUNTER exists, write a properly-populated row to the FORM_DICTATION table and retrieve the auto-incremented ID column.
4. Insert a new record into the FORMS table referencing the ENCOUNTER, FORM_NAME, and newly generated FORM_ID.

Am I in the ball park?  Or off on another planet?
Thank you very much.

2

bradymiller wrote on Thursday, December 13, 2012:

Hi,
Sounds like you are in the right ball park.
-brady
OpenEMR

3

pfwilliams wrote on Thursday, December 13, 2012:

Thank you for the response, Sir.
Having a functional test environment, that can be reloaded in seconds,  allowed me to boldly proceed as above and it seems to behave exactly as it should.  This did get us all debating as to how to handle a patient that visits twice in one day, and what exactly constitutes an encounter.  Whether OpenEMR constrains our choices (perhaps correctly) or allows some flexibility.   We pretty quickly opted for creating only one encounter when a patient sees the same provider multiple times on the same day (someone here also mentioned that it needs to be that way for billing) . I was good with that, since the time portion of the “date” column in form_encounter does not relate to an appt time, and I’d have no way of uniquely identifying to which encounter a dictation being imported from an external source should be attached.  That got us to phase two of the debate: If a patient sees two different providers on the same day, is it one encounter or two?  I piped in that it was likely do-able as I see a provider_id column in the form_encounter program. But the concensus again opted for the “single encounter” policy. So, I guess if a patient sees Provider A in the morning, then immediately after sees Provider B, and then came back in the afternoon and saw Provider A again, we’re going see how linking all that activity to a single encounter works out.

I did later notice that most of the provider_id columns in our form_encounter table are empty.  The populated provider_id columns (from an earlier OEMR version?) seem to contain more of an “Entered by:” user, rather than the attending provider, as I’d assumed was the purpose of the column.  This may be related to a couple other threads here and a fix you already have staged for the next upcoming patch…

Thanks again.