1 Introduction

This chapter introduces a database system called Intentionally Linked Entities (ILE), which links data entities in a more robust and efficient way than the relational database system. ILE also stores data in a more organized fashion than the relational system, and is more efficient at searches. These positive qualities of ILE present the possibility of improving the reliability and correctness of health care databases, and may therefore lead to improved and more efficient patient care and database analysis. By storing information more accurately and in a more organized fashion than the relational database system, ILE may help health care providers avoid mistakes that can compromise patient health, patient confidentiality, or other aspects of high-quality patient care. The improved data modeling afforded by ILE may also lead to improved epidemiological data modeling, intended to aid epidemiological discoveries.

A major motivation for developing the ILE database system is the importance of implementing data linking in a better, more robust way. The importance of data linking in health care databases is eloquently described in Trotter and Uhlman (2013, p. 55):

The authors also pointed out that when the information from a health care database is used for making dangerous decisions such as drug dosing and administration, even a seemingly minuscule error rate such as 0.02% may mean several tragic errors because of the volume of cases handled in a large medical facility. Patients with the same or similar names are routinely confused in health care facilities. Such confusion may lead to serious health risks such as improperly handling drug allergies, inappropriate medicine or medical/surgical procedures, a compromise of patient confidentiality, or inefficient or inaccurate health care database analysis. This is why linking errors have to be eliminated as much as possible.

The relational database system, first developed by Edgar F. Codd in the early 1970s, remains the most popular type of database system for health care informatics today (Wager et al., 2005). Despite its name, a significant problem with the relational database system is relationship linkage, which refers to the physical linking of data entities that are supposed to be related to each other via a relationship. More specifically, the relational database system determines whether two data entries are the same by comparing data field values, values that are entered separately by the users, often without a stringent check to make sure that entries that supposed to match actually match each other.

The problem with the relational database’s value comparison scheme is that any misspelling, including the inclusion of extraneous blanks or invisible control characters, can cause an absence of linkage. Less likely, but also possible, is the situation where two entries are inadvertently spelled the same and therefore linked when they should not be.

Another problem with the relational database system is that it is not a natural means of modeling complex data. Researchers and practitioners have noticed this fact since the 1980s, including in computer-aided design (CAD; Stajano, 1998) and in electronic medical records (Speckauskiene and Lukosevicius, 2008). As stated correctly in Kalet (2014, p. 134), the relational database model is appropriate for use when data logically match the idea of many identically structured records with a relatively simple structure, or a collection of such structures.

The relational database system is also well known to suffer from data redundancy and data fragmentation. Data redundancy can be reduced by not permitting duplicate entries and by normalization. However, checking for duplicates reduces efficiency in a large database, and normalization can be quite difficult to do correctly. Additionally, many users and database practitioners prefer nonnormalized databases because the tables of a nonnormalized database can be much easier to use, having all or much of the desired information in one table.

Using an object-oriented database (OODB) would solve the abovementioned linking problem inherent in the relational database system. Using a network database, such as its new form, the graph database, would solve the linking problem as well. This is because both the OODB and network database systems use object references or pointers for linkage, and linking to a nonexistent object is automatically not permitted. From Chaudhri and Zicari (2001), it can be seen that Object-Oriented databases have often become the database paradigm of choice for bioinformatics, or least for genomic computations.

However, the OODB system has two limitations that make it far less than optimum for health care informatics, or at least the part of it that deals with the treatment of diseases by health care providers working with patients and institutions like hospitals. One limitation is the lack of a query language in the original versions of the OODB. It is argued that the OODB is more often used in programs, and therefore what is important is an application programming interface (API), not a query language. However, by the turn of the millennium, OODB vendors have realized that users normally require a query language, and thus the vendors responded by providing query languages. In fact, vendors went further and permitted relational features in their systems, resulting in the object-relational database system. The other, more important limitation of the OODB is that it only supports relationships with two roles (that is, binary relationships, or relationships with arity = 2). Basically, the only means the OODB has for relating objects is to use object-valued attributes with references to other objects (Kim, 1993; Schlegelmilch, 1996). Thus, researchers had to come up with various, nonnative ways to augment the OODB system to handle relationships of higher arity, that is, relationships with three or more roles played by entities (Schlegelmilch, 1996).

