The other relevant point is "Organizational Role", which is something we intend to attach to Person.
Perhaps we'd use the same thing for providers in the long run? -Darius On Wed, Mar 14, 2012 at 9:24 AM, Burke Mamlin <[email protected]>wrote: > I would use a provider attribute type of "Provider Role", as you suggest. > It's likely that this could be rolled into the provider table and making > that change should be relatively straightforward. > > It's worth noting that provider, like user, is itself a role, not a > distinct person. This means that we'd allow for a single person to have > multiple entries in the provider table (e.g., a doctor who practices in two > subspecialties) linked to the same person. So, I wouldn't worry about > allowing multiple provider roles for a single provider record; rather, make > separate provider entries when multiple provider roles are needed for the > same person. > > Our long-term goal is for the effort of representing distinct individuals > to happen at the person level. While we all know that data always can get > messy, our assumption is that an individual shouldn't be more than one > person (that's why we created a merge feature for persons). Users, > providers, and – eventually, probably only with a major API version change > – even patient could/should be allowed (at the API level) to be many-to-one > to person. > > -Burke > > On Wed, Mar 14, 2012 at 12:01 PM, Mark Goodrich <[email protected]> wrote: > >> ** ** >> >> All this feedback has been helpful…**** >> >> ** ** >> >> I definitely would be interested additional thoughts on Mike’s point >> about a “Provider Role” in his previous email… we are likely to model CHWs >> as Providers in the system. However, there are different CHW roles that >> define what kind of services the CHW could provide. We could track the >> role(s) a CHW has by creating a ProviderAttributeType of “CHW Role”, or, >> possibly, a more generic “Provider Role”, and it sounds like this may be >> the preferred approach. But associating a role with a provider seems like >> a standard enough need that relegating it to a custom attribute type seems >> like the wrong (at least long-term) solution. **** >> >> ** ** >> >> Thoughts?**** >> >> ** ** >> >> Mark**** >> >> ** ** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke >> Mamlin >> *Sent:* Wednesday, March 14, 2012 10:02 AM >> >> *To:* [email protected] >> *Subject:* Re: [OPENMRS-DEV] Modelling Provider Types and Provider >> Services in OpenMRS**** >> >> ** ** >> >> Sorry, didn't mean to be glib. I was in clinic, so could only throw out >> some thoughts. Probably should've mentioned that.**** >> >> ** ** >> >> Jonah created a household module that we should cultivate. I would like >> to see OpenMRS evolve to have more robust cohorts along with cohort-level >> observations that would subsume much of what Jonah has created in his >> module. But that will take some design conversations & some time to get in >> place.**** >> >> ** ** >> >> OpenMRS core will be unlikely to meet all the needs of any specific CHW >> program out of the box, since the personnel management, scheduling needs, >> etc. for a CHW program are likely to go beyond the scope of an EMR. I >> believe what PIH folks are trying to do (and I applaud them for it) is to >> try to tease out the common needs across CHW programs so that efforts can >> leverage OpenMRS in a consistent way and go toward a single, shared module >> instead of everyone creating their own.**** >> >> ** ** >> >> -Burke**** >> >> On Tue, Mar 13, 2012 at 10:45 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < >> [email protected]> wrote:**** >> >> Burke, I think this reply is a little glib for the CHW situation. CHWs >> tend to be household-based or geography-based, making the relationship >> model a little bit gimpy. CHWs also tend to be program oriented, so the >> CHW needs to be a provider of program services for programs in which they >> have been trained. Also, their encounters tend to be group-oriented, for >> which we don’t have easy data entry mechanisms. I think it would be useful >> to convene a brainstorming session around CHWS, maybe Andy Kanter could >> make happen. **** >> >> **** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke >> Mamlin >> *Sent:* Tuesday, March 13, 2012 12:26 PM**** >> >> >> *To:* [email protected] >> *Subject:* Re: [OPENMRS-DEV] Modelling Provider Types and Provider >> Services in OpenMRS**** >> >> **** >> >> The encounter represents a clinical transaction in our model, so as Ben >> suggests, a provider providing clinical services for a patient would fall >> into an encounter, which (eventually) could generate any number of >> observations, orders, notes, or form data. >> >> For denoting ongoing relationships between persons (e.g., providers & >> patients), we would use the relationship model. >> >> To connect multiple encounters over time, you could use the visit model >> (created to group encounters, but usually representing a series of >> contiguous encounters) or the yet-to-be-implemented episodes of care, which >> are designed to connect encounters related to a treatment program across >> multiple, possibly non-contiguous, visits (e.g., pregnancy). >> >> FWIW, I believe we added (or planned to add) date ranges to >> relationships; however, if you want to track "service" (possibly for >> billing purposes), then I would suggest using visits, since that's where an >> account number would go. >> >> Note that these aren't mutually exclusive. For example, you could create >> relationships to track relationships between accompagnateurs and their >> patients and still record encounters +/- visits for clinical transactions >> between the provider and their patient. >> >> -Burke**** >> >> On Tue, Mar 13, 2012 at 11:59 AM, Mark Goodrich <[email protected]> >> wrote:**** >> >> Ben,**** >> >> **** >> >> Hmm… that may be the way to do it generically, but I don’t know if it >> works for us since we need to model this over time.**** >> >> **** >> >> Mark**** >> >> **** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Ben Wolfe >> *Sent:* Tuesday, March 13, 2012 11:39 AM >> *To:* [email protected] >> *Subject:* Re: [OPENMRS-DEV] Modelling Provider Types and Provider >> Services in OpenMRS**** >> >> **** >> >> Would you be able to store these as the encounterrole for that CHW for >> each encounter? >> >> Ben**** >> >> On Tue, Mar 13, 2012 at 11:21 AM, Mark Goodrich <[email protected]> >> wrote:**** >> >> I’ve been looking at the new Provider model in 1.9, and I was wondering >> if thought has been put into modeling provider types (Cardiologist, PCP) >> and specific provider services, and how to record that a provider provided >> a specific service to a patient. Do we have a vision as to how we may want >> to model this going forward?**** >> >> **** >> >> The reason I’m asking is that I’m currently working on determining how >> PIH wants to model Community Health Workers within our system, and I’m >> considering how they may fall into a more generic provider structure. We >> want to be able to handle various types of CHWs (Accompagnateurs, Pallative >> care workers, Community Health Nurses) that provide various services (HIV >> accompaniment, end-of-life care, etc) that we’d like to be able to model, >> and then we’d like to be able to track what services are being provided to >> what patients. Additionally, we need to track the dates over which a CHW >> provided such a service, ie:**** >> >> **** >> >> “Accompagnateur A provided HIV accompaniment to Patient B from 1/2/2010 >> to 3/4/2011” **** >> >> **** >> >> At first, it seems like Relationships would be the way to model this kind >> of interaction, since a relationship defines a relationship between two >> people, and (as of 1.9) can have a start date and an end date. However, it >> doesn’t quite seem to be the right way to do this, primarily because a >> relationship is a Person-to-Person relationship, when what we are modeling >> is a Provider-to-Patient relationship. It seems like this is an >> archetypical relationship in an EMR that it may make sense to model in a >> different manner than general relationships.**** >> >> **** >> >> Take care,**** >> >> Mark**** >> >> **** >> ------------------------------ >> >> 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]
