OpenMRS (latest stable release: version 1.8.

3)
URL http://openmrs.org/
Description
The Open Medical Record System (OpenMRS) is an
open source medical record platform for developing
countries. t is a common platform upon !hich medical
informatics efforts can "e "uilt. The system is "ased on
a conceptual data"ase and can "e customi#ed for
different uses. t allo!s implementers to design a
customi#ed medical records system !ith little or no
programming s$ills. OpenMRS features include a
%entral concept dictionary& Modular architecture and
Standards support.
Licensing
OpenMRS is distri"uted under the OpenMRS 'u"lic
(icense ).). This license is "ased on the Mo#illa pu"lic
license version ).)& "ut contains certain terms and
conditions that differ.
(See section *.+ of
https://!i$i.openmrs.org/display/R,S/OpenMRS-'u"lic
-(icense-).) for these differences)
Cost .ree
Support
OpenMRS volunteers& core developers and
implementers maintain developer and implementer
mailing lists. OpenMRS has its o!n ans!er support
system. The core team also hosts !ee$ly calls to share
$no!ledge. /o!ever& free support is not guaranteed
for implementations. 0lternatively& they
(implementers) may open tic$ets and as$ for guidance.
Counit!
0 large and active community of volunteers&
professionals and academics. 0lso maintains mailing
lists and a !i$i.
Counit! URL http://openmrs.org/
Source co"e
availabilit!
Source code is freely availa"le
#ctive
Developent
1es& "y OpenMRS core developers employed "y the
Regenstrief institute and '/& 2oston. 0lso supported
"y a large num"er of volunteer developers.
Language
Support
3ocumentation is availa"le only in the ,nglish
language. /o!ever the product provides (ocali#ation /
internationali#ation (currently supports ,nglish 4S&
,nglish 45& talian& Spanish& .rench and 'ortuguese).
OpenMRS also supports the possi"ility to e6tend to
other languages !ith full 4T.78 support.
Operating
S!stes
OpenMRS is cross7platform& and !ritten in 9ava. t uses
a Spring//i"ernate/maven stac$. There is no specific
preferred OS. 3evelopers use :indo!s& (inu6 and Mac
OS;.
Database
S!stes
<ersion ).8.= only supports MyS>(. /o!ever version
).? (yet to "e released) includes changes to support
'ostgres@l and S@l Server.
$nteroperabilit!
OpenMRS can "e accessed via "oth R,ST and SO0'
!e" services. The recommended (and only supported
method) is via the :e"services.rest Module. The
';/'3> module supports "asic ';/'3> transactions.
OpenMRS also provides a SM0RT container for SM0RT
applications.
Current
$nstallations
OpenMRS implementations e6ist in South 0frica&
5enya& R!anda& (esotho& Aim"a"!e& Mo#am"i@ue&
4ganda& Tan#ania& /aiti& ndia& %hina& 4nited States&
'a$istan& 'hilippines& Sri (an$a& ndonesia and many
other countries. 0 detailed list of implementation sites&
contact persons and appro6imate si#es can "e seen at
(http://openmrs.org/a"out/locations/)
%er&orance
Metrics
Matc'ing
algorit's
The OpenMRS 'atient Matching module is "uilt on the
.elligi7Sunter pro"a"ilistic matching algorithm.
Requirements
S
c
o
p
e
P
r
i
o
r
i
t
y
F
u
l
l
y

C
o
m
p
l
i
e
s
P
a
r
t
i
a
l
l
y

C
o
m
p
l
i
e
s
D
o
e
s

n
o
t

C
o
m
p
l
y
Notes + Further Information
1 Shared Health Records



Functional Requirements
1.1 Information Request
1.1.1 System must retrieve an appropriate record in response to a
request.
Y 1
1.1.2 System must validate the request location
N //Does not apply, removed. To be handled by
the Interoperability layer.
1.1.2 System must respond to time based and cohort queries
Y but I believe !e
a"reed this is part o#
the messa"in" N$T
the S%&
'

(e !ill be supportin" the queries de#ined here.

(e !ill not be supportin" )ohort *ased queries
#or the +hase 1 +ro,ect Implementation. -n
,6ample 4se %ase of a cohort
"ased @uery is : .rom the 'O%
perspective& if !e have a
scheduling solution in place for
0B% visits& !e could ma$e "atch
re@uests to pull do!n the latest
encounter data from the S/R some
time "efore the actual visit.
1.1.' System must identi#y ne!ly updated in#ormation
Y 1 Ne! in#ormation !ill be returned based on
messa"in" based requests
1.1.. System must have security rules to validate data request
N !e also
decided
there is
N$ /I so
this is not
applicable
1

0rom the interoperability 1ayer. 0or no!, !e2ll

be supportin" *asic -uthentication or similar
bet!een the interoperability layer and the S%&.
1.1.3 System must en#orce di##erent security requirements on
di##erent data
N see above 2

$pen4&S persists data as $bservations. (e

cannot en#orce restrictions #or only a "iven set
o# data.
-ny user !ho has permissions to vie!
observations may vie! all observations.
1.1.5 System must accommodate e6ternally de#ined roles, !hich
are equivalent to those in the +rovider &e"istry.
N 2

*asic &ole *ased Security !ill be supported

!hich $pen4&S currently provides.
1.1.7 System must maintain an audit lo" o# all in#ormation requests
!hether they are completed or not
Y 2

The -ccess 1o""in" module 8requires 1...9:

!ill allo! access lo""in" #or +atients and
;ncounters. %o!ever, there is no provision #or
uncompleted requests.
(e !ill ,ust lo" all communications !ith the
interoperbaility layer.
1.1.< System must provide an ac=no!led"ment #or each
in#ormation request. The ac=no!led"ement may be either a
success or error messa"e
Y 1

&e#er to Transaction speci#ications document #or

the responses !e have identi#ied.
).).? System must identi#y !hen a subset o# the available
in#ormation is returned due to insu##icient credentials etc.
N see above '

$pen4&S #avors to re,ect the entire request in

such an event>. There#ore. No such
identi#ication is made.
).).)CSystem must retrieve in#ormation in speci#ied a""re"ates or
domain speci#ic subsets
N not
needed to
support our
use case
'

0or the +hase 1 Implementation, !e !ill only be

supportin" the queries de#ined in the transaction
speci#ication !hich !ill be initiated #rom the
$pen4&S +$). -ny additional reportin" is out
o# scope.
1.1.11 System must e6port either the #ull set o# data #or a particular
patient, or a prede#ined subset based on user tri""ered
prede#ined subsets.
N '

(e !ill support all queries de#ined in the

transaction speci#ication document.
1. Information Stora!e
1.2.1 System must validate that patient, provider and location is
valid.
N
//Does not apply, removed. To be handled by the
interoperability layer
1.2.1 System must validate the content is usin" the appropriate
vocabulary.
N
//Does not apply, removed. To be handled by the
TS throu"h the interoperability layer.
1.2.1 System must be able to per#orm saves in an asynchronous
#ashion. 8via usb or a queue:.
Yes? 2

The /S* use case still needs to be de#ined

#urther.
1.2.2 System must retrieve both persistent 8e.". aller"ies: person and
encounter data 8based on security restrictions:
Y this !ill
have a lot
to do !ith
our data
model
2

-"ain, !e !ill support the de#ined queries in the

transaction speci#ication.
1.2.' Success#ul transactions must be ac=no!led"ed to ori"inatin"
system
Y 1

&e#er to Transaction speci#ications document #or

the responses !e have identi#ied.
).=.D System must store unsuccess#ul transaction data alon" !ith
reasons #or #ailure
y but could be
in an error
queue
1

The -ccess 1o" module is the closest contender

to support this #unctionality. %o!ever neither
this module records unsuccess#ul transaction
data.
).=.* In the event o# an unsuccess#ul transaction, the ori"inatin"
system must be noti#ied
Y 1

).=.E System must be able to correct/address any unsuccess#ul

