The intent of "Organizational Role" was to serve as a job title – e.g., "Assistant Professor of Surgery" – that could be used for reports, signatures, letters, etc., allowing application roles to be modified as needed without affecting the person's job title. This might overlap with provider roles in some cases, but might not always be the same thing. I would imagine the provider roles would be supplied by the authority assigning the provider identifiers. In one case, an implementation may create their own list of providers and come up with a series of useful categories for provider roles like "Surgeon", "Health Care Worker", "Nurse", etc. In another case, an government or insurance agency might provide the implementation with a large list of physicians in the area, where the provider roles are closer to physician specialty. At this point, we didn't want to predetermine the needs; rather, allow for provider attribute (just like person attribute) to meet implementation-specific needs as we discover the patterns common across implementations.
-Burke On Wed, Mar 14, 2012 at 12:47 PM, Darius Jazayeri <[email protected]>wrote: > 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 >> > > ------------------------------ > 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]
