Burke has consistently referred to our having Person be what represents
a...um...Person. And that Users and possibly even Patients in the
future are things that are associated with Persons. I think the same
should hold true for Provider. By leaving the link optional, it may
give us a bit more flexibility, but at the cost of added complexity,
confusion, and inability to write common tools that are applicable
across all usage patterns. I don't think the benefit outweighs the cost
here....
On 04/19/2012 03:04 PM, Ben Wolfe wrote:
Yes, the idea was that you don't always know that other info. But it
was also the fact that you don't need those 10000 rows in the person
table if you're only going to be referring to the provider from an
encounter. If you are going to use them for more (like linking via
relationships) then you "upgrade" those providers to be person-based.
Ben
On Thu, Apr 19, 2012 at 2:46 PM, Michael Seaton <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
I brought up an idea buried in an email during the Provider
Attribute thread a few weeks ago, but it was lost a bit in all of
the many other points being made, so I wanted to raise it here
again explicitly.
I think making the link between Provider and Person optional is a
mistake. Here is my reasoning:
* A Provider in OpenMRS is not meant to be a subclass. It is
meant to be a particular role in the health care system that a
Person can have. And a person may have many of these.
* The most similar thing we have in OpenMRS to this is User. No
users are allowed in OpenMRS without being associated with a
Person. User is probably more accurately thought of as a User
Account. Clearly a single Person can hold multiple User Accounts.
* The only real reason I can see for making Person optional is so
that we can avoid having to require things like "gender",
"birthdate", etc. on Provider that have traditionally been
required of Person at the database and API levels. For example,
if we are uploading a list of 10,000 providers from a national
registry, and all we have is a String name, and no gender or
birthdate data. However, I think a more valid solution to this
problem is just to remove those data model and API restrictions,
and to make Person not require this data. Then, we just move
those validation constraints onto the Patient object if we desire
(though to be honest we don't always have this information here
either, particularly if we are importing data from a legacy system).
So, I realize we are at RC3 for 1.9 and all, but my proposal would
be to:
* Make Person not null on Provider
* Make gender and birthdate nullable on Person
This is particularly relevant to our team at PIH as we are
currently building a Provider Management module on top of 1.9.
Mark has had to bake in the assumption that all Providers have
Person records (at least those that can be managed with this
module), because this is required for many of our use cases - in
particular the notion that Providers are linked to their Patients
and to other Providers via Relationships.
I would be interested to hear others thoughts on this or if any of
my assertions / assumptions are just wrong.
Thanks,
Mike
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an
e-mail to [email protected]
<mailto:[email protected]> with "SIGNOFF
openmrs-devel-l" in the body (not the subject) of your e-mail.
[mailto:[email protected]
<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l]
------------------------------------------------------------------------
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]
