Integrating D-tree International e-CTC System with the CTC2 Database

blareweyrSoftware and s/w Development

Dec 13, 2013 (3 years and 7 months ago)

109 views

1


Integrating D
-
tree

International
’s

e
-
CTC

System with
the
CTC2 Database

Report by Things Prime GmbH

Prepared for:
D
-
tree International

Project: P
hone
-
Based Patient Screening for HIV Care and Treatment

Date Submitted
:
April 13, 2012


Introduction

The main design aim of
the
e
-
CTC application on
the
Android

platform

produced by D
-
tree

International

is to support
C
are and Treatment
C
enter (CTC)

nurse
s

in Tanzania

with a
screening protocol,
which helps identify

patients
with cases that
need to be seen
by the doctor

or

c
ounselor

vs. patients who are doing well on current treatment and can receive their
monthly medication without further consultation with a doctor
.

The protocol
is tied into an on
-
device Electronic Medical Records System (EMRS
) so that
pa
tients are registered in the system upon first visit, and can be re
-
identified by
a
CTC id
number on subsequent visits. Data obtained by use of the screening protocol then form a
longitudinal record of each patient’s condition.

Clearly, the usefulness of
this application is enhanced in the context of HIV care and
treatment within Tanzania if the data so obtained can be integrated with e
xisting data
management systems. Currently, there
are

two
main

systems in operation

(i)

The

NACP (National AIDS Control Progra
mme)

CTC2 database
. The CTC2
database was designed according to the NACP standard CTC2 card and report
formats and is currently being used by more than 90 HIV/AIDS care and treatment
clinics in Tanzania.

(ii)

The
OpenMRS CTC Database
. The OpenMRS CTC Database
was

designed by
the National AIDS Control Programme in conjunction with Morogoro Regional
Hospital, Ocean Road Cancer Institute and Tumbi Hospital, Kibaha and
was
engineered by University Computing Centre Ltd

(UCC)
, Dar es Salaam

This report outlines how
data from D
-
tree’s application can be integrated into these two data
management systems.



2


Data
Representation

and Mapping in the CTC application


The data obtained via D
-
tree’s application is stored in a relational database
(SQLite)
on the
device. It may also be synchronized, via GPRS data link, to a server, which utilizes MySQL
database in the background. The data model used is, in both cases, the same, and is a
modification of the basi
c data structuring found within
OpenMRS
1
.

OpenM
RS data is conceptualized in terms of 10 “domains”, the following
7
of which are
reflected also in the D
-
tree data modeling:

1.

Concept:

Concepts are defined and used to support strongly coded data throughout
the system

2.

Encounter:

Contains the meta
-
data
regarding health care providers


interventions
with a patient.

3.

Form:

Essentially, the user interface description for the various components.

4.

Observation:

This is where the actual health care information is stored. There are
many observations per Encounter.

5.

Patient:

Basic information about patients in this system.

6.

User:

Basic information about the people that use this system.

7.

Person:

Basic information about person in the system.


Of these 7 domains, the first 5 are the most important for CTC data collection
issues.

Differences between OpenMRS and D
-
tree data models

(i)

One major

difference between the concrete data model used by D
-
tree and the
OpenMRS

data model is that Observations are maintained within JSON structures
in a field of the Encounters table, rather than in a separate Observation table. This
is done to make the process of data retrieval within the application and
synchronization over GPRS
more efficient.


(ii)

Similarly, instead of a separate “Patient

Attribut
e” table, the D
-
tree model retains
patient attributes together in a JSON structure with
in a field of the Patient table
(and Patient Identifiers are represented as attributes within that str
ucture).


(iii)

U
nique identifiers are UUIDs (universally unique identifiers) rath
er than
traditional internal

primary keys.

(iv)

Concepts are not identified by standard codes, but are in fact direct representations
of XPaths (see
section
below

on XForms

and XPaths
)

These differences

are
all “
syntactic


modifications which do not alter the semantics


i.e.
the D
-
tree data model can
be

mapped “back” into OpenMRS tables.

The tables within the D
-
tree application are:



Bconcept



Bencounter (
analogous with OpenMRS

ENCOUNTER, though
with observations in
JSON)




1

See
https://wiki.openmrs.org/display/docs/Data+Model

3




Bform



Blocation



Bpatient (
analogous with OpenMRS PATIENT, except
with attributes and identifiers
in JSON)



Buser


X
Forms

and XPaths

We can observe (in
OpenMRS
domain 4 above) that
OpenMRS

