On Nov 3, 2016, at 9:46 AM, Kariuki, James M. (CDC/CGH/DGHT) <firstname.lastname@example.org> wrote:
Here is a graphic I created to illustrate the mapping/relationship between indicator (numerators, denominators and disaggregation) with the patient level data elements.
Is there a way to represent the logic for calculating/aggregating indicator values from patient level data as FIHR resources?
From: Carl Leitner [mailto:email@example.com]
Sent: Thursday, November 03, 2016 8:00 AM
To: firstname.lastname@example.org <mailto:email@example.com>
Cc: Bob Jolliffe <firstname.lastname@example.org <mailto:email@example.com>>; Luke Duncan <firstname.lastname@example.org <mailto:email@example.com>>; firstname.lastname@example.org <mailto:email@example.com>; firstname.lastname@example.org <mailto:email@example.com>; firstname.lastname@example.org <mailto:email@example.com>; Kariuki, James M. (CDC/CGH/DGHT) <firstname.lastname@example.org <mailto:email@example.com>>; Carol Macumber <firstname.lastname@example.org <mailto:email@example.com>>; John Gresh <firstname.lastname@example.org <mailto:email@example.com>>
Subject: Re: iHRIS and DHIS2 support for Terminolgy Services
There are also ways that you can express relationships between code systems.
One place to start is looking at a Concept Map:
which lets you define relationships between one or more code systems (via Value Sets). They types of relationships defined are here:
There is another type of relationship that can be defined in the code system itself in which concepts can have children associated to them:
http://build.fhir.org/codesystem-definitions.html#CodeSystem.concept.concept (the last thing on the page)
which can have an "is-a” “contains” or “categorizes” relationship
I suppose that this gives us two ways to express hierarchy. One through the child concepts, and one (possibly) through the “narrower” equivalence in a concept map.
For the ADX stuff specifically, I was thinking you would want your indicators to be a code system and use the one or more properties to associate them to one or more sets of disaggregators.
On Nov 3, 2016, at 2:23 AM, Grahame Grieve <firstname.lastname@example.org <mailto:email@example.com>> wrote:
From a FHIR perspective, CodeSystems define concepts that have 3 things:
- codes that represent them to computers
- designations that represent them to humans (one of which is the default for general use)
- properties that define extra things about the concept
The last moves us away from simple lists towards complex multi-dimensional structures. And 'terminologies' can be used this way for .... well, medications is the primary reason. See RxNorm, AMT, DM+D, SNAPP... there are many around the world. And also, there are code systems that use a similar approach for defining data elements - LOINC is pretty much at that point.
From our point of view in FHIR, this starts to look like elegant forms of Origami - trying to fold complex structures into generic reference models of [concept+code+designations+properties] delivered by terminology service. Rather than doing that, we define specific resources that capture the complexities of these things directly. Specifically, we have Medication and DataElement for these purposes (and a few others on the design table for next round). I recommend that you look at those 2 resources. Note that we assert (loosely, for now) a relationship between those resources and terminologies. e.g. a repository of Medication resources also implicitly defines a vocabulary summary of the medications, that you can subset etc. There's things about that relationship that aren't nailed down and operationalised yet - that's where the terminology focus will be for the next version of FHIR
On Thu, Nov 3, 2016 at 10:48 AM, Bob Jolliffe <firstname.lastname@example.org <mailto:email@example.com>> wrote:
Placing myself at some risk of appearing ignorant can i ask some very general questions about terminology, ontology and FHIR?
Mostly when we see terminologies they appear as lists of one sort or another. Sometimes they can have some sort of hierarchical structure but still inherently list like.
Sometimes (often) ontology requirements demand more graph structure than simple lists. They need to express more complex relationships which will may well include reference to lists. I am thinking here of ontology service like (for a dated example, ISO Topic Maps or W3C RDF).
So my first question is to ask whether I am right in interpreting the scope of terminology service in this way. ie. as a sort of controlled vocabulary repository. Or does it or can it drift into more general ontology service?
My motivation for asking relates to the ADX use case in Carl's document. There is a figure there called "Get Structural Metadata". Structural metadata is a term I crib from ISO SDMX because I think it captures the notion of structural ontology quite well. But let me get even more concrete.
An ADX dataset is typically a routinely reported public health report (eg. Monthly malaria case report). It consists largely of reported dataelements (How many confirmed malaria cases? How many suspected malaria cases? How many tests performed? etc). Some of these dataelements might be further disaggregated (commonly by age and or gender but also others). So the structural metadata for an ADX dataset will contain references to various coded vocabularies but is itself a more complex ontological beast. It must refer to a list of dataelements but also indicate how each of these dataelements should be disaggregated.
So my next question is what might be a recommended FHIR way to represent such a resource? Whether or not we consider it as part of terminology service. (In fact one can view it as a hierarchical codelist though perhaps with additional attributes eg. the periodicity of the report being monthly, weekly, quarterly etc)
Sorry for basic questions. I only took a close look at Carl's work on DHIS2 terminology recently and am hovering over inclusion into new revision of ADX profile. I am fairly confident we will be able to use FHIR (even if just for the controlled vocabularies) but I wonder about the best way of dealing with the graph that binds them together into an ontological whole.
On 1 November 2016 at 19:33, Grahame Grieve <firstname.lastname@example.org <mailto:email@example.com>> wrote:
I can't answer for Apelon, but I'll answer the other stuff:
I assume that the create/update transactions are supported. Are the history transactions already supported?
my server does support history. and history is intended to support pub/sub or synchronization. Note, though, that the Australian national terminology service uses Atom because it's also able to distribute other kinds of terminology resources. (they could have used FHIR binary for that, but chose not to)
What do you think is the best way to structure a generic "sync" service that is a pull against a source server/directory w/ a timestamp. I was thinking of using the "history" transaction at either the resource type level or the whole system level. I suppose that we could also use the search transaction if we only need the current state.
the problem with search is that it isn't robust about removing things - you never get notified about things that fall out of the search. So definitely history.
It looks like your reference server supports some terminology service functionality (value set management). Does it also provide UIs for code system and concept map management?
no. we're intending to write a generic electron client that does those things - in fact, CSIRO already have a concept map manager ready to contribute , but it hasn't happened yet.
http://www.healthintersections.com.au/> / firstname.lastname@example.org <mailto:email@example.com> / +61 411 867 065
You received this message because you are subscribed to the Google Groups "Terminology Services" group.
To unsubscribe from this group and stop receiving emails from it, send an email firstname.lastname@example.org <mailto:email@example.com>.
For more options, visit https://groups.google.com/d/optout.
<Indicator_patient level data element mapping.png>