Health IT and OpenMRS

Health IT and OpenMRS
An introduction
Tutorial at the OpenMRS Worldwide Summit
Dec 8th, 2015 - Singapore

What will we do in this tutorial?
• In this full-day tutorial, you will learn basic overview of electronic
medical records systems, health data management and how you can
use the OpenMRS system for data and information management.
• Terms in health information systems, electronic health records and
how the OpenMRS platform can meet (or not meet) you information
needs
• We will cover
– Requirements gathering before selecting OpenMRS
– OpenMRS Installation
– User management
– Location management
– Patient dashboards
– Showcasing some modules and customization (a preview of sorts for the

What you need to complete this tutorial
• An internet connected computer/device
• At least 4GB RAM and 1Ghz to install OpenMRS, with Linux, OSX or
Windows
• Elementary English language skills
• Elementary-level computer proficiency

Learning objectives
At the end of the tutorial, you should be able to:
1. Identify the non-technical factors that influence the adoption of
electronic medical record (EMR) system by clinicians and describe
strategies for promoting effective use of EMR systems.
2. Describe the processes of developing or selecting an EMR system,
preparing and supporting clinicians for system implementation, and
evaluating system effectiveness.
3. Describe the role of EMR systems and how they are used in different
health care settings.
4. Identify key features of OpenMRS platform and reference application,
such that they correlate with the health care setting
5. Install OpenMRS reference application for testing purposes
6. Understand privileges, roles, locations and learn how to manage them.

Learning objectives (cont’d)
7. Understand the difference between metadata and data in OpenMRS
8. Describe the OpenMRS data model and how information is modelled in
OpenMRS
9. Register a patient, create visits, capture vitals, capture visit notes,
diagnosis and other types of clinical information
10.Describe some health care settings in which the OpenMRS platform has
been customized and used

How will you learn these objectives?
• Are majority of these objectives in sync with your objectives to be
in this room?
• Pay attention to the speaker. Ask doubts while we are still on the
topic
• Participate in discussion,
when you see this icon next to a bullet point
• Do reflection internally,
• Do work on your laptop individually

Health data/information management

Information management
• A method of using technology to collect, process and condense
information with a goal of efficient management (Gartner).
• A cycle of organisational activity concerned with the acquisition of
information from one or more sources, the custodianship and the
distribution of that information to those who need it, and its
ultimate disposition through archiving or deletion (Wikipedia).
• In health care settings, the goal is providing care to the patient in
a way that is appropriate, safe and effective.
– Efficient and effective might have different meanings based on your health
care environment. Discuss some differences between the terms in your
health setting

Source: Association for Information and Image Management
http://www.aiim.org/What-is-Information-Management

Health data/information management
• Health information management (HIM) is the practice of acquiring,
analyzing and protecting digital and traditional medical
information vital to providing quality patient care (Wikipedia).
– Advocacy to use digital/electronic means for information management
• Referred to by different names:
– Health information systems
– Health informatics tools
– Health information technology
– …
• An inter-disciplinary field of
– Medicine and related health care services
– Computer science
– Management and library science

Why is health information management important?
• The World Health Organization (WHO) stated that the proper
collection, management and use of information within healthcare
systems “will determine the system’s effectiveness in detecting
health problems, defining priorities, identifying innovative
solutions and allocating resources to improve health outcomes.
(Stansfield, 2005)
Institute of Healthcare Improvement
1) Improving the patient experience of care
(including quality and satisfaction);
2) Improving the health of populations; and
3) Reducing the per capita cost of health care.
Not just for resource-rich environments, but more
important for low-resource environments because
the limited resources need to be distributed
appropriately with most effectiveness
All of these goals have information availability and
information use at the core.

More than patient records
• To meet those goals, Health information systems need to manage than
health records. They range from process-related systems like:
– Logistics systems (like OpenBoxes)
– Billing systems
– Ordering/acquisition systems (beyond patient) (like OpenERP/Odoo)
• To strategic and management related systems like:
– Health management information systems (HMIS like DHIS2)
– Strategic information systems
– Simulation systems
• Our focus in this community is health data systems. OpenMRS is
designed with a patient-centric approach. This is different from a
process-centric approach, which is adopted by many health

Needs for health information are
different at different levels
Source: Braa et al. (2007), Hierarchy of standards

Electronic health records (EHR)
Take a break of 10mins

Electronic health record
• Electronic health record (EHR) refers to the systematized collection of
patient and population electronically-stored health information in a
digital format (Wikipedia).
• Electronic medical record (EMR) systems, defined as "an electronic
record of health-related information on an individual that can be
created, gathered, managed, and consulted by authorized clinicians
and staff within one health care organization“ (Agency of Healthcare
Research and Quality).
• These systems can facilitate workflow and improve the quality of
patient care and patient safety (AHRQ).
• The process to computerize patient medical records has been going on
for the last 30 years
• These range from single-practice records to large hospitals to entire

Electronic health record (cont’d)
• These have been referred to with multiple names:
– electronic medical records (EMR)
– computerized medical records
– longitudinal patient records
– electronic charts
• Different from Health information exchanges (HIE), but HIEs exchange
electronic health records between EHR systems
• An early contributor to EHR - computer based patient record institute
(CPRI) suggested the following characteristics of EHRs:
– Capture data at point of care
– Integrate data from multiple sources
– Provide decision support

