Talk:Location

PIH Team Thoughts

Something just came up in Peru, which I’m going to brainstorm about because I think we should consider some changes to the data model for locations:

Back in August, the ministry of health changed the name of a health center from "Centro Salud Canto Grande" to "Hospital San Juan de Lurigancho". (I just learned today that this health center has previously been known as "Centro Maternal Infantil Canto Grande" and "Hospital Maternal Infantil Canto Grande".)

The way we decided to deal with this (back when I was only aware of the first 2 names) is to create 2 separate locations, and marked the first as being deprecated in favor of the second (we added columns to store new_id, date, and reason for the change). We didn’t like the alternative of changing the location’s name, because:

1. our epidemiologists prefer to be able to distinguish between people who started at this place when it was a health center versus after it was reclassified as a hospital.
2. we didn’t want old data like previous tb treatments to show up as being at Hospital Y when they were entered as Health Center X.

We would have had more flexibility if we weren’t trying to minimize changes to our old code base.

Another thing I was reminded of is that in Peru they strictly classify all health institutions as one of the types below. They really like lists and classification there. (Also, each location falls within a health district, and possibly a subdistrict. And it might be reclassified from one to another over time.)

Centro Salud Clinica Centro Maternal Infantil Hospital Maternal Infantil Hogar Hospital Hospital Nacional Hospital de Apoyo Hospital Regularl Instituto Puesto de Salud (health post) INPE

So in summary:

1. We should consider modeling the administrative district that a location falls into. That starts to get a bit further from "patient-centric" than I’d like, but I suspect that many use cases we’ll face not far down the road are going to cry out for this. Maybe we can use the same mechanism we’ve discussed for projects to model this. Alternately we could add a single text column called location.administrative_district and handle it at the application level (e.g. "Lima Este::San Juan de Lurigancho")
2. We might want to add a nullable location.type column (maybe FK to concepts). I can’t think of any actual use case for this: it’s probably fine to handle at the application level.
3. Location details may change over time. At a minimum the name might change. So might administrative district and address, I suppose, but hopefully we can ignore that, Some options:

• pull location.name (and maybe other columns) into a new location_name table
• add deprecated_to, deprecated_date, and deprecated_reason to location.

Regenstrief Thoughts

• We agreed that changes in locations are likely modeled as another row in the location table
• Locations are any arbitrary size or scope you want (ie, a broad geopgraphic swath, or a portion of a clinical location)
• There might be future value in location hierarchies (new column that's a self-referential key back to location_id)
• There might be future value in a location_type table much like the encounter_type table, which could allow code to cross reference and display locations by type. Another option is to build another location.type attribute that FK'ed concept table.

We all agreed that the current data model could mold to accomodate the latter two functions, but we'd hold off on changing the model until we reached a point where the implementation would drive the model changes