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] >> >> _________________________________________ 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]
