Attributes are meant to serve as local (implementation-specific) extensions to tables and can contain simple metadata or links to other objects (think of them as another column added to the core table). For example, a person attribute could store a person's primary clinic as a Location reference.
Don't think of Provider as a unique person. A provider represents a person as a provider. Just as a single person could have multiple user accounts, it's possible for a single person to have multiple provider entries (e.g., a doctor who practices in more than one specialty, a doctor registered at through two different institutions). <digression>If we ever end up needing to support multiple institutions within OpenMRS in the future, then patient could go the same direction (e.g., a person allowed to have a patient entry for each institution where they've been a patient). If that ever happens, the API would need to do the heavy lifting to present patients across institutions as a single patient.</digression> -Burke On Wed, Mar 28, 2012 at 5:45 PM, Mark Goodrich <[email protected]> wrote: > Hello all—**** > > ** ** > > I asked this question a couple of weeks ago on this list, but Mike & I > were debating it yesterday so I wanted to follow up with a more detailed > version of the question…**** > > ** ** > > I’m working on a new Provider Management module that we are planning to > use to manage community health workers. To do this, I’ve created a new > Provider Role domain object that has a many-to-many relationship to > RelationshipType as well as other Provider Roles:**** > > **** > > public class ProviderRole extends BaseOpenmrsMetadata implements > Serializable {**** > > ** ** > > private Integer providerRoleId;**** > > ** ** > > // the provider/patient relationships this role can support**** > > private Set<RelationshipType> relationshipTypes;**** > > ** ** > > // the provider roles this provider role can supervise**** > > private Set<ProviderRole> superviseeProviderRoles;**** > > ** ** > > etc …**** > > ** ** > > A Provider Role has many-to-one relationship with Provider, and so the > obvious solution to implement this would be to create a foreign key mapping > table between Provider and Provider Role, but I thought it might be worth > considering storing Provider Role as a Provider Attribute instead… so I > asked the list, and the general consensus, I believe, was to use Provider > Attribute.**** > > ** ** > > I’m second guessing my decision a bit now… are Provider Attributes (and > Attributes in general) really meant as a way to create a link between two > core domain objects, or are they only intended for storing more basic > information like provider health center, provider home town, etc? **** > > ** ** > > Thanks,**** > > Mark**** > > ** ** > > ** ** > > ** ** > > ** ** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
