Hi Burke,
I understand your point. But is it all or nothing with regards to
constraints? If we remove the data model constraints on Person here, it
gives us the flexibility to address each use case as we see fit:
* We allow Providers to be simply links to mostly-empty person records,
with a single Person name that contains a title and a surname.
* We allow Users to also be genderless and ageless (why should we care
about this here either)?
* We force Patients to have age and gender specified if entered via
certain service methods
* We leave the door open for Patients without gender or birthdate if
needed (eg. if I want to import from EPI Info, and some patients are
missing these fields)
As it is now we will have a provider management module that will manage
_some_ providers, but not all. This isn't a deal-breaker, but it would
be better if it weren't so.
We also have API methods that we have to deal with (and haven't done so
well as of yet) - for example, in trunk currently we have
Provider.getName() return simply the name property of the object. It
does not take the underlying Person into consideration at all. Yes,
this could (and should) be fixed, but it's just added complexity to now
have 2 places where names may be stored for a Provider.
It just seems to me that we are over-complicating things unnecessarily,
and I want to put out this alternative design out for consideration...
Mike
On 04/19/2012 03:23 PM, Burke Mamlin wrote:
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]
<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]
