Following up from discussion on TRUNK-4722…
@burke (moving this to talk, and simultaneously testing whether the workflow of reply-to-JIRA-notification-but-change-address-to-dev-list works)
This is a good thought example…
Here are some “magic” location tags in the reference application:
- Login Location => can be selected from the login screen
- Visit Location => allowed to be used as visit.location
- Admission Location => can be the first assigned location at an admission
- Transfer Location => an inpatient can be transferred to this location
PIH introduces a bunch of additional ones in its Core EMR: Vitals Location, Consult Note Location, Dispensing Location, etc. The Ebola module introduces some additional ones: Ebola Suspect Ward, Ebola Confirmed Ward, Ebola Recovery Ward, Inpatient Bed. (The PIH and Ebola examples are all “implementation-specific” but you could easily imagine generic modules providing similar functionality.)
I think it’s important for a module to be able to create a “magic” location tag, and own the tag’s definition and meaning. In fact I think the primary use case for location tags should be to have code that knows how to behave differently, given tags. Letting implementers create a folksonomy of tags through the UI adds much less value. (As far as I know, the place these are at all useful is where HTML Form Entry lets you do <encounterLocation tags="Admission Location" />
.)
So, I propose that we add a way for code to lock a Location Tag such that a user can’t edit or delete it through the UI. (And in general I think this should be the pattern for all our tag types.)