Is the TS doing i18n as well as acting as a registry? Is the TS maintaining facility-specific terms, e.g. “Regimen 1d” for “AZT-3TC-EFV” (itself a synonym). Is the TS maintaining semantic relationships among terms? Is the TS maintaining facility-specific relationships, e.g. drugs in the formulary, lab tests in a test panel, available diagnostic procedures?
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.
Lots of good questions here. A TS is generally capable of holding any structured data set with a defined set of attributes (metadata) and associated values. Typically one starts with the “standard” clinical terminologies, SNOMED CT, LOINC, etc. These tend to be very rich structures having both vertical (parent/child) and horizontal relationships. Ususally these are called “semantic” but I caution that the definition of “semantic” is often in the eye of the beholder. I18N considerations such as alternate names (synonyms) in alternate languages are typically supported.
The next step is usually “local” terminologies, e.g. clinic X’s lab test names. These names, along with their metadata: codes, synonyms, definitions, etc., can be loaded. Each of these “concepts” (names) may then be given a link (aka association or map) to one of the standard terminologies. These are the structures used by the interoperability layer for message translation. The TS group has tried to use the names “reference terminologies” for the former and “interface terminologies” for the latter.
I am certainly not informed enough to understand what parts of a registry, say the facility register, should be in one place or the other. If a user application wants to know what metadata is associated with a registry entry, where should it go? To the registry or the TS? Now if any part of this metadata need to be “mapped” to an external standard, say what is the canonic SCT code for “Facility Name”, then this would seem to be grist for the TS, although it could also simply be held in the registry. One reason for using the TS is that it would be most aware of what needs to happen when SNOMED, in its infinite wisdom, decides to inactivate its current code for “Facility Name” in favor of a different code.
Again I would ask about the specific use-cases folks feel need to be supported.
Is the TS doing i18n as well as acting as a registry? Is the TS maintaining facility-specific terms, e.g. “Regimen 1d” for “AZT-3TC-EFV” (itself a synonym). Is the TS maintaining semantic relationships among terms? Is the TS maintaining facility-specific relationships, e.g. drugs in the formulary, lab tests in a test panel, available diagnostic procedures?
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?
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.
Thanks for the insightful response. Maybe I can take a stab at defining the uses cases I see as useful (within a HIE environment):
The Interoperability Layer validates a particular clinical code with the TS to ensure that it exists
The Interoperability Layer requests the reference terms for a particular interface term from the TS so that it can normalize a message
Other registries query for an updates list of metadata codes so that they can update their internal list.
I’m sure there are more but these are the major ones that stick out to me.
Lots of good questions here. A TS is generally capable of holding any structured data set with a defined set of attributes (metadata) and associated values. Typically one starts with the “standard” clinical terminologies, SNOMED CT, LOINC, etc. These tend to be very rich structures having both vertical (parent/child) and horizontal relationships. Ususally these are called “semantic” but I caution that the definition of “semantic” is often in the eye of the beholder. I18N considerations such as alternate names (synonyms) in alternate languages are typically supported.
The next step is usually “local” terminologies, e.g. clinic X’s lab test names. These names, along with their metadata: codes, synonyms, definitions, etc., can be loaded. Each of these “concepts” (names) may then be given a link (aka association or map) to one of the standard terminologies. These are the structures used by the interoperability layer for message translation. The TS group has tried to use the names “reference terminologies” for the former and “interface terminologies” for the latter.
I am certainly not informed enough to understand what parts of a registry, say the facility register, should be in one place or the other. If a user application wants to know what metadata is associated with a registry entry, where should it go? To the registry or the TS? Now if any part of this metadata need to be “mapped” to an external standard, say what is the canonic SCT code for “Facility Name”, then this would seem to be grist for the TS, although it could also simply be held in the registry. One reason for using the TS is that it would be most aware of what needs to happen when SNOMED, in its infinite wisdom, decides to inactivate its current code for “Facility Name” in favor of a different code.
Again I would ask about the specific use-cases folks feel need to be supported.
Is the TS doing i18n as well as acting as a registry? Is the TS maintaining facility-specific terms, e.g. “Regimen 1d” for “AZT-3TC-EFV” (itself a synonym). Is the TS maintaining semantic relationships among terms? Is the TS maintaining facility-specific relationships, e.g. drugs in the formulary, lab tests in a test panel, available diagnostic procedures?
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?
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.
From our perspective (dhis2 aggregate data warehouse) what we generally need to exchange in order for systems to formulate routine reports are relatively simple code lists (eg. facility code=‘HP45’, total confirmed malaria cases=‘MALC’ etc ). Similarly in interactions with other registries such as resource mapper there are typically facility type, ownership (public, private, ngo etc).
There are many ways such codes can be exchanged, but it seems likely to me that a terminology server could in principal act as a common reference point for these. Whether it adds another layer of complexity without adding significant value is maybe less clear. I am not really too sure. As Paul says, it depends really whether there is a case for extending a medical terminology server into a more general registry of health system codelists. There might well be. Failing which (or perhaps even in addition) most of those codelists, at least the ones relevant to dhis2, are available through the dhis2 web api.
···
On 13 December 2013 09:11, Ryan Crichton ryan@jembi.org wrote:
Hi Jack,
Thanks for the insightful response. Maybe I can take a stab at defining the uses cases I see as useful (within a HIE environment):
The Interoperability Layer validates a particular clinical code with the TS to ensure that it exists
The Interoperability Layer requests the reference terms for a particular interface term from the TS so that it can normalize a message
Other registries query for an updates list of metadata codes so that they can update their internal list.
I’m sure there are more but these are the major ones that stick out to me.
Cheers,
Ryan
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
Lots of good questions here. A TS is generally capable of holding any structured data set with a defined set of attributes (metadata) and associated values. Typically one starts with the “standard” clinical terminologies, SNOMED CT, LOINC, etc. These tend to be very rich structures having both vertical (parent/child) and horizontal relationships. Ususally these are called “semantic” but I caution that the definition of “semantic” is often in the eye of the beholder. I18N considerations such as alternate names (synonyms) in alternate languages are typically supported.
The next step is usually “local” terminologies, e.g. clinic X’s lab test names. These names, along with their metadata: codes, synonyms, definitions, etc., can be loaded. Each of these “concepts” (names) may then be given a link (aka association or map) to one of the standard terminologies. These are the structures used by the interoperability layer for message translation. The TS group has tried to use the names “reference terminologies” for the former and “interface terminologies” for the latter.
I am certainly not informed enough to understand what parts of a registry, say the facility register, should be in one place or the other. If a user application wants to know what metadata is associated with a registry entry, where should it go? To the registry or the TS? Now if any part of this metadata need to be “mapped” to an external standard, say what is the canonic SCT code for “Facility Name”, then this would seem to be grist for the TS, although it could also simply be held in the registry. One reason for using the TS is that it would be most aware of what needs to happen when SNOMED, in its infinite wisdom, decides to inactivate its current code for “Facility Name” in favor of a different code.
Again I would ask about the specific use-cases folks feel need to be supported.
Is the TS doing i18n as well as acting as a registry? Is the TS maintaining facility-specific terms, e.g. “Regimen 1d” for “AZT-3TC-EFV” (itself a synonym). Is the TS maintaining semantic relationships among terms? Is the TS maintaining facility-specific relationships, e.g. drugs in the formulary, lab tests in a test panel, available diagnostic procedures?
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?
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.