Providers and Persons

classic Classic list List threaded Threaded
16 messages Options
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Providers and Persons

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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Michael Seaton
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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Ben Wolfe (openmrs)
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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Burke Mamlin
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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Michael Seaton

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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 19, 2012 3:31 PM
To: [hidden email]
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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Michael Seaton
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

Mike,

You're right that introducing a type that's a real-life person, but doesn't necessarily point to a Person, is a questionable idea. And it's probably a mistake to introduce that preemptively, without a strong implementation need pushing for it.

We should look at the feasibility of doing a quick hack before we release 1.9 to disable non-person providers. Later we can decide to either re-enable it, or permanently remove it. It's worth considering...

-Darius

On Thu, Apr 19, 2012 at 8:00 PM, Michael Seaton <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Michael Seaton
Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):
  • Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
  • Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)
That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

-Burke

On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

PIH has asked for birthdate to be null for patients recently: https://tickets.openmrs.org/browse/TRUNK-3016  Use-case: when importing patients from past records that have missing date.

Mark: if the provider is linked to the person, provider.name is cleared and should defer to provider.person.name.  We need a simple API/pojo method for getting the name if it doesn't exist already.

Any changes decided upon here will not make it into 1.9.0.  Any change to the underlying datamodel or API at this point will force us to re-beta the 1.9.x line.

If we change our minds and make provider.person non null in 1.9.1 it is not the end of the world.  Creating person records for each null provider.person would be relatively easy using liquibase.  Mark's Provider dashboard would simply require that point release and would work more "completely".

I'm on the side of requiring providers to have a person record. person.gender doesn't have to be nullable: We could add an "unknown" gender to prevent NPE backwards compatibility.  person.birthdate could be nullable and make it an API/UI option if it is required on the person/patient/provider creation screens.  (with 10000 extra rows in the person_name table we will need to implement the lucene searches soon though: https://tickets.openmrs.org/browse/TRUNK-425)

Ben


On Fri, Apr 20, 2012 at 12:13 AM, Burke Mamlin <[hidden email]> wrote:
Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):
  • Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
  • Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)
That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

-Burke


On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

It sounds like we are converging on something here, and potentially actually agreeing on an approach.

Ben - your statement that it will be possible to migrate relatively easily from person-less providers to person-full providers with a Liquibase script between 1.9.0 and 1.9.1 or whenever makes me feel much better.  This makes sense - I _definitely_ do not want to go back to a beta for 1.9 at this point given that we have dependencies on 1.9 for our June release in Rwanda and need it out the door before then.

Ben - the delegation you describe about provider.name and provider.person.name is not currently happening.  This _should_ be fixed as a bug prior to 1.9.0, if possible.

Can we take this onto an upcoming design call in the next few weeks with an aim to agreeing upon a design and create some tickets?

Mike
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Ben Wolfe [[hidden email]]
Sent: Friday, April 20, 2012 8:16 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

PIH has asked for birthdate to be null for patients recently: https://tickets.openmrs.org/browse/TRUNK-3016  Use-case: when importing patients from past records that have missing date.

Mark: if the provider is linked to the person, provider.name<http://provider.name> is cleared and should defer to provider.person.name<http://provider.person.name>.  We need a simple API/pojo method for getting the name if it doesn't exist already.

Any changes decided upon here will not make it into 1.9.0.  Any change to the underlying datamodel or API at this point will force us to re-beta the 1.9.x line.

If we change our minds and make provider.person non null in 1.9.1 it is not the end of the world.  Creating person records for each null provider.person would be relatively easy using liquibase.  Mark's Provider dashboard would simply require that point release and would work more "completely".

I'm on the side of requiring providers to have a person record. person.gender doesn't have to be nullable: We could add an "unknown" gender to prevent NPE backwards compatibility.  person.birthdate could be nullable and make it an API/UI option if it is required on the person/patient/provider creation screens.  (with 10000 extra rows in the person_name table we will need to implement the lucene searches soon though: https://tickets.openmrs.org/browse/TRUNK-425)

Ben


On Fri, Apr 20, 2012 at 12:13 AM, Burke Mamlin <[hidden email]<mailto:[hidden email]>> wrote:
Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):

 *   Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
 *   Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)