Do clinicians really want EHRs?
• At least in the USA, large-scale EHR adoption is fairly recent. The factors
for adoption are shown below:
• According to a Bloomberg News report
from 2015, the top 10 countries with
the highest EHR adoption rates are:
– Norway (98%)
– Netherlands (98%)
– United Kingdom (97%)
– New Zealand (97%)
– Australia (92%)
– Germany (82%)
– United States (69%)
– France (67%)
– Canada (56%)
– Switzerland (41%)
Source: Office of National Coordinator (ONC). 2013

What are the benefits for EHR use?
• Providers who have adopted EHRs, report the
following benefits:
– Accurate and complete information about a
patient's health. This enables providers to
give the best possible care, whether during
a routine office visit or in a medical
emergency
– The ability to quickly provide care. In a
crisis, EHRs provide instant access to
information about a patient's medical
history, allergies, and medications.
– The ability to better coordinate the care
they give. This is especially important if a
patient has a serious or chronic medical
condition, such as diabetes.
– A way to share information with patients
and their family caregivers. This means
patients and their families can more fully
Source: Jamoom et al. (2011)

Barriers to EHR adoption
• While the benefits of EHRs are both care-related and efficiency-
related, the following are barriers to EHR adoption:
Source: Ajami & Bagheri-Tadi, 2013
• Time – limited physician time
• Cost – in owning/maintaining
• Absence of computer skill
• Workflow disruption
• Concern about security and
privacy
• Communication among users
• Interfaces with doctor-patient
relationship
• Lack of incentives
• Complexity and UI challenges
• Technical support
• Interoperability
• Vendor trust
• Concern about data entry

Core functions of an EHR
• IOM (Institute of medicine) puts forth 8 core functions:
1. Health information and data
2. Result management
3. Order management
4. Decision support
5. Electronic communication and connectivity
6. Patient support
7. Administrative processes and reporting
8. Reporting and population health

Where OpenMRS fits best?
• OpenMRS is a patient-centric application, meaning data is captured
about interactions between a health care provider and a patient.
• Your main information needs should also focus on direct patient care. If
you primarily intend to capture data about something other than the
patient (for example, about lab specimens), you should consider other
alternatives.
• OpenMRS is designed to manage patient data longitudinally, linking
multiple interactions over time into a single patient chart.
• If you only care about individual patient visits, and not about linking
those together into a longitudinal chart, then OpenMRS may not be the
right tool for you.
• There are EHR components like PACS (Picture archiving systems) or Lab
Information Systems, or Pharmacy management systems. Depending on

OpenMRS platform (also referred to as Core)
• The OpenMRS Platform is the shared platform upon which all distributions of
OpenMRS are based.
• Its goal is to be a minimal Java (a programming language) and RESTful (the
design pattern of HTTP and the internet) services that developers can use to
build their own clinical data applications. It does not aim to provide a user
interface (UI) or application itself
• Developers can use the OpenMRS Platform to a build a separate application
that uses OpenMRS as a RESTful clinical data store. Developers can use the
OpenMRS Platform to build a Java server-side web application.
• Implementers can use the OpenMRS Platform and the legacy UI (with the
addition of common community-supported add-on modules like the HTML
Form Entry module or the XForms Module) to build an EMR for retrospective
data entry.
• Upto v1.12, the legacy UI was provided in the platform. From v2.0 of the
platform, no UI is provided. The legacyui module can be installed to get the 1.x

OpenMRS documentation (OpenMRS Wiki)

OpenMRS distributions
• OpenMRS is a flexible, modular, multi-layered system, and one of its
strengths is that its platform can be used in many different
configurations
• To implement an OpenMRS system, you typically start from an
existing OpenMRS Distribution, and configure that distribution for
your implementation use case..
• Depending on which distribution you choose, and what your use case
is, this may range from:
– configuring metadata through a UI
– to writing custom add-on modules,
– or your own custom UI backed by OpenMRS REST web services.
• Implementations with strong development teams may choose to build
their own custom application(s) on top of the Platform

OpenMRS reference application
• The OpenMRS reference application is a sample EMR application
running atop the OpenMRS API.
• OpenMRS has always had a web application component; however, the
web application focused primarily on basic administrative features and
lacked most content, leaving it up to modules and administrators to
provide EMR functionality and content.
• The Reference Application, on the other hand, strives to provide more
of a starter set of content along with basic EMR functionality (e.g.,
registration, basic reports, etc.).
• The Reference Application comprises a handful of modules that run
within the Java web application and provides a Groovy (a scripting
language)-based framework for web development.
• In community lingo, you’ll hear this distribution referred to as

OpenMRS reference application (cont’d)
• The RefApp distribution demonstrates how the OpenMRS platform can
be used to build a facility EMR, and it is where the community
develops starter sets of metadata and terminology.
• The RefApp is a good starting point for implementing OpenMRS in a
facility, and it intends to eventually be a full-featured EMR system, but
it is dependent on distributed volunteer efforts, and hasn't yet
achieved that goal.
• This distribution does not intend to cover the entire Hospital
Information System use case, e.g. we won't cover billing or pharmacy
stock management.
• In this tutorial, we use the Reference application as a starter EMR on
which you will be able to explore the different features provided by
OpenMRS.