data
-
entry is based on the
notion of data entry “form”. Although the D
-
tree system embodies a complex screening
protocol, this can nevertheless
, for the purposes of data management,

also be viewed as a data
entry “form”
.
The concrete implementation of the
se forms, internally within the D
-
tree
system, is as XForms. XForms are XML structures and the data which result from executions
of an XForm are also

XML structures (referred to as “instances”).


The D
-
tree application executes XForms
, obtains instances, and, in storing this data, maps
elements of those instances to the OpenMRS
-
style relational data model.

Elements of an
XForm instance are identified by XPaths.
(
To take up the reference from the discussion of
the
OpenMRS data model:
Co
ncept ids within the
D
-
tree
database are hashcode encoding
s

of
string representations of XPaths).

The D
-
tree application contains the following
(X)
Forms:



Registration



Visit



Lab



Close

We illustrate the nature of the data here by showing a screenshot from a
utility which shows
the data points

(in the “itext” column)

and XPaths
(in the “instance path” column)
from the
R
egistration Form
:

4




Within the D
-
tree application, the mapping

from such a data structure into the fields of the
OpenMRS

style data model of “patients”, “encounters” and “observations” is done via a
hardcoded mapping
, since not all fields here ma
p to fields of a single OpenMRS
-
style table.
However,
as one would expect,
the
registration

form fields broadly map to “PATIENT”

d
ata
and

visit

and
lab

form fields broadly map to “ENCOUNTER
/OBSERVATION


data.


So, to conclude and summarise this discussion:



the D
-
tree application is based on XForms.



Data from the XML structures which result from the execution of XForms

are
mapped to OpenMRS
-
like tables in an SQLite database on the phone, and the
same data is available in the same data structures within Mysql database on the
server.



“Concept” identifiers are essentially XPaths within the XForms


Having this understanding

of the internals of the D
-
tree application, we can turn to the
question of integrating the data with the two CTC databases in use.


For the purposes of integration, there are two issues. We can again consider
to be

“syntactic”
and “semantic”. The former is: how to transform the patient data from the D
-
tree data model;
the latter being how to map the data so obtained into the target databases. I think the former
syntactic problem is straightforward and not interestin
g: it is merely a question of obtaining
JSON structures from the b
-
encounter table entries and reading the observations (concept
-
5


value pairs) from those structures. The key issue for integration, long
-
term, is whether the
observations are encoded in a way
which makes the data compatible with the target databases.
Since the XForms were designed with the CTC2 card in mind, this is largely the case. The
target of the current project has been, however, the screening protocol, rather than the
development of a da
ta collection tool, and so there are gaps in the mapping, but these are gaps
which can be easily filled by the addition of questions to the forms. There would also be the
need to check that the values of the observations have the codes mandated by the CTC2

card.

Here, we will illustrate mapp
ing to the two target databases.

Integration
with the CTC2 database

The CTC2 database is an Access database with the following
key
tables
2
:



tblPatients


record for each patient



tblStartARTanotherClinic


record for each patient who transferred in on ART



tblVisits


record per patient visit (PatientID and VisitDate combination unique)



tblOtherMedication


record for each medication prescribed at each patient visit



tblStatus


record for each time a patient’s

status is updated


tblPatients


The field
s of the patient database are found in the registration XForm, under the following
XPaths:


CTC2

Concept

(
XPath
)

PatientID

/ctc/ctc_id_no

DateOfBirth

/ctc/date_of_birth

Sex

/ctc/sex

TransferInId



tblVisits

Information corresponding with the fields from the Visits table come largely from the
screening protocol, but also from other sources, as illustrated by this sample:

Field name

Format

PatientID

/ctc/ctc_id_no

VisitDate

Found in the d
ate

created

field of the
bencounter

table

Weight

/ctc/intro/weight (visit

xform
)

CD4

/ctc/cd4count (lab xform)

Pregnant

/ctc/history/pregnant (visit xform)







2

From the document “Core data points in the CTC2 database“

6


Integration with the CTC OpenMRS database

The main difference, in integration terms, between the CTC2 and the CTC OpenMRS
databases is the syntactic one. In the case of the CTC OpenMRS database, the syntactic
transformation of the data from the D
-
tree data model is significantly simpler because of

the
existing syntactic similarity between the OpenMRS data model and the D
-
tree data model.

However, as mentioned above, this syntactic issue is the lesser important issue. The semantic
issue, of ensuring that the XPath concepts in the XForms and the conc
epts within the CTC
OpenMRS database, and the values used for those concepts, correspond perfectly, is the key
integration task.