As mentioned earlier, the graph database would also solve the linkage problem. However, like the OODB, this style of database system also restricts the arity of the relationships to 2. Furthermore, many-many relationships, which are binary (arity-2) relationships, are also not natively supported. Therefore, only relationships that are binary and one-to-one or many-to-one are natively supported by the OODB. Additionally, in an OODB system, there are no physical objects (in the object-oriented sense) representing the entity sets, and likewise no physical objects representing the relationship sets. As detailed in this chapter, ILE, on the contrary, does use objects to represent entity sets and relationship sets, as well as entities and relationships.

Lee et al. (2013) studied using Extensible Markup Language (XML) and certain tabular NoSQL approaches as alternatives to the relational approach for storing medical records. In brief, they found that the NoSQL approach is a “viable alternative” to the relational approach, whereas the XML is a “promising solution” that is “not yet ready for prime-time usage.” We will consider these approaches and compare them with the ILE approach in section 4 of this chapter.

As stated before, this chapter introduces the author’s Intentionally Linked Entities (ILE) data model and the corresponding ILE database system as a better alternative to the electronic health record (EHR) than the relational, objected-oriented, tabular NoSQL systems, or the graph database system. The ILE database system was reported by this author in Kantabutra (2007). How ILE can be used in social network analysis and other applications in the digital humanities was explored in Kantabutra et al. (2010, 2014).

ILE uses object-reference-based data structures to link entities that play various roles in each relationship. The ILE database system natively supports relationships of all arities, meaning binary, ternary, quaternary, etc. In addition, there is no restriction on how many other entities each entity could be related to in a relationship. So, for example, many-many relationships, which are binary, are supported. Additionally, each role in a relationship can be played by an entire set of entities if that capability is needed. No other database system or model supports such general types of relationships, and that fact makes ILE more suited to the complex relationships found in health care situations. ILE was conceived as a direct implementation of the Entity/Relationship (E/R) database model. However, as it stands now, ILE is more general in some important ways than E/R.

At the time of Kantabutra (2007), ILE was not implemented. Since then, however, a prototype has been implemented in Ruby, an object-oriented programming language that is particularly good for handling complex data structures and algorithms. However, lately the Treetop library for interpreting the commands and queries has been broken. The Treetop package is not easy to work with anyway, so the author decided to rewrite the command interpreter. The ILE code itself, implementing all the data structures, remains intact, and a new command interpreter is being written using a different package, Parslet, which, in the author’s opinion, is much easier to work with than Treetop.

This chapter extends the author’s earlier BIOCOMP conference paper (Kantabutra, 2014) by adding a new section on modeling an epidemiological database with ILE and another section surveying other nonrelational approaches in keeping medical records.

2 Introducing ILE for Health Care Applications

The best way to think of ILE is that it is a direct, straightforward implementation of the E/R model. There are differences and extensions, but we can deal with those as they come up.

As can be concluded from the previous discussion, the relational model favors relatively simple data models, even when these models are not necessarily as realistic as one would like. As an example, consider a relational model from a database for JMTZ Bee Healthcare, Inc., of a relationship between a provider (a doctor in this case) and a patient, shown in Figure 14.1 (Jin, 2000).

Suppose that we want to model the fact that a relationship between a provider and a patient comprises a set of visits. There are database models for the patient-provider relationship where the two people are related by a “visit” relationship. In such a representation, each visit is a separate relationship, and there is nothing that really binds all the visits of one patient to the same provider together.

In ILE, we can easily model both individual visits and the longer-term relationship between a provider and a patient. The most natural way to do this is shown in Figure 14.2.

This can be easily implemented in ILE as a ternary relationship, where the roles are patient, provider, and visits. The third role, visits, is actually a set or an array. In relational databases, arrays are usually not permitted. For example, MySQL does not permit array data types. Workarounds are necessary; for example, see MySQL 5.7 reference manual, section 11.1 (n.d.). Oracle, which has some features that are beyond those of plain Relational databases, does have an array data type called ARRAY, and a variant of that data type called VARRAY (see the definition of ARRAY, in the Oracle database system, n.d.), but the elements don’t appear to be full-fledged entities that can be conveniently linked in relationships as individuals or first-class citizens of the database.

As another example to use in comparing the various kinds of databases, we can look at prescriptions. In JMTZ’s relational database, a prescription is an entity with two binary relationships, as shown in Figure 14.3.