Readiness assessment
• The assessment should look at the current state of your health system:
– Are administrative processes organized, efficient, and well documented?
– Are clinical workflows efficient, clearly mapped out, and understood by all staff?
– Are data collection and reporting processes well established and documented?
– Are staff members computer literate and comfortable with information technology?
– Does the health system have access to technology resources like internet
connectivity, hardware/software upgrade plan?
– Does the health system have access to the financial capital required to purchase
new or additional hardware?
– Are there clinical priorities or needs that should be addressed?
– Does the practice have specialty specific requirements?
Source: healthit.gov

Setting “SMART” Goals
• You should set “SMART” goals during your readiness assessment. Goals
should be:
• Specific – Achieving the goal would make a difference for our patients
and our organization.
• Measureable – We can quantify the current level and the target goal.
• Attainable – Although the goal may be a stretch, we can achieve it.
• Relevant – The goal is worth the effort.
• Time bound – There are deadlines and opportunities to celebrate
success!

Your organizational goals and practice
• For now, forget about technology and instead think about your
organizational goals and processes. Here's a list of questions to start:
• What are the high level goals of your organization?
• What are the teams and staff in the clinic? What roles exists? What
functions does each role perform?
• What tasks are staff involved with on a day to day basis?
• What services does the clinic provide to your patients? What activities are
involved?
• What other 3rd-party or government organizations do you report to? What
information is included in each of these reports?
• Answering these questions will probably help you think of more related
questions. Make sure you consider them thoroughly.

Outcome of readiness assessment
• Critical outcomes of the assessment process include:
• A designated leadership team for the EHR implementation process
(clinical and practice management staff, or for small practices, the
entire team). Having strong and positive advocate(s) for change can be
one of the strongest tools to guide the transition.
• A unified vision, where each member of the practice team understands
how they will be affected by the change and understands the roadmap
to success.
• Measureable, quantifiable, realistic goals, which are the key to the
assessment phase

Planning phase for EHR
implementation

Map your needs to OpenMRS
• OpenMRS has been designed to be flexible and adaptable, based on
input from many different partners, but it may not be an exact fit for
the ways that your organization currently works.
• Doing things the "OpenMRS way" could mean adapting your workflow
and adopting best practices in medical informatics.
• Be pragmatic and flexible, and think about whether your current
working practices might need to change.
• Remember that OpenMRS offers many opportunities to capture and
analyze information in new ways not previously possible.
• Taking advantage of these new possibilities might possibly lead to
positive changes and improvements for your organization.

Do not "reinvent the wheel"
• The open source ethos of OpenMRS extends beyond just the
application, to a much larger open community where ideas and
experiences are shared. There are many existing resources available in
the form of pre-built OpenMRS features (modules)
• Reuse an existing concept dictionary
• A well-constructed, mature concept dictionary (we’ll learn about this
later) is a strong foundation for any OpenMRS Implementation.
• The CIEL dictionary and Maternal Concept Lab (MCL) maintains a well
curated concept dictionary. If this dictionary is applicable to your
domain of care, we strongly recommend that you consider using it.
• Other OpenMRS implementers can also help advise you about other
concept references for your domain.

Do not "reinvent the wheel“ (cont’d)
• Adapt existing forms
• Implementers should evaluate data collection forms built by other
OpenMRS users before creating new custom forms for their specific
needs.
• Implementers across the OpenMRS community have invested a lot of
resources in ensuring that their forms reflect clinical best practices,
international standards, and current research. These forms have
already been optimized for electronic data entry.
• Many OpenMRS partners develop forms using medical informatics
experts that may not be available to all projects
• Creating forms is time consuming - those resources could be
redirected to other efforts.
• The OpenMRS Form Bank is a new community-driven project which is

Steps of the planning phase
1. Analyze and map out the practice’s current workflow and processes of how the
practice currently gets work done (the current state).
2. Map out how EHRs will enable desired workflows and processes, creating new
workflow patterns to improve inefficiency or duplicative processes (the future state).
3. Create a contingency plan – or back-up plan – to combat issues that may arise
throughout the implementation process.
4. Create a project plan for transitioning from paper to EHRs, and appoint someone to
manage the project plan.
5. Establish a chart abstraction plan, a means to convert or transform, information
from paper charts to electronic charts. Identify specific data elements that will need
to be entered into the new EHR and if there are items that will be scanned.
6. Understand what data elements may be migrated from your old system to your new
one, such as patient demographics or provider schedule information. Sometimes,
being selective with which data or how much data you want to migrate can influence
the ease of transition.

Steps of the planning phase (cont’d)
7. Identify concerns and obstacles regarding privacy and security and create a plan to
address them. It is essential to emphasize the importance of privacy and security
when transitioning to EHRs.

Common errors
in EHR
implementation
closely related to
planning

ONC’s EHR
evaluation matrix
https://www.healthit.gov/sites/default/fi
les/vendor_evaluation_matrix_tool_v1.0_
0.xlsx

Project team planning
Your EHR implementation team should include clinic staff:
• Management are aware of funding obligations and 3rd party reporting requirements.
• Health care providers are focused on improving patient care.
• Administrative staff are specialists of workflow issues and clinic processes.
The team could also include the following people that may or may not be from the clinic:
• A system administrator is in charge of installing and maintaining OpenMRS inside of the
clinic's ICT infrastructure.
• Medical informatics expert(s) create clinical documentation and ensure that data is
managed properly in the system. Develop reports.
• (Optional) A project manager or coordinator. For larger implementations, this person
works to hold people accountable to finishing their work in a timely manner, and
ensures the project is on track.
• (Optional) Software developers may be needed for locations that decide to customize
the system.

