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]<mailto:[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<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