One of these relationships is with an invoice, and the other with one or more medicines. An invoice may have 0, 1, or more prescriptions.

The relational data model used by JMTZ allows for relationships with arbitrary arity. However, many designers of relational databases favor binary relationships because in a binary relationship, entities can be linked directly, without an extra table representing the relationship, and also because joins can be expensive, especially joins of more than two tables. Even query optimization can take considerable time. If this situation were to be modeled using a graph database or a pure OODB, then the type of relationships used would most likely be binary because only binary relationships are natively supported.

ILE, as opposed to these other database schemes, comfortably and natively supports relationships of practically any finite arity. Figure 14.4 shows how we can model a prescription in ILE as a relationship of arity 4.

In section 5 of this chapter, we will discuss, among other things, how such relationships are implemented in ILE using relationship objects that securely link the various entities playing the roles in each relationship so that navigation from the entities playing one set of roles to the entities playing another set of roles is direct and efficient.

3 ILE and epidemiological data modeling

One important use of health care databases that doesn’t seem to have been thoroughly explored, judging from the lack of well-cited papers in that area, is the use of such databases in epidemiology, including using databases to facilitate making epidemiological discoveries. Here again, researchers have been using the relational model. In particular, we will examine the database model introduced in Winnenburg et al. (2006), shown in Figure 14.5.

In this E/R model, it is clear that each member of the entity set Interaction actually has the meaning of a relationship that relates entities in several other entity sets, namely, Species (host and pathogen), Paper, and Gene.

For a good correspondence between data representation and data model semantics, Interaction should really be modeled as a relationship between these other entities. However, as observed earlier, relational database designers favor binary relationships over relationships with arity greater than 2, which explains why we have binary relationships here, forcing Interaction to be an entity set rather than a relationship set. It is not difficult to see why relational database designers prefer binary relationships when working with this example. If Interaction were to be represented directly as a relationship, it would need to be a quinary relationship; that is, a relationship with five roles. A relational table representing such a relationship would be large, and a query on this relational database would involves a join of up to six tables, with one table representing the relationship set Interaction and one table for each of the five roles.

Actually, even representing Interaction as an entity set and implementing the set as a table in the relational model may not save on the complexity of queries. If fields from all the entity sets are queried at the same time, then we still need to join multiple tables.

In Figure 14.6, we show the ILE alternative; that is, the ILE modeling of the same database.

Since ILE naturally supports relationships of arbitrary arities, we represent the interactions between the true entities in the database—namely, Species (host and pathogen), Paper, and Gene—as a set of quinary relationships. Each relationship object has direct object references to the objects representing the entities involved in the relationships, and each of the entity objects likewise has direct object references to all the relationship, as well as to all the other relationships that the entity is involved in. No expensive table joins are required at all.

4 Other nonrelational approaches to keeping medical records

This section will describe another paper that introduces nonrelational database models for use in storing health records, and compare those approaches with the ILE model presented here. In particular, we will discuss the approaches discussed by Lee et al. (2013). Two approaches were considered in that paper: namely, table-based NoSQL and XML. For the XML approach, two options were considered: the option of using native XML and the option of using Microsoft SQL Server and its XML data type.

According to Lee, Tang, and Choi, each medical consultation (which we call a “visit” elsewhere in this chapter) results in a medical note. This note is then organized into a hierarchical structure, as shown in Figure 14.7.

Such medical records can be represented in XML as shown in Figure 14.8.

The same paper also gives the actual XML code snippet for this. The header in that code contains patient information, whereas the body contains elements representing a subset of a wide variety of possible medical concepts, which we could also call “medical conditions” or “attributes,” such as fever, nausea, vomiting, or paralysis.

Our critique of the XML approach favored by Lee and colleagues is that XML most naturally supports hierarchical relationships, even though other relationships can be represented by identifying an element with an attribute of type ID and then referring to such an element with an attribute of type IDREF (Garcia-Molina et al., 2008). This general-graph capability of XML only naturally supports one-to-one and many-to-one binary relationships, like the graph database system. Many-to-many binary relationships and relationships with arity greater than 2 are not supported. Perhaps higher-arity relationships can be supported somewhat awkwardly in XML by simulation. On the contrary, ILE supports multiple-arity relationships natively, as explained previously.

An additional result in the Lee et al. study shows that the XML approach, whether using native XML or the XML data type in a relational server, is currently much slower than using tabular NoSQL approaches.