OpenMRS key features

OpenMRS implementations around the world

1. Central Concept Dictionary: Definitions of all data (both questions and answers) are
defined in a centralized dictionary, allowing for robust, coded data which can be
terminologies like ICD-10, SNOMED, LOINC, RxNorm etc.
2. Security: User authentication with complex password support. Support for roles,
privileges to separate what user can and cannot do. Users can also login through a
for centralized enterprise authentication.
3. Patient Repository: Creation and maintenance of patient data, including
demographics, clinical observations, encounter data, orders, etc.
4. Multiple identifiers per patient: A single patient may have single or multiple identifier
numbers like passport number, national id, medical record number etc.
5. Flexible Data entry: With the FormEntry module, clients with InfoPath (included in
Microsoft Office 2003 and later) can design and enter data using flexible, electronic
FormEntry module, forms can be created with customized HTML and run directly
XForms module, users have a drag-drop interface to design forms that can then be
OpenMRS top-ten features

6. Data export: Data can be exported into a spreadsheet format for use in other tools
(Excel, Access, etc.), including aggregation HMIS systems like DHIS2.
7. Modular architecture: An OpenMRS Module can extend and add any type of
functionality to the existing API and web application. 200+ available modules.
8. Support for complex data: Radiology images, sound files, etc. can be stored as
“complex” observations
9. Cohort management: The cohort builder allows you to create groups of patients that
match a “criteria” for data exports, reporting, analysis etc.
10. Localization / internationalization: Multiple language support and the possibility to
extend to other languages with full UTF-8 support.
OpenMRS top-ten features (cont’d)

https://www.youtube.com/watch?v=Fvc__rmS7lk
OpenMRS: history of 10 years

People are using the
OpenMRS platform for all
sorts of things.

OpenMRS forms for WHO HIV Treatment

Chart of a
patient’s lab
results

Disease-specific
EMR (MDR-TB)
Credit: WHO-TB and PIH

Inpatient Care
Credit: Andrey Kozhushkov,
Ghislain Kouematchoua (Göttingen)

Registration Module with fingerprint and patient image
Credit: HISP India

Research Data Coordination
Credit:
Dave Thomas

Adaptive Turnaround Documents
Credit: Vibha Anand,
Paul Biondich (Regenstrief)

Eligibility Across Institutions
Credit: Monica Waggoner

Google Maps Integration Credit: IRD
Owais Ahmed, Aamir Khan

ID Cards and Barcodes Credit: Brian Mckown (AMPATH)

“Mateme” Touchscreen Registration
Credit: Jeff Rafter (Baobab), Evan Waters (PIH)

iPhone App
Credit: Rowan Seymour
& Parker Erway

Notifiable Condition Detector
Credit: Shaun Grannis,
Regenstrief Institute

Health Data Exchange
Credit:
Odysseas Pentakalos

1. OpenMRS Standalone - OpenMRS Standalone provides a simplified, all-inclusive
installation option with both an embedded database and web server. You can have a
running within minutes: simply download and expand the archive, and then run the
standalone.jar file. Your browser will open a new instance of the OpenMRS system.
"admin" and the default password is "Admin123".
2. OpenMRS Platform - Recommended for advanced users using OpenMRS 2.x or
Platform in production. Requires an existing Java servlet container such as Apache
database such as MySQL.
3. OpenMRS Reference application – The reference application download is a zip archive
which includes the platform war (webapplication archive) and OpenMRS addon
(omod files).
Choosing which OpenMRS to install

1. Web browser – Since the OpenMRS reference application is a web application, you will
need a web browser to install and use OpenMRS. Mozilla Firefox or Chrome are the
2. Java is the platform on which OpenMRS has been programmed. OpenMRS platform
since v2.0 requires Java 8. The reference application till v2.3 can run on Java 7 since
Later releases that use platform v2.0 will require Java 8. Due to backwards
versions of OpenMRS too.
3. MySQL 5.6 is recommended as the database management system (DBMS). Due to the
use of Hibernate (a database abstraction library), OpenMRS is also supposed to work
fork), PostgreSQL and MS SQL server. But these other DBMS have not been tested to
application.
4. Apache Tomcat – a Java servlet container to run web applications. OpenMRS has been
deployed on Jboss and Glassfish previously, but the reference application has not
other Java application servers.
Install dependencies

• OpenMRS works on Sun/Oracle Java or OpenJDK. It has not been tested with other Java virtual
machines such as JRockit or IBM J9
• Java installation instructions can be found here:
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
• The webupd8 has a popular ppa that is used in Ubuntu. See here:
http://www.webupd8.org/2012/01/install-oracle-java-jdk-7-in-ubuntu-via.html
• Once Java 7 is installed, configure the JAVA_OPTS environment variable to allocate adequate
heap memory as well as PermSize variable.
JAVA_OPTS="-Xms512m –Xmx1024m –XX:MaxPermSize=256m" (Sets the heap min size and max size)
• In linux, set this in /etc/environment or .bashrc file
• In Windows, control panel  System  Advanced system settings  Environment variables  New (under user
variables)  variable name: JAVA_OPTS and value provided above
Java Download and installation

