The overall system architecture

According to the actual organization of the Serbian public healthcare system, one patient can have more than one medical (health) record, while 1 medical record is always linked to only one patient (there are no cases when one record is connected to many patients, e.g., for a “family medical record”). Usually, the main medical record is the one kept by the patient’s GP doctor. It contains full history of any noted illness, prescribed medications etc.

Figure 2. Connection between medical records, medical record items, and medical documents

The main medical record 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 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 extended easily. In our application modules connection between medical record classes and medical document classes are established as it is shown on the Figure 2. Supporting scheme in the database is exact as a structure of classes. Table MedicalRecordBase is a parent entity for specific medical records and they have established relation one?to?many between parent and each child. Each children entity has an id from MedicalRecordBase as a foreign key. Same hierarchy is established both for MedicalDocumentBase table and tables having it for parent table. In the same time, MedicalRecordBase is parent table for MedicaDocumentBase table which have id from MedicalRecordBase as a foreign key.

Basically, in our meta model, we have class MedicalRecordHeader (Figure 3) for defining different medical records and MedicalRecordItem to define all different kind of medical documents contained by medical record. Both of them are derived from MedicalDataContainer class. Each MedicalDataConatiner object (MDC in further text) 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 MDC is also associated with the list of boundaries of normal values (MedicalRecordItemElementRange objects). Such generic modeling (actually, meta-modeling) offers the possibility to perform various extensions (e.g., of the set of medical services) in a uniform 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 MDC object. The defined EHR model is usable in any kind of ambulatory medical institution [7], but also in the clinical (hospital) environment because hospitals also keep their own history of illness for each hospitalization.

Model

Figure 3. Main form of data modeling and generating tool

Figure 4. Example of defined medical record item element

Figure 5. Example of defined ranges for medical record item element

Figure 6. Example of ranges representing catalog of values

Meta data model is defined as a serializable class (EHRMetaModel class) that contains list of generated medical records and generated medical documents as well as general information about model (name, description, list of supported languages, indicator is model active). Model can be either saved in the file (XML) or saved in the database in appropriate tables.

All MDC, item element, and range representing objects can also have list of translations associated with languages defined in EHRMetaModel parent object. Each translation object will keep name of field to be translated and translating value in des-tination language.