Thanks Burke,
Sounds like a a decent approach, I'd be interested to hear what Shaun
thinks about the de-duplication issue. That is also something I care a
lot about. I would hope API and UI-level restrictions would be able to
mitigate this, when appropriate.
Obviously there is little chance that this conversation has any impact
on our 1.9 release. Unfortunately, it will be harder to make a
previously nullable column not-nullable down the road than it would to
start out with the more restrictive option. Of course, I could have
weighed in on this 9 months ago (or more) when it was actually being
designed, but I don't think I would have had the same perspective then.
In any event, this isn't really a deal-breaker for us, but it will have
an impact on what providers can be managed by the module we are
developing. I'm happy to discuss it further on a design call if my
proposal has merit. If not, we can work with it as is.
Cheers,
Mike
On 04/19/2012 04:44 PM, Burke Mamlin wrote:
Mike,
I'm just concerned about our de-duplication efforts. If we make all
demographics optional, then we may go take de-duplication from a
difficult task to an impossible one. That said, if the de-duplication
effort can take linked objects into consideration – i.e., know that a
person is linked to a provider – then perhaps an anonymous person
record isn't so terrible… as long as it's linked. In other words,
perhaps the compromise here is the best solution: only un-linked
person records require basic demographics. In other words, you cannot
create a nameless, genderless, ageless person record that stands on
its own; rather, it would have to be linked to a patient, user, and/or
provider. Likewise, you could not unlink an person record lacking
name+gender+age from all patient/user/provider objects without also
voiding it. Of course, the API would need to enforce this.
Maybe we can discuss with Shaun regarding side-effects on
de-duplication efforts.
BTW… I know I have a reputation as a complicator (that's why Win
avoids me). I'm not thrilled about it & I'd much rather be seen as a
simplifier, but I don't believe it's always "simpler" when an easy
solution now just ends up deferring the difficulty or shifting it to
somebody else. Usually, un-debated solution (even my own) are weaker
than those that have been beaten around a few heads. In fact, the
best solutions I've seen are compromises. If I'm making things
complicated without good reason, please continue to call me on it.
-Burke
On Thu, Apr 19, 2012 at 3:53 PM, Michael Seaton <[email protected]
<mailto:[email protected]>> wrote:
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]