• The OpenMRS reference application downloads can be found here:
http://openmrs.org/download/
• Choose the OpenMRS Standalone download for now.
https://sourceforge.net/projects/openmrs/files/releases/OpenMRS_2.3.1/openmrs-standalone-2.3.1.zip/download
• In this tutorial we will also show you provide you information for more advanced installation. You
can use this for extending OpenMRS tutorial.
• After the above download completes, please extract all files. Here you will see openmrs-
standalone.jar. If you double-click on this, it should start Java and start deploying OpenMRS. The
deploying OpenMRS. The browser will open once OpenMRS is ready to be used
OpenMRS download

Starting OpenMRS standalone
You will see a screen once
you start the standalone
Choose the
Demonstration mode,
because we want demo
data and the starter
dictionary that is part of
the reference application.

Allow ports to communicate with MySQL
The 2.x standalone uses Tomcat on port
8081 and MySQL on port 3316. These are not
the default ports of Tomcat and MySQL
deliberately, so that there is no conflict with
existing installations
You can run the standalone side-by-side with
the platform or more advanced installation by
using the individual components, as shown in
the slides later.

OpenMRS Standalone configuration options
Tomcat Port This is the port at which to run Tomcat
MySQL Port This is the port at which to run MySQL
File → Quit This stops Tomcat and MySQL and then closes the
File → Launch Browser This opens the OpenMRS login page for the current web
File → Clear Output This clears the output log in the user interface text area,
log file written on the file system
Start
This button runs Tomcat, which will automatically start the
engine if it was not already running. For the embedded
connection automatically starts the MySQL engine
Stop This button stops Tomcat and then also stops the MySQL
without closing the application

OpenMRS Starts with Login
• Browser should start with OpenMRS 2.x login page.
• If there is any error, you will see a different screen along with the error
message. The error message is also known as Exception. Remember to
report error messages with the error log (the box which showed
OpenMRS starting).
• Username: admin
• Password: Admin123
• Remember that a
Location must be
Selected or else the
Login button will not be
activated

Administering OpenMRS
Lunch break here

OpenMRS Apps page
• After successful login, you will see the navBar  the top black bar,
showing username, Location for the session and Logout
• The list of apps are the ones that are available. Depending on the user
privileges and roles, the available list of apps can be changed. Since
everyone now logged in as admin, you’ll see all apps.
• When you click on any app, you will see the path to that app in
breadcrumb, like shown on the right screen. You can click the home icon
to come back.

OpenMRS Administration page
• The Administration page can be
reached from:
Administration  System
administration
• The Administration page still uses
the Legacy UI and thus, has a
different look-and-feel. This is in
the process of being moved to the
new 2.x UI
• Understand the difference between
legacyUI and 2.x UI by recalling the
architecture diagram from earlier.

OpenMRS Roles and Privileges
• Roles and Privileges are controlled through the Administration page, under
the Manage Users section.
• OpenMRS uses privileges and roles to control access to data within the system.
Privileges define what can or cannot be done in the system (e.g., Edit Patients or Add
Users) while roles are used to group privileges into more manageable groupings.
• We will use this example: you are working with several privileges related to patient
data - e.g., View Patients, Edit Patients, and Add Patients. The View Patients privilege
lets users look at patients in the system, the Edit Patients privilege lets users edit
information about existing patients, and the Add Patients privilege allows users to
create a completely new patient record within the system.
• Now imagine that you need to assign the proper rules to three people: Mary the
Medical Student, Bob the Data Assistant, and Erica the Data Manager. You want
medical students to be able to view patients, but not edit or add them. Data assistants
should be able to not only view, but also edit patient data. And you want your data
managers to be able to create new patients within your system

OpenMRS Roles and Privileges (2)
• Very often, certain roles can be defined as a combination of other roles. In our
example, a Data Manager oversees the Data Assistants and therefore should have all
of their privileges plus some additional privileges. So, let's redesign our roles slightly
to show how this might work.
• You can see that the Data Manager role can be more clearly defined as a Data
Assistant with the extra ability to add patients to the system.
Role
Inherit
Privileges
from
Role(s)
Additional
Privilege(s)
Medical Student View Patient
Data Assistant
View Patient
Edit Patient
Data Manager
Data
Assistant
Add Patient
• In addition, if you should change or enhance the
privileges of the Data Assistant role at any time in
the future, the Data Manager will automatically
adapt to those changes.
• E.g. if you decided a month later to allow any Data
Assistant to Edit Encounters (by adding the Edit
Encounters privilege to the Data Assistant role),
the Data Manager role would automatically gain the
ability to edit encounters as well.

OpenMRS Built-in roles
• There are some special roles that are predefined within OpenMRS and cannot be
deleted: Anonymous, Authenticated, and System Developer.
• Any privileges granted to the Anonymous role will be available to people without
logging into the system. Generally, Anonymous privileges should be kept very
restricted, since patient information might otherwise be compromised.
• Privileges granted to the Authenticated role
are granted to anyone that logs into your
system, no matter what other role(s) they
might be assigned. Granting privileges to
Authenticated role is an easy way to grant
privileges to all users of the system.
• The System Developer role is automatically
granted full access to the system and should
only be granted to system administrators.
• The roles with Application: (prefix) and
Organizational: (prefix) are UI 2.x roles

