To organize the productive activity of specialists, medical institutions use the popular web program OpenEMR, which allows planning the working hours of specialists and patients. It provides authorized access only for employees of the institution. Patients of a medical institution usually cannot individually register and make an appointment with specialists. The article suggests a mechanism for producing a holistic info-communication system for an institution that provides medical counseling services for a group of patients who study in one educational institution or work within one enterprise, department or organization. The mechanism is implemented by combining the existing OpenEMR web application with a newly created web portal for self-registration and enrollment of such a group of patients. Also, the article proposes methods to eliminate errors and shortcomings of the interface of the web program OpenEMR, which arose as a result of the fallacious translation of elements of this interface from English to other regional languages.
For the broad majority of modern commercial enterprises operating in a competitive
market, it is necessary to use an effective CRM system (Customer Relation
Management). After all, in the eyes of remote customers it is the functionality of the
CRMsystem that represents the entire trading company as a whole [
EHR-systems and EMR-systems have much in common and, conversely, do not
have a clear line between their purpose and functionality [
EMR systems also contain the necessary information about patients' health, but this
information is as complete and detailed as it is necessary for the patient's medical care
in a particular medical institution. Access to this information is available only to
medical staff because it includes not only patient's data, but also data about medical
professionals, their work schedule, and a log of all medical services provided to the patient
with financial information. The emphasis of the EMR system is not on the completeness
of information about the patient, but on the organization and logistics of medical center
care for a large number of patients [
The vast majority of EMR systems are commercial, not open-source systems
[
The article offers a model of deployment and configuration of a logistics information complex for a medical institution, which provides a wide range of medical services in the form of two self-sufficient and independent modules that are exchanging data using specialized software interfaces (Fig. 1). The first module is a service web portal for competent employees of the medical institution, including administrators, coordinators, and medical consultants of this institution. The administrator-coordinator should create and constantly maintain a complete schedule of all events, which are attended, in the first place, by consulting physicians, as well as representatives of support staff. The standard calendar of the service web portal should contain complete information on which user-patient is registered with a particular doctor-consultant, on what date, as well as time and duration of reception. In addition, the service web portal should contain a complete list of all psychologists, a record of all patients and their personal data required for successful counseling, as well as a list of all other employees with a detailed definition of each employee's authority and rights to access resources of the medical institution.
Content and logistics of the infocommunication model Implementation of the service web portal is an objectively complex technical task, which, has already been solved for many clinics and medical centers around the world. Therefore, the article proposes the application of a ready-made service web portal based on the popular web program OpenEMR, coded in PHP.
Among the means of web portal is another important module of this service, where patient users can log in, register, make the necessary modifications in any field of the patient's questionnaire, place an application and obtain an electronic appointment for a medical consultation. This module consists of the web interface and system service. The patient deals directly with the web interface, which sets the application and checks its status. In the web interface, the program code can be executed only by the user pressing the buttons on the web page. It is impossible to make permanent periodic execution of program code in the web interface.
Instead, the system service is a permanent resident program that can periodically execute generated code as a function of the programming language C. The main benefit of system services, is that execution process is completely hidden from and invisible to the user, regardless of his actions or thoughts. In Figure 1, the system service is conventionally represented as a gear.
Access to the web portal of patients can only be authorized, and access to the registration procedure itself can be organized. In our example, the patient has a mailbox in one of the e-mail systems of the institution. To get to a consultation or interview with the consulting doctor, a patient must initiate the procedure, which is presented in Fig. 1 as a sequence of stages from 1 to 6, and wait for its successful completion. These steps can be expressed as follows:
The user is authorized on the patient's web portal using a mailbox, directory service, or another departmental authorization service of the enterprise or institution. In particular, the user must receive a one-time password to the mailbox and apply it to go to the authorized part of the patient's web portal.
The user can self-register as a new patient or change his data if he was previously recorded. Thus, in the respective MySQL table patient_data of database "openemr" of a service web portal, the new record is added or the existing record is changed accordingly. The patient_data table has 107 fields (!), Therefore the query to the MySQL database management system looks like: INSERT INTO patient_data SET pid = '2', date = NOW(), `title` = '', `fname` = 'Ivan', `mname` = 'Ivanovich', `lname` = 'Ivanov', `pubpid` = '2', `DOB` = '2016-03-09', `sex` = 'Male', `ss` = '2345678910', `drivers_license` = '', `status` = '', `genericname1` = '', `genericval1` = '', `genericname2` = '', `genericval2` = '', `billing_note` = '', `street` = '', `city` = '', `state` = '', `postal_code` = '', `county` = '', `country_code` = '', `mothersname` = '', `contact_relationship` = '', `phone_contact` = '', `phone_home` = '', `phone_biz` = '', `phone_cell` = '', `email` = '', `email_direct` = '', `providerID` = '', `ref_providerID` = '', `pharmacy_id` = '0', `hipaa_notice` = '', `hipaa_voice` = '', `hipaa_message` = '', `hipaa_mail` = '', `hipaa_allowsms` = '', `hipaa_allowemail` = '', `allow_imm_reg_use` = '', `allow_imm_info_share` = '', `allow_health_info_ex` = '', `allow_patient_portal` = '', `care_team` = '', `cmsportal_login` = '', `imm_reg_status` = '', `imm_reg_stat_effdate` = '', `publicity_code` = '', `publ_code_eff_date` = '', `protect_indicator` = '', `prot_indi_effdate` = '', `industry` = '', `occupation` = '', `language` = '', `ethnicity` = '', `race` = '', `family_size` = '', `financial_review` = '', `monthly_income` = '', `homeless` = '', `interpretter` = '', `migrantseasonal` = '', `referral_source` = '', `vfc` = '', `religion` = '', `deceased_date` = NULL, `deceased_reason` = '', `guardiansname` = '', `guardianrelationship` = '', `guardiansex` = '', `guardianaddress` = '', `guardiancity` = '', `guardianstate` = '', `guardianpostalcode` = '', `guardiancountry` = '', `guardianphone` = '', `guardianworkphone` = '', `guardianemail` = '' This query can be identified by the means of the MySQL database temporarily logging all SQL-queries that run on it as a result of the OpenEMR web program, any other programs, or manually by the system administrator. To enable this feature, it is necessary to change the global MySQL database variable called general_log by the SQL query: MariaDB [(none)]> set global general_log=1; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> To check the current value of the global variable general_log, the following SQL query is used: MariaDB [(none)]> show variables; +----------------------------------------+ | Variable_name | Value | +----------------------------------------+ ................................... | general_log | OFF ...................................
MariaDB [(none)]> After successful creation of a new patient record in the patient_data table, it is possible to proceed to step 3 of implementing a consultation request.
The patient-user web portal queries the MySQL table openemr_postcalendar_events to the service web portal and defines the options of available free dates and available free time for an appointment to the consulting specialist. For example, a fragment of the official web portal with a consolidated calendar of work of three doctors-consultants (named Belous, Golovkevich, Shatokhina) during one selected day (April 6, 2020) is presented in Fig. 2.
The logic of the patient's web portal functioning can be implemented in different ways. As a rule, students and employees of higher educational establishments cannot choose a specific doctor-consultant (Bilous / Golovkevich / Shatokhin). Usually, they are not provided with such information, and therefore they perceive consultants as identical anonymous employees of the medical institution. On the contrary, for a particular category of experienced patient users, such a choice can be foreseen and supported for many reasons. This is possible since the complete information that deciphers the names and other data about counselors-psychologists is contained in the MySQL-table users, where each specialist can be identified by the field ID.
Among offered options, the patient chooses the most convenient date and time of consultation. This patient’s choice is stored as a new unconfirmed request in the form of a new MySQL table entry openemr_postcalendar_events of the medical institution's service web portal.
The administrator-coordinator of the medical institution inspects the official web portal and checks for new unconfirmed applications. If there are such applications, the administrator must determine exactly how many consultants can "accept" patients on the selected date and time according to the application, choose which specialist to appoint as executor of the application (if this choice was not made by the patient), and, finally, change the status of the application from "unconfirmed" to "confirmed". In this case, the administrator does not need to search for the patient, because he is already specified in the application, he only needs to change the status of the application. As a result of the application change, the consultation entry is saved as an updated record of the openemr_postcalendar_events table created on step 5, and is displayed as a white rectangle in the specialist's calendar (Fig. 2).
The system service running on the patient's web portal periodically checks the MySQL table openemr_postcalendar_events of the service web portal and determines the fact that after the patient places a new unconfirmed request, the coordinator administrator changes its status and sends the patient an information message confirming his request. In this process, the patient learns about the fact of confirming an appointment for a doctor's consultation by receiving an e-mail or as a result of visiting the patient's web portal.
In contrast to the service web portal, which by definition can only be authorized for medical staff, patient web portal is a web software with anonymous and authorized parts.
Authorization of the patient's web portal can be organized in different ways. In particular, if a medical institution provides medical services only to employees working or students studying in the same university, enterprise or institution with its own e-mail system, then in order to access the authorized part of the patient's web portal, it is possible to perform authorization using the departmental e-mail system and entering onetime password received at this address. Therefore, the e-mail address can play the role of the primary key by which the user is identified.
If the organization, enterprise or institution has a departmental directory service configured based on popular programs Microsoft Active Directory, OpenLDAP, 389 Directory Server, then access to the authorized part of the web portal can be organized based on logins and passwords of this directory service.
Patients who have been successfully authorized by one of these methods and entered the authorized part of the patient's web portal can independently add themselves as patients to the MySQL-table patient_data database of the service web portal OpenEMR, update patient information, apply for an appointment or medical consultation, view status of execution of their applications.
One of the definite advantages of the OpenEMR web program is that it's an open-source product, coded in PHP - a classic popular programming language used for web development (along with Java, Perl, .NET, Python). Program code in PHP is a set of opento-edit text files with a .php extension that are permanently stored in an extensive directory structure. Each PHP-file is interpreted by the webserver into hypertext markup in HTML or program code in JavaScript, which as a result of a successful HTTP request is sent to the client's browser and displayed to the user as a web page.
The user can not view the PHP program code, which allows the programmer to safely store even passwords to databases and other confidential information, used to generate web pages, within PHP code, without getting to the content of the web pages themselves.
Often changes to the PHP program are required. For example, in English-speaking countries, people are described only by name and surname. As a rule, patronymic is not used. Only in official documents, such as questionnaires and medical records, just the dotted first letter of father’s name is placed. Consequently, the American developers of the OpenEMR program have firmly resolved that the paternal input field should be only a few characters long, and this format will be acceptable in all countries of the world (!). As a result, the patient's patronymic looks as shown in Fig. 3, i.e. only the first four letters of the word "Borisovich" are visible. To fix the interface, it was necessary to change the line #391 in the php-file. /var/www/html/openemr/library/options.inc.php specifically, in the assignment operator to the variable $fldlength it was necessary to add three characters "15+", as a result of which the current value of the variable $fldlength, which is the length of the text field (field length) changed from 2 characters to 17 characters, as determined from the review HTML source code of the web page (View source) in Mozilla Firefox. As a result, a fragment of the options.inc.php file looks like: if ($data_type == 1 || $data_type == 33) { echo generate_select_list( "form_$field_id", $list_id, $currvalue, $description, ($showEmpty ? $empty_title : ''), '', $lbfchange, '', ($disabled ? array('disabled' => 'disabled') : null), false, $backup_list ); } elseif ($data_type == 2) { // simple text field $fldlength = 15+htmlspecialchars($frow['fld_length'], ENT_QUOTES); // <CHANGED! $maxlength = $frow['max_length']; $string_maxlength = ""; // if max_length is set to zero, then do not set a maxlength if ($maxlength) {
$string_maxlength = "maxlength='".attr($maxlength)."'"; }
In turn, in the corrected interface of the patient's father's questionnaire "Borisovich" is now displayed completely (Fig. 4.), the width of the field for paternal input is now 17 characters wide, which is acceptable for most countries.
Another feature of the OpenEMR web program is the inaccurate translation of menu items from English into other languages, including Ukrainian. Philologists are well aware that English is perhaps the number one language in the world in its ability to convey the exact meaning of expression through the minimum length of a phrase or the minimum possible number of characters, thanks to a whole list of daily regular expressions and idioms.
For example, the state of the consulting physician, in which he is at work in his office and is ready to receive the patient in English can be conveyed in only two letters - "In" (English "in the middle"). The American translators decided that in Ukrainian such a state of the consulting doctor could be conveyed not by two, but even by one Ukrainian letter "У" (abbreviated "in the office" or "inside"). As a result, if a doctor accepts patients from 12.00 to 13.00, has lunch from 13.00 to 14.00 and works from 14.00 until the end of the day, the English interface of the calendar will display the status of this doctor as "IN", and in the Ukrainian interface - as Ukrainian "У". B ", which is a lexical error.
There are MySQL tables and lang_definitions in the OpenEmr database to fix related inaccurate translations. From the table lang_languages it is obvious (Fig. 5) that the program OpenEmr supports 34 different languages, the Ukrainian language has the identifier lang_id = 29. The second MySQL table, lang_definitions, contains a translation of each word or phrase into all the languages listed in the lang_languages table. For example, to illustrate the translation of the phrase "IN" in all languages, it is essential to execute the following SQL query: SELECT * FROM `lang_definitions` WHERE `cons_id`=4649 which translates the phrase "IN" into all other languages declared in the table lang_languages, including Ukrainian: As a result of updating the Ukrainian translation of the English phrase "IN" using MySQL-query or administrative web program PhpMyAdmin, the consultant's condition can be easily changed from the incorrect value of Ukrainian "у" to the correct value "PATIENT ADMISSION", normal and reasonable for Ukrainian-speaking web users of OpenEMR. 1. The information complex of the medical institution consists of two interacting parts. The first is the official web portal, which provides authorized access exclusively for employees of the medical institution. The database of this web portal stores complete information about administrators-coordinators, doctors-consultants, patients, a common calendar of events with a schedule of admissions, a list of applications and patient records. Business web portals for medical institutions are a separate category of sites called EMR-systems (Electronic Medical Records). The article introduces and recommends the use of the open web program OpenEMR, which is certified by the US Department of Health. 2. Another part of the information complex is a web portal for patient users, which can be students and employees of any educational establishment, institution or enterprise. At each enterprise, department or institution, as a rule, there are specific mechanisms of network authorization of employees, and therefore, due to the requirement of implementation of these systems, it is advisable to develop and deploy the authorized part of the patient's web portal independently. Users who have successfully passed the authorization in one of the following ways can individually add themselves as patients to the official web portal, update information, place a request for a consultation, review the status of accomplishment of submitted requests. 3. In case if the users of the medical service are not related to a common establishment, enterprise or institution where they work or study, access to the authorized part can be established by entering the address of any e-mail or mobile phone number to which the user should receive a letter or SMS message with a one-time password. 4. Opensource OpenEMR implies a wide range of options for enhancing the web user interface. In particular, the words and phrases of this interface can be replaced as a result of Update queries to MySQL tables lang_definitions and lang_languages, and the size of text fields can be changed by analyzing the dynamically generated HTML markup and comparing it with the corresponding PHP program that generates the markup.