Mark, If we have (very useful) information about all providers in the district and they contain title & identifiers like "Dr. Ochieng (1234-5)", are you saying that we should not require gender, at least estimated birthdate, and at least two names on Person to allow this?
The key difference between a provider and a user is that a provider does not have to *have* anything whatsoever to do with the EMR beyond being references (e.g., capturing a referring provider from an external facility). Defining a person without knowing their name, whether they're male vs. female, or whether they're two years old vs. 50 years old would make Person solely a linking tool – i.e., akin to auto-generating 100,000 nameless, genderless, ageless records in the person table and picking the next one when you want to link a patient to user, provider to user, etc. This is directly counter to our effort to leverage Person as the one location within which we focus our efforts to *avoid and address* duplication errors. We could require that all providers are persons, but I don't believe we should make all hopes at identification for person optional to do it; rather, we'd need to come up with a solution for those folks who get the list of providers like "Dr. Ochieng (1234-5)" and are missing the demographics to generate a person. What's driving you to this conclusion? Is there some reason that you can't limit yourself to providers linked to person records? Where is the assumption that provider must be a person being made? -Burke 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]