Adding new roles
• If you then follow the Add Role link, you will see a form for adding a new role.
– Enter Role Name
– Choose Roles Privileges of which you want to inherit
– Choose Privileges which you want this Role to have
• The privileges are made available by pages in
add-on modules
• This is specified as part of the config.xml in
the OpenMRS module source code. You will
learn more detail about this in the Extending
OpenMRS… tutorial
• Go ahead and create the Medical Student role,
which will have inherited Application:
Registers Patients, App: coreapps.findPatient.
• Then, save the Role.

Manage users
• To create these users, we'll go through Administration > Manage Users. This page
also lets you find and edit existing users.
– Create a new User
– Search Users by Name or Roles
– Edit a single Use
• Users in OpenMRS need to be associated with
Persons. You either need to create a new
Person, or attach the user account to an
existing one
• Go ahead and create new Person, give your
first, last name and gender, you date of birth
and create the person. This person will then
be given the Medical Student role that you
created in the earlier slides. See next screen

Add user
• Provide the username with which the user
will login and type password twice.
• The following global properties (we’ll show
you later) will let you configure the
complexity of your password (default values
below):
– security.passwordCannotMatchUsername = true
– security.passwordMinimumLength = 8
– security.passwordRequiresDigit = true
– security.passwordRequiresNonDigit = true
– security.passwordRequiresUpperAndLowerCase =
true
• You can also checkbox for the user to set
their own password after first login
• Checkbox the Medical student role that you

Doing System settings using global properties
• Go to Administration  Settings to work with global properties. The UI is divided into
global properties based on each module
• Each add-on module exposes a set of settings that can be configured to show the
system setting. Remember that these settings are system-wide and not per-user. Thus,
it affects all the users that have access to the module
• Be very careful to change these
settings because there is no way to
undo the changes.
• Global properties are not voided or
backed up when they are changed.

Logging in as Medical student
• Press logout from the top right link.
• Login as the medical student username and password that you just created. You will see
that there are only 3 apps available to this user now.
• We next move to clinical management functions. We first need to understand how
OpenMRS stores patient information. So lets get back to the conceptual level from the
hands on work that we have been doing.

• While OpenMRS has a nearly 1:1 relationship between Entities and database tables, this is not
necessarily the most efficient way to design APIs.
• Yet, it is something that makes it easier for newcomers to understand and comprehend (and then
contribute code) to OpenMRS.
• This means that for nearly every OpenMRS object, there is a linked table that has similar
properties that represent the column names of the tables.
• So for the Person entity, there is a Person table. For the User entity, there is a User table.
Similarly, there is for Patient, Encounter, Obs etc.
• Please open the below link and zoom into the diagram. It is large in size and you can look at the
complex relationship between the tables, shown using the interconnected lines.
• https://wiki.openmrs.org/display/docs/Data+Model?preview=/589829/34374263/openmrs_data_model_1.9.0.png
Database tables

• When you zoom into the image, you’ll see sectional blocks in them. These are different domains
within the data model.
– Concept: Concepts are defined and used to support coded data throughout the system
system
– Encounter: Contains the meta-data regarding providers interventions with a patient.
– Form: Essentially, the user interface description for the various components of a form.
Domains in the data model

• Look here in more details at the OpenMRS data model
http://burkeware.com/openmrs-data-model/
Exploring the OpenMRS data model

• The actual information you want to record in OpenMRS is called Data. Examples of Data in OpenMRS are Patients,
Encounters, and Observations. To support this data, and describe its meaning, you need additional Metadata.
Data
• When a user deletes a piece of data in OpenMRS, the information actually remains in the database. It is marked as
voided, so that it will not show up in the interface, but it is not immediately deleted from the database.
Data and Metadata

• An administrator may also retire metadata in OpenMRS. This does not mean that the metadata is deleted, but rather
that it is not intended to be used going forwards. Old information that refers to the retired metadata remains valid.
• An administrator may unretire metadata if it becomes relevant to active use again. If no actual data refers to a piece
of metadata, an administrator may purge the metadata to permanently remove it from the database.
• For example, the hospital you refer patients to closes. Therefore, you can no longer refer patients there. This
Location can now be retired in OpenMRS. This would not invalidate the fact that many patients were referred there in
the past.
• Thus, whenever you see retired or retired_by columns in the tables, it means that it is metadata related table, where
as when you see voided or voided_by in the tables, it means that it is data table.
Data and Metadata (cont’d)

• The OpenMRS concept dictionary is the central knowledge base of medical as well as non-medical/program-
related terms that need to be captured.
• E.g. suppose we want to capture the patient vitals after a patient has been registered at a clinic. We want to define
all the terms that should be captured in Vitals. i.e. Height, weight, systolic blood pressure, diastolic blood pressure
etc.
• Each of these need to be defined as a CONCEPT in OpenMRS and concepts are managed through the concept
dictionary.
• If you want to ask a question that has a fixed set of coded answers, those answers are also Concepts. (For
example, the question concept Blood Type may have 4 different answer concepts: A, B, AB, and O)
• To understand what medical terms (Concepts) are available in your dictionary, let us look at the reference
application’s pre-installed concept dictionary now
• More details about this is covered in the Manage concept dictionary tutorial
Concept dictionary

•Once you’ve successfully logged in you will see a number of apps like Find patient record,
Active Visits etc.
•Press the System administration and then go to Advanced Administration
•Here you will be able to see the legacy UI of OpenMRS. What you were using till now was the
new OpenMRS 2.x reference UI
Viewing the Concept dictionary

