We specifically said that if you want to have import "long list of providers" you could do that and they would be personless. But if you want to be able to store richer data (names, gender, attributes) you have to create a person for the provider. I think linking the provider to a patient is that kind of richer data.
Ben On Mon, Apr 2, 2012 at 6:59 PM, Michael Seaton <[email protected]> wrote: > ** > Perhaps we need to re-visit the decision of supporting Person-less > Providers. > > Can the reason for doing this essentially be summed up as "we don't > necessarily know the genders and birthdates of every provider that we might > want to upload to our system, and these are required on Person"? Are there > other reasons that led to this decision that I'm not aware of? > > If that's the extent of it, perhaps we'd be better off loosening this > restriction on Person and enforcing that Person be non-null on Provider. > We certainly have situations in our system (migration of Patient data from > legacy systems like EPI Info, for example), where birthdate and gender > information of Patients is incomplete and we'd want this restriction > loosened anyway in order to be able to properly add this data in without > putting hacks in place... > > Mike > > > > > On 04/02/2012 06:21 PM, Mark Goodrich wrote: > > 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] <[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]> 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 > **** > > ** ** > ------------------------------ > > 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 > > ------------------------------ > 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]
