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]] *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
------------------------------------------------------------------------
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]
