Electronic Health Record – Meta Model

One of the main goals for developing healthcare/medical information systems is to enable collection and processing of medical data so that the best possible decisions can be made in limited time. Therefore, the first step in the development of our system was defining a data model of an Electronic Health Record (EHR). An EHR, as a founding block of any MIS, formats medical and other data, and prepares them for processing and/or interchange with other information systems. An-other benefit from using EHR and MIS systems is that medical data can be more easily available for further educational and scientific work. With a lot of data stored in an electronic for-mat, different types of search and analysis can be done quickly. For example, EHRs are useful for “rare cases” for which paper data might be lost or forgotten. Researchers, students and other medical staff can access EHRs to improve their work. An analysis of key capabilities of different MIS systems concludes that the main uses of EHR-based systems are: patient care delivery, patient care management, patient care process sup-port, education and research, improving policy and regulations, public health improvement and patient self-management. How-ever, an important constraint is that data access must be strictly controlled to avoid misusage. This section presents the basic structure of our EHR model.

Actors & contacts

This part of our EHR is used for modeling all actors of MIS and for keeping track of their active and inactive contacts (e.g., postal address, telephone, e-mail). The base class is Actor, storing data of any entity taking part in MIS. All actors have a unique id, a type, a current status within MIS and a relevant qualified name. The list of contacts is also associated with the class Actor. Further specialization is brought through derived classes of Actor. There are two main branches, starting with subclasses Person and Company. The class Person is further inherited by subclasses Patient, ClinicalStaffMember, and MedicalStaffMember – these actors are the most important one in healthcare delivery. Beside general demographic data, some additional information is kept about persons: the list of relationships between persons with their relationship type, the list of occupations and work places, and a list of general notes.

Global actor hierarchy

Personalized actors

Actors & contacts

Billing & payment model

This model partly covers financial and business aspects of an ambulatory institution. It is used in combination with medical data to create bills for medical services, analyzes and procedures conducted by the institution. The central class here is Payment, which models a bill for a medical service. (This bill could be a credit with a grace period and an interest rate.) Every instance of Payment is associated with a clinical staff member that verifies bill. Each instance of Payment contains 1 or more payment items (instances of Paymen-tItem). A payment items represents price for 1 specific medical procedure done by some clinical staff member in the institution. Since some medical procedures are covered by insurance and some are not, for each payment item the list of payment modes (direct payment, payment by insurance) with related values must be defined. 1 patient can have 1 ore more insurance policies that cover different medical procedures with different percents. For each instance of the class Insurance, the list of insurance scopes is defined. Insurance scope (in this model) represents definition of percentage of some medical treatment price covered by the insurance company. Based on these payment item coverage percentages, payment modes for a payment item are defined. For example, assume that a bronchoscope procedure costs 1000 Serbian dinars and is covered by an insurance fund 75%. The payment item for this procedure will have 2 instances of PaymentMode sub-classes: 1 PaymentByInsurance instance with the value of 750 Serbian dinars and 1 DirectPayment instance with the value of 250 Serbian dinars. After a bill creation, the financial department will take care of the payment realization, using existing information systems. We are developing support for interoperability between our MIS and these financial information systems.

Medical record meta data model

The Unified Modeling Language (UML) class diagram of the main classes in our EHR model is shown in Figure 3. The class MedicalRecord represents a general EHR, so it is the basic entity in our medical data modeling. Any instance of the class MedicalRecord has to be connected to some instance of class Patient. As we already mentioned, our (and probably every) MIS must be designed in a way that GP doctors find it suitable and usable; otherwise they will probably not use it [10]. According to the actual organization of the ambulatory part of the Serbian public healthcare system, 1 patient can have more than one medical (health) record, while 1 medical record is always linked to only 1 patient (there are no entities like “family medical record”, which is 1 record connected to many patients). Usually, the main medical record is the one kept by the patient’s GP doctor. It contains full history of any noted disease (e.g., prescribed medications). The main medical re-cord also contains general medical data, such as the list of immunizations, the list of allergies, notes about hospitalizations, etc. Beside the main medical record, some departments (such as dental service, endocrinology, gynecology, pediatrics) within the ambulatory healthcare system also keep their local medical records related only to their scope. Since there can be several different medical records containing different specific data and many different documents defining data for medical procedures, we defined our data model so that it can be ex-tended easily. The class MedicalRecord contains general properties that should be specified in any medical record (i.e, EHR). Classes modeling specific records extend MedicalRecord and bring domain-specific properties required by particular medical domains. Each medical record contains the list of chronic diag-noses, as well as the list of members of medical staff that are doctors chosen by the patient. By Serbian legislation, each pa-tient can choose up to 4 medical doctors that can sign medica-tion related to the patient’s chronic diseases. One of the chosen doctors is marked as the “main personal GP”. This doctor signs and verifies all medical documents related to the patient.
The full history of a disease is a collection of different medical analyzes, reports about medical treatments, laboratory analyzes, general notes about the patient and other medical documents. It is a part of a medical record. Since a medical record can be seen as collection of data from different medical procedures, MedicalRecordItem is the base class for such data. Any class defining some medical document extends this class. Thus, all medical treatments, examinations, analyzes, procedures, processes, routines result in a creation of a medical record item (MRI). Each MRI has the list of properties stored as instances of the class MedicalRecordItemElement. For each property, the system stores its name, type and measurement unit. An MRI is also associated with the list of boundaries of normal values and the list of prices for different patients. Such generic modeling (actually, meta-modeling) offers the possibility to perform various extensions (e.g., of the set of medical services) in a uni-form and consistent way. It also enables our generator tool (explained briefly in the next section) to automatically create a separate class and a database table for each medical record and MRI. The defined EHR model is usable in any kind of ambulatory medical institution, but also in the clinical (hospital) environment [11] because hospitals also keep their own history of disease for each hospitalization. These can be treated in the same way as MRIs within ambulatory institutions. However, after a hospitalization is finished, the hospitalization report could become a part of the main health record. Therefore, one can define the class HistoryOfDesease as a sub-class of MedicalRecordItem that brings specialization relevant for hospitals.

Users and privileges

Since medical data are considered as very sensitive, precise and reliable system of access rights and privileges should be defined. In MIS (and similar systems), users must be divided into different groups by access levels to some sets of data. Any Person object within our MIS is a potential user. The separate class ApplicationUser is used for user profile modeling. It keeps track of user’s credentials and the actual status within the system. Each application user can be a member of one or more groups. Each group of users contains the list of application roles that will be assigned to any member. Each application role contains the list of application actions defined for different entities within the system. Using this scheme, generally, specific rights can be assigned to any user, but usually administrators can predefine the most com-mon groups in order to assign these rights to users faster.