=Paper=
{{Paper
|id=Vol-1515/early2
|storemode=property
|title=Replacing EHR structured data with explicit representations
|pdfUrl=https://ceur-ws.org/Vol-1515/early2.pdf
|volume=Vol-1515
|dblpUrl=https://dblp.org/rec/conf/icbo/BonaC15
}}
==Replacing EHR structured data with explicit representations==
https://ceur-ws.org/Vol-1515/early2.pdf
Replacing EHR structured data with explicit representations
Jonathan Bona1 and Werner Ceusters2
1
Department of Oral Diagnostic Sciences, University
at
Buffalo,
355
Squire
Hall,
Buffalo,
USA
2
Department
of
Biomedical
Informatics,
University
at
Buffalo,
921
Main
street,
Buffalo,
USA
1 INTRODUCTION 3 EXAMPLE
As part of a project to develop a roadmap for the creation of Figure 1 shows selected Problem entries and their Prob-
a multi-center fully identified patient data warehouse in- lem Headers for four patients. Within an example each
volving all State Universities of New York State (SUNY), row shows the problems under a single header for the pa-
we’ve examined patient records stored in an EHR database tient. Columns represent days with entries for the patient. A
to 1) determine what its contents are intended to represent, filled oval indicates a problem entry on that day. This figure
and 2) develop ontologically sound models based on the shows ordering of updates but not their spacing in time. A
principles of Ontological Realism and Referent Tracking table of header descriptions appears on the next page.
(Ceusters, Chiun Yu Hsu, & Smith, 2014; Smith & In example 1, two headers are created initially: e1ph1
Ceusters, 2010). The exploration of the EHR database is
driven by identifying the structures that contain answers to
questions that might be obtained with relative ease using the
EHR system’s user interface but that are difficult to find by
working directly with the database, for example: ‘what di-
agnoses have been made about which disorders a specific
patient is suffering from; when were those diagnoses made
and by whom; what entities are those diagnoses about?’
This abstract presents issues with the data model currently
used in the EHR database and an approach to address them.
2 CHARACTERIZING DATA AND ISSUES
The EHR database presents several obstacles to properly
understanding its contents. The intended meaning of its data
elements is not explicitly specified, but implicitly depends
on connections to the user interface, other software that uses Figure 1 Examples of Problem entries for four patients
it, workflows, etc. Nevertheless, it’s possible to determine (Diabetes mellitus type II) and e1ph2 (Diabetes Mellitus
some of this by examining tables, their elements and the With Complication). Later e1ph1 gets a new entry. Two
connections between them. months later, e1ph3 (Diabetes Mellitus) is created. It is up-
For example, the tables named Person and Problem dated regularly. Six months after their creation, e1ph1 and
are linked to healthcare processes. Problem entries are e1ph2 are updated with new entries with the status Error.
organized under Problem Headers, where each header Later, e1ph4 (Type 1 Diabetes Mellitus - Uncontrolled) and
entry is supposed to correspond to a single thing (diagnosis, e1ph5 (Diabetes Mellitus With Complication) are added.
procedure) and Problem entries are spread out in time After that e1ph3, e1ph4, and e1ph5 are updated occasional-
each under its header and correspond to updates to the rec- ly, keeping the status Active.
ord made during encounters (Weed, 1968). By focusing on The likely sequence of events is that the diagnosis of Type
patterns of diagnoses stored in these tables, we have identi- II DM was changed to Type I DM, after which a different
fied several ways in which the data fail to represent. These header for Type I was created and used, and entries in the
include: multiple entries standing for the same entity; single first two headers were marked Error. Old entries under
entries that stand for more than one entity; entries that might those headers were marked as Resolved.
represent either more than one entity of the same type sepa- Clearly, this record has drifted from representing reality
rated in time, or a single entity that persists over time; en- after just a few updates. This patient does not have more
tries wrongly marked as resolved or errors; and wrong or than one DM, but what was first thought to be Type I was
outdated active entries. then recognized as Type II. The system in this case fails to
Copyright c 2015 for this paper by its authors. Copying permitted for private and academic purposes 1
Bona and Ceusters
distinguish 1) information that was retracted due to some 4 EXPLICIT REPRESENTATIONS
change in knowledge about the patient’s health from 2) in- We propose using ontology-based models that explicitly
formation that was truly entered in error. represent the entities and processes relevant to health care
Example 2 shows a more correct use of the Error status: encounters. Figure 2 depicts an instance of diagnosing a
the header e2ph3 (Type II DM – Uncomplicated, Uncon- fracture as part of a health care encounter.
trolled) was created at the same time as headers about ke- Only some of the entities represented here will appear in
toacidosis (e2ph2) and acanthosis nigricans (e2ph4), which other encounters. Any other diagnostic process will be a
are complications of Diabetes. This mistake was quickly different instance. Its output will be a different instance than
caught and e2ph3 was marked Error. e2ph1 here repeats diagnosis1 -- even if it’s about the same things. The in-
the misuse of the Resolved status: the patient was thought to stance diagnosis1 persists, even if it is later outdated, con-
have Type I DM and the diagnosis changed in time. It’s not tradicted, or otherwise known to be wrong and marked as
that the Type I DM existed and then stopped existing. such. We also must be able to say that disorder1 exists at
Another issue is related to the use of ICD9 codes and time t1 but not at time t2; that when it exists it is located at
ICD9-like descriptions: some Problem entries refer to mul- a particular spot on bone1; and that further fractures of
tiple things. The patient's Type II Diabetes is one thing in bone1 once disorder1 has already healed are new fractures
the world; their Ketoacidosis is a separate related disorder.
A better representation would have identifiers for both the
patient's diabetes and the patient's ketoacidosis, and would
explicitly represent the relations between them (one was
caused by or was a complication of the other).
e1ph1: Diabetes mellitus type II (NIDDM)
e1ph2: Diabetes Mellitus With Complication
e1ph3: Diabetes mellitus
e1ph4: DM (diabetes mellitus), type 1, uncontrolled
e1ph5: Diabetes mellitus with complication
e2ph1: Type 1 Diabetes Mellitus - Uncontrolled
e2ph2: Type II diabetes mellitus with ketoacidosis
e2ph3: Type 2 Diabetes Mellitus - Uncomplicated, Uncontrolled
e2ph4: Acanthosis nigricans
e3ph1: Closed Fracture Of The Shaft Of The Humerus
e3ph2: Closed Fracture Of Neck Of Femur - Transcervical
e3ph3: Closed Fracture Of The Humerus
e4ph1: Open Treatment Of Humeral Shaft Fracture w Plate/Screws
e4ph3: Fracture of left humerus Figure 2 Representation of a fracture diagnosis
Example 3 shows a pattern of Problems for a patient who
has multiple fractures. Entries in e3ph1 and e3ph2 indicate (disorder2). Having single identifiers for single entities
that the patient has closed fractures both of the shaft of the (this patient’s diabetes), which we can then say things about
humerus, and of the neck of the femur. e3ph3 (Closed Frac- (it is complicated by peripheral neuropathy) is just as im-
ture of the Humerus) is created the following month. How portant as having separate terms for separate fractures.
many fractures are represented here: two or three? Probably Work is ongoing to develop computationally useful repre-
the patient had two fractures: one in the femur and one in sentations in OWL, mechanisms to interpret and translate
the humerus, and both e3ph1 and e3ph3 correspond to the patient data, and techniques to deal with temporal considera-
same fracture. But possibly the patient had two fractures in tions and other issues that are not straightforward.
the humerus at the same time, one specifically in the shaft
and one in an unspecified place. REFERENCES
Example 4 shows a patient being treated for a humeral Ceusters, W., Chiun Yu Hsu, & Smith, B. (2014). Clinical data wrangling
shaft fracture but there is initially no entry that represents using ontological realism and referent tracking. CEUR Workshop
the fracture itself – only for a treatment. e4ph3 (Fracture of Proceedings, 1237, 27-32.
left humerus), which is created eighteen months after e4ph1, Smith, B., & Ceusters, W. (2010). Ontological realism: A methodology for
seems to represent the fracture itself. The next entry in coordinated evolution of scientific ontologies. Applied Ontology, 5(3-4),
e4ph3 is more than five years later. Note that all Problems 139-188. doi: Doi 10.3233/Ao-2010-0079
shown here have the status Active. None of these - including Weed, L. (1968). Medical records that guide and teach. New England
a six-year-old fracture - have been marked as Resolved. Journal of Medicine, 278, 593-600.
2 Copyright c 2015 for this paper by its authors. Copying permitted for private and academic purposes