Instinctively, it would seem to be good idea to extend relationships to allow Provider-to-Patient relationships instead of just a Person-to-Person relationships. But if we do go this route, doesn't it seem like Provider should be data, not metadata?
As a way to logically wrap my head around the issue when working on the Provider Management module, I defined Provider (from the perspective of the module) as "a Person with one or more Provider metadata objects associated with them". This, of course, isn't entirely right, because from an OpenMRS perspective you can have a Provider that isn't associated with a person, but it seems to work for the module because the module is meant to manage *people* who are providers. Mark From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Monday, April 02, 2012 5:34 PM To: [email protected] Subject: Re: [OPENMRS-DEV] ProviderAttributes @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]<mailto:[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]> [mailto:[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]<mailto:[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]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Burke Mamlin Sent: Wednesday, March 28, 2012 9:17 PM To: [email protected]<mailto:[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 ________________________________ Click here to unsubscribe<mailto:[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]