transactions.
y but this
!ill li=ely
be
4-N/-1
at #irst
1

).=.8 System must be able to a""re"ate several episodes to"ether

8care composition:
y a"ain
"oes to
data model
'

-lthou"h !e can support this, !e do not have

speci#ic use cases #or our +hase 1
Implementation, besides returnin" multiple
encounters #or our messa"in" requests.
).=.? System must be able to create tri""er events #or clinical
decision support or alerts
Y li=ely
only 1 or
2 I !ill
tell you
!hat they
are
speci#ically
soon
1

$pen4&S uses -rden and the DSS module to

provide clinical decision support.
).=.)C System must be able to support all data types
y althou"h
lets discuss
photos I
thin= out
o# scope
but !e
need to
ma=e sure
!e don2t
build
somethin"
that does
not let us
add this
later
1

$pen4&S supports all data types #rom numbers

to Strin"s to concepts and te6t / ima"e #iles.
).=.)) System must process asynchronous requests in the order that
they !ere created, not the order !hich they !ere received.
y part o#
the interop
layer I
believe
(e a"reed at the pro,ect meetin" to process
messa"es in the S%& based on the ;ncounter
Date and not on the 4essa"e TimeStamp in
!hich it !as received.
1.3 Interface " Communication



1.'.1 System !ill not use the end user inter#ace Y
1.'.2 System data must be available #or reportin"
Y 1

)an be done usin" the &eportin" module,

+atient Summary module or the )linical
summary module
1.' ' System must record and version all data updates
Y 2

$pen4&S lets users lo" data chan"es usin" lo"s

or the -ccess 1o" module. In the event o#
updatin" data, $pen4&S retires the old ob,ect
and introduces a ne! one !ith the modi#ied
data, thus @versionin"2 the data.
1.'.. System must record the author o# each data chan"e
Y 1
1.'.3 In the event o# a data chan"e, the system must record a user
comment on the reason #or the chan"e
Y 1
1.( #usiness Rules
1...1 System must de#ine and implement business rules that are y to be 1 -s stated above, this can be done usin" -rden
tri""ered by the entry o# speci#ic data
de#ined 12
speci#ic
rules
and the DSS module
1.) Non$Functional Requirements
1.3.1 System must have a data recovery and bac=up solution
Y 1

In addition to the traditional 4ySA1 database

bac=up, $pen4&S also provides the Database
bac=up module, !hich allo!s users to include or
e6clude selected data #rom the bac=up process.
1.5.2 System must allo! #or real time updates
Y 1
1.5.' System must provide su##icient support documentation in
;n"lish
Y 1 ;6tensive !i=i documentation available
1.5.. System must be easily scalable to 8a minimum: o# double the
current +atient count in &!anda
Y 1
1.5.3 System must provide user restricted security to the S%&
con#i"uration
Y 1
1.5.5 System must ensure ma6imum possible uptime
Y 1
1.5.7 System must be able to support an 6 number o# concurrent
users
N- this is
immaterial
as the user
only
interacts
!ith the
+$)
system
1

//In the !orst case scenario, ho! much

concurrent users can !e e6pectB
1.5.< S%& database must support database chan"e mana"ement so
that database modi#ications can be made
Y

$pen4&S uses liquibase to support database

chan"e mana"ement
+riority
1. %i"h +riority C must be done as part o# &%;- pro,ect
2. 4edium
'. 1o!