1 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): Electronic Health Record Data Model Optimized for Knowledge Discovery Shaker H. El-Sappagh, Samir El-Masri 2, A. M. Riad 3, Mohammed Elmogy 4 Collage of Science, King Saud University, Saudi Arabia 2 School of Computer and Information Sciences, King Saud University, Saudi Arabia, 3,4 Faculty of Computers & Information, Mansoura University, Egypt Abstract Database is a core component the Electronic Health Record (EHR) system, and creating a data model for that database is challenging due to the EHR system s special nature. Because of complexity, spatial, sparseness, interrelation, temporal, heterogeneity, and fast evolution of EHR data, modeling its database is complex process. This paper tried to build dynamic, complete and stable data model for EHR database. There are a little work and standards in this aspect because of its difficulty. We will use object relational modeling approach and entity attribute value with classes and relationships to build the model. This design facilitates and enhances the operations of data mining and decision support which is integrating component of an EHR system. Keywords: Electronic Health Record, database, health informatics, data mining, database design.. INTRODUCTION The Electronic Health Record (HER) is a longitudinal electronic record of patient health information produced by encounters in one or more care settings. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR is an integration of patient information systems . The EHR also includes the network that links these systems, databases, interfaces, physician order entry, electronic communication systems, and the clinical workstations (ISO TC 25 , ISO/TR 2054:2005 ). EHR systems are developed to improve quality of care , reduce organizational expense, produce a data stream for electronic billing, and provide electronic support for secondary users (payers, policymakers and researchers) . To support the previous functions, HER system contains a mix of highly structured data. These data include medical, security and privacy, legal and financial data. The most critical component is the EHR database. Having a highly structured, dynamic, complete and consistent database is important to achieve EHR objectives. This database has different architectures if EHR is centralized, distributed or hybrid. Healthcare systems moved from isolated systems in hospitals towards solutions which include multiple healthcare professionals and institutions, interoperability and information sharing. It becomes crucial to allow all relevant patients clinical data to be available at anytime, anywhere and to improve the quality and delivery of healthcare. The interoperability can be achieved using two solutions: - Building EHR structure and content in each hospital by unified technology and terminology standards. Although this solution facilitate the interoperability, it is difficult to apply because many existing systems use different standards and technologies. 2- Building EHR structure and content locally in each hospital using any technology and standards and use the interoperability standards for EHRs which are offered by the world leading standard bodies as: European Committee for Standardization (CEN) , International Organization for Standardization (ISO) , Health Level Seven (HL7)  and Digital Imaging and Communications in Medicine (DICOM) . In this paper, we will use the second solution and build a data model for the EHR in local hospital and leave the connectivity and interoperability burden to the available standards [5, 6, 7]. The complexity and the rapid evolution and expansion of the clinical domain make development and maintenance of clinical databases difficult. Whenever new data types are introduced or existing types are modified in a conventional relational database system, the physical design of the database must be changed accordingly. In this paper, we try to build a temporal, dynamic, and generic clinical data model which solve the above challenges. The model uses object-relational model and use Entity-Attribute- with Classes and Relationship (EAV/CR) . Moreover, it is compatible with ASTM E 384 [3, 6] and CEN/TC25 preenv 238  standards. The paper is organized as follows: Section 2 discusses related works. Problem statement is discusses in section 3. Section 4 is the proposed data model. The paper is concluded in section 5. Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
2 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): RELATED WORK In this section, we go through some background about essential aspects of health informatics related to EHR and database design. 2. Data Models There are many design methodologies for database as range from hierarchical model to object/relational model and object-oriented model. Each modeling approach has its advantages and disadvantages. Object model is suitable for the design of complex databases as EHR but its Database Management System (DBMS) is not popular and its query languages are complex. Relational model  is the most applicable model. However the sparseness, complex data types, and speed evolution of clinical data make the conventional design approach costly. Extending the relational model by allowing the storage of objects and solving the sparseness and evolution of data can permit the development of robust and generic model. As will be shown in section 4., this approach is EAV/CR [9, 0]. 2.2 EHR Database Architectures There are two architectures of EHR, basic and universal. The basic architecture is built inside one organization (i.e hospital) and connected to all hospital information systems as shown in figure . RIS LIS Pharmacy system HL7 & DICOM HL7 PACS HL7 EHR Database HL7 Billing HL7 HL7 Fig. : Basic EHR architecture Order Entry In figure, the EHR database is centralized and collect data from all operating healthcare systems in the hospital as radiology information system (RIS) and others. The universal EHR architecture has two categories. In the first one, it may be centralized system as shown in figure 2. The centralized EHR database will be fed from different healthcare systems such as hospitals. The feed will be messaging based on standard as HL7 V3.0 RIM (Reference Information Model) and a pre-agreed data set . In the second category, it can be a distributed system as shown in figure 3. In this architecture each healthcare organization has its own EHR with its own data model and with its own terminology standards. These are autonomous and heterogeneous systems developed under different objectives, and consequently with diverse data models, platforms, standards and semantics. In the best conditions, they could follow a standard, but different ones could be selected for each system. These conflicts can be classified into three levels: () Semantic: the information models or database schemas are different. (2) Functional: the interfaces to manage data are different. (3) Instance: the information about the same real entity could differ from one system to another. The interoperability standards as HL7, CEN TC, ISO, and other achieve the connectivity between local systems. Fig. 3: Distributed universal EHR architecture This architecture is the most flexible one, and it is used in our model. 2.3 EHR structures National/Regional EHR Database Clinic Clinic Fig. 2: Centralized universal EHR architecture EHR Database EHR Database HL7/ XML EHR Database In HER systems, there are four record structures : () Integrated record: Data are presented in a strictly chronological way, identifying each episode of care by time and date. (2) Source-Oriented Medical Record (SOMR): It is organized according to the source that generated the data, typically different hospital departments. Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
3 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): (3) Protocol-driven patient record: In this model, a template is captured in a pre-structured form that dictates what specific data are to be obtained and recorded by the clinician. (4) Problem-Oriented Medical Record (POMR): It organizes data according to the list of patient problems. The problem list acts as an index to the whole record. All progress notes, tests, treatment notes and medications are numbered according to the problem they relate to. Progress notes are often written according to the Subjective Objective Assessment Plan SOAP template. No single patient record structure will suit every purpose. In our model will support POMR because physician concentrates on patient problems when searching for and storing data. 2.4 EHR standards We concentrate on three EHR design problems where are () Healthcare messages exchange, (2) EHR object model (i.e. content and structure), and (3) Healthcare terminology/ vocabulary. In addition, the EHR system should incorporate a proper security mechanism. Table  summarizes how the three standards organizations support the three parameters of EHR. Table : EHR Standards  HL7 CEN TC 25 ASTM E3 Messaging HL7 V3 ENV ASTM E238, ASTM394, ASTM E467 partially: EHR Object no partially: ENV , Model standard ASTM 384 ENV Terminology LOINC, SNOMED, UMLS, etc. no standard ICD9, SNOMED, etc. The table shows that while standards for healthcare message exchange and terminology exists, there is no standard for EHR Object Model. HL7  is in the initial phases of defining EHR content. CEN TC 25 suggests an EHR structure but does not define its content. ASTM E3 is the closest to an EHR object model , but it still lacks a lot of essential information and it s not clear how to extend the given model. As a result our proposed model tries to handle this shortage and develop a generic EHR data model. 3. PROBLEM STATEMENT EHR integrates heterogeneous data from many sources which is important for knowledge discovery. The complexity, sparseness and fast evolution of clinical information makes development and maintenance of clinical databases challenging . Conventional (relational) databases have static design. On the other hand, in healthcare environment, entities and attributes (physical design) are changed continuously. This can be time consuming for the maintenance and upkeep of the database and all applications depending on it and user interface must be changed as well. Also, in relational database there are a maximum number of attributes for each relation and a set of predefined data types which cannot be extended. EHR databases should ideally be flexible enough to handle new data types and attributes without needing to change the physical database schema. Also, Time is important in EHR data model. Representing, maintaining, querying, and reasoning about time-oriented clinical data are critical success factor. Although EHR contains temporal data as patient history, the structure of conventional database does not make it easy to store time-varying data. Healthcare data are sparse. Each entity will have thousands of attributes, but each row in the table will use only small set of these attributes as patient tests. This situation waste storage space as shown in table 2. Table 2: EHR sparseness of data Id name X Y Z A B C.. D N x null null a b null.. null 2 N2 null null z2 null null c2.. d2 3 N3 null y3 null null b3 null.. d3 We require an open schema data model to support dynamic schema change, sparse data, temporal and high dimensional data. In open schema data models, logical model of data is stored as data rather than as schema, so changes to the logical model can be made without changing the schema. In this paper, we will use relational design to build EHR data model after solving its problems and handling its shortages. The problems as sparseness, continuously evolving problems [20, 22], adding new data types, and temporal data modeling [4, 9] are solved in our model. In this model, we use EAV/CR modeling when we need to model sparse and dynamic data. Non-sparse data as patient demographic data stored in conventional relational tables. This is a mixed-schema design. Also, EAV permits the extraction of archetypical data from database to facilitate data interoperability . For interoperability and knowledge discovery purposes, there are also vocabulary tables as shown in figure 4 . Database Server Vocabulary Dictionary 4. PROPOSED DATA MODEL EAV data Non-EAV data tables Fig. 4: EHR database server. In this section, we will propose our data model for EHR database that solves all of its design problems. Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
4 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): Evolution of EAV and EAV/CR The model allows the storage of conventional relational data for not sparse data. Also, if new data type is needed, class diagram can be defined and map any class to relational table or to a type of column. Spare data will be stored in EAV sub-schema. This behavior is used to minimize the negative effects of EAV to the whole EHR system as shown next. At the same time, it meets the challenges in section 3. In relational databases, the logical and physical schemas have the same layout. The complexity and the rapid evolution and expansion of the domain of clinical information require a large maintenance overhead if data are laid out using a relational design. For this reason, it is desirable that EHR database be flexible and allow for modifications and for addition of new types of data without having to change the physical database schema. The ideal design would implement a highly-detailed logical database schema in a completely-generic physical schema that stores the wide variety of clinical data in a small (and constant) number of tables. - Basic EAV Schema In EAV design all data can be stored in a single generic table with conceptually 3 columns: for entity (e.g., patient identification), for attribute (e.g., name), and for value (e.g., "Jens Hansen") . To add more descriptive fields to the entity class, you add attribute values in the attribute field as in table 3, 4. The main advantages of this design are flexibility and effective entity-centered queries and storage saving by preventing fields with NULL values. Table 3: Conventional relational database Patient_id Date Name Test Test2 //202 Hans T null 2 2//202 Gems T T22 3 3//202 Tom null T222 Table 4: EAV database design Patient_id Date Attribute //202 Name Hans //202 Test T 2 2//202 Name Gems 2 2//202 Test T 2 2//202 Test2 T22 3 3//202 Name Tom 3 3//202 Test2 T222 In EHR environment, the meaning of null (inapplicable, unavailable or unknown) is sometimes required. To handle this situation, a missing value code column should be added to an EAV table, which is non-null only when the value column is null. The main disadvantages are data display, attribute-centered query complexity and inefficient constraint checking. The logical schema is described in EAV metadata relational tables, so any change to the logical structure will be added, deleted, or updated without affecting the physical structure. Metadata plays a critical role in virtually converting EAV physical schema to the relational-like, user friendly logical schema. This allows end users to query EAV as relational data. The non-sparse data as patient demographics can be modeled in conventional tables and connect this table to EAV table that model sparse and evolving data, figure 5. In figure 5 the EAV data table contains: The entity. For clinical findings, the entity is the patient event: a foreign key into a table that contains at a minimum a patient ID and one or more timestamps (e.g., the start and end of the examination date/time) that record when the event being described happened. The attribute or parameter: a foreign key into a table of attribute definitions (in this example, definitions of clinical findings). At the very least, the attribute definitions table would contain the following columns: an attribute ID, attribute name, description, data type, units of measurement, and columns assisting input validation, e.g., maximum string length and regular expression, maximum and minimum permissible values, set of permissible values, etc. The value of the attribute. This would depend on the data type. Querying EAV data is more difficult than conventional data as follows: querying tables 4, 5 for patient Hans using SQL: Conventional table Patient Patient_Id Integer Name Varchar(30) Date of birth Date EAV table EAV_Data Patient_Id Integer Date Datetime Attribute_Id Integer Varchar(255) Metadata table Table 4: SELECT * FROM table4 WHERE name LIKE 'Hans%' AND Date < '2//202'; Table 5: Attribute Attribute_Id Integer Attribute_Name Varchar(5) Data Type Varchar(5) Fig. 5: Simple EAV schema Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
5 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): SELECT d.patientid AS patientid, d.value AS name, d2.value AS Date FROM table5 AS d INNER JOIN table5 AS d2 USING (patientid) WHERE d.attribute='name' AND d.value LIKE 'Hans%' AND d2.attribute = 'Date' AND d2.value < '2//202'; Querying EAV data includes a self-join for each attribute. This query complexity is solved by: () There may not be a problem. Attribute-centered queries are important for research questions only. (2) Any need for regular cross-patient data access could be met by making backups of the production database and restoring them onto separate hardware. Resourceintensive queries run on the backup data will not affect the production server. Additionally, the EAV data schema could be transformed into numerous conventional tables after backup thus easing query design by end users with modest SQL skills. (3) Optimization of queries may increase the efficiency considerably. (4) EAV data may be pivoted  and converted to logical relational model using data warehousing, materialized views or in-memory data structures as hash tables and two-dimensional arrays. (5) Extension of the SQL language to facilitate "pivoting" of attribute-centered data into a conventional layout the Extended Multi-Feature (EMF) SQL can solve the problem. - Multi data types EAV Schema s may of course be of any type, for example, text, number, or Boolean (true/false). In the example in Table 5, the value field of the data table is text type. Such a design achieves simplicity by storing all simple types as text values. This approach has, however, some drawbacks. First, not all data types will fit into a text field as Binary objects. Second, queries based on values will be less efficient for non-textual values. The text "2" is less than the text "2" even though it is numerically greater, because text is sorted character by character, from left to right. One enhancement to EAV design is done by storing data with different data types in separate tables . This multi-data type EAV design allows the use of any data type including text, integer, floating point, time stamp, object and graphical data (Binary Large Object (BLOB)) as in figure 6. Indexing is possible in this design. Patient_Id Integer Data integer Name Varchar(30) Patient_Id Integer Date of birth Date Date Datetime Attribute_Id Integer Integer Data text Patient_Id Integer Date Datetime Attribute_Id Integer Varchar(255) Fig. 6: Multi-data types EAV schema Furthermore, EAV makes it easy to model the one-tomany relation between patient and clinical events. In EHR, it should be possible to record relationships between clinical events (e.g., infection leads to a course of penicillin or myocardial infarction leads to death). EAV/CR schema handles the complex relationships between classes. This model adds an object-oriented framework to the EAV model by definition of classes and relationships. EAV/CR data and metadata are stored in Object-Relational data model. Figure 8 shows the EAV/CR metadata relational tables. Class Class_ID Class_Name Description Class Type ClassHierarch SuperClass SubClass Patient - Hybrid EAV Schema The best enhancement is hybrid EAV format that allows the use of multiple data types in a single table to provide simpler and faster queries , figure 7. It combines the best features of the simple and multi-data type EAV designs without increasing the size of the data storage. This approach will be used in our model. - Enhancing EAV to EAV/CR EAV is convenient when attributes are of simple or primitive data types. However, it is possible that attribute is of object (class instance) type that has substructure. That is, some of its attributes may represent other kinds of objects, which in turn may have substructure, to an arbitrary level of complexity. EAV/CR schema supports complex substructure . Data Patient Patient_Id Integer Patient_Id Integer Date Datetime Name Varchar(30) Attribute_Id Integer DateOfBirth Date _int Integer _text Text _object Class_type Fig. 7: Hybrid EAV schema _binary BLOB Attribute Class_ID Attribute _Name Attribute_Description DataType Required Default_value Format Upper_Bound Lower Bound Fig. 8: EAV/CR Metadata relational model Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
6 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): In Figure 8, inheritance is designed in the ClassHierarch table. Figure 9 shows how to model objects using EAV schema. Composition relationship is modeled in EAV_Object table where one attribute of the main object can be object of a different class. Also, objects as clinical events can be related in EAV_Object by adding attributes as O in_response_to O2, or O result_from O2. Keyword table is used to enhance the search process (Google-style search), by linking some descriptive words to specific objects. Ad hoc relationship between objects (e.g., penicillin leads to rash) may be recorded as objects themselves. For this purpose, a class ObjectRelation could be defined with two attributes, objectid and relatedobjectid. More descriptive attributes may be added to this class if required e.g., causality. If you have hundreds or thousands of non-sparse objects for a given class, you should create a distinct table for this class, preferably with the same name as the Class itself. (Naturally, such tables are not illustrated in the schema above, since they are specific to your application.) The summary information for each object, however, still lies in the Objects table. This way, the Keyword table lets users locate Objects of interest irrespective of what Class they belong to. When you use a Mixed Design approach, where some data is stored in regular tables and other data in EAV form, the metadata in the Class table above should have a flag that states whether Object data for a given class is recorded in conventional columnar form or in EAV form. This way, your application code knows what to do when the user wishes to inspect the details of a particular object. Obviously, considerable up-front programming is required to drive an ergonomic user interface for the EAV/CR model in a real-life production environment. On the other hand, this is a one-time-only job. 4.2 Data transformation using domain dictionary and rule base For interoperability, the EHR database must contain standard medical terminologies as UMLS or SNOMED. For knowledge discovery, the medical data have to be transformed into a suitable transaction format. For categorical data, each value is connected to one code. For continuous attributes, we use a rule base such as if age>20 and age < 30 then age=2 and so on . 4.3 EHR database is bitemporal Time is one of the most important variables in healthcare, as medical temporal reasoning is directly relevant to almost every aspect of medical practice. Longitudinal data are essential for outcome analysis, CDSS and temporal data mining. History-taking, causal diagnostic explanation, diagnostic decisions, and patient monitoring all rely heavily on the patient's past clinical course, current medical status and future course (patient treatment). Modeling time is varying and based on the choice of ontological primitives, whether time is viewed as discrete or continuous, modeling of uncertainty, incompleteness and impreciseness and granularity of the time stamp chosen. The temporal database may store transaction time (rollback database and DBMS support that), valid time which is the time when the event is valid (historical database) and both (bitemporal database). The EHR bitemporal database must allow: () Relating situations to a calendar. (2) Relating situations to reference situations. (3) Relating events together in before- and after- chains. Object Object_Class_ID Object_Name Date_Created Date last changed EAV Binary EAV Object EAV Real Fig. 9: EAV/CR data model Keyword Keyword Keyword type EAV Int EAV Date EAV Text Moreover, the time of an event may be known with respect to a specific calendar date, time or timestamp (time point or instant) , with exact interval (start time and end time, or occurrence time and duration), with respect to the occurrence of some other event, with uncertain time, and/or uncertainly with other event. There are 49 relationships between time intervals and time points . Temporal data model need to manage uncertainty of events, both to actual date/time of occurrence of an event time (e.g., Event A occurred about 5 years ago, and it was winter, around 02:00 AM.), and to the occurrence relative to some other event, both qualitatively (e.g., Event A occurred before Event B) and quantitatively (e.g., Event A occurred approximately week before Event B). Our model will not handle the uncertainty. The precise time of an event, either time point or time interval, will be modeled by two attributes Event_Start_Time and Event_End_Time. This time Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
7 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): interval will have the same value in its both ends in case the event in time point event. In addition to defining an event with respect to an absolute date/time, the model enables defining the time of an event with respect to the time of some other event. We have 49 potential temporal relationships between two events. This requirement will be achieved by defining another relation named Temporal_Relationships which normalize the many-to-many temporal relationship between two events as shown in Figure 0. The temporal relationship between any two events can be described by the attribute Temporal_Relationship. The domain for this attribute is the 49 temporal relationships. In addition to these 49 qualitative relationships (e.g., Event A occurred before Event B), the model represents quantitative temporal relationships (e.g., Event A occurred approximately 2 weeks before Event B) by using the attribute Relative-Interval, which represents the amount of time between two related events. There are many query languages which extends SQL as Time Line SQL (TLSQL), TSQL2, TQuel and other which facilitate the querying of the temporal database. Domain expert must choose the appropriate level of granularity for each table which may be one of: Years: <year> Months: <year, month> Days: <year, month, day> Hours: <year, month, day, hour> Minutes: <year, month, day, hour, minute> Seconds: <year, month, day, hour, minute, second> The interval will contain a finite sequence of discrete, indivisible time quanta, according to granularity. If the Days level is chosen, duration of five means five days. Clinical_Event Event_ID Integer Temporal Relationships Event_ID_ Integer Event_ID_2 Integer 0. m 0. m Temporal_Relationship Varchar(50) Relative Interval Integer Fig. 0: Management of temporal relationships 4.4 Details of proposed model The proposed framework tries to model all patient clinical events. To keep the simplicity of the model, standardization tables such as medicine type, controlled vocabulary for problem list (SNOMED CT) and terminology tables are removed, sparseness (EAV tables) will be designed aside, and only attributes required for relationships between entities (primary key) are modeled (entities contains other attributes). The conceptual schema should correspond to expert understanding of the medical domain. It should be concerned with data representation and not with issues of data storage and access efficiency. These sub-schemas can be appended easily to our schema. Our model is problem oriented temporal model where patient problems are the core component. This structure provides a means of depicting a patient's problems and all clinical entries related to each problem (e.g., symptoms, physical findings, laboratory tests, etc.). This grouping of data provides a context within which one may interpret clinical information. EHR also contains summary data from other systems. When detailed data are needed, a link to these systems (RIS, PACS, LIS and PIS) can be added. The clinical heart of the EHR is the core of the entities: patient, provider, problem, encounters, orders, services and observations. Representing the overall structure of the record is difficult since it is complex and has a number of dimensions. It also can be viewed from many perspectives. Four of these are: chronological, by encounter/episode, by problem, and by topic. Each of these views looks at the same stored data in a different way. Our model concentrates on patient problem list as in Figure 2. The model starts with the concept of a person's clinical file which is patient identification, social and demographics data as in Patient table (non-sparse table). The model allows an unlimited number of identifiers for patient a primary key for internal consistency plus any number of external identifiers . It allows an extensible set of identification values to use for both ID lookups and de-duplication requirements that crop up when integrating multiple systems. Tables Person_Identifier and Identity_Type are used to achieve this purpose. The SSN and Health Record Number are rows in the Identity_Type table and the Patient_Identifier table references the appropriate identity_type_id (for example, SSN) and store the actual type value in the Identifier column. This model allows having as many different identities as necessary into the future. Patient table stores demographic data (e.g., names, sex, birth date, death date, etc), social data (Father, mother, and family IDs) to build social network and allow Social Network Analysis and Mining (SNAM), and linked to Address table which store patient detailed addresses over time. The addresses data can be used in spatial data mining. Table Vital_Sign stores complete vitals over time (time is part of primary key), such as height, weight and blood pressure for each patient. This table stores temporal data so attributes as Start_date_Time and End_date_Time are required. For the most recent vitals, the End_Date_Time is NULL. Each person has a set of problems, the Problem table. Problem table is sparse, so we have to extend it by EAV_Problem table as shown next. The problems are identified by the physician, Physician table. Problems may also have temporal relationships with each other and this is handled by Temporal_Relationships table. Each problem has Status (Active/Inactive /Resolved/Erased), Link to the Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
8 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): previous problem, Start_Date_Time and End_date_time. For the current patient problems, the End_date_time is NULL. In table 5, problems P2, P3 are current problems, and P2 reference P (P2 occurs after P) and P3 reference P2. The model allows one problem to be linked to many problems, and many problems to link one problem simply be conventional table Problem or by EAV_Problem table. This feature allows us to record the evolution of each problem until it is resolved. Each problem has one initial plan (Problem_Initial_Plan) which is a set of structured data that must be recorded whenever such problem is identified in a patient. The evolution of a patient s problem is recorded through its EPISODES, the set of which is called the PERSON PROBLEM'S DIARY. In an outpatient clinic environment, each episode of a problem corresponds to the occurrence of an encounter; in each ENCOUNTER several problems can be addressed, hence several EPISODES can be created. For each EPISODE several pieces of information that correspond to the proposed Subjective, Objective, Assessment and Plan (SOAP) structure for progress notes can, optionally, be recorded or created. Each episode has Prescription which has a set of Medications which describes the types of medicine the patient will take for the problem. Observation table stores the patient s assessments and diagnoses. It stores the observations of the physician during structured and systematic examinations of the patient s body during encounters/episodes. It allows characterization of expressed problems with observational evidence in explicit common terms and measures that, over time, will allow practitioners to follow the course of illness and recovery. Laboratory tests are stored in Lab_Test table, and radiological tests in Radiology_Procedure. Each problem has many lab and radiology tests and the tables contain summary information about it. If clinician needs to see test details, the model contains a link to the RIS or LIS. Some problems may need non medical therapies which may be advices or practices. These data are stored in Non_Medical_Therapies table. In an encounter the physician may need to schedule a set of events for the patient. Each problem may have a treatment plans and orders (Order/Plan table). A care treatment plan may be a broad perspective program that identifies planned clinical encounters, education and scheduled events (Scheduled_Events table) related to specific diagnosis or problem. Each order may require a set of clinical services. Electronic ordering should include medications, oncology management, laboratories and radiology. Orders should automatically be routed to the department and staff responsible for executing them. The class hierarchy in Figure 8 will be added to the model, and any complex type can be defined as a class hierarchy and used as table or column type. Also, the EAV/CR can extend any sparse table as Problem table. Any table for EAV modeling will begin by EAV_. Figure shows how to extend conventional relation as Problem with the dynamic attributes in EAV_Problem without affecting the physical design of database. This process requires domain expert to define each table s conventional part. EAV_Problem table contains Table 5: A Problem table snapshot ProblemID Name Status Link Start End P A //202 /3/202 2 P2 A 2/3/202 null 3 P3 A 2 2/3/202 null _Missing attribute to record the absence of value for attribute if it makes sense. The same extension is done for Episodes table. Moreover, the referential integrity constraint is preserved in this extended model because the relationships are between the conventional tables and the integrity which is preserved by the DBMS. Many types of relationships exist in our model: - Inheritance (between classes). 2- Composition (if class define attribute as object or if EAV table has attribute of type object). 3- The conventional design relationships. 4- The relationships between EAV tables and conventional tables. 5- The temporal relationships. If any entity has temporal relationships with other entity including itself, it can use the ideal in Figure 0. We will not represent all these relationships in the model to preserve simplicity. EAV_Episodes Problem EAV_Problem EpisodeID Date_Time Attribute _Int _Text _ Number _Object _date _BLOB _missing Episodes EpisodeID 5. SCOPE AND LIMITATIONS ProblemID ProblemID Date_Time Attribute _Int _Text _ Number _Object _date _BLOB _Missing Fig. : EAV/CR Extension with referential integrity preserved. This EHR data model can be applied in any healthcare organization which needs to enhance its patient care capability. The model can preserve a complete picture about patient s current and past medical and clinical conditions. It is an open model and allow designer to select which attributes to add. At the same time the model optimize memory usage. Because of space Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
9 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online): restrictions, the model needs to handle the interoperability issues. If the hospitals need to build a national EHR, the communication between local EHR must be handled may be by using a standardized terminology server as SNOMED CT. 6. CONCLUSION In this paper, we proposed a generic, clinical and temporal data model for the EHR database using object relational data model. This is achieved by using a mixed design consisting of standard and generic tables so that varied data types can be represented in the database. Because patient problems are the most important driver for physicians queries in healthcare, this model models a problem oriented record. This logical design did not present data attributes for entities to preserve the simplicity and to make the design as generic as possible. The most important entities are modeled and any temporal or generic entity can be modified with minimum effect on the physical design of the database. This solution allows continuous modifications of EHR database requirements to be applied smoothly and with minimum effect on EHR system applications. The temporal, social, and clinical aspects of the model enhance the data mining and knowledge discovery processes on the EHR database which enhances the operations of CDSS. The next step will be to implement this logical model and apply data mining techniques on its data. We will solve the interoperability problem in the next version of the model. Moreover, we will build a clinical decision support system. This system collects patient data from EHR and takes clinical decisions to aid healthcare personnel to make clinical decisions. References  A. Begoyan, An overview of interoperability standards for electronic health record, Integrated Design and Process Technology, Society for Design and Process Science (IDPT),  International Organization for standardization (ISO) Requirements for electronic health record reference architecture, ISO TC 25/SC  American Society for Testing and Materials (ASTM), ASTM E Standard Practice for Content and Structure of the Electronic Health Record (EHR), Available from: URL: E384.htm, last seen: January 202.  European Committee for Standardization CEN/ TC25 preenv 238, TSMI: a standard for time specific problems in healthcare informatics and telematics 997, last seen: Jan  W. MacKinnon, M. Wasserman Integrated Electronic Medical Record Systems: Critical Success Factors for Implementation, IEEE Proceedings of the 42nd Hawaii International Conference on System Sciences, On Page(s): -0, issue date Jan  W. Xu, Z. Guan, H. Cao, H. Zhang, M. Lu, T. Li; Analysis and evaluation of the Electronic Health Record standard in China: A comparison with the American national standard ASTM E 384, international journal of medical informatics, Vol. 80, Issue 8, Pages e39-e88, , 20.  R. Elmasri, Fundamentals of Database Systems (6th Edition), Publisher: Addison Wesley, ISBN- 3: , 200.  P. Nadkarni, L. Marenco, R. Chen, E. Skoufos, G. Shepherd, DPhil, P. Miller; "Organization of Heterogeneous Scientific Data Using the EAV/CR Representation," J. of the American Medical Informatics Association JAMIA / 6(6):478-93, 999.  M. Luis, T. Nicholas, C. Chiquito, S. Gordon, M. Perry, N. Prakash; "Achieving Evolvable Web- Database Bioscience Applications Using the EAV/CR Framework: Recent Advances," Journal of the American Medical Informatics Association 0 (5): ,  D. Valentin, N. Prakash; "Guidelines for the effective use of entity-attribute-value modeling for biomedical databases", International journal of medical informatics 76 ( 2): ,  R. Sriram, The Role of Standards in Healthcare Automation, 5th Annual IEEE Conference on Automation Science and Engineering Bangalore, India, August 22-25, On page(s): 79 82,  S. Cohen, A. Shabo; Electronic Health Record (EHR) Standards Survey, IBM research, 200, Available at: research.ibm.com /haifa/projects/software/imr/papers/ehrsurvey.pdf, last seen: January 202.  E. Coiera, Guide to Health Informatics, Publisher: Hodder Arnold Publishers; 2nd edition,  Health Level Seven International [Online]. Available from: URL: index.cfm/, last view: January 202.  Z. Yaowei, X. Yabin; Design of Electronic Medical Record Data Integration Model Based on OGSA-DAI, IEEE 3rd International Conference on Advanced Computer Theory and Engineering (ICACTE), on page(s): V V3-28, 200.  C. Kumar, C. Rao, A. Govardhan; A framework for interoperable healthcare information systems, IEEE International Conf. on Computer Information Systems and Industrial Management Applications (CISIM), pages: , 200. Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
10 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No, September 202 ISSN (Online):  Frank L., Andersen S.K.; Evaluation of Different Database Designs for Integration of Heterogeneous Distributed Electronic Health Records, The IEEE/ICME Inter. Conf. on Complex Medical Engineering (CME), page(s): , 200.  J. Anhoj, "Generic design of web-based clinical databases," Journal of Medical Internet Research, vol. 5(e27), November  T. Yong, T. Na, Y. XiaoPing, F. ZhiSheng, X. Wei; A Unified Model of Temporal Knowledge and Temporal Data, The IEEE 8th International Conference on Computer Supported Cooperative Work in Design. Pages: 7-73 Vol.,  Paul R., A. Latiful Hoque; Optimized Entity Attribute Model: A Search Efficient Representation of High Dimensional and Sparse Data, the 9th Asia Pacific Bioinformatics Conference (APBC20), IBC, vol. 3, article no. 9, pp. -6, 20.  G. Duftschmid, T. Wrba, C. Rinner; Extraction of standardized archetyped data from Electronic Health Record systems based on the Entity- Attribute- Model, International J. of Medical Informatics; Vol. 79(8); pp ; 200.  P. Nadkarni, C. Brandt, S. Frawley, F. Sayward, R. Einbinder, D. Zelterman; Managing attributevalue clinical trials data using the ACT/DB clientserver database system, J. American Medical Informatics Association vol. 5, no: 2,  T. Beale, GEHR System Architectures, 2003, last seen: Jan  I. Roma n, L. Roa, J. Reina-Tosina, G. Madinabeitia; Demographic management in a federated healthcare environment, International Journal of Medical Informatics, Volume 75, Issue 9, Pages ,  X. Wang, J. Ling; Multiple valued logic approach for matching patient records in multiple databases, J. of Biomedical Informatics, pp , Vol. 45, 202.  Gilchrist, J., Frize, M., Ennett, C.M., Bariciak, E.; Performance Evaluation of Various Storage Formats for Clinical Data Repositories, IEEE Transactions on Instrumentation and Measurement, Vol. 60, Issue: 0, Page(s): , 20.  V. Dinu, P. Nadkarni, C. Brandt; Pivoting approaches for bulk extraction of Entity Attribute data, ACM Journal of Computer Methods and Programs in Biomedicine archive, Vol. 82, Issue,  S. B. Johnson, "Generic data modeling for clinical repositories," Journal of the American Medical Informatics Association (JAMIA), vol. 3, pp , 996.  PRAKASH M. NADKARNI, C. BRANDT; Data Extraction and Ad Hoc Query of an Entity Attribute Database, Journal of the American Medical Informatics Association, Vol. 5, Num. 6, 998.  R. S. Chen, P. Nadkarni, L. Marenco, F. Levin, J. Erdos, P. L. Miller; Exploring Performance Issues for a Clinical Database Organized Using an Entity- Attribute- Representation, Journal of the American Medical Informatics Association, Vol. 7 Number 5, pages ,  R.H. Dolin, Modeling the temporal complexities of symptoms, Journal of the American Medical Informatics Association, Vol. 2, Num. 5, 995.  Paul R.; Hoque A.S.M.L.; A storage & search efficient representation of medical data, IEEE International Conference on Bioinformatics and Biomedical Technology (ICBBT), Page(s): , 200.  CEN (European Committee for Standardization)/Technical Committee 25- Medical Informatics. Project Team 07. Time Standards for Healthcare Specific Problems. Draft. CEN/TC25/ PTO7. September 30, 994.  Nadeem M., Aqil B., Kamran A.; A Logical Temporal Relational Data Model, IJCSI International Journal of Computer Science Issues, Vol. 7, Issue, No., 200.  International Organization for Standardi-zation (ISO), Available: _technical_committee?commid = Last seen: January 202.  International Organization for Standardi-zation (ISO), Available: iso_catalogue/catalogue_tc/catalogue_detail.htm?cs number= Last seen: January 202.  International Organization for Standardization, [Online]. Available:  Digital Imaging and Communications in Medicine, [Online]. Available:  The European Committee for Standardization, [Online]. Available: Copyright (c) 202 International Journal of Computer Science Issues. All Rights Reserved.
International Journal of Information Science and Intelligent System, 3(3): 51-60, 2014 Modeling Temporal Data in Electronic Health Record Systems Chafiqa Radjai 1, Idir Rassoul², Vytautas Čyras 3 1,2 Mouloud
Electronic Health Record (EHR) Standards Survey Compiled by: Simona Cohen, Amnon Shabo Date: August 1st, 2001 This report is a short survey about the main emerging standards that relate to EHR - Electronic
Evaluation of a Persistent Store for openehr Jon Patrick 1, Richard Ly 1, Donna Truran 2 1 School of Information Technologies University of Sydney 2 National Centre for the Classification in Health University
Techniques for ensuring interoperability in an Electronic health Record Author: Ovidiu Petru STAN 1. INTRODUCTION Electronic Health Records (EHRs) have a tremendous potential to improve health outcomes
Advanced Aspects of Hospital Information Systems EHR- and related Standards DI Harald Köstinger (firstname.lastname@example.org) INSO - Industrial Software Institut für Rechnergestützte Automation
Model Driven Laboratory Information Management Systems Hao Li 1, John H. Gennari 1, James F. Brinkley 1,2,3 Structural Informatics Group 1 Biomedical and Health Informatics, 2 Computer Science and Engineering,
openehr The Reference Model Thomas Beale Sam Heard 1:N openehr Semantic architecture Screen Forms Messages 1:N Reports Templates Data conversion schemas 1:N Archetypes Terminology interface Terminologies
Digital Healthcare Empowering Europeans R. Cornet et al. (Eds.) 2015 European Federation for Medical Informatics (EFMI). This article is published online with Open Access by IOS Press and distributed under
COMP 378 Database Systems Notes for Chapter 1 of Database System Concepts Introduction A database management system (DBMS) is a collection of data and an integrated set of programs that access that data.
HL7 and SOA Based Distributed Electronic Patient Record Architecture Using Open EMR Priti Kalode 1, Dr Onkar S Kemkar 2, Dr P R Gundalwar 3 Research Student, Dept of Comp Sci &Elec, RTM Nagpur University
Database Systems I (Compulsory) INTRODUCTION This is one of the 4 modules designed for Semester 2 of Bachelor of Information Technology Degree program. CREDITS: 04 LEARNING OUTCOMES On completion of this
TEMPORAL DATABASES Richard Thomas Snodgrass A temporal database (see Temporal Database) contains time-varying data. Time is an important aspect of all real-world phenomena. Events occur at specific points
International Journal of Grid and Distributed Computing 23 Remote Sensing Images Data Integration Based on the Agent Service Binge Cui, Chuanmin Wang, Qiang Wang College of Information Science and Engineering,
A COMPARATIVE STUDY BETWEEN THE PERFORMANCE OF RELATIONAL & OBJECT ORIENTED DATABASE IN DATA WAREHOUSING Dr. (Mrs Pushpa Suri) 1 and Mrs Meenakshi Sharma 2 1 Associate professor, Department of Computer
Release 1.0.1 The openehr Reference Model a. Ocean Informatics Editors: T Beale a Revision: 0.6 Pages: 15 Date of issue: 22 Jul 2006 Keywords: EHR, reference model, integration, EN13606, openehr EHR Extract
EHR Requirements David LLOYD and Dipak KALRA CHIME Centre for Health Informatics and Multiprofessional Education, University College London N19 5LW, by email: email@example.com. Abstract. Published
ehealth Week 2007 EuroRec Institute / ProRec Germany Workshop EHR Systems: an Introduction Bernd Blobel 1 & Dipak Kalra 2 1 ehealth Competence Center University of Regensburg Medical Center Regensburg,
Digital Healthcare Empowering Europeans R. Cornet et al. (Eds.) 2015 European Federation for Medical Informatics (EFMI). This article is published online with Open Access by IOS Press and distributed under
Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe Table of Contents A. Short Table of Contents (This Includes part and chapter titles only) PART 1: INTRODUCTION AND CONCEPTUAL
Proceedings of the 7 th International Conference on Applied Informatics Eger, Hungary, January 28 31, 2007. Vol. 1. pp. 335 342. Object-relational EH databases Lajos Kollár a, Henrietta Sipos b, Krisztián
The following is an excerpt from a draft chapter of a new enterprise architecture text book that is currently under development entitled Enterprise Architecture: Principles and Practice by Brian Cameron
Prediction of Heart Disease Using Naïve Bayes Algorithm R.Karthiyayini 1, S.Chithaara 2 Assistant Professor, Department of computer Applications, Anna University, BIT campus, Tiruchirapalli, Tamilnadu,
113 Comparing Different Approaches to Two-Level Modelling of Electronic Health Records Line Michelsen, Signe S. Pedersen, Helene B. Tilma, Stig K. Andersen Abstract Department of Health Science and Technology
Presented By: The National Learning Consortium (NLC) Developed By: Health Information Technology Research Center (HITRC) Vendor Selection and Management Community of Practice Version: 1.0 Date: October
International Journal of Information and Computation Technology. ISSN 0974-2239 Volume 3, Number 9 (2013), pp. 971-976 International Research Publications House http://www. irphouse.com /ijict.htm Deriving
Healthcare Data: Secondary Use through Interoperability Floyd Eisenberg MD MPH July 18, 2007 NCVHS Agenda Policies, Enablers, Restrictions Date Re-Use Landscape Sources of Data for Quality Measurement,
: Database Systems 1 (DBS 1) (Compulsory) 1. OUTLINE OF SYLLABUS Topic Minimum number of hours Introduction to DBMS 07 Relational Data Model 03 Data manipulation using Relational Algebra 06 Data manipulation
ehr Sharable Data Vicky Fung Senior Health Informatician ehr Information Standards Office ehr - Vision DH HA epr Private Private Hospit als Hospitals EHR Repository Access Portal CMS onramp PPP Clinics
A Tool for Generating Relational Schema from EER Diagram Lisa Simasatitkul and Taratip Suwannasart Abstract design is an important activity in software development. EER diagram is one of diagrams, which
Integration of Distributed Healthcare Records: Publishing Legacy Data as XML Documents Compliant with CEN/TC251 ENV13606 J.A. Maldonado, M. Robles, P. Crespo Bioengineering, Electronics and Telemedicine
1 B.Sc (Computer Science) Database Management Systems UNIT-V Business Intelligence? Business intelligence is a term used to describe a comprehensive cohesive and integrated set of tools and process used
Improving EHR Semantic Interoperability Future Vision and Challenges Catalina MARTÍNEZ-COSTA a,1 Dipak KALRA b, Stefan SCHULZ a a IMI,Medical University of Graz, Austria b CHIME, University College London,
SQL Server An Overview SQL Server Microsoft SQL Server is designed to work effectively in a number of environments: As a two-tier or multi-tier client/server database system As a desktop database system
Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy
, pp.-40-44. Available online at http://www. bioinfo. in/contents. php?id=42 SPATIAL DATA CLASSIFICATION AND DATA MINING RATHI J.B. * AND PATIL A.D. Department of Computer Science & Engineering, Jawaharlal
Introduction to Information and Computer Science: Information Systems Lecture 1 Audio Transcript Slide 1 Welcome to Introduction to Information and Computer Science: Information Systems. The component,
EHR Standards Landscape Dr Dipak Kalra Centre for Health Informatics and Multiprofessional Education (CHIME) University College London firstname.lastname@example.org A trans-national ehealth Infostructure Wellness
Measuring the Interoperability Degree of Interconnected Healthcare Information Systems Using the LISI Model Mihaela Vida*, Lăcrămioara Stoicu-Tivadar*, Elena Bernad**, *Faculty of Automatics and Computers,
Database Design Considerations Designing a database requires an understanding of both the business functions you want to model and the database concepts and features used to represent those business functions.
Genomics and the EHR Mark Hoffman, Ph.D. Vice President Research Solutions Cerner Corporation Overview EHR from Commercial Perspective What can be done TODAY? What could be done TOMORROW? What are some
ISM 318: Database Systems Dr. Hamid R. Nemati Department of Information Systems Operations Management Bryan School of Business Economics Objectives Underst the basics of data databases Underst characteristics
This image cannot currently be displayed. Chapter 1: Introduction Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Database Management System (DBMS) DBMS contains information
A VOICE MEDIATED SYSTEM FOR STRUCTURED ENTRY OF MEDICAL DATA IST-2001-38143 ATVN-EU-GP Conference Applications Relating to Health 1-3 December 2005, Pułtusk near Warsaw, Poland 1 AGENDA AND TIME SCHEDULE
A MODEL OF OPENEHR-BASED ELECTRONIC MEDICAL RECORD IN INDONESIA 1 A.B. MUTIARA, 2 A. MUSLIM, 3 T. OSWARI, 4 R. ASRITA 1 Prof., Faculty of Computer Science and Information Technology, Gunadarma University,
SUMMARY Features INTERIN Technology, a complex of software tools and techniques for building health care information systems, was developed in the Program Systems Institute, Russian Academy of Sciences.
Chapter 5 Foundations of Business Intelligence: Databases and Information Management 5.1 Copyright 2011 Pearson Education, Inc. Student Learning Objectives How does a relational database organize data,
Chapter 1: Introduction Database System Concepts, 5th Ed. See www.db book.com for conditions on re use Chapter 1: Introduction Purpose of Database Systems View of Data Database Languages Relational Databases
CST171 DB Management Approaches Page 1 1 2 3 4 5 6 7 Database Management Approaches CST171 Distributed DBMS (DDBMS) (Page 1) Computers at various sites can be connected with communications network or network
Data Base Management Systems (DBMS) Study Material (Objective Type questions with Answers) Shared by Akhil Arora Powered by www. your A to Z competitive exam guide Database Objective type questions Q.1
Chapter 2 Data Model Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: Why data models are important About the basic data-modeling
UNIT-1 Ques 1. Define dbms and file management system? Ans- Database management system (DBMS) is a collection of interrelated data and a set of programs to access those data. Some of the very well known
334 JOURNAL OF ELECTRONIC SCIENCE AND TECHNOLOGY, VOL. 10, NO. 4, DECEMBER 2012 A Data Model of EHR Storage Based on HL7 RIM Ke Li, Jin Xu, Jiang-Xiong Li, Guo-Sheng Huang, Ming Zhou, Cong-Cong Qiao, and
META DATA QUALITY CONTROL ARCHITECTURE IN DATA WAREHOUSING Ramesh Babu Palepu 1, Dr K V Sambasiva Rao 2 Dept of IT, Amrita Sai Institute of Science & Technology 1 MVR College of Engineering 2 email@example.com
SAĞLIK-NET Project in Turkey and HL7 v3 Implementation K. Turhan, B. Kurt, and E. Uzun Abstract This paper describes Clinical Document Architecture Release Two (CDA R2) standard and a client application
SAĞLIK-NET Project in Turkey and HL7 v3 Implementation K. Turhan, B. Kurt, and E. Uzun Abstract This paper describes Clinical Document Architecture Release Two (CDA R2) standard and a client application
Introduction: In this lecture, we discuss the principles of dimensional modeling, in what way dimensional modeling is different from traditional entity relationship modeling, various types of schema models,
A MODEL OF OPENEHR BASED ELECTRONIC MEDICAL RECORD IN INDONESIA 1 A.B. Mutiara, 2 A. Muslim, 3 T. Oswari, 4 R.A. Miharja 1,2,4 Faculty of Computer Science and Information Technology, Gunadarma University,
Physical Design Physical Database Design (Defined): Process of producing a description of the implementation of the database on secondary storage; it describes the base relations, file organizations, and
CONCEPTUAL UNIVERSAL DATABASE LANGUAGE (CUDL) AND ENTERPRISE MEDICAL INFORMATION SYSTEMS Nikitas N. Karanikolas, Christos Skourlas Technological Educational Institution of Athens Ag. Spyridonos Str., 12210,
July 8, 2009 Version 2.5 HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component HITSP/C32 Submitted to: Healthcare Information Technology Standards Panel Submitted by: Care Management
Ahmed AlBarrak PhD Medical Informatics Associate Professor, Family & Community Med. Chairman, Medical Informatics Department College of Medicine King Saud University firstname.lastname@example.org What are Medical
Templates and Archetypes: how do we know what we are talking about? Sam Heard, Thomas Beale, Gerard Freriks, Angelo Rossi Mori, Ognian Pishev Version 1.2, 12th February 2003 This discussion paper is addressed
ehealth Beyond the Horizon Get IT There S.K. Andersen et al. (Eds.) IOS Press, 2008 2008 Organizing Committee of MIE 2008. All rights reserved. 3 An Ontology Based Method to Solve Query Identifier Heterogeneity
HL7 and Meaningful Use Grant M. Wood HL7 Ambassador HIMSS14 2012 Health Level Seven International. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven International.
Chapter 6 Basics of Data Integration Fundamentals of Business Analytics Learning Objectives and Learning Outcomes Learning Objectives 1. Concepts of data integration 2. Needs and advantages of using data
3 Database Management Chapter Objectives When actually using a database, administrative processes maintaining data integrity and security, recovery from failures, etc. are required. A database management
Chapter 6 FOUNDATIONS OF BUSINESS INTELLIGENCE: DATABASES AND INFORMATION MANAGEMENT Learning Objectives Describe how the problems of managing data resources in a traditional file environment are solved
TANJI Natsuki Abstract Standardization of medical information systems by industry associations such as ISO/TC 215 and CEN/TC 251 is currently underway internationally. In Japan, too, participation in and
Cross-Border Challenges in Informatics with a Focus on Disease Surveillance and Utilising Big-Data L. Stoicu-Tivadar et al. (Eds.) 2014 The authors. This article is published online with Open Access by
Towards Integrating National Electronic Care Records in Saudi Arabia Mohammed Alnuem, Samir EL-Masri, Ahmed Youssef, Ahmed Emam Department of Information Systems, King Saud University, Riyadh, KSA Abstract
The 8 th International Conference on Computer Supported Cooperative Work in Design Procceedings Bitemporal Extensions to Non-temporal RDBMS in Distributed Environment Yong Tang, Lu Liang, Rushou Huang,
Lightweight Data Integration using the WebComposition Data Grid Service Ralph Sommermeier 1, Andreas Heil 2, Martin Gaedke 1 1 Chemnitz University of Technology, Faculty of Computer Science, Distributed
www.ijcsi.org 198 Survey on Multi-Tenant Data Architecture for SaaS Li heng 1, Yang dan 2 and Zhang xiaohong 3 1 College of Computer Science, Chongqing University Chongqing, 401331, China 2 School of Software
Oman College of Management and Technology Course 103402 MIS Topic 5 Foundations of Business Intelligence CS/MIS Department Organizing Data in a Traditional File Environment File organization concepts Database:
DISTRIBUTED ARCHITECTURE FOR ELECTRONIC HEALTH REFERRAL SYSTEM UTILIZING COMPUTATIONAL INTELLIGENCE FOR CLINICAL DECISION SUPPORT By Majd Misbah Al-Zghoul Supervisor Dr. Majid Al-Taee, Prof. This Thesis
International Journal of Information Technology and Knowledge Management January-June 2012, Volume 5, No. 1, pp. 234- Health Care Management Information Systems with Object Oriented Methodology Kanta Jangra
Shelly Spiro, Executive Director, Pharmacy HIT Collaborative reports no relevant financial relationships. 1. Discuss the vision, mission, and goals of the Pharmacy HIT Collaborative as it relates to informatics,
Foundations of Information Management - WS 2012/13 - Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Data & Databases Data: Simple information Database:
D. Tcharaktchiev University Hospital of Endocrinology, Sofia, Bulgaria I. E. Ivanov, V. Gueorguiev Technical University Sofia, Bulgaria D. V. Georgieva 4New Bulgarian University, Bulgaria Design of Modern
Foundations of Business Intelligence: Databases and Information Management Problem: HP s numerous systems unable to deliver the information needed for a complete picture of business operations, lack of
Web Contents for Database Design Book Link to the Authors Web Site The Perpetual Technologies web site, http://www.perptech.com, contains information about relational database technology, with specialization
HETEROGENEOUS DATA INTEGRATION FOR CLINICAL DECISION SUPPORT SYSTEM Aniket Bochare - email@example.com CMSC 601 - Presentation Date-04/25/2011 AGENDA Introduction and Background Framework Heterogeneous
Setting the World on FHIR W. Ed Hammond. Ph.D., FACMI, FAIMBE, FIMIA, FHL7 Director, Duke Center for Health Informatics Director, Applied Informatics Research, DHTS Director of Academic Affairs, MMCi Program
DATA WAREHOUSING AND OLAP TECHNOLOGY Manya Sethi MCA Final Year Amity University, Uttar Pradesh Under Guidance of Ms. Shruti Nagpal Abstract DATA WAREHOUSING and Online Analytical Processing (OLAP) are
Session-7: Object-Relational DBMS Cyrus Shahabi 1 Motivation Relational databases (2 nd generation) were designed for traditional banking-type applications with well-structured, homogenous data elements
Your consent to our cookies if you continue to use this website.