•Click on the Dictionary link in the header bar. This shows the UI for concept management.
•DO NOT download the concept dictionary.
•You can search for the same concept ‘systolic’ in the OpenMRS concept dictionary. You will see
two results. Click on systolic blood pressure.
Viewing the Concept dictionary (2)

•A good thing to do for interoperability and linking with other providers that may use OpenMRS
or other EMR systems, is to be able to use standardized terminology like ICD, SNOMED or
RxNorm.
•As we saw earlier, the MCL allows you to look at shared concepts. Please open MCL and
search for the terms and compare “Systolic blood pressure”.
•Edit you local concept if you’d
like to make your
Implementation interoperable
with others.
Correlating this concept with MCL

• Every individual who is referred to in any patient's record in OpenMRS must be stored in the system as a Person.
Most persons will also be Patients or Users.
Names
• A person can have one or more names, one of which must be marked as the preferred name. The preferred name
will be displayed in search results and patient screens.
Addresses
• A person may have zero or more contact addresses. You may configure the format of these addresses for your
particular locale.
Person Attributes
• To support your local needs, you can define additional pieces of information about the people in your system, on top
of those that are natively supported by OpenMRS. You can define the datatype of a Person Attribute, as well as any
constraints on the possible values, using metadata. This metadata is called a Person Attribute Type.
• Person Attributes are suitable for storing other information. But historical values of person attributes are not retained.
For example, you should use a person attribute to record a patient's contact telephone number.
Person

• Anyone who receives care in OpenMRS must be a Patient (for example, anyone who has an Encounter or who is
enrolled in a Program). Every Patient must have at least one Identifier, which is explained below.
• A Patient is also a Person, meaning they must have at least one name and they may have addresses.
Patient Identifier
• The Patient Identifier is a medical record number assigned by your facility, used to identify and re-identify the patient
on subsequent visits.
• A Patient Identifier Type defines the format of a particular kind of patient identifier. For example, you might define
that your facility patient ID is an identifier type that is required for every patient; the format is 2 letters followed by 6
digits and uses a particular check digit1 algorithm.
Patient

• A Visit in OpenMRS represents exactly what it sounds like: a time period when a patient is actively interacting with
the healthcare system, typically at a location
• The metadata differentiating different types of visits is a Visit Type. Visit Types are displayed in the user interface,
and can be searched against.
• A visit contains Encounters, which store more granular data about treatments or services.
• A patient may receive several kinds of care and services while at a health clinic. For example, they may see a
clinician, have an X-ray taken, and be given a lab test. Each of these services is an Encounter, recorded in a form.
OpenMRS uses Visits to collect these related encounters into one group
• Visits are managed in Administration > Visits. Here you can define the kinds of visits and their attributes, and set the
default behaviour for how visits are created.
Visits and Encounters

• Manage Visit Types:
A Visit Type is a name and description of a kind of visit. Every visit has a type. You
how your health site classifies visits, such as "Outpatient", "Hospitalization", "Dental",
• Manage Visit Attribute Types:
If you wish to record extra information about visits, you can create Visit Attributes and
example, you might create attributes for "Followup Visit,"or "Distance Patient Traveled".
Visits Types

• Visit is enabled by default, but is an optional feature. While Visit is enabled, the patient dashboard will show a tab
called Visits and group all encounters by visit. If disabled, the patient dashboard will show the Encounters tab and list
encounters chronologically with no grouping.
• A visit has a start time and an end time. The start date and time is automatically set when a visit is created. The end
date and time is left blank by default. It is set manually by a data clerk
• The Start auto close visits task option changes this. If enabled, auto-close will automatically set the end date to the
start date, and the end time to 23:59.
Visits Configuration

What is an encounter?
• A patient visits a health center or hospital. For each electronic form completed for a
created.
• Each encounter has a unique encounter_id and encounter_type. Forms could be
departments/location (ie. drug pickup, visit to HIV clinic), and will have an associated
Regimen Pickup, Adult intake, food assistance, lab test, etc). Each encounter has an
location and provider.
What is an observation (obs)?
Within an encounter, different observations (aka obs) are recorded. Obs_ids are unique
unique obs_id is generated for every obs. These are possible scenarios:
• One visit with one encounter without observations
• One visit with one encounter with one observation
• One visit with one encounter and many observations
• One visit with multiple encounters and many observations
Encounters and Obs

Reference app – clinical workflows

• Data is recorded in an EMR for a patient, so creating a patient is the first task to record data. Press the Home button
and you’ll go back to 2.x UI
• Press the Register a patient button. Create a patient with your details.
• After filling the details, press the Confirm button to save the patient.
• You can configure the fields based on Person attributes
Register a patient

• Press the Find Patient Record button at the home page
• You can search a patient based on their name, or patient identifier. There have been deployments on OpenMRS that
use barcodes of patient identifiers. These can be read directly into these fields just like keyboard typing. Type John in
the field
• Click on Betty Johnson from the list of existing patients to go to their patient dashboard.
Find a patient and go to patient dashboard

• The top most section of the dashboard shows Patient name, date of birth and identifiers. This can be customized
through modules or global properties
• The patient dashboard lists all the forms that are available, under the General actions section. You will also see
DIAGNOSES, RECENT VISITS, ALLERGIES, VITALS, APPOINTMENTS
• You can add data by either selecting General Actions or selecting a visit or the edit icon on the sections. Click on the
start visit to create a new visit for the patient. Press confirm and
select the Capture Vitals from the actions
that can done in the Current visit
Using the Patient dashboard