That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

-Burke


On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]<mailto:[hidden email]>> wrote:
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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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 [hidden email]<mailto:[hidden email]> with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]<mailto:[hidden email]>?body=SIGNOFF%20openmrs-devel-l]


________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

In reply to this post by Ben Wolfe (openmrs)

The issue with provider.name vs provider.person.name is that now a Provider’s name could be either a String or a PersonName (or really a list of Person Names).  This makes it harder, for example, to develop a generic “Provider Demographics” widget.  Now this may be moot because Demographics implies Person.  The UI I’m designing in the Provider Management module will provide the means to handle editing Provider demographics information, and will be designed to only work with Persons who are Providers, not any Providers.  I don’t think this a huge deal, but I think Mike’s point is that since this is one of the first uses of the new Provider object and we are ignoring Personless providers, we might want to reconsider if it is worth having them at all.

 

Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Friday, April 20, 2012 8:16 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

PIH has asked for birthdate to be null for patients recently: https://tickets.openmrs.org/browse/TRUNK-3016  Use-case: when importing patients from past records that have missing date.

Mark: if the provider is linked to the person, provider.name is cleared and should defer to provider.person.name.  We need a simple API/pojo method for getting the name if it doesn't exist already.

Any changes decided upon here will not make it into 1.9.0.  Any change to the underlying datamodel or API at this point will force us to re-beta the 1.9.x line.

If we change our minds and make provider.person non null in 1.9.1 it is not the end of the world.  Creating person records for each null provider.person would be relatively easy using liquibase.  Mark's Provider dashboard would simply require that point release and would work more "completely".

I'm on the side of requiring providers to have a person record. person.gender doesn't have to be nullable: We could add an "unknown" gender to prevent NPE backwards compatibility.  person.birthdate could be nullable and make it an API/UI option if it is required on the person/patient/provider creation screens.  (with 10000 extra rows in the person_name table we will need to implement the lucene searches soon though: https://tickets.openmrs.org/browse/TRUNK-425)

Ben

On Fri, Apr 20, 2012 at 12:13 AM, Burke Mamlin <[hidden email]> wrote:

Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

 

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):

  • Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
  • Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)

That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

 

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

 

-Burke

 

On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

Created ticket: https://tickets.openmrs.org/browse/TRUNK-3290

Ben

On Fri, Apr 20, 2012 at 9:49 AM, Mark Goodrich <[hidden email]> wrote:

The issue with provider.name vs provider.person.name is that now a Provider’s name could be either a String or a PersonName (or really a list of Person Names).  This makes it harder, for example, to develop a generic “Provider Demographics” widget.  Now this may be moot because Demographics implies Person.  The UI I’m designing in the Provider Management module will provide the means to handle editing Provider demographics information, and will be designed to only work with Persons who are Providers, not any Providers.  I don’t think this a huge deal, but I think Mike’s point is that since this is one of the first uses of the new Provider object and we are ignoring Personless providers, we might want to reconsider if it is worth having them at all.

 

Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe


Sent: Friday, April 20, 2012 8:16 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

PIH has asked for birthdate to be null for patients recently: https://tickets.openmrs.org/browse/TRUNK-3016  Use-case: when importing patients from past records that have missing date.



Mark: if the provider is linked to the person, provider.name is cleared and should defer to provider.person.name.  We need a simple API/pojo method for getting the name if it doesn't exist already.

Any changes decided upon here will not make it into 1.9.0.  Any change to the underlying datamodel or API at this point will force us to re-beta the 1.9.x line.

If we change our minds and make provider.person non null in 1.9.1 it is not the end of the world.  Creating person records for each null provider.person would be relatively easy using liquibase.  Mark's Provider dashboard would simply require that point release and would work more "completely".

I'm on the side of requiring providers to have a person record. person.gender doesn't have to be nullable: We could add an "unknown" gender to prevent NPE backwards compatibility.  person.birthdate could be nullable and make it an API/UI option if it is required on the person/patient/provider creation screens.  (with 10000 extra rows in the person_name table we will need to implement the lucene searches soon though: https://tickets.openmrs.org/browse/TRUNK-425)

Ben

On Fri, Apr 20, 2012 at 12:13 AM, Burke Mamlin <[hidden email]> wrote:

Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

 

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):

  • Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
  • Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)

