Roger, A provider is a role within the healthcare system that may provide some form of care to a patient. In the simple/common cases, where a single provider record is created for each healthcare provider at a facility, they will match up one-to-one with person; however, it's possible for a single person to function within more than one provider role (e.g., a doctor who wears one hat on one day of the week and another hat on other days of the week in a different clinic; a nurse who moonlights as a therapist; etc.). Enforcing a one-to-one (saying provider is a person), does not obviate the fact that a single person can have more than one provider role; rather, it just pushes it out to more tables beyond provider. By focusing the task of defining/ensuring individuality in one place (on the person table) instead of across multiple domain objects, we can focus our tools (mergining, weeding out duplicates, etc.) in one place. It's analogous to users (a single person can have multiple user accounts, rather than saying that user is an individual and then having to manage the case of multiple accounts/roles/credentials all linked to a single user record).
We have no near/mid-term (or even long-term) plans to do the same with patient; however, I have seen it done. For example, Regenstrief chose to treat "patient" as a role (i.e., a patient within a single institution), meaning that an individual could have multiple patient records if they had been to multiple different institutions. This was a decision based on the fact that Regenstrief is supporting/consolidating data from a myriad of institutions. It seemed counter-intuitive and wrong to me when I first saw it. When your collecting data for a single institution or don't care about merging data from multiple institutions (most cases of OpenMRS now), then it's not worth the trouble. The advantage of separating "patient" from the individual (i.e., allowing duplicates) does become evident when you see a system like Regenstrief's medical record, which is coordinating data across multiple institutions. The biggest advantage is that the system can present all patient entries for an individual (and all the data associated with them) as a single patient OR easily filter the data to some combination of institutions without having to track institution for every atomic piece of data. In any case, I'm not proposing that we do this now... I'm not even proposing that we consider doing this now. -Burke On Tue, Apr 3, 2012 at 12:24 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > @Darius, perhaps you could explain what it means for a person to be > multiple providers and for a person to be multiple patients. It certainly > escapes me.**** > > ** ** > > *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]> 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 > _________________________________________ 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]
