Harmonizing Clinical Information

longtermsingularInternet και Εφαρμογές Web

4 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

37 εμφανίσεις

Harmonizing Clinical Information
Between Patient Record Systems:
Distinguishing Information from Data


Distinguishing Information from Data


Electronic medical records (EMRs) are a very rich
source of health information


However, what’s typically within them is the raw content
clinicians collect to document details of service delivery.
These low level “facts” are called
data
.


What people want from these systems however, is
information
, which is a processed and analyzed product
of data.


Clinicians typically interpret data during clinical care


Researchers and M&E specialists also communicate and
typically think in terms of information as well





Challenges of Information Harmonization


Process of harmonizing information between
EMRs is deceptively complex


Variations in how care is provided and
documented in different locations leads to
variations in what/how data are gathered and
how they are stored


To efficiently pool health information between
settings, we must develop practical approaches
with freely available technologies that can be
used to streamline this labor
-
intensive, manual
process.


Example
-

Identifying HIV positive patients
between settings:


Foundation of all of IEDEA research


Identifying these patients, especially in the pediatric
population, can be extremely challenging.


Data sources include enrollment in an HIV clinic, HIV
test results (both DNA PCR and Elisa), CDC
classification, WHO stage, CD4 count or percent, ART
use, and in some settings, clinician’s assessment.


To define HIV Positive, researchers must make
inferences from these various data elements.


Challenges of Information Harmonization

Information Tokens


Tokens are information definitions or logic
-
based
derivations of multiple discrete clinical data elements
within a given clinical setting


Tokens are defined collectively by a data sharing
community, but the logic underneath each is specific to
the vagaries of a given EMR implementation


Example
: HIV positive is a token described by EA
IeDEA, but the Masaka implementation of OpenMRS
creates the logic one time to best derive that notion and
then reuses it as necessary


Currently, this derivation work is often done in a very
unorganized way, by multiple analysts, with little or no
documentation or ability to reuse methodology.




OpenMRS Logic Service


Automates derivations using
a human expressible form
of logic (Arden Syntax)


Provides a mechanism for consuming data from
OpenMRS
, both discrete data elements, as well as,
derived data elements



Reporting with Tokens and Indicators


A report builder takes tokens generated by the logic
service and selects/groups as needed to arrive at
indicators

(indicators = compositions of tokens)







Allows sharing of data logic between reports


More efficient and transparent


Easier to maintain


Eliminates redundancy


Ensures consistency across reports







Token Reuse for Research

One Option: Pooling Information from
Multiple Systems


Logic service standardizes information across programs

Another Option: Sharing Indicator
Definitions Between Sites


The EA
-
IeDEA supplement group has been
working hard with the WHO to support the
evolution of the SDMX
-
HD standard
(
http://www.sdmx
-
hd.org
) to define a standard
for sharing indicator definitions between sites


Pilot implementation will share the same SDMX
-
HD definition of three indicators between a
clinical site in Kenya and Uganda.


Each site will have tokens defined within the
implementation of OpenMRS

Next Steps


Finalize upgrades of software at pilot sites


Pilot three indicators through sharing of SDMX
-
HD definition file


expected ETA in a month


Complete software development


Optimize performance (speed)


Make token development more end
-
user friendly


Prepare instruction manuals and technical
documentation






Questions?