As we have been designing the Provider Management module, it has been clear that the use cases of the module revolve around management of people (who are providers), not an abstract concept of a provider. Therefore, from the module's perspective a "Provider" is defined as "a Person with one or more associated Provider metadata".
The module works around providers who aren't people by ignoring them... so provider-less persons isn't a showstopper. But we'd hope that this module could be useful to the community and there is the fear of the complexity & confusion that Mike mentions. For instance... what is the "name" of that provider? The name field of the provider? The PersonName of the underlying person? Mark From: [email protected] [mailto:[email protected]] On Behalf Of Michael Seaton Sent: Thursday, April 19, 2012 3:31 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Providers and Persons 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 ________________________________ 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]