That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

 

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

 

-Burke

 

On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

I don't think anyone has qualms about our ability to get person attributes (date, sex, dead, name, home address, contact info, relationship info) from providers when the provider is internal to the organization.  The problem comes with providers external to the organization, as to whom we may receive substantially no attribute information (but for whom we have little or no processing responsibility).

 

Not all the provider attributes are person attributes or patient attributes, e.g. medical board number or insurance company provider number or office address/phone, so at least some attributes will always be in provider attributes, we won't want them to appear on the patient dashboard.    So my thought would be that we accept whatever attributes are provided and put them in provider attributes.  When we dedupe and have enough information to identify persons, then we can make a person and remove any duplicated attributes from provider attributes.  The automatic substitution of person.name (preferred) for provider.name where provider.person_id exists (which can be done in the POJO if not in the hbm).

 

I think Mark may be putting more into the person/non-person distinction than is there.  He really wants to know what providers his module is managing, and that should depend on a provider tag, a provider category, a provider attribute, a provider role or some other provider characteristic.  If he is trying to make some link between person.address and a CHW's territory, then I think he needs to have a CHW territory provider attribute with a default value of the person preferred address village field (or some such).

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Friday, April 20, 2012 4:05 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

Created ticket: https://tickets.openmrs.org/browse/TRUNK-3290

Ben

On Fri, Apr 20, 2012 at 9:49 AM, Mark Goodrich <[hidden email]> wrote:

The issue with provider.name vs provider.person.name is that now a Provider’s name could be either a String or a PersonName (or really a list of Person Names).  This makes it harder, for example, to develop a generic “Provider Demographics” widget.  Now this may be moot because Demographics implies Person.  The UI I’m designing in the Provider Management module will provide the means to handle editing Provider demographics information, and will be designed to only work with Persons who are Providers, not any Providers.  I don’t think this a huge deal, but I think Mike’s point is that since this is one of the first uses of the new Provider object and we are ignoring Personless providers, we might want to reconsider if it is worth having them at all.

 

Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe


Sent: Friday, April 20, 2012 8:16 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

PIH has asked for birthdate to be null for patients recently: https://tickets.openmrs.org/browse/TRUNK-3016  Use-case: when importing patients from past records that have missing date.



Mark: if the provider is linked to the person, provider.name is cleared and should defer to provider.person.name.  We need a simple API/pojo method for getting the name if it doesn't exist already.

Any changes decided upon here will not make it into 1.9.0.  Any change to the underlying datamodel or API at this point will force us to re-beta the 1.9.x line.

If we change our minds and make provider.person non null in 1.9.1 it is not the end of the world.  Creating person records for each null provider.person would be relatively easy using liquibase.  Mark's Provider dashboard would simply require that point release and would work more "completely".

I'm on the side of requiring providers to have a person record. person.gender doesn't have to be nullable: We could add an "unknown" gender to prevent NPE backwards compatibility.  person.birthdate could be nullable and make it an API/UI option if it is required on the person/patient/provider creation screens.  (with 10000 extra rows in the person_name table we will need to implement the lucene searches soon though: https://tickets.openmrs.org/browse/TRUNK-425)

Ben

On Fri, Apr 20, 2012 at 12:13 AM, Burke Mamlin <[hidden email]> wrote:

Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

 

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):

  • Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
  • Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)

That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

 

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

 

-Burke

 

On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: Providers and Persons

Roger,

 

I don’t think anymore is arguing for removing Provider Attributes…  we definitely are using provider attributes within the Provider Management module.

 

Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Friedman, Roger (CDC/CGH/DGHA) (CTR)
Sent: Monday, April 23, 2012 8:58 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

I don't think anyone has qualms about our ability to get person attributes (date, sex, dead, name, home address, contact info, relationship info) from providers when the provider is internal to the organization.  The problem comes with providers external to the organization, as to whom we may receive substantially no attribute information (but for whom we have little or no processing responsibility).

 

