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