The other approach for storing medical record data suggested by Lee and colleagues is to use a table-based NoSQL database. Four options (a, b, c, and d) for this approach are shown in Figure 14.9.

These NoSQL approaches, being based on tables storing values, suffer from the same linkage problem described in this paper as belonging to relational databases. By this, we mean that such linkages implemented by matching character strings are error prone.

Additionally, these tabular NoSQL approaches suffer from data fragmentation (namely, the same data fragmentation suffered by relational systems. More specifically, there is no one place where all data pertaining to one entity can be found.

Figure 14.10 shows how to model the same database in ILE. Here, linking is more secure because the links are done with relationship objects and object references. Data fragmentation is also nonexistent because all information pertaining to each entity is linked securely.

Using ILE makes it much easier to tie together all the instances of the same medical condition because they all belong to the same entity set. The concept of entity set doesn’t really exist in either XML or in the NoSQL models used by Lee, Tang, and Choi. Additionally, because the medical conditions are full-fledged entities in ILE, we can potentially link them to other entities via ILE relationships. This could be very useful in making epidemiological discoveries.

5 Inside the ILE database system

This section will look more deeply into the ILE system. Before we do that, though, let us note that the main idea is to be able to represent each relationship as an object that links the related entities together by means of links (object references or pointers) that go in both directions (namely, from the relationship object to each entity and from each entity to the relationship object). For example, the prescription relationship illustrated earlier in Figure 14.4 would be linked as illustrated in Figure 14.11.

While the idea behind this relationship linkage is simple enough, the actual implementation is not so simple. This is because each entity may be involved in more than one relationship, and maybe even more than one type of relationship. Therefore, instead of using one object reference to go from an entity to a relationship object, we will use an aggregate data structure to hold such object references. This and other details will be the subject of the rest of this section.

The top-level structure of ILE is actually a database set, implemented as a database set object. The database set contains its databases in a hash. This setup will permit cross-database searches within a database set, to be implemented in the future if there appears to be a need for such searches. Each database is also implemented as an object. The database set object has a hash whose data values are references to the database objects representing the databases of the database set. Each database object also has a reference back to the database set object.

Within an ILE database are four different sets of components:

• Entity sets

• Entities

• Relationship sets, also known as relsets

• Relationships

Each of these components is implemented as an object. The database object keeps track of the database’s entity sets and relationship sets, and each entity set and each relset in turn has direct references back to the database to which they belong.

Note that the current version of ILE is value-oriented, not object-oriented, though arbitrary classes of entities are permitted simply because ILE’s implementation language, Ruby, is object-oriented. In the near future it may be a good idea to extend ILE to allow full object-oriented features. Being a value-oriented database system, ILE requires the entities of each entity set to have at least 1 field serving as the primary key. This concept should be familiar to readers who use the relational database model.

The principal function of an entity set object is to keep all the entities belonging to the entity set together, as well as to facilitate searches for members of the entity set. The components of the entity set object are shown in Figure 14.12:

• Entity set name. This is any string, but of course, it is meant to describe the entities in the entity set.

• Link to database. This is just an object reference back to the database to which this entity set belongs.

• Key field names. The current version of ILE is value-oriented like the relational database system, not object-oriented, even though it is implemented with an object-oriented language and permits use of nonelementary objects such at Date, or anything else for that matter. Anyway, the fact that the ILE system is value-oriented means that all entities in an entity set have key fields. The entities may also have nonkey fields just like the entities in a relational database.

• Multilevel hash or index to the entities belonging to this entity set. Every entity set uses a multilevel hash as the primary way to access the entities. Another indexing scheme could be used, especially if the database is large enough that the entities mainly reside in secondary storage or somewhere on a computer network. The current index, the multilevel hash, is structured so that each level corresponds to a key field.

• A hash of relsets to whose members the members of this entity set are involved. This is a useful aid for performing queries on the database.

An entity object contains the following fields:

• A hash of key values.

• A hash of nonkey values.

• A link back to the entity set object representing the entity set to which this entity belongs.

• A hash to arrays of relationship objects with relset names as hash keys. For each relset, there may be more than one relationship in which this entity participates, thus explaining the use of an array of relationship objects for each relset.

We now explain relationship set (relset) objects and relationship objects, as shown in Figure 14.13.

A relationship set object, or relset object, contains the following fields:

• A field for the relset name, which is any string but should represent a descriptive name.

• An object reference back to the database object.

• A verbal description of the relationship set.

• A set of role names.

• A description of relationship attributes, if any. This should be upgraded in later versions of ILE to be a more structured container for such attributes.

• Relarray, an array of all relationships in this relset.

• A data structure called aha_rel, which is an array of hashes of arrays of relationships in this relset. This is a complex and efficient index of all the relationships.

A relationship object has the following fields:

• A link to the database.

• A hash of roles, hashed by role name.

• An array of roles, so that one could access the roles in numerical order. Since both the hash and the array really contain object references, it is not much of a waste of space to have both the hash and the array.

• A hash of relationship attributes, if any.

A role belonging to a relationship can be of different types (see Figure 14.14).

The simplest type of role is just an entity object, representing the entity that plays that role. However, in case there is a per-entity relationship attribute, then we need such attributes to be attached to the entity, forming an entity structure object.

But what is a per-entity relationship attribute? The concept behind this kind of attribute was inspired by a historical database, where merchants and their clients came together to sign a contract in the presence of a notary back in the 1500s in Spain. There were some cases where the person wasn’t present but had someone sign the contract instead.

The contract was modeled as a relationship in ILE, and each merchant and each client played roles in this relationship. A Boolean flag was used to indicate whether or not the person was present in person to sign the contract. This flag was modeled as a per-entity relationship attribute, so that each person had a different flag. The flags could have been modeled as a bit array serving as an ordinary relationship attribute. However, it appears that the modeling of these flags as per-entity relationship attributes was a more natural, intuitively appealing choice.

We have now discussed the first two possibilities for a role as shown in Figure 14.14. The third possibility is that a role can be an array (representing a set) with each array element being either an entity object or an entity structure object.

As an example of a relationship linking roles, Figure 14.15 shows how three roles can be linked by a relationship object in ILE.

6 An example of the Importance of an EHR implemented in ILE

We close this chapter by examining how the sophisticated data modeling afforded by ILE can make for an EHR for a hospital admission that would make it easier for hospital epidemiologists or infection control practitioners to track down how an infectious disease or agent, such as staph, tuberculosis, Ebola, or pneumonia, is being spread or may be spread in a hospital. Nosocomial infections are one of the hazards of hospitalization. Minimizing the chances of harmful nosocomial infections being spread is essential to patient health and health care administration and a robust ILE patient EHR can help with this. A robust EHR implemented in ILE can also make it easier to track which health care workers may have been exposed to a particular infectious disease.

One solution is to model hospital admissions as a relationship set. Each hospital admission then becomes a relationship in this set. This relationship is very complex because it relates entities from many entity sets. In particular, it relates a patient with a set of doctors, a set of nurses, certified nursing assistants (CNAs), technicians of various sorts, equipment, doctor’s orders, patient diagnosis or diagnoses, rooms occupied, what diet the patient is eating, and other factors. If the patient has an infectious disease, the room and patient could be flagged to indicate this fact with a per-entity relationship attribute. If a particular infectious disease agent is spreading, the epidemiologist or infection control practitioner can look at the database of ILE EHRs to see if there is a common factor or factors, such as a particular health care worker, that is found in many of the patients contracting a nosocomial infection. Other database system types would have difficulty modeling such a complex set of entities and relationships about health care admissions and may be more error prone and present more difficulties with analyzing the health care data.

7 Conclusions

This chapter introduced Intentionally Linked Entities (ILE) and explains why it may be a better database system than the existing relational, graph, object-oriented, and other NoSQL database systems for managing health care information. ILE links data entities in a more robust and efficient way than the relational database system. With the embodiment of the entity sets, entities, relationship sets, and relationships as objects, ILE stores data in a more organized fashion than the relational or the graph database system. ILE is also capable of expressing more general relationships among data entities than the OODB system because the pure OODB system only natively supports binary relationships when more complex relationships may need to be represented, such as in the hospital epidemiology example described in this text. Object-relational database systems have the same pitfall in linking general relationships of arity higher than 2 as the relational database system does. ILE is designed to make more complex relationships between data entities easy to represent and analyze. All these desirable properties of the ILE database system may lead to better management of health care information and therefore possibly improved patient care, better protection of patients, hospital health care workers, support staff, and visitors from infectious disease, more efficient health care operations, and better health care database analysis.