Not all the provider attributes are person attributes or patient attributes, e.g. medical board number or insurance company provider number or office address/phone, so at least some attributes will always be in provider attributes, we won't want them to appear on the patient dashboard.    So my thought would be that we accept whatever attributes are provided and put them in provider attributes.  When we dedupe and have enough information to identify persons, then we can make a person and remove any duplicated attributes from provider attributes.  The automatic substitution of person.name (preferred) for provider.name where provider.person_id exists (which can be done in the POJO if not in the hbm).

 

I think Mark may be putting more into the person/non-person distinction than is there.  He really wants to know what providers his module is managing, and that should depend on a provider tag, a provider category, a provider attribute, a provider role or some other provider characteristic.  If he is trying to make some link between person.address and a CHW's territory, then I think he needs to have a CHW territory provider attribute with a default value of the person preferred address village field (or some such).

 

From: [hidden email] [hidden email] On Behalf Of Ben Wolfe
Sent: Friday, April 20, 2012 4:05 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

Created ticket: https://tickets.openmrs.org/browse/TRUNK-3290

Ben

On Fri, Apr 20, 2012 at 9:49 AM, Mark Goodrich <[hidden email]> wrote:

The issue with provider.name vs provider.person.name is that now a Provider’s name could be either a String or a PersonName (or really a list of Person Names).  This makes it harder, for example, to develop a generic “Provider Demographics” widget.  Now this may be moot because Demographics implies Person.  The UI I’m designing in the Provider Management module will provide the means to handle editing Provider demographics information, and will be designed to only work with Persons who are Providers, not any Providers.  I don’t think this a huge deal, but I think Mike’s point is that since this is one of the first uses of the new Provider object and we are ignoring Personless providers, we might want to reconsider if it is worth having them at all.

 

Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe


Sent: Friday, April 20, 2012 8:16 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Providers and Persons

 

PIH has asked for birthdate to be null for patients recently: https://tickets.openmrs.org/browse/TRUNK-3016  Use-case: when importing patients from past records that have missing date.



Mark: if the provider is linked to the person, provider.name is cleared and should defer to provider.person.name.  We need a simple API/pojo method for getting the name if it doesn't exist already.

Any changes decided upon here will not make it into 1.9.0.  Any change to the underlying datamodel or API at this point will force us to re-beta the 1.9.x line.

If we change our minds and make provider.person non null in 1.9.1 it is not the end of the world.  Creating person records for each null provider.person would be relatively easy using liquibase.  Mark's Provider dashboard would simply require that point release and would work more "completely".

I'm on the side of requiring providers to have a person record. person.gender doesn't have to be nullable: We could add an "unknown" gender to prevent NPE backwards compatibility.  person.birthdate could be nullable and make it an API/UI option if it is required on the person/patient/provider creation screens.  (with 10000 extra rows in the person_name table we will need to implement the lucene searches soon though: https://tickets.openmrs.org/browse/TRUNK-425)

Ben

On Fri, Apr 20, 2012 at 12:13 AM, Burke Mamlin <[hidden email]> wrote:

Actually, allowing persons to exist without names, genders, or birthdates will probably have broader implications on existing code (possibly introducing a wave of NPEs) than whether or not providers, who aren't being used anywhere yet, are required to be linked to a person record.

 

Would the allowance for person records without names, genders, or birthdates be allowed for persons linked to patients and/or users as well?  We don't want patients without names, genders, or birthdates do we?  I could imagine (and think folks might appreciate) creating user accounts without requiring genders/birthdates, but I'm not thrilled about supporting users without names.  So, we end up with something like this (with provider, like user & patient, requiring a person record):

  • Person stubs (not linked to user, patient, or provider) and Patients (i.e., person records linked to a  patient) still require name, gender, and birthdate.
  • Person linked to a user or provider (but not patient) must at least have a name (gender & birthdate become optional)

That would mitigate a large number of the potential NPE, meaning that only code assuming that all persons have known genders or birthdates be refactored.

 

FWIW, I'll try to chat with Shaun tomorrow about the implications for de-duplication efforts.

 

-Burke

 

On Thu, Apr 19, 2012 at 11:00 PM, Michael Seaton <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list