Patent Application
20090055437
This invention relates, in general, to referent tracking, and in particular, to employing referent tracking to unambiguously track portions of reality over time.
Today, information is maintained-in information systems which consist of data repositories that contain data in either unstructured form (such as free text or digital multi-media objects) or structured form, the latter being such that numerical information is expressed by means of numbers, and non-numerical information by means of concepts taken from different sorts of terminologies (such as vocabularies, nomenclatures, concept systems, and so forth) as they are offered in terminology servers. However, current information systems do not offer a mechanism to unambiguously determine in each individual case what entity in reality a concept from a terminology server is used to relate to. As a consequence, information systems thus conceived work with instances of data, but algorithms working on such data have no clue what the data are about, i.e. about what specific entity in reality each specific data-element contains the information.
For example, if a driving license number is used in an information system, it is often not formally clear whether the number is used to denote the driving license of a person or that person itself.
As a further example, if in an information system the gender of a person is stated to be “unknown”, then it is often not formally clear whether this means either (1) that the person does have a gender which is one of the scientifically known gender types, such as female, male, mosaic, etc., but that information of the precise gender of that person is not available in that information system, or (2) that the gender of that person is known to be of a type which scientifically has not yet been determined.
Another example is that if at a certain time the gender of a specific person is stated in some information system as being “male”, and at a later time it is stated to be “female”, then there is, under existing data storage paradigms, no way to derive from this change whether the change in the information system reflects (1) a change in reality, for instance, because the person underwent transgender surgery, (2) a change in what became known about reality: the person's gender might because of a congenital disorder not have been determinable at the time of birth, but only later after several investigations, or (3) that there was no change in reality or what we know about it, but that at the time of the first entry a simple mistake was made. One can even imagine a fourth possibility, namely that the meaning of the word “female” would have been changed.
These problems of inadequate reference are particularly, although by far not exclusively, relevant in Electronic Health Record systems (EHRs). EHRs consist primarily of descriptions of a patient's medical condition, the treatments administered, and the outcomes obtained. These descriptions are about concrete entities in reality, such as the particular pain that the patient experienced in his chest on this specific day; or about the particular pacemaker that was implanted. The descriptions contained in current EHRs include very few explicit references to such entities, but primarily expressions in generic terms that are either in natural language or taken from terminologies or ontologies.
This has some obvious consequences. When a patient suffers from the same type of disease and exhibits the same kinds of symptoms on two successive occasions, then the descriptions of these conditions using concept-codes from a terminology will be identical. When another patient suffers from the same type of disease and exhibits similar symptoms in his turn, then the resulting descriptions will also be identical to those relating to the first patient. But note that one cannot assume that if the same code is used in two such records, then they refer to two distinct entities. When a fracture code is used in relation to two distinct patients, then numerically different fractures are involved. But when a code is used to provide the additional information that the fractures are due to an accident in a swimming pool, the very same, probably dangerous, swimming pool might be involved.
One also cannot assume that if two different concept-codes are used in an EHR, then they refer to different entities. It may be that the most specific or detailed code is not always used when the same entity is referred to on successive occasions. A colon polyp might simply be referred to as “intestinal polyp”, or just “polyp”, and thus associated on successive occasions with different codes. It might also be that the polyp has become malignant, and then it might be assigned the code for malignant neoplasm of colon. Clearly, the relevant entity, i.e. the polyp, underwent changes. But it is still the same entity: its identity did not change. A third reason why different general codes may not automatically be taken to refer to different particular instances turns on the fact that a concept-code may not suffice to describe a given instance appropriately. If, for example, one wants to use SNOMED-CT (v0301) to code a closed pedicular fracture of the fifth cervical vertebra, then a single code is not available; to give a faithful description one must combine several codes. If, however, these codes are not entered in the EHR in such a way that it is clear that they refer to the same particular entity, then their presence might be taken incorrectly to refer to two different fractures.
Based on the foregoing, a need exists for an enhanced information system. In particular, a need exists for a referent tracking system that enables the unambiguous tracking of specific aspects of reality. For example, a capability is needed for tracking entities (in reality), their relationships and descriptions thereof over time. A further need exists for a capability to detect and correct errors in a referent tracking system. Yet, a further need exists for a capability that enables a referent tracking system to communicate with other referent tracking systems and/or traditional systems. Moreover, a need exists for a capability that enables translation of data collected by traditional information systems into a format that satisfies the data organization scheme of a referent tracking system.
The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of facilitating the management of information. The method includes, for instance, providing in a tracking system a description of a portion of reality to be tracked, the portion of reality being a specific part of reality to be tracked by the tracking system, the description including, for instance, a plurality of entities that represent items that exist or have existed in reality and that are relevant to the specific portion of reality to be tracked; a first data type assigned to the plurality of entities; information about one or more configurations, wherein a configuration of the one or more configurations is an association between two or more entities of the plurality of entities; and a second data type assigned to one or more types of the one or more configurations, the second data type being different from the first data type and explicitly distinguishing configurations from entities; and using the description to unambiguously track the portion of reality over a selected time period.
Systems and computer program products relating to one or more aspects of the present invention are also described and claimed herein.
Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.
One or more aspects of the present invention are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
In accordance with an aspect of the present invention, a capability is provided to facilitate the management of information. As one example, portions of reality, described below, are unambiguously tracked over time. In particular, entities (of a portion of reality), their relationships and descriptions thereof are tracked. To facilitate the tracking, in one example, a referent tracking system is used.
In a further aspect of the present invention, one referent tracking system is able to communicate with other referent tracking systems and/or traditional information systems. Further, a capability is provided that enables translation of data collected by traditional information systems into a format that satisfies the data organization schema of a referent tracking system.
Yet further, a capability is provided that enables errors in the referent tracking system to be detected and corrected in such a way that after a correction has been introduced, the prior state of knowledge can still be tracked.
Further details of a referent tracking system and the various features of the present invention, including, but not limited to, those mentioned above, are described below.
One aspect of the present invention relates to referents and the management of a specific form of references, called “representational units”, thereof in a Referent Tracking System (RTS), such that the structure in which the references are organized in the RTS serves as a digital copy of the structure of the portion of reality formed by the referents. By “referent”, it is meant an entity in reality, such as a specific person, a specific organization, a football game played at a specific date and place, for which it is the case that there exists another entity in reality called “information bearer”, such as a specific record in an information system that (1) denotes, represents, or carries information about the former, or (2) contains a reference to the former while being about another entity in reality. In addition, one aspect of the invention allows these information bearers themselves to be treated as referents in other information bearers through which they are referenced. As a consequence, an RTS embodies a generic capability that offers at least two functions: (1) to keep track of what is the case in reality, and (2) to keep track in an objective way of what information is stored in information systems about that reality, thus what is known about reality from the perspective of specific information systems and their users.
With respect to the first function, an RTS with appropriate user-interfaces can perform similar functions as currently existing traditional information systems, but because of the specific way in which the references are set up, has the advantage that only the user-interfaces need to be tailored towards the specific needs of its users, but not the underlying data and information models. Thus, although a specific RTS might be set up and used to collect data for a specific purpose, this purpose will not be reflected in the organizational structure of the data, so that the data, in contrast to existing approaches, can be re-used un-problematically for other purposes than those for which they have been collected.
With respect to the second function, an RTS can be used as a device to make traditional information systems semantically interoperable. By “semantic interoperability”, is meant the ability of, for instance, two or more computer systems to exchange information and have the meaning of that information automatically interpreted by the receiving system accurately enough to produce useful results, as defined by the end users of both systems. Current attempts to achieve semantic interoperability rely on agreements about the meaning of so-called concepts stored in terminology-systems, such as nomenclatures, vocabularies, thesauri, or ontologies, the idea being that if all computer systems use the same terminology, they can understand each other perfectly. The reality is, however, that, rather than one such terminology being generally adopted, the number of terminology-systems with mutually incompatible definitions or non-resolvable overlap amongst concepts grows exponentially, thereby contributing more to the problem of semantic non-interoperability than solving it.
Components of a Referent Tracking System
A “referent (a.k.a., reference) tracking system” (RTS) is a special kind of digital information system which keeps track of (1) what is the case in reality and (2) what is expressed in other information systems about what is believed to be the case in reality. One example of a RTS is described with reference to
As shown in
As an example, the components execute on one or more computing units, such as one or more processors, computers or computing devices, which have the following specifications, as one example: Intel® Core 2 Duo e6400 processor (Intel® is a registered trademark of Intel Corporation); RAM 2 GB; Windows® XP Operating System (Windows® is a registered trademark of Microsoft Corporation); and a VGA card and monitor screen supporting a resolution of 1024×768. Although the above specifications are provided as one example, the components can run on many types of processors, computers, computing devices or other computing units having various specifications. The specifications provided are just one example. Further, all of the components of the referent tracking system can run on one computing unit; one or more components can run on one computing unit, while others run on one or more other computing units; or the components may be distributed among various computing units. Many configurations are possible without departing from the sprit of the present invention.
Each referent tracking server includes, for instance, a data access server 110, which manages service requests coming from RTS Proxy Peer 106 or RTS Server Proxy Peer 108 and which performs data manipulation on the server's main component: a referent tracking data store 112 thereby assisted by a reasoning server 114. The latter performs various sorts of reasoning functions by combining data from the data store with information coming from external terminology servers 116. The type of reasoning that can be performed depends on whether the terminology server contains nomenclatures, vocabularies, thesauri, and so forth.
The referent tracking server comes also with an internal ontology 18, which is a repository dedicated, for instance, to store information obtained during the initialization process, access control information about authorized users and usages, and so forth.
The referent tracking system user interfaces allow direct users 120 of the RTS to perform (1) a variety of management functions such as registering new external information systems 122, configuring a referent tracking server, adding additional referent tracking servers, and so forth, and (2) content functions such as running pattern-matching logic on the data in the referent tracking data store to detect inconsistencies, invoke triggers and alerts, perform population-based studies, and so forth.
Networks of Referent Tracking Systems
Since referent tracking is to make reference to entities in reality by means of singular and globally unique identifiers, one set up is one in which only one RTS is used worldwide. More realistically, however, is the adoption of the RT paradigm in a step-wise fashion: each organization first installs its own RTS, and afterwards connects them in expanding networks.
To support this evolution, as shown in
In one example, the application design is a mix of client-server and P2P programming models. As an embodiment, a RTS P2P network 200 (
An example of an RTS network is shown in
Each organization can form its own local group of servers whose membership is not known outside the organization, which protects against unauthorized access to the peers in the group. Controlled “public” access to each organization's data is offered through the Proxy Server peers. The separation of local peer advertisement within an organization from public (outside the host organization) contexts is the basis for the implemented security layer. The peers which are known locally provide full access to the local database, and the peers which are known publicly provide very restricted access to the database (they might, for instance, allow only searches over certain sorts of RT tuples, as explained further).
Reality, Data and Aboutness
A referent tracking system is distinct from other information systems in that each data element points to a portion of reality in a specific way. This is described further with reference to
In one aspect, a capability (e.g., technique and system) is provided for the unambiguous symbolic representation of portions of reality in a digital information network that includes several representational and computational (e.g., logic, servers, etc.) facilities, as further described herein.
Referring to
A “configuration” is a portion of reality which is not an entity in its own right. Whereas a specific patient, its specific disorder, the physician examining the patient, and the examination itself are each individual entities, the configuration that this disorder is inside that patient, that the physician is examining that patient, etc, is not. Another example of a configuration is the being of a person in a car. Both that car and that person are entities, but the fact that that person is in that car, is not. If that engine would not be in the car, but, for instance be placed by a mechanic outside the car for repair purposes, still the very same entities (the car and the engine) would be involved, but there would be another configuration.
A representational facility of the capability is that through the data types that it comprises, it makes the distinction between configurations and entities explicitly, as shown in
Configurations are referred to by means of a data type referred to as a “RT-tuple” 306, whereas entities are represented by means of a data type called “representation” 308. Both data types come in several forms depending on the nature of the portion of reality they carry information about.
Another representational facility is that, through its data types, it allows for the drawing of an explicit distinction between specific entities (called “particulars” 312) from generic entities (called “universals” 314).
Particulars are specific and unique entities, unique in the sense that they each occupy specific regions of space and time, and that nothing else than a specific particular can be that particular. Examples are concrete persons, such as George W. Bush Jr. and George W. Bush's heart. Some particulars, such as each of six chairs around a specific dining table, may exactly look the same, but they are still distinct particulars. One can be destroyed, while the other five remain intact. For particulars of specific interest, such as persons, ships, and hurricanes, proper names are used to mark the importance of their individual identity. For other particulars, such as cars or pieces of medical equipment, serial numbers are used for unique identification purposes.
Universals, in contrast, are such that they are (1) generic and (2) expressed in language by means of general terms, such as ‘person’, ‘ship’, and ‘car’, and (3) represent structures or characteristics in reality which are exemplified in an open-ended collection of particulars in arbitrarily disconnected regions of space and time.
Another representational facility is that, through its data types, it makes explicitly the distinction between two sorts of particulars: those that are information bearers 316, and those that are not; the latter called non-referring particulars 318. Examples of information bearers are a piece of paper containing a text about a person's medical history, and a digital object, such as an image of a person in an information system. Information bearers are “about” something else, while non-referring particulars are not about something else. Information bearers can be about not only non-referring particulars, an example being the driving license card of a person which is about its driving rights, but also about other information bearers, an example being a textual description of a specific person's driving license, stating, for instance, that the name of the driver is almost not readable. A copy of such a driving license can be at the same time about both the card and the rights enjoyed by the license holder.
Another representational facility is that it distinguishes explicitly and formally between various relations that obtain (are held) between the various types of portions of reality it is capable of describing. These relations are:
Examples are an image, record, description or map of the United States.
Note that a representation (e.g., a description such as ‘the cat over there on the mat’) represents a given entity even though it leaves out many aspects of its target.
Another representational facility is that it distinguishes explicitly and formally between three types of denotators, referred to respectively as “IUI” 336, “UUI” 338 and “CUI” 340.
An IUI 336—abbreviation for “Instance Unique Identifier”—is a denotator in the form of a persistent, globally unique and singular identifier which is stored in a referent tracking system and which denotes or is believed to denote a particular. It includes the principles and methods applied in the RTS that assure—modulo the occurrence of errors, the resolution of which is also covered by an aspect of the present invention—that an IUI is (1) persistent because once created in a RTS it is never deleted, (2) globally unique because a IUI denotes only one entity within an RTS, and (3) singular because within an RTS, there is only one IUI for a specific entity.
A UUI 338—abbreviation for “Universal Unique Identifier”—is a denotator which denotes a universal within the context of a realism-based ontology, a specific sort of knowledge resource within a terminology server.
A CUI 340—abbreviation for “Concept Unique Identifier”—is a denotator for what is commonly called a “concept”, but which in the context of a referent tracking system is referred to as a “defined class” 342, and what is defined as a subset of the extension of a universal which is such that the members of this subset exhibit an additional property which is (a) not shared by all instances of the universal, and (b) also (might be) exhibited by particulars which are not instances of that universal.
Another representational facility is that, because of (1) the explicit distinction between information bearers and other entities, and between various sorts of non-referring entities, and (2) the specific way in which the RT-tuples are defined, the structure of the internal representation inside the system mimics the external structure of reality which offers thus a measure for the quality of the representation. The appropriateness of this measure rests on three axioms. The first one is that reality exists objectively in and of itself, i.e. independently of the perceptions or beliefs or theories of cognitive beings. Thus, that not only do a wide variety of entities exist in reality (human beings, hearts, bacteria, disorders, . . . ), but so also the relations between these entities (that certain hearts are parts of human beings, that certain bacteria cause disorders in human beings) is not a matter of agreements made by scientists, but rather of objective fact. The second assumption is that reality is accessible to us and that its structure can be discovered: scientific research allows human beings to establish what entities exist and what relationships obtain between them. The third assumption is that information in information systems and terminology servers should as far as possible mirror the corresponding domain of reality. Thus, an important aspect of the quality of an information system is determined by the degree to which (1) its individual representational units correspond to entities in reality, and (2) the structure according to which these units are organized mimics the corresponding structure of reality.
A Use Case Scenario: A Patient with an Adverse Event
Table 1 below shows some adverse event definitions from various sources.
Table 2 below shows the minimal collection of representations related to entities in reality that are to be taken into consideration to be in a position to represent the portion of reality around a particular patient as an adverse event. Under the label ‘Denotation’, a generic term is provided that is applicable to a member of the corresponding class. The ‘Class type’ column indicates whether the class is the extension of a universal (U) or a defined class (DC). The ‘Particular type’ column indicates to what category of particulars, the members of the corresponding class belong.
The descriptions provided in the right-most column illustrate the sorts of roles played by different sorts of entities in a scenario in which an adverse event might have occurred. The conditionals that are used in most of these descriptions reflect the fact that a particular portion of reality might be such that a phenomenon which is considered to be an adverse event under one definition, is not an adverse event in terms of another definition. The conditionals should not be interpreted as having in every case to do with probabilities or uncertainty.
The representational units for the core classes identified above can be used to represent all possible portions of reality which feature entities that can be referred to by means of the term 'adverse event’ under any of the definitions in Table 1 above. As an example, Table 3 below lists the particulars and associated properties involved in a case in which:
This table thereby provides an example of an adverse event case analysis of the sort that is made possible by the framework here presented.
The relationships employed in composing representations of properties in this Table are drawn from realism-based ontology. The primitive is_about relation is introduced, which holds between a representational unit and the entity in reality about which this unit contains information at a certain time. Certain shortcuts are taken in the representation of the temporal relationships involved in such an analysis, by simply stating for example that to earlier t1 earlier t2 earlier t3.
Under the proposed scenario, #10, i.e. the coming into existence of #9, would (modulo the wide variation in interpretations that can be given to the majority of the definitions found) qualify as an adverse event as defined in D5 of Table 1 above. However, for definition D9, it would rather be #9 itself that would so qualify, while for D4, it would be either #12 or #13.
Referent Tracking Data Elements: RT-Tuples
Information in an RTS is stored by means of tuples, called “RT-tuples”, which come in various flavors depending on the sort of information they contain.
A-Tuples
When, after due consideration, a particular has been identified as requiring a IUI, then an alphanumeric string, thus far unused, is generated by a unique ID generator and an act of assignment is carried out. At least one example of this generation and assignment is described in Ceusters W, Smith B. Referent Tracking for Digital Rights Management. International Journal of Metadata, Semantics and Ontologies 2007;2(1):45-53; Ceusters W, Smith B. Referent Tracking and its Applications. In: Proceedings of the WWW2007 Workshop i3: Identity, Identifiers, Identification. Banff, Canada, May 8, 2007, CEUR Workshop Proceedings, ISSN 1613-0073, online http://ceur-ws.org/Vol-249/submission—105.pdf; Rudnicki R, Ceusters W, Manzoor S, Smith B. What Particulars are Referred to in EHR Data? A Case Study in Integrating Referent Tracking into an Electronic Health Record Application. In Teich J M, Suermondt J, Hripcsak C. (eds.), American Medical Informatics Association 2007 Annual Symposium Proceedings, Biomedical and Health Informatics: From Foundations to Applications to Policy, Chicago Ill., 2007;:630-634; and Manzoor S, Ceusters W, Rudnicki R. A Middleware Approach to Integrate Referent Tracking in EHR Systems. In Teich J M, Suermondt J, Hripcsak C. (eds.), American Medical Informatics Association 2007 Annual Symposium Proceedings, Biomedical and Health Informatics: From Foundations to Applications to Policy, Chicago Ill., 2007;:503-507, each of which is hereby incorporated herein by reference in its entirety.
An IUI is created out of the generated string, by attaching it to the particular in question. Three factors can be distinguished as structural elements involved in such an assignment act:
The resulting IUIs will, together with certain further types of associated information, constitute the IUI-repository.
The units, called “A-tuples” that are deposited in this repository and that represent the assignment act (‘A’, here, stands for assignment) are, in one example, of the form:
where IUIp is the IUI of the particular in question, IUIa is the IUI of the author of the assignment act, and tap is a time-stamp indicating when the assignment was made.
D-Tuples
In light of the need or desire to resolve mistakes, one aspect of the invention includes the use of meta-data called “D-tuples”. D-tuples are created whenever (1) a tuple other than a D-tuple is added to the RTS Data Store, in which case it includes meta-data about by whom and at what time the corresponding tuple was deposited, or (2) a tuple, including D-tuples, is declared invalid in the system, in which case it includes additional information concerning the type of mistake committed and the reason therefor.
D-tuples are, for instance, of the form:
where:
PtoP-Tuples
Descriptions which express configurations amongst particulars are referred to as PtoP—particular to particular—descriptions. Here again a number of structural elements can be distinguished:
This relationship data will then take the form of an ordered sextuple, such as, for example:
where
P contains as many IUIs as are required by the arity of the relation r. In most cases, P will be an ordered pair which is such that r obtains between the particulars represented by its first and second IUIs when taken in this order.
PtoU-Tuples
Another type of information that can be provided about a particular concerns what universal within an ontology it instantiates. Here, too, time is relevant, since a particular, through development, growth or other changes, may cease to instantiate one universal and start to instantiate another: thus George W. Bush Sr. changed from foetus to newborn, and from child to adult.
Descriptions of this type (which are referred to as PtoUtuples—for: particular to universal) are represented by ordered tuples of, for instance, the form:
where
Note that it is specified from which ontology inst and UUI are taken (and precisely which inst relationship in those cases where an ontology contains several variants). Such specifications not only ensure that the corresponding definitions can be accessed automatically, but also facilitate reasoning in the RTS Reasoning Server across ontologies that are interoperable with the ontology specified.
PtoC-Tuples
Whereas for PtoU-tuples their denotators of relationships and universals are taken from realism-based ontologies rather than from other knowledge repositories in terminology servers, PtoC tuples do allow CUIs to be used instead of UUIs. Of course, the relationship to be used is not to be some variant of ‘inst’ since the standard definitions in use for ‘concept’ (such as ‘unit of knowledge’ or ‘unit of thought’) disallow most particulars from being declared as instances of concepts.
PtoC tuples (for particular to concept code) have the form
where
Such tuples are to be interpreted as providing a facility equivalent to a simple index of terms in a work of scientific literature.
PtoU(−)-Tuples
Since in one aspect of the invention only entities that exist or have existed are to be assigned an IUI, a capability is provided that deals with what is called ‘negative findings’ or ‘negative observations’ as captured in expressions such as: “no history of diabetes”, “hypertension ruled out”, “absence of metastases in the lung”, and “abortion was prevented”. Such statements seem at first sight to present a problem for the referent tracking paradigm, since they imply that there are no entities in reality to which appropriate unique identifiers could be assigned.
Therefore, the following relationship is defined: p lacks u with respect to r at time t: there obtains a relation between the particular p and the universal u at time t, which is such that p stands to no instance of u in the relationship r at t.
This ontological relation can be expressed by means of a “PtoU(—) tuple” which is a lacks-counterpart of the PtoU-tuple and has the following form, in one example:
It expresses that the particular referred to by IUIa asserts at time ta that the relation r of ontology IUIo does not obtain at time tr between the particular referred to by IUIp and any of the instances of the universal UUI at time tr.
PtoN-tuples
Important particulars, such as persons, ships, hurricanes, and so forth are often given proper names which function as denotators in reality outside the context of a referent tracking system. This sort of information is stored in an RTS by means of one or more “PtoN-tuples” where “N” stands for “name”.
These tuples have the following form, as an example:
where
Referent Tracking Data Store
With reference to
In
A Client Side layer 410 includes the RTS Client which is typically a third party information system 412 or middleware components. The latter sends a query to a Proxy Peer 414 in a network layer 416 that forwards the request to the appropriate RTS server in the network. During execution of the query, a RTS server 418 calls the services of a RTS core 420 API to retrieve the results from the Database Management System databases (DBMS) that constitute a data source layer 422.
RTS Core Layer
RTS Core layer 420 implements the business logic of RT, namely, the insertion and retrieval of RT tuples in a database. RTS datastore 400, includes, for instance, two database applications: IUIRepository database 424 and RTDB system 426. The IUIRepository database manages the statements about the assignment of IUIs to particulars, and provides a central repository of IUIs 428 to the RTS. The RTDB is a database of statements representing the detailed information about particulars, examples being ‘#IUI-1 instantiates the universal Person’ and ‘#IUI-1 has the name “John”.’ It provides one or more tables 430.
The IUIRepository and RTDB components are implemented through a series of application programming interfaces (APIs). The IUIRepository includes services to search particular representations and to insert new ones in its corresponding DBMS. Similarly, the RTDB components provide API get methods (e.g., getPtoN, getPtoP, etc.) to search and create methods (e.g., createPtoN, createPtoP, etc.) to insert tuples in its database.
The IUIRepository and RTDB components are implemented independently of any specific DBMS (e.g., MYSQL, HSQL). DBMS support is controlled by DBMS specific driver components, such as for MYSQL and HSQL.
Insertion services
Insertion services allow inserting a new RT tuple into the repository. The RT tuples are inserted in, for instance, a transaction, which is an information unit. As an example, entering a patient's blood pressure could involve a couple of RT statements which could include one or more RT tuples. All tuples in a transaction are guaranteed to be committed in the data store. In case where either a system breaks down (by power failure or other means) or a user aborts the operation (e.g., a user closes/cancels the data entry screen while entering data), no partial information is stored in the data store. This service marks the start of a transaction for a specific session of a user. The RT paradigm does not allow, in this example, any deletion operation in order to be able to always return to a state of the database as it was at a certain time in history. To avoid mistakes in creating new tuples in the RTRepository, the tuples are cached right after the create operation. The client can remove or modify the tuples from the cache, as long as the commit service has not been called.
The most basic service assigns an IUI to a real world entity and creates its representation in the RTS. For instance, the call ‘ParticularPresentation particular=repository.createParticular Representation (tap, IUIa);’ creates first an A-tuple in the repository, assigns the metadata properties IUId and td, and then returns the instance.
The next step is to assign detail to this particular. For example, the call ‘PtoU ptou=repository.createPtoU(particular.getIUI( ), IUIa, “rts.ri/OBO_REL/instance_of”, “rts.u//FMA/Left+forearm”, ta, tr),’ relates the particular created earlier to the Left forearm class (represented through a PtoU tuple) of the FMA (Foundational Model of Anatomy) by means of the instance_of relation from the OBO (Open Biomedical Ontologies) relation ontology. The arguments for the service call are, for instance, generated by means of the middleware component discussed further which translates the data from the data capture screens of the external information system into the referent tracking data types, as discussed herein.
Table 4 below shows various create services:
Retrieval Services
The API retrieval methods help in searching the particulars in the RT repository. Particulars can be searched by means of any data associated with them, such as their names, the ontology classes of which they are instances, or the creation and observation dates.
The following table provides a few examples of such services:
The arguments in the above services can be ‘null’ to enable search with the most global wildcard. Because the search pattern in the services might match with several thousands of particulars and the network bandwidth might not allow the transfer of that many results to the clients, a limit can optionally be set in the RTS configuration file. What precise selection will be returned within that limit depends on the data source technology which the system administrator of the RTS decides to use or for which the organization has obtained appropriate third party licenses.
RTS Network Layer
Network layer 416 (
RTS Services Server:
RTS services server component 419 (of referent tracking data access server 418) provides central query execution services to a proxy peer functioning as a client. The server is implemented in a way similar to the Services Oriented Architecture (based on an idea similar to that of web services), in which a set of services (similar to remote procedures) are provided as a query mechanism. The XML language is used to send both query and results between peers. Implementing the query mechanism by using XML avoids making changes in the server and proxy components as new services are introduced.
Listing 1, below, shows an example of the createPtoN service which allows inserting PtoN tuples in the database. The Name element inside the RtsService element would hold the name of the service, and the elements inside the Params element would contain the parameters of the service. For the sake of simplicity, only two parameters are shown in this example: ‘iuip’ stands for the IUI of the particular for which statement PtoN is inserted and ‘ta’ stands for the time at which the PtoN statement is inserted.
In the architecture of one aspect of the present invention, it is not required that all server peer installations provide the same set of services. Services in a server are published via a RtsServicesFactory 440, an interface which returns the list of service handlers, where each service handler is responsible for the execution of a specific service. Each service handler is implemented as a class which has two methods: getServiceName( ) and handlService(queryXML).
The method getServiceName( ) returns the name of the service, e.g., createPtoN, for which this handler is implemented. The RtsServer component calls this method to match the service name in the query (which is sent by a client for execution). If the query name is matched with getServiceName, then the server calls the handleService method of this handler.
The handlService(queryXML) method handles the execution of a service and returns the results in the form of XML to the server. Then, the server sends the XML, including its header information (which is used for internal purposes between server and clients), to the client who sent the query.
To publish new services in a server, the server configuration file is modified to inform the server about the availability of the new services implemented as a Java class.
As an example, the RTS server executes the query in Listing 1, as follows:
RTS Proxy:
RTS Proxy 414 is the client side implementation of the RTS server that provides interfaces to RTS clients. The output of the proxy client, when querying multiple servers in a group, is based on the idea of streaming such that it outputs a result as soon as it receives it from a server.
Just after building a successful connection to a server, a Proxy Peer requests a list of services from the Server Peer (e.g., insertPtoU, getPtoU, getPtoN, etc). The Proxy Peer uses this information to forward the RTS client query to the appropriate servers which handle the query. For example, in
In one example, the Proxy component is implemented in such a way that it need not be changed if a server announces a new service. Since the service calling mechanism uses XML as a data format, the proxy component provides a RtsQueryService class to build a service query in XML. To create a service as in Listing 1, an object of the type of RtsQueryService class is created first. The service name, e.g. ‘createPtoN’, is assigned through the object method setServiceName(“createPtoN”). The parameters of the RtsQueryService object are assigned through the setParam method by supplying name-value pairs ( e.g. <“IUIp”, “IUI-50”>) as in setParam(“IUIp”, “IUI-50”). After the RtsQueryService object has been fully specified, it is serialized into the service query XML string as shown in Listing 1.
The proxy communicates with the server with the following protocol, as an example:
Reasoning Server 114 (
Reasoning is a part of the RTS and its purpose is double: first to avoid inconsistent data from being entered, and second to draw inferences during the execution of the search queries using the generic knowledge expressed in the terminology servers used to annotate the data and by exploiting the reasoners that operate on them. Various third party reasoners exist, some being specific to a particular knowledge source, some coming with a public DIG (Description Logic Implementation Group) interface for description logic representations, while others use directly OWL-DL (Web Ontology Language-Description Logics).
In order to be able to deal with terminology servers and the various sorts of knowledge sources they offer (nomenclatures, thesauri, ontologies, . . . ), the RTS includes a Reasoning API which helps in sending reasoning queries uniformly to different terminology servers. The Reasoning API has an abstract class called OntologyConnector, which provides an interface to the external terminology systems by means of services (see Table 6 below). The interpretations of the OntologyConnector services are specific to a particular terminology server; therefore, there is a separate implementation of the OntologyConnector for each terminology server which is used to annotate the particulars in the RTS.
Examples of various OntologyConnector class services are described with reference to Table 6:
Description logics are widely used for building ontologies. The reasoners for such ontologies may take from 1 second to a day to compute inferences over the ontology classes depending on their size and definitional complexity. Therefore, instead of directly communicating with the reasoners for each ontology, the RTS is able to compute all the inferences at one time and then to store the result as an inference graph in a database. Furthermore, because the execution time of the OntologyConnector services can range from milliseconds to minutes, depending on the query execution time in the external terminology system, the OntologyConnector caches the results returned from these systems. The cache is stored, for instance, in a RDBMS. During the execution of any of the OntologyConnector services, it first searches in the cache.
Reasoning is performed for any query which involves PtoU tuples. If, for example, the query getParticularsWithPtoPByPtoU(iuip=>rts:IUI-1, r=>rts:r//OBO_REL/has_part,PtoU.<UUI=>“Upper limb”, o=>“FAM”>) is executed, then first the IUIs for the particulars which are related to the particular rts:IUI-1 via the has_part relation are retrieved. Then, it retrieves the UUIs for the universals which are instantiated by the particulars denoted by these retrieved IUIs. Finally, it requests the terminology servers in which the universals are represented by calling the isRelationExistsBetweenUniversals(“Left forearm”, “Upper limb”, “part of”) service from the OntologyConnector instance of the specialized class implemented for the FMA ontology. If the service returns true, then it returns the resulting IUIs with their associated tuples.
Initialization of a Referent Tracking Server
When an RTS is installed in an organization, a system administrator creates a configuration file that includes basic information about the environment. The minimal information that is provided includes, for instance:
When the RTS is then started for the first time, the setup information is translated into a series of A-tuples and D-tuples, while the corresponding generic information is loaded in the internal ontology.
Example of a Referent Tracking System Used in Combination with an Electronic Health Record (EHR) Operated by a User
EHR Environment
The EHR application has a mechanism to search for codes assigned to terms or concepts in a terminology (T), or to universals as in realism-based ontologies (RBO), via a search utility which could be launched as a graphical user interface (GUI) to a clinician while the clinician is documenting the patient encounter.
The EHR application has been connected to the RTS system during the initialization phase such that:
Use Case Scenario
One day, John consults for a left femur fracture with Dr. Rose, who enters the data in his EHR system. This encounter involves many actions to be carried out before the data are finally translated in the referent tracking data types and stored in the referent tracking data store. These actions include, for example:
Action 1: The clinician makes the diagnosis that John has a left femur fracture.
Action 2: The clinician registers this diagnosis in the EHR application. To do this, he starts by searching for information about John in the EHR database, but since John is a new patient, he does not find a reference to him in the system. He then inserts John's demographic data in the demographic module of the EHR application.
Action 3: At this stage, the EHR application communicates adequately with the IUIComponent to search John in the RTS, as he might have been registered there already, as described below.
Action 3.1: In one example, the EHR application calls the services of the IUIComponent to find John's IUI, for instance by means offindPatientByName(“Name”, “John”), described below. This service communicates with the RTS to find a particular for which there is a PtoN-tuple that includes the name term pair (nj, ni) (“Name”, “John”). Finding a patient's IUI in the RTS might involve other sorts of identifiers such as a local patient id (patient number in the clinic, driving license number, social security number, and so forth). Relations between a particular and such identifiers can be expressed by means of PtoP tuples or PtoN tuples.
findPatientByName(“Name”, “John”).
Action 3.2: If John is not yet represented in the IUI-Repository, then the IUIComponent calls the RTS create services to insert the particular representation in the IUI-Repository as described in the following way, as an example:
1) createParticularRepresentation(tap=>date, IUIa=>“IUI-]”)
The order of the variable set <tap, IUIa> corresponds with the values in the create service for the tuple in the ParticularRepresentation table. IUIa stands for the IUI of the entity, in this case Dr. Rose, that wishes to assign a IUI to a yet unregistered entity, in this case John. During the execution of the create service, the RTS generates IUI-2 for the particular, then inserts the tuple in the ParticularRepresentation table, and finally a corresponding D-tuple in the Metadata table. Finally, the RTS server returns the “IUI-2” to the IUIComponent.
2)createPtoC(IUIa=>“IUI=1”, ta=>date, IUIC=>T.IUIp=>“IUI-2”,CUI=>“116154003”, tr=>date).
The values in the create service correspond to the variable set <IUIa, IUIp, ta, tr, rts:/cbs/co>, in which the variable names correspond to the attributes in the PtoC tuple and the 116154003 code correspond with the term “patient” in terminology T. During execution of the create service, the RTS inserts the tuple within the PtoC table and its corresponding D-tuple in the Metadata table.
createPtoN(IUIa=>“IUI-1”,ta=>date, nt=>“Name”, n=>“John”,IUIp=>“IUI-2”, tr=>date ,IUIc=>c)
The order of the variable set <IUIa, IUIp, ta, tr, ntj, ni> corresponds with the values in the create service for the tuple in the PtoN table. During the execution of the service, the RTS inserts the PtoN tuple in the PtoN table, and its corresponding D-tuple in the Metadata table.
Action 4: After calling the RTS create services, the IUIComponent sends the “IUI-2” to the EHR application. The EHR system stores that “IUI-2” denotes patient John.
Action 5: After adding the patient demographic data, the clinician opens an encounter input screen from the EHR system to write down his diagnosis. At this stage, the EHR system internally ‘knows’ that the patient for whom the documentation is being entered is John, and it ‘knows’ also that John's IUI is IUI-2.
Action 6: During the encounter documentation, the clinician searches for “left femur fracture” in terminology T with the interfaces provided by the EHR application. Unfortunately, T does not contain that term, and therefore, the clinician decides to use a combination of two other terms, one with CUI “419161000” and term “Unilateral left” and one with CUI “71620000” and term “Fracture of femur” to describe John's Left femur fracture.
Action 7: The EHR application calls the getIUI(“IUI-2”, {419161000, 71620000}) service of the IUIComponent. The getIUI service searches the RTDS for IUIs denoting particulars (having any relation with the particular #IUI-2 (John)) that are already annotated with these codes through the following steps, as one example.
Action 7.1: During execution of the getIUI service, the IUIComponent first executes the RTS service:
getParticularsWithPtoPByPtoC(iuip=>“IUI-2”,r2=>null,PtoC :<IUIc=>T. CUI=>“71620000”,is_a=>“is_a”>)
to retrieve the IUI for a particular in relation to patient John (#IUI-2) which has the is_a relation with 7162000 (Fracture of Femur) in terminology T. In this case, the service finds nothing in the repository and notifies this to the IUIComponent. As the getIUI service receives no applicable IUI, it does not further search particulars annotated with the other code 419161000 (Unilateral left).
Action 8: As no particular is found in RTS, the IUIComponent calls the create services of the RTS to insert the new particular representation in the context of patient John, which generates IUI-3. The IUIComponent then inserts both CUIs (419161000 and 71620000) with the same timestamp.
Method To Translate Data from External In formation Systems into a Referent Tracking Compatible Format.
An advanced application is presented demonstrating how data collected by an Electronic Health Record application (EHR) can be reformulated to be compatible with the requirements of referent tracking, namely that the particulars assigned an IUI are instances of the kinds included in a realism-based ontology.
A typical EHR application enables a user to generate a fully readable, highly detailed progress note using only point-and-click controls as input. This is accomplished by creating a multitude of “control” types of which many are built up from one of four basic types (Checkbox, Radio Buttons, Checklist, and Number Box) and whose instances are used by clinicians to document the patient encounter. The output of the controls is formed by merging the input from the user into a predefined parameterized sentence. This design is well suited to the integration of a referent tracking system as each control in the application has a finite set of possible statements as output. Each of these statements can be linked to an RT compatible reformulation during design-time rather than at run-time. As an example, this is explained for a data-form control that is used to enter information on the strength of flexions of the feet.
As RT requires its IUIs, in one example, to refer only to spatiotemporal particulars (instances), its integration into an EHR application sometimes requires expanding single data elements from an EHR into several data elements. This expansion is performed in order to make explicit all of the references that an EHR data element contains only implicitly under current paradigms which focus on what are called concepts. The expansions that are performed follow the ontological—in contrast to biological—dependency relations that hold between the various types of particulars, as described in realism-based ontology and that, as explained further below, lead to the distinction of the three types of particulars relevant for these purposes, namely: (1) independent continuants (e.g. John Smith), (2) dependent continuants (e.g. John Smith's left femur fracture), and (3) occurrents (e.g. the healing of John Smith's left femur fracture).
Data elements which refer directly to independent continuants, such as persons and their body parts, require no expansion. Elements which refer to other types of particulars, such as weights, blood pressures and measurement acts themselves, do require expansion, in one example, so that all of the particulars on which the particulars they refer to depend are explicitly mentioned. This requirement is meant to ensure that there are no dangling references within the RTS: if the RTS stores a reference to a fracture, it also stores a reference to the bone that is fractured.
The main subdivision among particulars is based upon whether or not they have temporal parts, that is, on whether or not at any moment of time an entity is fully present or is instead only partially present. The former type of entity is a continuant and the latter an occurrent.
A subdivision of continuants (but not occurrents) is that between independent or dependent entities. An independent entity is for example a molecule or a cell. A dependent entity is for example the shape of a molecule or cell. The latter require the former in order to exist (in an ontological sense of ‘require’ that is different from what is involved for example when we say that organisms require food or oxygen). John Smith's left femur is an independent continuant—there is no other particular on which it depends in this ontological sense. The fracture of John Smith's left femur, in contrast, depends ontologically upon another continuant particular: the left femur itself. Each of these distinctions among entities is mutually exclusive and pair-wise disjoint. They yield a total of four distinct categories of particulars. But since all occurrent particulars are dependent entities (they all require one or more independent continuants which serve as their bearers), there are just three categories left: dependent and independent particulars on the one hand, and occurrents on the other.
A first step in making an EHR application RT compatible is to make an analysis of how current data from the EHR application is to be restructured. To accomplish this, for each type of assertion in the EHR, the following tasks are completed, (based upon the distinctions amongst entities as described and on the needs which EHR are to serve, e.g. in providing traceable liability):
RT requires, in one example, further information about the state of affairs referred to by an assertion to be expressed by means of one of the following types of statements:
The data-entry control that is being used in this example can generate the following sentence which then is stored in that form in the patient's EHR: “The patient's strength of right foot plantar flexion is ⅗.”
This sentence includes references to multiple particulars. In the example EHR, however, the EHR only assigns to the entire data element generated by the control one globally unique identifier which is formed through the concatenation of (i) the identifier it assigns to the patient session during which the control is used, with (ii) the identifier it assigned to the control itself. Note that (ii) is the same independently of the patient and session involved. Such a concatenated identifier does not qualify as a IUI for an entity on the side of the patient. Rather, it is as if the identifiers for the various individual particulars are “hidden” in the sentences generated by the control in a way which causes problems when these sentences are used for reasoning, and may even prevent reasoning from occurring at all.
The statement ‘The patients strength of right foot plantar flexion is ⅗’ is interpreted as being elliptical for: ‘The measurement of the strength of the patient's right foot plantar flexion yielded a value of 3 on a scale from 0 to 5.’
The particulars and associated ontological categories explicitly referred to by this sentence are thus, in one example:
Tracing the dependency relations of these particulars reveals the particulars that are implicitly referred to:
The relationships that obtain between these particulars are:
Finally, for each particular, it is also specified in the given example what universals they instantiate. This is done at that level which qualifies the universals as instantiating particulars of one of the three categories that indicate whether or not an entity is dependent. This led to four universals, in this example: Process (occurrent), Object (independent continuant), Disposition (dependent continuant), and Object Aggregate (independent continuant).
The instantiations of these universals are then:
I5: P5 is-instance-of ObjectAggregate
So in this case, making the single statement “The patient's strength of right foot plantar flexion is ⅗” from the EHR application compatible with the requirements of RT requires translating it into a set of 23 more detailed statements, as an example.
The process of expanding a data element such as is illustrated above to make explicit all of the implicit references to particulars that it may contain can thus be described in a few steps:
These steps are performed only once: e.g., when the EHR system is integrated with a RTS.
RTS—Middleware Component
For efficiency, a middleware component has been created which provides a bridge between the RTS and the host application which is referred to as “HostEHR”. As the HostEHR saves the patient encounters as XML, this design has been exploited to use the same XML for the communication between the RTS and the HostEHR. The middleware component identifies particulars by iterating through the XML and calls the services of the RTS on behalf of the HostEHR to annotate the particulars with IUIs. This approach keeps the HostEHR application and the RTS integration specific implementations at separate places. One example of the design of the middleware application is depicted in
As one example, a middleware component 600 is designed to run as a standalone application and to provide its interface to a HostEHR 602 via web services following several communication scenarios, which each employ a distinct level of integration. One scenario is to monitor the HostEHR database 604 for new transactions related to patient encounters. In response to a monitoring component (HostEHRDBMonitor) 606 finding newly entered patient data, it forwards them to a RTSEhrBridge component 608 for further processing. Another approach is that HostEHR 602 sends the data actively via web services to the middleware application just before or after saving the encounter data. After annotating the identified particulars with the appropriate IUIs, the middleware application returns the results to the HostEHR. This approach, in contrast to the previous one, allows the HostEHR to manage the IUIs at the time of documenting the encounter. For both approaches, in one example, software changes are made in the HostEHR, the latter more drastically than the former.
The middleware application is also designed as a library, so that EHR applications can embed it easily in their programming environments. The middleware application includes middleware services 618 that translates the information in an information system into a format for the RTS.
Web Services
The Web Services provides an interface to the remote clients by forwarding the clients’ requests to the bridge component. They are remote procedures that can be invoked from any programming environment.
Term Mapping Database
The information regarding which particulars are possibly referred to when an input control is used in the context of an encounter is stored in a term mapping database 610 coupled to RTS EhrBridge 608. ‘Possibly’ here refers to the fact that some particulars may already be listed in the RTS such that, in line with the RT paradigm, the IUI already assigned to them is used for further reference. Other particulars might not yet be denoted in the RTS, in which case a new IUI is created. Deciding what is the case for a given data element can be accomplished by looking at the ontological characteristics of the universals (types, kinds) of which the particulars under scrutiny are instances and under what scenario they are referred to in the HostEHR. Four different cases are identified herein.
Case 1 involves particulars which exist throughout the life of a particular patient, examples being the patient himself, most body parts (e.g. his brain), some diseases (e.g., his diabetes) and some conditions, such as his blood pressure. Whenever these particulars are first observed, they are assigned an IUI, and that IUI is to be used in all future EHR statements made about them. This case encompasses also particulars which do not necessarily exist throughout a patient's life time, but which are assumed to still exist when they are referred to in the context of a new observation. Thus, a patient can indeed lose his left foot, but if a clinician states to have measured the strength of a patient's left plantar flexion, then this foot must exist.
Some particulars start to exist at t1 and disappear at t2, such as, hopefully, a fracture of the femur, or the flexion of his foot. Furthermore, John may have more than one femur fracture in his life and, without doubt, will flex his left foot quite often, each flexion being a new particular. However, in the context of, for instance, a follow-up encounter, some particulars can not be the same as observed during a previous encounter, while others may be the very same particulars as observed before. This leads to three further cases.
Case 2 involves particulars which may be re-observed, but the context of the encounter is such that it can be decided upon automatically whether or not a new or existing one is observed. As an example, if John breaks his left leg and therefore visits a clinician at t1 for treatment, then the HostEHR would record that John (#IUI-1) has a femur fracture (#IUI-2) in his left leg (#IUI-3). For everyfollow up visit (t2 . . . t1) for that particular fracture, #IUI-3 is used. If John later breaks again his left femur, then a new IUI is assigned, and that this is the case can be derived from the context that a new visit is entered, and not a follow-up visit.
Case 3 involves particulars which can not be re-observed during a new encounter, a foot flexion being an example, a measurement act being another one. Here, there are primarily processes which have a life-time that is shorter than the duration of an encounter.
Case 4 involves particulars which may be re-observed, but the context of the encounter is such that—in contrast to case 2—it can not be decided upon automatically whether a new or existing one is observed. If, for example, the RTS already contains a reference to a femur fracture in John which was created in the context of a HostEHR disease model other than the femur-fracture disease model, then activation of the femur-fracture model alone provides not enough evidence for the former reference to be used automatically.
The practical consequence of the distinction drawn is that for particulars in case 1, a new IUI is to be assigned the first time they are observed, and that IUI is to be retrieved afterwards. In case 2, the EHR application can inform the middleware component whether a new IUI is to be assigned. In case 3, the RTS 612 would create automatically a new IUI without any further questions to be asked. In case 4, the clinician has to provide the information whether or not a new particular is involved
As an example, the data-entry control discussed above would make HostEHR 602 store the string ‘strength of rightfoot plantarflexion is ⅗’ in John's EHR. Therefore, Term Mapping Database 610, which can be viewed as an application ontology for the HostEHR, includes the information on how this string is to be interpreted in terms of the underlying particulars that are to exist in order for the string to be a true statement. That information is derived on the basis of an ontological analysis carried out a priori. The following table shows the results of this analysis, together with the classification of the particulars according to the four cases identified above:
The Term Mapping Database includes such an analysis for each data control used in the HostEHR. The Term Mapping Database also keeps track of which particulars belong to which parent-control such that decisions on whether or not a particular requires a new IUI in the context of a follow-up visit can reliably and automatically be made. In addition, the Term Mapping Database includes the information about the relations that are to exist between particulars if they are referred to in the context of a specific disease model.
The Middleware Core Component
A middlewarecore component 614 receives the HostEHR patient's encounter XML by monitoring database 604 or, in this example, the XML is sent by HostEHR 602 through web services. It is composed, for instance, of two software components: BuilderForHostEHR 620 and RTSEhrBridge 608.
BuilderForHostEHR component 620 is a parser for the HostEHR's XML structures. It extracts the EHR statements (such as strength of right foot plantar flexion is ⅗) by iterating over the XML source.
RTSEhrBridge component 608 first retrieves the configuration of involved particulars for each statement from the Term Mapping Database. Based on this information, as well as on the encounter context information (whether a new visit or a follow-up is being documented), it decides whether IUIs for the particulars are first to be searched for in the RTS, or are to be created directly.
To assess whether particulars are already listed in the RTS, the RTSEhrBridge queries for these particulars by means of statements of the form, for instance:
getParticularsWithPtoPByPtoC(iuip=>“IUI-1”,r2=>null,PtoC:<IUIc=>T. CUI=>“24176006”>).
In case the particulars are not listed in the RTS, or when the information in the Term Mapping Database states this directly, the RTSEhrBridge requests the RTS to create new IUIs for those particulars by means of a series of statements of the form, for instance:
IUI-2=createParticular(IUIa=>IUI-10, tap=>“02/27/2007”);
createPtoC(IUIa=>>“IUI-10”, ta=>date, IUIc=>T, IUIp>“IUI-2”, CUI=>24176006, tr=>date).
createPtoP(IUIa=>“IUI-10” ta=>date, r=>“has_art”, IUIo=>O,P=>{“IUI-1, “IUI-2”}, tr =>date).
The createParticular method, in the example above concerning IUI-10 which stands for John, creates a reference to a particular and returns its IUI. The createPtoC associates the HostEHR Rightfoot term with the particular IUI-2. The createPtoP method asserts the has_part relation between IUI-1 and IUI-2. The relation information between the particulars IUI-1 and IUI-2 is also found in the Term Mapping Database. After the IUI assignment is complete, the RTSEhrBridge class returns the IUIs to BuilderForHostEHR 620. When encounter data are sent to the middleware component, BuilderForHostEHR associates the IUIs at the appropriate places in the XML, e.g. along with the “strength of right foot plantar flexion is ⅗” phrase decomposed into particulars, and finally the resulting XML is sent back to the HostEHR.
In cases when it cannot be determined whether a new or existing particular is observed, for instance, under a scenario with less intimate integration or when the clinician is not willing to supply the additional information, the RTSEhrBridge class assigns a denotator which is a unique identifier to the particular but which is not an IUI because it does not satisfy the requirement of singularity. This identifier is created in the RTS by means of a statement of the type: ‘ID=createIdentifier(tap, IUIa)’. Because these identifiers are clearly distinguished from IUIs, it is possible to supply the missing information later and to replace the identifier accordingly with an appropriate IUI.
Change Management And Error Correction
The real world is subject to constant change, and so also is our knowledge thereof. To keep track of these two sets of changes in an RTS, any assertion concerning a relationship between entities is associated with an index for the time period during which the relationship obtains, for the time at which the assertion is made, and for the author of the assertion. When such an assertion is made, the RTS assumes that:
Because data stored in referent tracking data stores, as thus conceived, (1) are artifacts created for some purpose and because (2) they are intended to mirror reality, and because (3) reasoning with the representations requires efficiency from a computational point of view, an optimal data store, in this example, is to contain data which constitute a representation of all and only those portions of reality that are relevant for its purpose. Clearly, things may go wrong on the way to achieving this optimal representation. First, users may be in error as to what is the case in their target domain, leading to assertion errors. Second, they may be in error as to what is objectively relevant to a given purpose, leading to relevance errors. Third, they may not successfully encode their views, so that particular representational units fail to point to the intended entities because of encoding errors.
An ideal data store, in this example, would be marked by none of these three types of errors. Each information bearer in such a data store would designate (1) a single POR, which is (2) relevant to the purposes of the host application, and such that (3) the authors of the representations intended to use this term to designate this POR. Moreover, (4) there would be no PORs objectively relevant to these purposes that are not referred to in the data store.
To keep the data in the data store consistent with the portion of reality they intend to describe, and at the same time to keep a historical view over what was believed to be the case at earlier times, its information will often be updated by adding appropriate tuples and corresponding D-tuples. The latter therefore have the parameters “C” and “E”, as described above.
Mistakes in Existing Tuples
Values for the C-parameter make explicit whether changes in a new version of a tuple are due to, for instance,
(1) A change in reality (code “CE”);
(2) A change in the authors’ understanding or beliefs thereof (code “CB”);
(3) A change in the relevance for inclusion of representations (code “CR”); or
(4) Correction of mistakes.
For corrections of mistakes, the E-parameter of the D-tuple can have several values, depending on what type of RT-tuple is in error.
A-tuples, as explained, are used to assert the existence of some particular in reality at some time, and to differentiate this particular from other particulars by assigning it an IUI as a globally unique and singular ID. Hence, A-tuples can be qualified as being in error for one or other of the following reasons, as examples:
PtoU-tuples, which relate a particular to a universal the reference to which is drawn from some external ontology, can be in error for many more reasons, including, for instance:
Where the ID for the particular is subject to an A-type error, the following additional PtoU-errors may occur, as examples:
Four further types of mistakes are such that reality is mirrored by the PtoU-tuple in question, but what is mirrored is either not what was intended, or is irrelevant:
Similar situations, with corresponding error codes, are defined for all other tuples in a similar way. In one embodiment, those error codes are inserted into the D-tuple (by means of the E parameter) corresponding to the tuple in error.
Mistakes of Omission
All portions of reality that are relevant for the purpose for which the RTS is maintained should be represented by means of corresponding tuples. If not, the following mistakes occur, in both cases leading to the absence of an A-tuple, as examples:
Similarly, two further types of errors are recognized involving universals or particulars:
Whereas mistakes of omission may occur independently of other mistakes, some mistakes of type A and type U will automatically bring in their wake mistakes of other types: Thus, for example, mistakes of type U6 and U9 are automatically associated with a mistake of type U-1.
Overview of Correction Logic
One example of an overview of the logic executed by the RTS to correct an error is described with reference to
Example Scenario
Described herein is a simplified criminal case, based on a real case, to demonstrate the principles: Jul. b 15, 1984, 9-year-old Christie Hamilton was raped and murdered. Aug. 20, 1984, Stan Ruffner was imprisoned for rape and attempted murder on Louise Talbry. A composite sketch of the perpetrator in the Hamilton case was shown on the local news. Two anonymous callers advised that Kirk Peeters looked like the composite. Peeters was convicted of the murder. Oct. 5, 1993, new forensic tests discovered semen on Hamilton's underpants. DNA tests proved it was not Peeters'. Sep. 19, 2003, the DNA sample recovered from Hamilton's underpants was identified as that of Ruffner.
Described herein are the sequence of actions and corresponding logic employed to represent this case in a specific implementation of a referent tracking system that is assumed to have been set up in 1984. The corresponding states of the relevant parts of the referent tracking data store are shown in this specific implementation using simple tables, one table for each sort of tuple, with the columns—except for the last one—corresponding to the parameters used in the tuples as described above—“Referent Tracking Data Elements: RT-tuples”. Each row in any table corresponds with a new tuple instance. The last column of each tuple-table includes IUIs which represents the corresponding tuple-instances, and thus, can be seen as primary keys for the tuple-instances. This specific implementation thus leads to a more compact A-tuple table than what would be achieved by inserting two A-tuples for each assignment as described in
Rather than displaying lengthy unique identifiers, surrogates of the form “IUI-x” are used, where “x” is a number.
Further, for the sake of the example, let FBI agent, John Smith, be responsible for the follow-up of the case and for registering all information, including the correction of mistakes, and also assume that the RTS itself was set up in the FBI by system administrator Barry Jones on Jan. 2, 1984.
Also, relevant parts of the internal ontology of the RTS used to annotate the particulars in the referent tracking system (RTS) are displayed.
Sequence 0: Installation of the RTS
Barry Jones, as designated system administrator for the RTS within the FBI, writes on Jan. 2, 1984 the configuration file as described above—Initialization of a Referent Tracking Server. The specific implementation of the RTS to be installed provides that the following initialization file is to be completed (“ * * * ” indicates parameters to be supplied by the system administrator):
The administrator fills out this file using a text editor, resulting in, for instance:
Then, the initialization logic is launched (e.g., by the RTS data access server) which generates the following events, as an example:
Sequence 1: Adding Agent John Smith as Authorized RTS-User
Adding new users is performed by the system administrator by calling a AddNewUser service which implements the following logic, in one example:
Sequence 2: Registering Christie Hamilton's Murder
Jul. 16, 1984, 6.34 PM, agent John Smith registers in the RTS that on Jul. 15, 1984, 9-year-old Christie Hamilton was raped and murdered.
This involves the following steps, as an example:
which results in the following tuples being added, as examples:
Sequence 3: Stan Ruffner's Imprisonment is Registered
In ways similar as in Sequence 2, the data for Stan Ruffner are added. Several tuples are added, of which only the following, the assignment of IUI-2001 to Stan Ruffner are relevant for the purposes of our example to demonstrate the error-correction logic:
Sequence 4: Asserting Kirk Peeters as the Murderer of Christie Hamilton
In ways similar as before, a series of tuples are added, of which the following are relevant for the example:
The assignment of a IUI to Kirk Peeters:
and the assertion that Kirk Peeters is the rapist and murderer of Christie Hamilton:
Sequence 5: Asserting Ruffner as the Rapist and Murderer of Hamilton
It is only at the time that it becomes known that Ruffner is Hamilton's murderer and not Peeters, that it is known that there are mistakes in the referent tracking system. The mistakes, in this particular case, are in the PtoP-tuples with the IUIs IUI-3004 and IUI-3006. The mistakes are corrected through the following steps:
These tuples indicate formally:
Continuing with the example scenario, further, provided below is Table 7 that depicts some relevant particulars and their associated UIUs in the Peeter's case. Relevant tuples not listed in Table 7 include the A-tuples representing the assignment of the IUIs to the corresponding first order particulars, and the D-tuples that go along with them.
Moreover, Table 8 below displays chronologically some of the D- and A-tuples—ignoring their authors—that would result from tracking the particulars. It provides a view into how the RTS changes over time, and how the error correction mechanism goes hand in hand with the representation of changes in reality, the understanding thereof, and changes of relevance. The correction introduced here is the insertion of the D-tuple to which IUI-109 is assigned: this tuple retires PtoP-tuple IUI-9 which included a Px type of mistake.
Described in detail above is a capability for unambiguously tracking a portion of reality over time. The tracking is performed by a referent tracking system that can be networked and can communicate with traditional information systems. Errors in the referent tracking system (e.g., in the information stored therein) are detected and corrected. Information of the referent tracking system can be stored, displayed, printed, etc., and there are many uses for the information, including in the health field, criminal investigations, intelligence, etc.
Additional details regarding referent tracking are described in the following articles, each of which is hereby incorporated herein by reference in its entirety:
One or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has therein, for instance, computer readable program code means or logic (e.g., instructions, code, commands, etc.) to provide and facilitate the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.
One example of an article of manufacture or a computer program product incorporating one or more aspects of the present invention is described with reference to
A sequence of program instructions or a logical assembly of one or more interrelated modules defined by one or more computer readable program code means or logic direct the performance of one or more aspects of the present invention.
Advantageously, a capability for performing referent tracking is provided that enables the unambiguous tracking of portions of reality over a period of time. Persistent, globally unique and singular identifiers are assigned to entities that exist or have existed in the world. Further, persistent, globally unique and singular identifiers are reserved for entities that are expected to come into existence in the world. Relationships that such entities exhibit in reality are described. To facilitate the tracking, a referent tracking system is provided for tracking entities, their relationships and descriptions thereof over time. Advantageously, the referent tracking system communicates with other referent tracking systems and traditional information systems. Data collected by means of traditional information systems are translated into a format that satisfies the principles of data-organization embodied in a referent tracking system.
Although various embodiments are described above, these are only examples. A referent tracking system can have more, less or different components than described above. Further, the components can execute on various personal computers, mainframes, distributed systems, etc. Moreover, the data may be represented in a different manner. Many other variations or additions are possible without departing from the spirit of the present invention.
Further, a data processing system suitable for storing and/or executing program code is usable that includes at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memory which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/Output or I/O devices (including, but not limited to, keyboards, displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives and other memory media, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.
The capabilities of one or more aspects of the present invention can be implemented in software, firmware, hardware, or some combination thereof. At least one program storage device readable by a machine embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.
The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified. All of these variations are considered a part of the claimed invention.
Although embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.
This application claims priority to U.S. Provisional Application No. 60/963,736, entitled “Referent Tracking”, filed Aug. 7, 2007, which is hereby incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60963736 | Aug 2007 | US |
