Package org.openmrs.api

The primary OpenMRS API interfaces.


Interface Summary
ActiveListService Contains generic methods pertaining to Active Lists in the system
AdministrationService Contains methods pertaining to doing some administrative tasks in OpenMRS
CohortService API methods related to Cohorts and CohortDefinitions A Cohort is a list of patient ids. A CohortDefinition is a search strategy which can be used to arrive at a cohort.
ConceptService Contains methods pertaining to creating/updating/deleting/retiring Concepts, Drugs, Concept Proposals, and all other things 'Concept'.
DataSetService Deprecated. see reportingcompatibility module
EncounterService Services for Encounters and Encounter Types
FormService This service contains methods relating to Form, FormField, and Field.
GlobalPropertyListener This interface allows code to be run when global properties are created, edited, or deleted.
LocationService API methods for managing Locations

Example Usage:
List locations = Context.getLocationService().getAllLocations();
ObsService The ObsService deals with saving and getting Obs to/from the database Usage:
OpenmrsService Base OpenMRS Service Interface All services registered to the ServiceContext are required to implement this interface.
OrderService Contains methods pertaining to creating/deleting/voiding Orders and DrugOrders Use:
PatientService Contains methods pertaining to Patients in the system Use:
PersonService Contains methods pertaining to Persons in the system Use:
ProgramWorkflowService Contains methods pertaining to management of Programs, ProgramWorkflows, ProgramWorkflowStates, PatientPrograms, PatientStates, and ConceptStateConversions Use:
ReportService Deprecated. see reportingcompatibility module
SerializationService Contains methods for retrieving registered Serializer instances, and for persisting/retrieving/deleting objects using serialization
UserService Contains methods pertaining to Users in the system Use:

Class Summary
EventListeners Holds all OpenMRS event listeners

Enum Summary
ConceptNameType The concept name type enumeration
OrderService.ORDER_STATUS The type of status to match on an order.
PersonService.ATTR_VIEW_TYPE These enumerations are used when determining which person attr types to display.

Exception Summary
APIAuthenticationException Represents often fatal errors that occur within the API infrastructure involving a user's lack of privileges.
APIException Represents often fatal errors that occur within the API infrastructure.
BlankIdentifierException Exception thrown when a Patient or PatientIdentifier is being saved with an empty or null PatientIdentifier.getIdentifier()
ConceptInUseException This exception is thrown when concept is used/attached to an observation.
ConceptNameInUseException This exception is thrown when one attempts to delete a concept that has a conceptName that is being used by an observation
ConceptsLockedException This exception is thrown when a specific implementation has chosen to lock down their concepts and prevent editing.
DuplicateConceptNameException An error of this type is thrown when a concept name is found in the database when one tries to create a new one with the same preferred name in the same locale
InvalidCharactersPasswordException Password exception when the password doesn't comply to the minimum set of required characters.
PasswordException Represents common exceptions that happen when validating a User's password.
ShortPasswordException Password exception when the length is less than the minimum allowed.
WeakPasswordException Password exception when the password is a simple word or matches the User's username or system id.

Package org.openmrs.api Description

The primary OpenMRS API interfaces. These services provide the necessary methods to access and manipulate OpenMRS domain objects.

Services are obtained statically from the Context.

These services compose the OpenMRS business layer API. The majority of developer interaction with the OpenMRS system should occur through these services.  Lower level (database) API methods are reflected within these services so that business logic hooks may be placed in front of the database layer. Developers should favor calling these services for database access, rather than going directly to the DAO objects in the org.openmrs.api.db package.

For example, using the API alone, a start-to-end application would look like this:

  Context.startup("jdbc:mysql://localhost:3306/db-name?autoReconnect=true", "openmrs-db-user", "3dx$ijt", new Properties());
  try {
    Context.authenticate("admin", "test");
    PatientService ps = Context.getPatientService();

    // fetch patient with identifier 3-4
    Patient patient = ps.getPatientByIdentifier("3-4");
    // set the patient's birthdate to today
    patient.setBirthdate(new Date());
    // save the patient to database
  finally {

Note: When using OpenMRS within a managed environment (like our web application war file), the only calls that are needed are to get the PatientService, set the birthdate, save the patient with the PatientService.


Generated Apr 27 2012 10:06 PM. NOTE - these libraries are in active development and subject to change