Created ticket: https://tickets.openmrs.org/browse/TRUNK-3290
Ben On Fri, Apr 20, 2012 at 9:49 AM, Mark Goodrich <[email protected]> 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:* [email protected] [mailto:[email protected]] *On Behalf Of *Ben Wolfe > > *Sent:* Friday, April 20, 2012 8:16 AM > *To:* [email protected] > *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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> wrote:** > ** > > Hi Burke, > > I understand your point. But is it all or nothing with regards to > constraints? If we remove the data model constraints on Person here, it > gives us the flexibility to address each use case as we see fit: > > * We allow Providers to be simply links to mostly-empty person records, > with a single Person name that contains a title and a surname. > * We allow Users to also be genderless and ageless (why should we care > about this here either)? > * We force Patients to have age and gender specified if entered via > certain service methods > * We leave the door open for Patients without gender or birthdate if > needed (eg. if I want to import from EPI Info, and some patients are > missing these fields) > > As it is now we will have a provider management module that will manage > _some_ providers, but not all. This isn't a deal-breaker, but it would be > better if it weren't so. > > We also have API methods that we have to deal with (and haven't done so > well as of yet) - for example, in trunk currently we have > Provider.getName() return simply the name property of the object. It does > not take the underlying Person into consideration at all. Yes, this could > (and should) be fixed, but it's just added complexity to now have 2 places > where names may be stored for a Provider. > > It just seems to me that we are over-complicating things unnecessarily, > and I want to put out this alternative design out for consideration... > > Mike **** > > > > > On 04/19/2012 03:23 PM, Burke Mamlin wrote: **** > > Mark, **** > > ** ** > > If we have (very useful) information about all providers in the district > and they contain title & identifiers like "Dr. Ochieng (1234-5)", are you > saying that we should not require gender, at least estimated birthdate, and > at least two names on Person to allow this?**** > > ** ** > > The key difference between a provider and a user is that a provider does > not have to *have* anything whatsoever to do with the EMR beyond being > references (e.g., capturing a referring provider from an external facility). > **** > > ** ** > > Defining a person without knowing their name, whether they're male vs. > female, or whether they're two years old vs. 50 years old would make Person > solely a linking tool – i.e., akin to auto-generating 100,000 nameless, > genderless, ageless records in the person table and picking the next one > when you want to link a patient to user, provider to user, etc. This is > directly counter to our effort to leverage Person as the one location > within which we focus our efforts to *avoid and address* duplication > errors.**** > > ** ** > > We could require that all providers are persons, but I don't believe we > should make all hopes at identification for person optional to do it; > rather, we'd need to come up with a solution for those folks who get the > list of providers like "Dr. Ochieng (1234-5)" and are missing the > demographics to generate a person.**** > > ** ** > > What's driving you to this conclusion? Is there some reason that you > can't limit yourself to providers linked to person records? Where is the > assumption that provider must be a person being made?**** > > ** ** > > -Burke**** > > On Thu, Apr 19, 2012 at 2:46 PM, Michael Seaton <[email protected]> wrote:** > ** > > Hi all, > > I brought up an idea buried in an email during the Provider Attribute > thread a few weeks ago, but it was lost a bit in all of the many other > points being made, so I wanted to raise it here again explicitly. > > I think making the link between Provider and Person optional is a mistake. > Here is my reasoning: > > * A Provider in OpenMRS is not meant to be a subclass. It is meant to be > a particular role in the health care system that a Person can have. And a > person may have many of these. > > * The most similar thing we have in OpenMRS to this is User. No users are > allowed in OpenMRS without being associated with a Person. User is > probably more accurately thought of as a User Account. Clearly a single > Person can hold multiple User Accounts. > > * The only real reason I can see for making Person optional is so that we > can avoid having to require things like "gender", "birthdate", etc. on > Provider that have traditionally been required of Person at the database > and API levels. For example, if we are uploading a list of 10,000 > providers from a national registry, and all we have is a String name, and > no gender or birthdate data. However, I think a more valid solution to > this problem is just to remove those data model and API restrictions, and > to make Person not require this data. Then, we just move those validation > constraints onto the Patient object if we desire (though to be honest we > don't always have this information here either, particularly if we are > importing data from a legacy system). > > So, I realize we are at RC3 for 1.9 and all, but my proposal would be to: > > * Make Person not null on Provider > * Make gender and birthdate nullable on Person > > This is particularly relevant to our team at PIH as we are currently > building a Provider Management module on top of 1.9. Mark has had to bake > in the assumption that all Providers have Person records (at least those > that can be managed with this module), because this is required for many of > our use cases - in particular the notion that Providers are linked to their > Patients and to other Providers via Relationships. > > I would be interested to hear others thoughts on this or if any of my > assertions / assumptions are just wrong. > > Thanks, > Mike > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]**** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
