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]> 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] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:LISTSERV@LISTSERV.**IUPUI.EDU <[email protected]> > ?body=SIGNOFF%**20openmrs-devel-l] > _________________________________________ 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]
