Digitization of personal health data facilitates easier and timely data access in integrated healthcare services and in medical or (historical) demographic research. We suggest a common middle layer framework that represents data content, related schemas and possible ontologies as temporal object versions on a timeline. Bidirectional and bi-temporal object versioning are included. The versioning is extended to accept mappings to none-existing (potential) data value versions in time. We enrich this framework by including temporal representation of mappings, and by adding metadata elements related to temporal data change and mapping generation. Such metadata is useful processing database requests from different local applications in the time space. The paper also provides examples and a short discussion of certain useful metadata elements. The usage is exemplified by XML with elements related to the Electronic Health Record (EHR) case.
1.1
In a modern integrated health care system the need for collected personal health data
is increasing [
We are also examining how different metadata about a mapping between object versions can help in interpretation of data. Such metadata can include information about why the mapping is needed (the cause of data changes, in some cases this is trigged by temporal changes) and how the mapping is (was) generated, including information about the mapping (match) type and the chosen mapping approach in the mapping generating process. Note that all mapping examples in the paper are sub-mappings between sub-elements in two object versions.
In this paper we focus on some versioning problems for our temporal object data model on the middle layer. The database layer is not discussed. Different research questions can be discussed concerning an implementation of our DRL (Data Representation Layer) system. We touch three questions in the following: 1. 2. 3.
How to represent mappings between object versions? Each individual (sub-)
mapping has to be related to a mapping rule represented in a well-known
language, for example XSLT [
How to approximate inexact (sub-) mappings when needed and how to
handle impossible (sub-) mappings? To this question we include how to
represent metadata about approximations, and how to representation errors if a
requisite result is impossible to generate. An approximation may be
motivated by medical profession reasons related to the semantic of the data.
How to represent and store metadata about causes of data changes. The
causes are linked to temporal changes, both structural and semantically
changes [
It is necessary to represent and store different temporal objects (instances) and
relationships between objects in the time space. We need object versions with their own
global temporal OID, a way to represent and store sets of different time stamps
related to each object (the model is bi-temporal [
We use object versioning to handle different requests (database queries) from local user applications, it means we handle temporal versioning both forward and backward in time. We choose to implement this by mappings between object versions, and to represent and store the mappings as own temporal objects as well. We do not present a single mapping algorithm for generating new mappings between object versions. Our suggested data model for the framework has to be general enough to accept such temporal changes in data representation over a very long-term time span, like a person’s lifetime (100 years).
Time valid start time stamps for object versions
MD0 xslt
D1 xml D0 xml
MS0 xslt Data representation layer (DRL)
S1 xmls S0 dtd
A1
A0
Fig.1 illustrates some object versions and links between them in the DRL. Each
object version is temporal and has an own start time stamp (start time may indicates the
transaction-time [
Fig. 1 also shows two local applications denoted A0 and A1. A0 and A1 are
implemented to access and store data of the type D as given by S0 through VIEW0 and by
S1 through VIEW1, respectively. A0 may needs to access D1 through S0, while A1
may needs to access D0 through S1. We do not require A0 to be re-implemented or
recompiled to read data in D1 [
In the following, section 2 shortly mentions how our research relates to other work. Section 3 describes how different metadata elements can be used related to different temporal issues and mapping problems. Section 4 shortly shows an example using XSLT. Section 5 summarized.
In our data model (in DRL) we adopt the following definitions from schema
versioning [
It is a lack of interoperable EHR systems (e.g. [
Implemented standards and solutions are related to electronic massage passing
exchange between local systems, for example MedXML [
It is research on representation of change in medical terminologies, e.g. [
Metadata is data that describes other data to enhance its usefulness. In our case we add metadata elements to the representation of (sub-) mappings in object versioning. In this section the meaning and usage of these elements are discussed. Section 4 summarized some of these elements in a XSLT-template. We can call a (metadata) element for representing a sub-mapping itself: subMapping - a complex element representing a sub-mapping between elements in two objects. 3.2
We include the metadata element: cause - this element shows the reason for a given
data change, and by that the reason for a mapping between two versions of the data.
The value of the element can be one (or many) standardized constant, that indicates
for example (possible causes discussed in [
The object versioning has to be seen in relation to different temporal perspectives, or dimensions, on a time axis. It is important to call attention to the fact that our versioning not only focusing on the newest, or most updated, versions of data content, but has to be able to handle requests from applications that need older data versions and older data representations (schema and ontology versions) as well. Such a perspective gives several temporal problems that can be discussed.
A possible metadata element: temporalHandlers - a set of sub-elements concerning the different temporal change perspectives. Such metadata can for example be useful for tools in the DRL when processing queries, e.g. to consider constraints on results from a specific time interval. Below we shortly discuss some examples related to such temporal perspectives.
We say that two or more temporal changes are “overlapping” if (sub-) changes caused by one of these temporal changes may results in “loss” of semantically knowledge about specific data content updates. To exemplify the problem we use a simple case showing updates on citizen’s postal address code. This particular case is partly spatial, and can be used in demographically health research. The postal code 7873 in Fig.2 is not in use anymore on the date 01.10.2005 and citizens having the code 7873 are split into two possible new codes, 7800 NO or 7700 NO (This change in the Norwegian postal address system is hypothetical for the matter of the example). In this example we have a value mapping from D0 → D1, that is (‘7873’ → ‘7800 NO’) or (‘7873’ → ‘7700 NO’). For object instances (citizens) that exist before this temporal change at the date 01.10.2005, a semi-automatically tool in DRL can choose which of the two alternative mappings above that work for every specific object (in cooperation with a system end user). At the same time as the mapping generating process decides the right mapping for D0 → D1, the value mapping D1 → D0 is also generated to make the mapping bidirectional. However, if a new citizen moves to the geographically post block ‘7800 NO’ after the change (after 01.10.2005), we do not know if the value mapping (‘7800 NO’ → ‘7873’) holds for this new instance. From an ordinary object versioning point of view such a mapping back in time is not meaningful since this person did not live at ‘7873’ before the actual temporal change, but for our bidirectional view this problem is relevant. Say if the local application A0 requests the postal code in the (old) format of ‘7873’ after the change of 01.10.2005 (as in Fig.1), we can only return citizens that lived at ‘7873’ at the time before the change, not the new citizens that lives there after the change. This example shows that an “old” temporal change can give “loss” of semantically knowledge in future data changes (in this case a future entity update). This means that a temporal change not only influence existing object versions by the time the change occurs, but may also influence future object versions that are introduced after the temporal change in time.
This problem asks for an own separate representation of the temporal change as a temporal object with an OID. Such a temporal change representation makes it possible to generate mappings back in time when a new object (instance) is introduced in the time space, since the DRL tool then can search back to find temporal changes of interest during the process of generating bidirectional mappings for the new object version.
Say, if we have an object version A, and a newer introduced version B, there might be a sub-mapping from A to B that is impossible or inexact. Later in time a newer version C is introduced, and the sub-mapping from A to C can still be possible even if A → B does not work. In real this situation asks for a change to generate a “new” sub-mapping from A by the time C is introduced, or in other words a “re-generating” of the mappings from A forward in the time space.
An example is if the postal code 7873 belonging to the post office “Hamar” is not in use by the postal service for a given time period and citizens having code 7873 are given the neighbor post office code 7870 “Oslo” from 01.10.2000 to 01.10.2002. At 01.10.2002 the code 7873 is reopened (Fig. 3).
01.10.2000
01.10.2002
Fig. 3. Example of temporal update of a postal code (from [
MD1 ti
MD0
D2 7873 If a person moves to “Hamar” during the time sequence between 01.10.2000 and 01.10.2002, it is impossible to generate a mapping back in time to the period before 01.10.2000 since “Hamar” does not exists as a post office at the time this person moves to the area. However, after 01.10.2002 the person’s postal code is updated from 7870 to 7873, and by then a mapping back to before 01.10.2000 is possible (it is an equal value map 7873 → 7873, a link from D0 to MD1 is illustrated as a dotted line in Fig. 4).
For a certain time interval a given query can be “impossible” to process, or returns an
inaccurate result. Say we have a query Q1 and a time interval given by the time
stamps t1 and t2. Processing Q1 before t1 and after t2 can be ok, but in between t1
and t2 (illustrated as the time interval ti in Fig. 4) on the time axis Q1 may give a
wrong or inexact result. This problem is from temporal databases where a query
returns different results when evaluated at different times [
If t1 and t2 are the dates in postal code example in Fig. 3 and if Q1 is the following SQL SELECT:
SELECT Person.* FROM Person
WHERE post_office = ‘Hamar’ AND date = ‘01.01.2001’; At the date Q1 requires, the post office value is “Oslo” instead of “Hamar”. The office element was updated at the date 01.10.2000 when “Hamar” stopped to exist as a post office, and the citizens in “Hamar” got the same post office as for the citizens of “Oslo”. However, after that update it is impossible to know who are living in “Hamar”, and because of that it is difficult to process Q1 for the required date. To return all citizens of “Oslo” as a result (meaning using a value mapping from “Hamar” to “Oslo”, that is a legal mapping from an object versioning point of view) will return too many entities (citizens).
In general a mapping that works in both direction has to be 1:1 (one-to-one and injective). A mapping that is M:1 (many-to-one) in one direction does not have any inverse mapping. For example a well-defined functional approach on implementation of mapping rules is then impossible. In such cases a 1:1 -mapping has to be generated by adding knowledge about the semantic of the data directly from medical professional end-users or if possible by using knowledge given by ontologies, or the mapping is terminated (if such a solution is accepted). Such a case can for example be caused by changes in the data value domain of an element. An example is if the blood pressure is represented as an integer value in one schema version and as a string value (e.g. a value domain of the possible values; “low”, “normal”, or “high”) in another version. For example a “high” blood pressure is a value higher than 130 +/-2 (mm Hg systolic pressure), meaning we have critical values from 128 to 132, and the mapping result (in the direction from the string to the integer) is never exact. Such a problem is critical if the local application acceptance of approximation in the returned result is low or not accepted.
Recall Fig.1. Say D0 stores the blood pressure value as the string above, while D1 stores the same value as the integer above. We may have the following scenario: The most updated version of the blood pressure element has the value “high” and is stored in D0. A local application A1 wants to read the value as an integer type according to a schema version S1, but D1 does not exist - it is just a potential version. An approximation has to be done when generating a value mapping D0.string → D1.integer. The reason for the approximation can be based (and justified) by a medical domain specific approach related to the semantic of the data. The approach can also be given by a temporal conceptual change in the interpretation of the result, like a paradigm shift in medicine. In this example two general mapping solutions are as follow: Mapping: D0.string → D1.integer
Solution 1: “high” → n, where n is an integer digit validated by S1
Solution 2: “high” → TERMINATED (an impossible mapping)
First, the fact that the mapping result is generated by a specific approach, like a
number approximation, is stored and linked to information about the mapping algorithm
(represented by syntax readable for applications in the future). Second, the reason
why the approach was chosen in this particular case is stored as well. Some
comments on each solution:
Solution 1: The decision of a selected approach is taken by a health care
professional end-user based on a medical assessment. Such assessments can be based on
known (medical) ontologies (e.g. ontologies mentioned in [
Solution 2: In the “terminated” case we suggest that the DRL offers a set of welldefined constants used to describe “default” reasons of why a number is not present in D1. This can still be interpreted as a legal value, even if no number value is given for D1. However, it is not sure that A1 can read such a constant, so this solution does not work in all cases, e.g. if the value is critical in emergency. Possible constants are (but not limited to): NULL that indicates an empty value (as in databases), ERROR that indicates an mapping attempt that was considered as impossible during the mapping generation process (given that such an error is acceptable in the particular case), and TERMINATED that indicates an end of a temporal line of (sub-) element versions in the temporal space (for example caused by a paradigm shift in medicine). The same solutions for the above example can be discussed for the opposite temporal direction: Mapping: D1.integer → D0.string
Solution 1: 130 → s, where s is a string validated by S0
Solution 2: TERMINATED → ERROR
Solution 1: An approach can decide that 130 in D1 are transformed to “high” in
D0. However, this mapping works for any value in the range from 128 and higher in
D1, so a question is if this approximation is acceptable. Using this solution the
process is equal to the mapping D0 → D1. A professional end user has to make a decision
on how the value 130 (if this value in D1) is transformed to a legal string in D0.
Solution 2: In the “terminated” case it is impossible to generate a value for D0
back in time, unless an end-user can generate the value mapping manually.
A metadata element: mappingInfo - shows information about a mapping and the
related mapping generating process, like the mapping approach (or matching) related
to different types in a classification of schema matching [
A metadata element: audit - shows audit data about the mapping process, and has a logging purpose. What were done by whom? Audit data is not discussed in this paper. 4
Presume that the data content of the different objects in Fig. 4 (from the postal code example in Fig. 3) is represented in XML-technology. The following XSLT-template is a part of the data content of the mapping object MD0 and shows metadata elements for the mapping from D0 to D1 at the time stamp t1. A similar metadata set can include the mapping from D1 to D0 as well. The element subMapping represents the mapping between the two postal codes. The complex element metadata includes the sub-elements mentioned in Section 3.2 to 3.4. A hierarchical structure of subelements can represent information of different levels of details. More research is needed on temporalHandlers to support help in the temporal problems of Section 3.3. The element tempQueryHandle can be used to identify change in the "post_office" entity (specified by S0) and to identify interval ti when generating metadata for MD1 at t2.
<xsl:template match="/"> <xsl:element name="subMapping"> <xsl:element name="postcode">
<xsl:value-of select="element/postcode"/> </xsl:element> <xsl:element name="metadata"> <xsl:element name="cause"> <xsl:element name="changeID">
OID.Temporal </xsl:element> <xsl:element name="changeCategory"> <xsl:element name="changeType">
Temporal Set Update </xsl:element> <xsl:element name="changeSchema">
none </xsl:element> </xsl:element> </xsl:element> <xsl:element name="mappingInfo"> <xsl:element name="mappingType">
Absolute Direct </xsl:element> <xsl:element name="mappingMethod">
Value </xsl:element> <xsl:element name="mappingProcess">
Semi-automatical </xsl:element> </xsl:element> <xsl:element name="temporalHandlers"> <xsl:element name="tempQueryHandle"> <xsl:element name="entityChange">
post_office </xsl:element> </xsl:element> </xsl:element> </xsl:element> <xsl:element name="audit"> not present </xsl:element> </xsl:element> </xsl:template> The database storage of all objects and metadata can be done in relations tables including time stamp attributes for ensuring the temporal dimension of the data content, for example [25] have relation tables for a bi-temporal database. Alternatively in this example some data may be stored as XML, e.g. in an object-relational database or a native XML-database. However the pure relational table solution is more general, and can ensure a normalized database.
Future work includes considering if semantically knowledge from (temporal) subontologies can increase the efficiency of generating new mappings between object versions. It is a question how to generate all needed mappings and their metadata in a cost-efficient semi-automatically way. Manually mapping will be very timeconsuming and also over-complex, since the end user has to consider temporal changes that may have occurred in the past. A DRL system tool has to help the end user to firstly; find all the needed mappings, secondly; suggest possible mapping values for each mapping, and thirdly; help generating desirable related metadata. Such a mapping generation process can for example be related to an ontology evolution strategy described in [26].
Future research is needed to test how metadata can improve the query processing in the DRL-system in the respect of the query result quality. One question is how to raise the quality of inexact results from approximate mappings by active use of stored metadata about mappings and temporal changes in the DRL. Examples of implementation can be done in a conventional programming language, for example Java.
From a database point of view, the major problem for realization of our temporal data object framework is the handling of all kinds of mappings between versions of data content, schemas and possible ontologies. This paper provides some guidelines of adding interesting metadata elements to sub-mappings in our framework's object model. Such metadata include information about why the mapping is needed (the cause of data changes, in some cases this is trigged by temporal changes) and how the mapping is (was) generated. The metadata about a mapping between object versions can help in interpretation of data. The paper shows examples on such usage and relates these to the temporal perspectives in our case. We link the problems to the realization of a future integrated Electronic Health Record (EHR). However, it is in the nature of our framework that the usage is not limited to a particular application domain. The framework is general enough to represent and store any data content related to temporal perspectives. 25. Wei H-C, Elmasri R. Study and Comparison of Schema Versioning and Data Conversion Techniques for Bi-temporal Databases, Sixth International Workshop on Temporal Representation and Reasoning, Orlando, Florida 1999. 26. Stojanovic L, Maedche A, Motik B, Stojanovic N. User-Driven Ontology Evolution Management, EKAW 2002, LNCS Volume 2473, 2002.