Section Evaluation
Evaluation of Family History & Related Sections
This document aims to provide some insight into the thought process and workflow of understanding a new E2E section for implementation. Overall, the workflow for evaluating the complexity of a new section for the E2E spec grinds down to the following steps:
- User Interface Evaluation
- Test User Entry
- Find Database Tables
By following this general procedure, you would be able to gain an understanding of how the database relates to the front end of the EMR, as well as gain insight as to what parts of the code should be looked at in order to take advantage of them to extend the E2E exporter template.
Family History is a section of the E2E specification that should be mapped from the OSCAR EMR. In order to do that, we have to understand how family history data is being handled in OSCAR. By understanding how OSCAR moves the data between the front-end and the database, we can then figure out where the data gets mapped to, and how to approach implementation.
In order to know where family history is inserted into the database, we need to insert some data of our own into the EMR. To do that, we would first locate the part of the user interface that handles family history input. In this case, we found the main family history input within the main Encounters page. Encounters is a feature which is associated to a demographic - or patient.
After finding where in the user interface it is handled at, we need to evaluate what type of data it accepts, and insert a few test entries. The screen to add a family history entry opens up as a page element popup, where it accepts a large note free text field, a start date, resolution date, age of onset, treatment, relationship, drop down selection of life stage, an option to hide CPP, as well as an option to insert at a specified position and to assign an issue to it.
In general, we discovered that the majority of these fields were free text entries, meaning that the user could specify whatever he wanted in these fields. Other than the life stage drop down which specified either not set, infant, child, adolescent, or adult, all other fields could effectively take in anything. With that in mind, we would input a few test strings that we could recognize immediately that we entered and have it show up in the database.
To find where the data eventually ends up, we would have to search for the new entries that we just entered in the database. Since we had prior knowledge that the oscar Encounter page generally deals with a group of casemanagement tables, that became the first place to search for our new entries.
Casemanagement consists of the following tables: casemgmt_cpp, casemgmt_issue, casemgmt_issue_notes, casemgmt_note, casemgmt_note_ext, casemgmt_note_link and casemgmt_tmpsave. We found that our new free text entries appeared in casemgmt_note, but we also learned that case management doesn't exclusively handle only family history. It also handles social history, medical history, ongoing concerns, reminders and risk factors as well. However, it wasn't clearly evident based on the field names how they differentiated between the entries.
In order to figure out how OSCAR differentiated between the entries, we investigated all the other casemanagement tables to see what else was being recorded. Eventually we found out that casemgmt_issue_notes links the casemgmt_note and casemgmt_note_ext tables to casemgmt_issue. As well, the issue_id field in casemgmt_issue correlated to the issue table. We discovered the following number scheme where it differentiated the different types of entries:
64 Other Meds 65 Social History (Personal History) 66 Medical History 67 Ongoing Concerns 68 Reminders 69 Family History 70 Risk Factors
With a bit more testing such as editing our previous entries, we also discovered that the old notes never disappear. Instead, the new updated notes get a new entry in the database, and they supplant the old records, where it mentions the id of the old message.
Based on this information gathered, we now understand where family history is stored, as well as how it is differentiated between the other entries that share the same table. It is possible to now craft sql queries to extract the data we entered previously, meaning we have an understanding of the database layer.
Because this is an evaluation and estimate of how long it would take to implement another section of the E2E spec, it would take approximately the same amount of time as previously implemented sections. The future tasks at hand would be to look at the data access layer within the EMR code and understand how the software moves the data around internally. When we understand what functions or APIs to call, we can then map the E2E fields to the available family history data and extend the existing exporter to handle the new section as well as expanding the template.
We also learned that two other sections - Risk Factors and Personal History also come from the same tables. Because of this, we know that once the Family History section is implemented, it will not take long to extend the other two similar sections as well because the architecture and code flow will be very similar to what has been done.
SCOOP is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
