Encounter Attributes

Dear All,

We presently have come up with a hacked way of labeling various encounter types with different tags to facilitate two processes: 1) marking an encounter_type as belonging to a particular program (for workflows); and 2) to facilitate the creation of datasets which include encounters based on type.

It would be very useful to us to instead embed this into OpenMRS (preferably core) perhaps using a scheme similar to Visits like:

  1. EncounterAttributeType (basically a tag)
  2. EncounterAttribute (assign an encounter type attribute type) to

You may ask, doesn’t the Visit Attribute system suffice? For us it does not, as we need resolution at the encounter level.

Anyone else likely to benefit from this expansion? Is there an alternative way of doing this that people favor?



Hi @jdick, we’d be interested in exploring this more. Regarding your proposal, are we talking about tagging Encounters or tagging EncounterTypes? I would think the naming you are going for would be:

  1. EncounterTypeAttributeType
  2. EncounterTypeAttribute

Sorry if I’m mis-reading this. Mike

@mseaton, excellent.

Yes, we are tagging encounter types not encounters.

I agree with you about the naming convention. Initially I was thinking the same but the visit attributes aren’t following that naming pattern (so I changed it to EncounterAttribute etc.). Either way works for us.


Isn’t VisitAttributeType a way of tagging a visit and not the VisitType?

@jdick, I think that Locations are a better analogy, since they are also OpenMRS Metadata. In OpenMRS core, Locations can have tags (e.g. “login location”) and also attributes (“barcode printer at this location =”, “DHIS facility ID = some-long-uuid”).

Your first example seems like an attribute (“belongs-to-program = x”) and your second example sounds like a tag (“admission encounter type”), is that right?

I would definitely support adding attributes and/or tags to EncounterType in OpenMRS Core, just like is done for Locations. (We’re generally supportive of anybody adding Attribute support to any domain object, if they’re willing to do the work.)

But it would be nice to understand the use cases more to see if there’s something less abstract we could add.

What are some examples of “encounter type type”? Are they things like “admission” or “hiv” or something else?

Or, for the program example, is the idea that you’re only allowed to have an encounter of X type if you’re enrolled in Y program? Or that having an encounter of X type will automatically cause you to transition to program state Y?

@darius, I think your description is correct. Here is a more thorough description of our current use cases.

  1. Clinic Flow Report : We extract data from the encounters table for all the encounters in a given day at a give location. We track the time it takes from registration, to triage, to the clinical encounter. To identify the type of each, we have created a table called “clinical_encounter_type_map” which maps an encounter_type to both a program_id and has a column is_clinical which helps us with the following. It’s a poorly named table and is pretty inflexible. It’s useful though as we can join it to the encounter table and get what we need.

  2. Workflows: For us, we primarily use “workflows” to facilitate the user entering the right data for a given clinical encounter. We have constructed a overarching container called “department”. A department would be “HIV” or “Oncology”. This is represented in a custom table outside the openmrs schema. A department can have multiple Programs. A program is mapped to multiple visit types. A visit type is mapped to multiple encounter types. Although encounter attributes/tags may not be the only or best solution to helping facilitate our workflows, it would make it easier to tag an encounter type as belonging to a given visit type. We would then still have to come up with a way to associate visit types with programs and programs with departments and departments generally speaking. Though this takes us away from the initial discussion, we would be happy to work on a backend supporting this (or a variation of) this architecture to support workflows.


What you’re doing sounds very similar to what was done in KenyaEMR, where programs were used to drive workflows.

While tags might be enough for implementation-specific solutions, I’d support evolving our way to making some of this functionality a first-class citizen in core – e.g., allowing programs to specify a list of applicable encounter types.

Attributes vs. Tags

Attribute tables are used to virtually extend the core tables in an implementation-specific manner – e.g., if core has a Foo table and some implementations want to add a column or two that aren’t needed by everyone else, then FooAtttribute and FooAttributeType (following our custom datatype pattern) can be used to extend the table locally in a way that core can understand.

Tags are used when you want to, er, tag or label things. In this case, you aren’t extending the core table so much as wanting to be able to put labels on existing domain objects just like you’d tag a blog entry, add a tag to a Talk post, or label a wiki page.

Just thinking out loud here, but, what about creating a generic tag table, “tag_type” perhaps with columns:

  • name: “[name of tag, e.g. HIV Encounter Type Tag”]
  • table: “encounter_type” | “location” | “program”, etc
  • mapped_id: [this would be the id pointing to the type, e.g. if 1 were the encounter type for adult HIV encounter type ]

I suppose this wouldn’t have the ability to have a foreign key check as it would map to encounter_type_ids, program_ids, etc. But would give a lot of flexibility as well as the ability to account for unforeseen tables in the data model.

Perhaps there are other flexible ways of doing this which preserve the foreign key check? Maybe just have a many columned table with a column for each table that could have a tag? (this doesn’t sound so good to me but does preserve the foreign key).


It might be worth checking on the outcome from the GSoC 2017 project Generic Tagging Mechanism. It looks like @jtatia was the student and @wyclif the mentor. There’s a module wiki page, but the project page doesn’t appear to have been updated.

@jtatia / @wyclif – how far did we get with generic tagging?

Also, it seems like that module requires the reference application. @wyclif, @jtatia, did you create any REST endpoints to support this? Could it be used with just platform?

As a proof of concept of that work, Jai added only support for tagging patients but should be very easy to support other domain objects, I think the work is close to being usable.

Yes the module has rest end points that you can consume in your custom UIs, you should be able to add/remove tags plus do some basic search for objects with specific tag(s) .

Thanks @wyclif. Is it possible to tag meta-data, e.g. can you tag an encounter_type?

@jdick the module supported tagging of all OpenMRS objects. As a proof of concept we added UI for adding/deleting/searching patients, but the backend can support all OpenMRS objects.

Thanks for this update. Can you point me to a description of the data model supporting this feature?



Really Sorry for the late reply. We never added information regarding the data model in the model description page but the following might give you a basic idea :-

tag_id INT(10)  (PK)
tag VARCHAR(50)
object_uuid CHAR(38)
object_type VARCHAR(255)   --> ("java class name")
creator INT(11)  (FK)
date_created DATETIME
uuid CHAR(38)

Just following up on this. We will try out this module in the coming weeks.

The data model above is using only uuids. Uuids can be expensive to index and slow to join on. Would you consider adding a column, object_id. One could store the appropriate id here, encounter_id I suppose if tagging encounters, or encounter_type_id if tagging encounter_types.


@burke is this applicable for all tables in core ? was just thinking and wondering if the same idea can be used at " Adding Program Attributes to HTML Form

@mksd @wyclif

@tendomart could you describe what the business needs are for program attributes on a couple of examples?

Theoretically, since Program defines the program and PatientProgram defines a patient’s enrollment into that program…

  • Program Attributes would be used to add implementation-specific metadata about a program
  • Program Tags would be used to categorize/label programs
  • PatientProgram Attributes would be used to add implementation-specific metadata about a patient’s enrollment into a program
  • PatientProgram Tags would be used to categorize/label enrollments