Carl, thanks for the useful comments .
First, services and components: I use “service” to indicate a programmatic activity to be carried out and “component” to indicate the organizational unit responsible for delivering the service. As I read/misread HPD, its service-related concept is specialty – a doctor might offer “TB diagnosis & treatment” as a specialty, and you could make an appointment with him/her for that purupose at whatever facility s/he has privileges. I would rather see a facility participate in the TB program at a service level which provides TB diagnosis service, HIV screening service, TB lab service, and TB observed treatment service through its TB clinic; patients can make appointments with the TB clinic from among those health workers that are associated with it. It may be that we need to offer both facility-first and provider-first appointment making, but once patient, provider and location are together in an appropriate encounter type,the manner of selection is unimportant.
So what I am saying is that services are fine-grained enough for program evaluation, although in some cases the service might be further refined by encounter type or provider or orderable (e.g… TB diagnosis service might have encounter types for “initial diagnosis”, “in-trreatment evaluation” and “adverse event”). As for data associated with services, that would be name, description, program/service levels providing the service. There would also be some program-associated facility data in the FR for reporting (e.g. for facilities that do ART, number of patients on ARVs).
Second, organizations, facilities, sub-facilities and hierarchies: I would love to have the ability to roll up facility data along multiple hierarchies based on both geography (civil boundaries, catchment areas) and organization (MOH, NGO). I really like the idea of hierarchies being maintained separately from the facility, especially in countries with changing civil boundaries, where you may need to display today’s data on yesterday’s boundaries to include old aggregate data. However, most people are using DHIS2 for their FR and DW, it’s much more important to be able use its roll-up/drill-down capabilities based on the principal hierarchy, and that becomes the controlling factor. So if you are saying that the facility is a leaf node in a geographical or organizational hierarchy, and the clinics and zones are all in a separate hierarchy subordinate to their parent facility, then we are in agreement.
For example, suppose a facility consists of an ANC clinic, an adult outpatient clinic, a HIV clinic, and a TB clinic. Each clinic performs HIV rapid tests, and we need to know how many are performed in each clinic. These seem like organizational units. But let’s suppose that this facility has a large campus and the ANC clinic is in a separate building with labor & delivery, neonatal ICU, and early childhood clinic; now the component has its own address, but we still want it to roll up with the facility for statistical purposes. Let’s also suppose the facility runs a CHW program that does HIV testing; the CHWs work in zones within the catchment area, but the catchment area doesn’t correspond to civil boundaries; their locations should not be used because it would interfere with rolling up to the facility. Mobile clinics could be treated the same way as CHW zones to roll up to the facility, or they could be treated as separate facilities in their actual locations to roll up with the principal hierarchy.
Note that HPD and Resource Map allow multiple hierarchies, so facilities and components could be linked to a node in each of several hierarchies, but neither product rolls up facility data.
Saludos, Roger
···
Hi Roger,
Per your query about the CSD data model: I agree that CSD is a bit unclear at this point. There has been some discussion to allow a “parent” attribute to be added to the facility entity so that a hospital could be composed of wards/departments (is that what you were thinking of?) or have satellite clinics.Personally, I think the CSD facility is more akin to FIHR’s location. In the above example, I think this type of relationship is more organizational rather than physical. As such, what I would recommend would be something along the lines:
- An organizational entity for a hospital
- A facility entity for the hospital that is part of this organization
- A facility entity for each of the wards/departments that are also a part of this organizational entity
If you need more depth in the hierarchy, then this can be represented through additional organizational entities. There is parent attribute to an organization so you could do something like:
- A organizational entity for a hospital
- A child organizational entity for the associated satellite clinics
- A child organizational entity for each of the departments in hospital
- the facilities are then assigned to the appropriate child organizational entities.
What’s missing from the definition of a service in your opinion?
Cheers,
-carl
On Thursday, May 29, 2014 10:33:36 AM UTC-4, Roger Friedman wrote:
Folks, sorry for those who get spammed with this due to overlaps. This paper is not totally done but has been delayed and I decided to send it out now because I thought it might be relevant to upcoming discussions. Please read the disclaimer. Don’t be misled by its formal appearance, it’s primarily for discussion, open for comment and revision, and available to be chopped up and put into other documents. The Word document and graphics are available upon request.
One topic which I would like to discuss is the CSD data model. I definitely think there is a need to be able to have substructure within a facility and for a clear definition of what is meant by a service.
-----Original Message-----
From: Carl LeitnerSent: May 29, 2014 11:22 AM
To: ohie-architecture@googlegroups.com
Cc: facility-registry@googlegroups.com, open-hmis@googlegroups.com, chris@jembi.comSubject: Re: Discussion paper on master facility lists
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.