@Mark, it was designed as a way to "add attributes to things." E.g. having your module create a ProviderAttributeType whose attribute value represents a providers role is perfectly fine, in the sense that a provider's specific role is an attribute of the provider.
That said, if you want to enforce referential integrity, or simplify the hql/sql to find providers with a given role, you might want to use an FK'd DB field instead. @All, it occurs to me that as we introduce providers (and we allow multiple providers for a person, as well as person-less providers), and as we plan to someday maybe support having multiple patient rows for a person, our relationship table is now lacking. Really we should be able to support saying that a specific row in the * provider* table has a relationship to a patient, not force Mark to do what he's doing here, and have to put a relationship on the provider's underlying person... -Darius On Thu, Mar 29, 2012 at 7:04 AM, Mark Goodrich <[email protected]> wrote: > Roger & Burke—**** > > ** ** > > Thanks for the input…**** > > ** ** > > Roger summed up my wariness pretty well… do people agree that the > “enriched attribute model” was designed as a way to handle structural > relationships? Was the attribute model designed to facilitate storing data > in a more RESTful manner than a structural relationship? **** > > ** ** > > One downside of doing things this way is that the “Provider Role” provider > attribute type has to be hardcoded into the Provider Management module (ie, > I’ve got a constant PROVIDER_ROLE_ATTRIBUTE_TYPE_UUID) **** > > ** ** > > @Roger—your suggestion of having “relationships supported” and > “relationships supervised” stored as provider attributes is interesting—the > one-click selection could probably be maintained via the API. I don’t know > if I I’m going to refactor it at this point, but it is worth considering.* > *** > > **** > > As for the argument of a one-to-one vs a many-to-one relationship between > provider and person, I don’t have a strong preference either way. The API > I’m creating assumes a many-to-one relationship, but I don’t think this is > a core part of the way I’m doing things. In my model a provider can only > have one provider role, and so if a person has multiple roles, they would > have an associated provider object for each role—but I don’t think > switching this in the future so that the person has only one provider, but > provider is allowed to have multiple roles would be terribly difficult.*** > * > > ** ** > > One perhaps controversial thing that I’m doing in the module is that I’m > hiding the Provider object behind the API. In terms of what the API > exposes to a consumer, a “provider” is defined as “a Person with one or > more Providers associated with it”. The reason for this is that the > Provider Management module deals primarily with relationships > (provider/patient relationships and supervisor/provider relationships) and > Relationships are defined on the person-to-person level. (For instance, > the API method getProvidersForPatient(Patient patient) has a return type of > List<Person>, not List<Provider>). This could be considered the “wrong” > approach since it ignores personless Providers, but the Provider Management > module is specifically designed to manage **people** who are providers. > The fact that Provider is metadata, as opposed to data, made me more > comfortable with this approach. The alternative approach would be to add > the ability to handle Provider-to-Person relationships.**** > > ** ** > > Take care,**** > > Mark**** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Friedman, > Roger (CDC/CGH/DGHA) (CTR) > *Sent:* Thursday, March 29, 2012 8:43 AM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] ProviderAttributes**** > > ** ** > > I understand your wariness about putting a structural relationship into a > provider attribute which as Burke says is a way of extending the provider > table. However, given our newly enriched attribute model and the benefits > of RESTful thinking, I would give each provider 3 attributes: "role", which > serves as a category for selection and reporting; "relationships > supported", a multi-value attribute; and "relationships supervised", a > multi-value attribute. Admittedly, this removes the one-click selection of > multiple relationships supported and supervised, but on the other hand > inhibits role fragmentation consequent to special cases (provider A can do > everything that a role X can except for supervising relationship N). If > you want to restore one-click selection, I would do something like > relationship type tags (and it turns out that tags are merely a special > case of attribute, so you might as well do relationship type attribute).** > ** > > ** ** > > Burke, despite your explanations, I still don't see the need for > non-unique providers, and especially the need for non-unique patients. The > base function of the provider table is to provide the ability to identify a > provider who is not a person, and to collect attributes which are important > for describing providers. If a provider works at multiple institutions or > has multiple specialties, that should not result in "aliased" providers. > Please take a look at how those relationships are handled in the HR module. > **** > > ** ** > > Likewise for patients, they already can have location-specific IDs, they > can receive services at any location. Having separate patient records for > each facility where a patient receives services is no different than having > separate patient records for the outpatient clinic, the x-ray room, the > optometry room, etc. Even with respect to privacy, locations within a > facility (e.g. HIV clinic, psychiatric ward) might be at least as sensitive > as different facilities. What's different about being a patient at more > than one facility is that the facilities might keep different sets of > patient attributes; this is a place for patient attribute type tags, as > suggested above.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke > Mamlin > *Sent:* Wednesday, March 28, 2012 9:17 PM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] ProviderAttributes**** > > ** ** > > 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 > **** > > ** ** > ------------------------------ > > 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]
