Electronic Health Record Data Model Optimized For Knowledge . - IJCSI

IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012ISSN (Online): 1694-0814www.IJCSI.org(3) Protocol-driven patient record: In this model, atemplate is captured in a pre-structured form that dictateswhat specific data are to be obtained and recorded by theclinician.(4) Problem-Oriented Medical Record (POMR): Itorganizes data according to the list of patient problems.The problem list acts as an index to the whole record. Allprogress notes, tests, treatment notes and medications arenumbered according to the problem they relate to.Progress notes are often written according to theSubjective Objective Assessment Plan SOAP template.No single patient record structure will suit every purpose.In our model will support POMR because physicianconcentrates on patient problems when searching for andstoring data.2.4 EHR standardsWe concentrate on three EHR design problems where are(1) Healthcare messages exchange, (2) EHR objectmodel (i.e. content and structure), and (3) Healthcareterminology/ vocabulary. In addition, the EHR systemshould incorporate a proper security mechanism.Table 1 [12] summarizes how the three standardsorganizations support the three parameters of EHR.Table 1: EHR Standards [12]HL7CEN TC 215ASTM E31ASTM E1238,ASTM1394,ASTM E1467MessagingHL7 V3ENV 13606 - 4EHR ObjectModelnostandardpartially:ENV 13606 - 1,ENV 13606 - 2partially:ASTM 1384TerminologyLOINC,SNOMED,UMLS,etc.no standardICD9,SNOMED,etc.The table shows that while standards for healthcaremessage exchange and terminology exists, there is nostandard for EHR Object Model. HL7 [14] is in theinitial phases of defining EHR content. CEN TC 215suggests an EHR structure but does not define itscontent. ASTM E31 is the closest to an EHR objectmodel [3], but it still lacks a lot of essential informationand it’s not clear how to extend the given model. As aresult our proposed model tries to handle this shortageand develop a generic EHR data model.3. PROBLEM STATEMENTEHR integrates heterogeneous data from many sourceswhich is important for knowledge discovery. Thecomplexity, sparseness and fast evolution of clinicalinformation makes development and maintenance ofclinical databases challenging [18]. Conventional(relational) databases have static design. On the other331hand, in healthcare environment, entities and attributes(physical design) are changed continuously. This can betime consuming for the maintenance and upkeep of thedatabase and all applications depending on it and userinterface must be changed as well. Also, in relationaldatabase there are a maximum number of attributes foreach relation and a set of predefined data types whichcannot be extended. EHR databases should ideally beflexible enough to handle new data types and attributeswithout needing to change the physical database schema.Also, Time is important in EHR data model.Representing, maintaining, querying, and reasoningabout time-oriented clinical data are critical successfactor. Although EHR contains temporal data as patienthistory, the structure of conventional database does notmake it easy to store time-varying data.Healthcare data are sparse. Each entity will havethousands of attributes, but each row in the table will useonly small set of these attributes as patient tests. Thissituation waste storage space as shown in table 2.Table 2: EHR sparseness of 2nullnullz2nullnullc2.3N3nully3nullnullb3null.We require an open schema data model to supportdynamic schema change, sparse data, temporal and highdimensional data. In open schema data models, logicalmodel of data is stored as data rather than as schema, sochanges to the logical model can be made withoutchanging the schema. In this paper, we will use relationaldesign to build EHR data model after solving itsproblems and handling its shortages. The problems assparseness, continuously evolving problems [20, 22],adding new data types, and temporal data modeling [4,19] are solved in our model. In this model, we useEAV/CR modeling when we need to model sparse anddynamic data. Non-sparse data as patient demographicdata stored in conventional relational tables. This is amixed-schema design. Also, EAV permits the extractionof archetypical data from database to facilitate datainteroperability [21]. For interoperability and knowledgediscovery purposes, there are also vocabulary tables asshown in figure 4 [22].Database ServerVocabularyDictionaryEAV dataNon-EAV data tablesFig. 4: EHR database server.4. PROPOSED DATA MODELIn this section, we will propose our data model for EHRdatabase that solves all of its design problems.Copyright (c) 2012 International Journal of Computer Science Issues. All Rights Reserved.

IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012ISSN (Online): 1694-0814www.IJCSI.org4.1 Evolution of EAV and EAV/CRThe model allows the storage of conventional relationaldata for not sparse data. Also, if new data type is needed,class diagram can be defined and map any class torelational table or to a type of column. Spare data will bestored in EAV sub-schema. This behavior is used tominimize the negative effects of EAV to the whole EHRsystem as shown next. At the same time, it meets thechallenges in section 3.In relational databases, the logical and physical schemashave the same layout. The complexity and the rapidevolution and expansion of the domain of clinicalinformation require a large maintenance overhead if dataare laid out using a relational design. For this reason, it isdesirable that EHR database be flexible and allow formodifications and for addition of new types of datawithout having to change the physical database schema.The ideal design would implement a highly-detailedlogical database schema in a completely-generic physicalschema that stores the wide variety of clinical data in asmall (and constant) number of tables.- Basic EAV SchemaIn EAV design all data can be stored in a single generictable with conceptually 3 columns: 1 for entity (e.g.,patient identification), 1 for attribute (e.g., name), and 1for value (e.g., "Jens Hansen") [28]. To add moredescriptive fields to the entity class, you add attributevalues in the attribute field as in table 3, 4. The mainadvantages of this design are flexibility and effectiveentity-centered queries and storage saving by preventingfields with NULL values.Table 3: Conventional relational databasePatient /2012TomnullTest2nullT22T222332described in EAV metadata relational tables, so anychange to the logical structure will be added, deleted, orupdated without affecting the physical structure.Metadata plays a critical role in virtually convertingEAV physical schema to the relational-like, user friendlylogical schema. This allows end users to query EAV asrelational data.The non-sparse data as patient demographics can bemodeled in conventional tables and connect this table toEAV 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 thepatient event: a foreign key into a table that containsat a minimum a patient ID and one or more timestamps (e.g., the start and end of the examinationdate/time) that record when the event being describedhappened. The attribute or parameter: a foreign key into a tableof attribute definitions (in this example, definitions ofclinical findings). At the very least, the attributedefinitions table would contain the followingcolumns: an attribute ID, attribute name, description,data type, units of measurement, and columnsassisting input validation, e.g., maximum stringlength and regular expression, maximum andminimum permissible values, set of permissiblevalues, etc. The value of the attribute. This would depend on thedata type.Querying EAV data is more difficult than conventionaldata as follows: querying tables 4, 5 for patient ‘Hans’using SQL:ConventionaltablePatient IdIntegerNameVarchar(30)Date of birth DateEAV tableTable 4: EAV database designPatient 2NameTest2ValueHansT1GemsT11T22TomT222In EHR environment, the meaning of null (inapplicable,unavailable or unknown) is sometimes required. Tohandle this situation, a “missing value code” columnshould be added to an EAV table, which is non-null onlywhen the value column is null. The main disadvantagesare data display, attribute-centered query complexity andinefficient constraint checking. The logical schema isPatientEAV DataPatient IdIntegerDateDatetimeAttribute Id IntegerValueVarchar(255)Metadatatable1 AttributeAttribute IdAttribute NameData TypeFig. 5: Simple EAV schemaTable 4:SELECT *FROM table4WHERE name LIKE 'Hans%'AND Date '2/1/2012';Table 5:Copyright (c) 2012 International Journal of Computer Science Issues. All Rights Reserved.IntegerVarchar(15)Varchar(15) 1

IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012ISSN (Online): 1694-0814www.IJCSI.orgSELECT d1.patientID AS patientID,d1.value AS name,d2.value AS DateFROM table5 AS d1 INNER JOIN table5 AS d2USING (patientID)WHERE d1.attribute 'name'AND d1.value LIKE 'Hans%'AND d2.attribute 'Date'AND d2.value '2/1/2012';Querying EAV data includes a self-join for eachattribute. This query complexity is solved by:(1) There may not be a problem. Attribute-centeredqueries are important for research questions only.(2) Any need for regular cross-patient data access couldbe met by making backups of the production databaseand restoring them onto separate hardware. Resourceintensive queries run on the backup data will not affectthe production server. Additionally, the EAV dataschema could be transformed into numerousconventional tables after backup thus easing querydesign by end users with modest SQL skills.(3) Optimization of queries may increase the efficiencyconsiderably.(4) EAV data may be pivoted [27] and converted tological relational model using data warehousing,materialized views or in-memory data structures as hashtables and two-dimensional arrays.(5) Extension of the SQL language to facilitate"pivoting" of attribute-centered data into a conventionallayout—the Extended Multi-Feature (EMF) SQL—cansolve the problem.- Multi data types EAV SchemaValues may of course be of any type, for example, text,number, or Boolean (true/false). In the example in Table5, the value field of the data table is text type. Such adesign achieves simplicity by storing all simple types astext values. This approach has, however, somedrawbacks. First, not all data types will fit into a textfield as Binary objects. Second, queries based on valueswill be less efficient for non-textual values. The text "12"is less than the text "2" even though it is numericallygreater, because text is sorted character by character,from left to right.One enhancement to EAV design is done by storing datawith different data types in separate tables [26]. Thismulti-data type EAV design allows the use of any datatype 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.3331Data integerPatient Id DateAttribute IdValueIntegerDatetimeIntegerIntegerPatientPatient IdIntegerNameVarchar(30)Date of birth DateData textPatient IdIntegerDateDatetimeAttribute Id IntegerValueVarchar(255)1 Fig. 6: Multi-data types EAV schema- Hybrid EAV SchemaThe best enhancement is hybrid EAV format that allowsthe use of multiple data types in a single table to providesimpler and faster queries [29], figure 7. It combines thebest features of the simple and multi-data type EAVdesigns without increasing the size of the data storage.This approach will be used in our model.- Enhancing EAV to EAV/CREAV is convenient when attributes are of simple orprimitive data types. However, it is possible that attributeis of object (class instance) type that has substructure.That is, some of its attributes may represent other kindsof objects, which in turn may have substructure, to anarbitrary level of complexity. EAV/CR schema supportscomplex substructure [30].PatientDataPatient IdDateAttribute IdValue intValue textValue objectValue binary1 Patient IdIntegerIntegerDatetime NameVarchar(30)IntegerDateOfBirth DateIntegerTextClass type Fig. 7: Hybrid EAV schemaBLOBFurthermore, EAV makes it easy to model the one-tomany relation between patient and clinical events. InEHR, it should be possible to record relationshipsbetween clinical events (e.g., infection leads to a courseof penicillin or myocardial infarction leads to death).EAV/CR schema handles the complex relationshipsbetween classes. This model adds an object-orientedframework to the EAV model by definition of classesand relationships. EAV/CR data and metadata are storedin Object-Relational data model. Figure 8 shows theEAV/CR metadata relational tables.1 ClassClass IDClass NameDescriptionClass Type1ClassHierarchSuperClassSubClassAttribute Attribute IDClass IDAttribute NameAttribute DescriptionDataTypeRequiredDefault valueFormatUpper BoundLower BoundFig. 8: EAV/CR Metadata relational modelCopyright (c) 2012 International Journal of Computer Science Issues. All Rights Reserved.

IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012ISSN (Online): 1694-0814www.IJCSI.org334In Figure 8, inheritance is designed in the ClassHierarchtable. Figure 9 shows how to model objects using EAVschema. Composition relationship is modeled inEAV Object table where one attribute of the main objectcan be object of a different class. Also, objects as clinicalevents can be related in EAV Object by addingattributes as O1 in response to O2, or O1 result fromO2. Keyword table is used to enhance the search process(Google-style search), by linking some descriptive wordsto specific objects.Ad hoc relationship between objects (e.g., penicillinleads to rash) may be recorded as objects themselves. Forthis purpose, a class ObjectRelation could be definedwith two attributes, objectID and relatedObjectID. Moredescriptive attributes may be added to this class ifrequired—e.g., causality.If you have hundreds or thousands of non-sparse objectsfor a given class, you should create a distinct table forthis class, preferably with the same name as the Classitself. (Naturally, such tables are not illustrated in theschema above, since they are specific to yourapplication.) The summary information for each object,however, still lies in the Objects table. This way, theKeyword table lets users locate Objects of interestirrespective of what Class they belong to. When you usea Mixed Design approach, where some data is stored inregular tables and other data in EAV form, the metadatain the Class table above should have a flag that stateswhether Object data for a given class is recorded inconventional columnar form or in EAV form. This way,your application code knows what to do when the userwishes to inspect the details of a particular object.Obviously, considerable up-front programming isrequired to drive an ergonomic user interface for theEAV/CR model in a real-life production environment.On the other hand, this is a one-time-only job.diagnostic explanation, diagnostic decisions, and patientmonitoring all rely heavily on the patient's past clinicalcourse, current medical status and future course (patienttreatment).Modeling time is varying and based on the choice ofontological primitives, whether time is viewed asdiscrete or continuous, modeling of uncertainty,incompleteness and impreciseness and granularity of thetime stamp chosen. The temporal database may storetransaction time (rollback database and DBMS supportthat), valid time which is the time when the event is valid(historical database) and both (bitemporal database).The EHR bitemporal database must allow:(1) Relating situations to a calendar.(2) Relating situations to “reference” situations.(3) Relating events together in “before- and after-”chains.KeywordObject4.2 Data transformation using domain dictionaryand rule baseMoreover, the time of an event may be known withrespect to a specific calendar date, time or timestamp(time point or instant) [34], with exact interval (start timeand end time, or occurrence time and duration), withrespect to the occurrence of some other event, withuncertain time, and/or uncertainly with other event.There are 49 relationships between time intervals andtime points [33].Temporal data model need to manage uncertainty ofevents, both to actual date/time of occurrence of an eventtime (e.g., Event A occurred about 5 years ago, and itwas winter, around 02:00 AM.), and to the occurrencerelative to some other event, both qualitatively (e.g.,Event A occurred before Event B) and quantitatively(e.g., Event A occurred approximately 1 week beforeEvent B). Our model will not handle the uncertainty.The precise time of an event, either time point or timeinterval, will be modeled by two attributesEvent Start Time and Event End Time. This timeFor interoperability, the EHR database must containstandard medical terminologies as UMLS or SNOMED.For knowledge discovery, the medical data have to betransformed into a suitable transaction format. Forcategorical data, each value is connected to one code. Forcontinuous attributes, we use a rule base such as ifage 20 and age 30 then age 2 and so on [32].4.3 EHR database is bitemporalTime is one of the most important variables inhealthcare, as medical temporal reasoning is directlyrelevant to almost every aspect of medical practice.Longitudinal data are essential for outcome analysis,CDSS and temporal data mining. History-taking, causal11 Object IDObject Class IDObject NameDate CreatedDate last changed EAV BinaryObject IDAttribute IDValueEAV Object Object IDAttribute IDValue Object IDAttribute IDValueEAV RealObject IDKeywordKeyword type EAV IntObject IDAttribute IDValueEAV Date Object IDAttribute IDValue Object IDAttribute IDValueEAV TextFig. 9: EAV/CR data modelCopyright (c) 2012 International Journal of Computer Science Issues. All Rights Reserved.

IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012ISSN (Online): 1694-0814www.IJCSI.orginterval will have the same value in its both ends in casethe event in time point event.In addition to defining an event with respect to anabsolute date/time, the model enables defining the timeof an event with respect to the time of some other event.We have 49 potential temporal relationships between twoevents. This requirement will be achieved by defininganother relation named Temporal Relationships whichnormalize the many-to-many temporal relationshipbetween two events as shown in Figure 10.The temporal relationship between any two events can bedescribed by the attribute Temporal Relationship. Thedomain 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 representsquantitative temporal relationships (e.g., Event Aoccurred approximately 2 weeks before Event B) byusing the attribute Relative-Interval, which represents theamount of time between two related events.There are many query languages which extends SQL asTime Line SQL (TLSQL), TSQL2, TQuel and otherwhich facilitate the querying of the temporal database.Domain expert must choose the appropriate level ofgranularity 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 theDays level is chosen, duration of five means five days.Clinical Event1 Event ID Integer1Temporal RelationshipsEvent ID 1IntegerEvent ID 2Integer0. m0. m Temporal Relationship Varchar(50)Relative IntervalIntegerFig. 10: Management of temporal relationships4.4 Details of proposed modelThe proposed framework tries to model all patientclinical events. To keep the simplicity of the model,standardization tables such as medicine type, controlledvocabulary for problem list (SNOMED CT) andterminology tables are removed, sparseness (EAV tables)will be designed aside, and only attributes required forrelationships between entities (primary key) are modeled(entities contains other attributes). The conceptualschema should correspond to expert understanding of themedical domain. It should be concerned with datarepresentation and not with issues of data storage andaccess efficiency. These sub-schemas can be appended335easily to our schema. Our model is problem orientedtemporal model where patient problems are the corecomponent. This structure provides a means of depictinga patient's problems and all clinical entries related toeach problem (e.g., symptoms, physical findings,laboratory tests, etc.). This grouping of data provides acontext within which one may interpret clinicalinformation. EHR also contains summary data fromother systems. When detailed data are needed, a link tothese 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, servicesand observations. Representing the overall structure ofthe record is difficult since it is complex and has anumber of dimensions. It also can be viewed from manyperspectives. Four of these are: chronological, byencounter/episode, by problem, and by topic. Each ofthese views looks at the same stored data in a differentway. Our model concentrates on patient pro

(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, . Entry PACS Billing HL7 & DICOM HL7 HL7 HL7 HL7 HL7 IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012