• The vitals is an example form. You could create many such forms that are important to your clinical setting. This can
be learnt in detail in the extending and customizing OpenMRS tutorial.
• Recall from the data model, that the Form is nothing but a view or bundling of the fields (that have underlying
Concepts) into a user interface.
• There are multiple form
technologies that are available
in OpenMRS. These types of forms
are generally developed using the
HTMLFormEntry module.
• Once you’ve captured all the
Vitals, save the form. An encounter
is created with the obs for this
patient.
Capture patient vitals

• Charts are important decision making tools for
clinicians. These are used to look at
observations over a period of time and monitor
changes in the obs values.
• You can return to the patient dashboard, by
click on the name of the patient from the
breadcrumb. Under General Actions click on
the Chart Search link.
• Once you see the chart search interface, click
on the QuickSearch link. This will display all the
observations for the patient. Scroll down from
the left list and click on Weight. You will see a
chart for the weight across different visits for
the patient
Charting the vitals

• One of the primary tasks that clinician perform during a patient visit is to capture visit notes.
• Click on a visit from the list of visits shown on the patient dashboard or the Current visit actions, if this is for the current
visit  Visit note.
• Here you can select the Primary and secondary diagnosis, which are coded values into the note. This is configured
using the global property - emr.concept.diagnosisSetOfSets
Capturing visit notes
• The clinical note section is free-text that can be
written to capture unstructed notes about the
patient visit.
• There are certain modules that can be used to
analyze the information stored in unstructured
clinical notes.
• Implementers need to make a balanced choice
between using structured or unstructured data
fields in the patient records

• There are other workflows. Demonstrate these:
– Capture allergies
– Schedule appointments
– Create programs
– Create program states
– Create orders (through the LegacyUI interface)
– Look at existing patient orders
– Difference between drug orders (drug concept) and other kinds of orders
• There are other types of clinical workflows that are not in the reference application. We will discuss this in the use-case
section of the tutorials
Going through other workflows

OpenMRS advanced
installation
If time permits at the end

• Instructions to install MySQL 5.5 for different
platforms can be found here:
http://dev.mysql.com/doc/refman/5.5/en/installing.
html
• Most real-world installations for large scale
MySQL happen on Linux/Ubuntu servers using
the command.
$ sudo apt-get install mysql-server
• You can either install on your local Windows or
Mac OSX using the binary installer (sorry, Chrome
OS users)
http://dev.mysql.com/downloads/mysql/
MySQL server installation
MySQL is an open-source database system, which
means the source code is available for people to
modify, change, rebuild and sell… all free of cost
Here you see the GNU GPL v2 license that is a popular
open-source license.

• The developer default installs a system that’s
appropriate for developers and testing. It installs
the server, workbench and connectors to different
programming languages
• In production i.e. real server, you want to install to
Server only option
Selecting installation type

Summary of what is to be installed

MySQL server configuration
• While the installation happens, you can get to the configuration step. Configuration can also be
done once the installation is complete and people have started using the database server.
• The port number is the location through which the database will be connected by external users
or programs. By default this port is 3306

MySQL server configuration (2)
• The main database user is called root. This user is installed by default and this password is crucial to
remember. The root user has privileges to all the database tables, so this user should never be used
other than DBA tasks
• The password for root user is set in this installation screen. You can also create other non-privileged
users by pressing the “Add User” button

• Installing MySQL as a service, means that the database system will start along with the system
startup. Here you can configure the name of the service and whether the database service should
start on system startup

• Logs are important information that is maintained by MySQL during the time it is
running. The Advanced Options during installation can be used to specify the location
where the logs are saved on the system.

• In the last step MySQL shows its progress in installation and configuration, where you have to
press the “Execute” button and the installation should run and finish all the steps.

MySQL upgrade
• The installer can also be used to upgrade the server installation.

• Download the zip archive for Apache tomcat from here:
http://download.nextag.com/apache/tomcat/tomcat-7/v7.0.65/bin/apache-tomcat-7.0.65.zip
Installation for Windows is just unpacking this archive into a location that you will remember. Right
click  Extract all.
• Platform specific versions come with Tomcat native bundled. You can use Ubuntu’s repo to install
apache tomcat 7
$ sudo apt-get install tomcat7
• Detailed installation for Ubuntu can be found here:
https://help.ubuntu.com/lts/serverguide/tomcat.html
• The tomcat documentation is an excellent resource that should be read for better understanding
its functioning and configuration options:
http://tomcat.apache.org/tomcat-7.0-doc/index.html
Apache tomcat download

• Move the downloaded openmrs.war to TOMCAT_HOME/webapps folder.
• Start tomcat
• Go to localhost:8080/openmrs – here you will be redirected to the initialsetup page.
• Follow the instructions on the screen and install OpenMRS.
• It is recommended that you do not use the root account to connect to OpenMRS. Instead, use the
user interface to select the option where the installer will create a new user account for you,
based on you providing the root MySQL username and password.
Deploy OpenMRS on Apache tomcat

Please attend the certification
discussion to understand how you
can use the skills you’ve gained
today.
We are working on OpenMRS Fundamentals
Exam – this tutorial will help you in giving that
exam

Health IT and OpenMRS

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Health IT and OpenMRS

Similar a Health IT and OpenMRS (20)

Último

Último (18)

Health IT and OpenMRS