We had a discussion of facility lists here today, and there seemed to be strong support for a capability to represent some structure within a facility. This might be inpatient/outpatient, might identify different clinics, might separate delivery points of a mobile clinic, might distinguish medical activities from affiliated activities (lab, pharmacy, dentist, feeding station, prosthesis workshop). This would be most useful for recording service statistics. The data elements and relationships with services, providers and organizations are the same as facilities, although there might be some inheritance logic for data elements. The need is to present data either aggregated over or disaggregated by sub-facilities. This should not be represented by extending the facility’s hierarchical id another level, because the reporting relationships are subject change as the result of relocation or by administrative fiat; the relationship should be represented separately.
I agree with Paul, it does seem like we are adjusting scope and getting everyone on the same page for what terminology should be stored in the TS is important. To me each registry should be the source of truth for its domain. For the facility registry this would mean that it keeps an up to date list of facilities and data about a facility. However, you can imagine that there are also code lists of metadata that are needed by a number of registries. For example ‘facility_types’, ‘administrative_units’ or ‘provider_types’. This sort of metadata, in my eyes, should be stored in the TS along with standardized clinical concepts (LOINC, ICD, etc). I’m thinking the the TS should be responsible of storing any common code lists used by the other systems in the HIE.
I’d like to take a stab at defining what this may include and see if we can come to consensus. Here is what I think makes sense to be stored in the TS:
- Clinical code systems (LOINC, ICD, SNOMED, etc)
- Administrative units (eg, the coded list of provinces, districts, sectors and cells within Rwanda)
- Common code systems for metadata (eg, a list of codes for provider_type, facility_type, etc - all the codes that Carl mention are needed by the CSD profile would fall under this category)
What do others think about these?
Cheers,
Ryan
···
On Wed, Dec 11, 2013 at 12:31 AM, r.friedman@mindspring.com wrote:
We had a discussion of facility lists here today, and there seemed to be strong support for a capability to represent some structure within a facility. This might be inpatient/outpatient, might identify different clinics, might separate delivery points of a mobile clinic, might distinguish medical activities from affiliated activities (lab, pharmacy, dentist, feeding station, prosthesis workshop). This would be most useful for recording service statistics. The data elements and relationships with services, providers and organizations are the same as facilities, although there might be some inheritance logic for data elements. The need is to present data either aggregated over or disaggregated by sub-facilities. This should not be represented by extending the facility’s hierarchical id another level, because the reporting relationships are subject change as the result of relocation or by administrative fiat; the relationship should be represented separately.
–
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/groups/opt_out.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org