Recording geocoordinates in OpenMRS

akanter · December 29, 2015, 9:21pm

We have received a request to store latitude and longitude for encounters in OpenMRS. I had thought at one time that we actually had such fields in the data model associated with a location. I don’t see them anymore in 1.11. I can create a concept for encounter longitude and latitude (two concepts) with precise numeric data type, but wondered if there was a better way for this to be stored in the data model. Location attribute based on a concept?

darius · December 30, 2015, 12:10am

Locations have latitude and longitude fields already (see

github.com

openmrs/openmrs-core/blob/1.11.x/api/src/main/resources/liquibase-schema-only.xml#L884


<column defaultValue="" name="name" type="varchar(255)">
    <constraints nullable="false"/>
</column>
<column name="description" type="varchar(255)"/>
<column name="address1" type="varchar(255)"/>
<column name="address2" type="varchar(255)"/>
<column name="city_village" type="varchar(255)"/>
<column name="state_province" type="varchar(255)"/>
<column name="postal_code" type="varchar(50)"/>
<column name="country" type="varchar(50)"/>
<column name="latitude" type="varchar(50)"/>
<column name="longitude" type="varchar(50)"/>
<column defaultValueNumeric="0" name="creator" type="int">
    <constraints nullable="false"/>
</column>
<column name="date_created" type="DATETIME">
    <constraints nullable="false"/>
</column>
<column name="county_district" type="varchar(50)"/>
<column name="address3" type="varchar(255)"/>
<column name="address4" type="varchar(255)"/>

) and every encounter must have a location, so if you’re talking about encounters at fixed locations, you should use the existing fields.

If you’re talking about recording the geocoordinates of encounters outside the facility (e.g. home visits for everyone in a cohort) that don’t correspond to a fixed Location, then you’ll need to do something different.

I can definitely see the argument for adding these as optional fields directly on encounter in the core data model, though I guess this might involve some discussion and wouldn’t be immediately available to existing implementations.

So my recommendation would be to go ahead and create these concepts, and push to get the idea integrated into the core data model in the future.

r0bby · December 30, 2015, 2:21am

How would this be represented?

akanter · December 30, 2015, 2:36pm

Thanks @darius! I should have looked in the address fields. I did great a generic latitude and longitude concept with datatype numeric, precise, units degrees with max/min of 90/-90 and 180/-180 respectively. They can be used in any set which requires a separate location, but I will direct fixed locations in the location table to have them entered as part of the address.

r0bby · December 31, 2015, 5:00am

@akanter, shouldn’t concepts be used to represent patient data, not location data? This is just my $0,02

akanter · January 1, 2016, 8:12pm

Concept dictionary is used for any structured data in the database. Not only for attributes used in other tables, but also for things like aggregated measures that might be used in reports and decision support :). There is even the household module which captures non-patient data in OBS-like tables…

r0bby · January 1, 2016, 11:30pm

Okay, I’m more than happy to be wrong here