FHIR Chat · Extending Questionnaire to support disaggregation · implementers

Stream: implementers

Topic: Extending Questionnaire to support disaggregation

Bob Jolliffe (Jan 18 2017 at 14:43):

Hi. I am a bit of a newbie so apologies if my question is silly. I am looking at using the Questionnaire resource to support facility routine reports. Often the questions in such reports have disaggregated dimensionality. For example a question "How many confirmed malaria cases this month" might be further disaggregated into males/females and how many under 5y, u12y, "12 y and over" etc. The equivalent paper form would show a grid. I think I can (by extending) indicate that questions on a Questionnare are further disaggregated by codes in valuesets. But the QuestionnaireResponse wouldn't really work as it expects an atomic single answer per question. I wonder is there a sensible way to approach this without resorting to having a single question for each cell in the multi-dimensional grid.

Bob Jolliffe (Jan 18 2017 at 14:46):

Is there a more specific Questionnaire specific forum to ask this question, please let me know.

Lloyd McKenzie (Jan 18 2017 at 14:58):

This is the right stream and that's definitely not a newbie level question :)

The expectation would be that the base question would have a bunch of child questions - one per "code". The answers would then mirror that. (BTW - in your example, what's the vertical axis for your grid?)

Bob Jolliffe (Jan 18 2017 at 16:29):

The vertical axis would be the dataelement or "base question". So you can imagine a left hand column of a grid with questions like "Number of confirmed malaria cases", "Number of suspected malaria cases" etc.

Lloyd McKenzie (Jan 18 2017 at 17:24):

k. So essentially a group of groups of questions where child group = row and questions = columns

Bob Jolliffe (Jan 18 2017 at 18:58):

sort of yes. In fact each base question expands into a tree of sub-questions when you consider all the disaggregation permutations (male/under5, female/under5. male/5-10, female/5-10, etc). I don't really want to explicitly and repetitively write that out - I'd rather just say that these questions are disaggregated by the following valuesets (age group and gender in this case). Just exploding out all the questions is going to get very verbose. Maybe that is what I have to do but it feels redundant and awkward for what is really an extremely common use case. I'm looking for a better way but might mean I have to break the semantics of Questionnaire as it is intended.

Grahame Grieve (Jan 18 2017 at 19:06):

I'm wondering what kind of structure you might have to represent this

Bob Jolliffe (Jan 18 2017 at 21:41):

Sorry Grahame I don't really know exactly - that is what I am trying to find out. I think I need in the QuestionnaireResponse (i) multiple answer elements to a question - which appears to be allowed - and (i) something more than the <linkid/> to key the answers back both to the question and also the disaggreagtion options. I think I can extend the answer element in the QuestionnaireResponse to provide the extra keys (eg Male and under5). I am going to have to work through some concrete example and maybe present a link here for comment/input.

Grahame Grieve (Jan 18 2017 at 21:45):

ok. sure. but I've seen a far few questionnaires in a variety of systems and I don't think that this is actually an extremely common use case - there are so many variations...

Lloyd McKenzie (Jan 18 2017 at 22:35):

At the moment, you'd have to list all the child questions on the questionnaire side and corresponding responses with link ids on the QuestionnaireResponse side. It's not super-concise, but it's consistent with how everything else is designed and it would work.

Bob Jolliffe (Jan 19 2017 at 10:18):

Maybe routine reporting systems are something of a special case. The system I am working on (DHIS2.org) is used in over 50 countries mostly in Africa and Asia. These routine reports are the life blood of the health information flows in most of those countries. And these disaggregated questions are very common. Perhaps it is because the health facility and its catchment population is the subject of the questionnaire, whereas many of the questionnaires you have in mind are patient centered? So the data has an intrinsic "statistical" quality to it - the dimensions of data are important for subsequent analysis rather than just a peculiarity of layout.

Bob Jolliffe (Jan 19 2017 at 10:32):

Thanks Lloyd. I had also figured out that this was the way it would have to work at the moment. I was just wondering what the hopes are of enhancing it. That a question might have multiple answers and the answers might be keyed, not just by the linkid of the question, but also by keys from a valueset(s). The issue with using the Questionnaire currently is less about conciseness (though that can also be an issue) but more that there is information lost (which are males, which are females?). You could retain that either by encoding somehow in the linkid or through elaborate and repetitive grouping, but I am not sure either is attractive. Just to provide some context, I am currently leading the development of a profile within IHE to represent these aggregate routine reports. Our requirements are maddeningly close to what is in Questionnaire ...

Pascal Pfiffner (Jan 19 2017 at 11:27):

If I understand correctly it doesn't seem that you'll lose information, and I don't think the grouping in this particular case is all that elaborate (but undoubtedly repetitive). With a structure similar to the following, you'd have the responses you desire in a format that hierarchically makes sense to me. The problem left then is the repetitiveness of all the items in each group – allowing a reference to a certain item in the questionnaire could mitigate that, but that would certainly increase complexity for those rendering the resource.

resourceType: Questionnaire
item:
  - type: group
    linkId: has-malaria
    text: Number of confirmed malaria cases
    item:
      - type: integer
        linkId: male-under-5
        text: Male under 5
      - type: integer
        linkId: female-under-5
      - type: integer
        linkId: male-5-to-10
      ...
  - type: group
    linkId: malaria-suspected
    text: Number of suspected malaria cases
    item:
      - type: integer
        linkId: male-under-5
      ... (same as above)

Marc de Graauw (Jan 19 2017 at 13:16):

I guess I'd use some custom XML/JSON to model the questions/categories like:
Questions:
- "Number of confirmed malaria cases"
- "Number of suspected malaria cases"
- ...
Categories:
- Age group (<5, 5-10...)
- Gender (F, M)
...
And use XSLT/JS to generate the Questionnaires / QuestionnaireResponses from those. That way you keep conciseness in the custom definitions. The Q/QR will get very verbose, but for using those as an exchange format, that wouldn't bother me. (The alternative being using a custom exchange format instead of a standard.) The UI is something else: if you want to use the Questionnaire to generate a UI, this approach won't work, since you'll want a grid there...

Bob Jolliffe (Jan 19 2017 at 13:32):

Marc you hit the nail on the head. The problem is that the xslt generated Quetionnaire is not only verbose, but also harder to process. I can think of one example from a hospital in India where these routine reports were being generated from an emr using 1100 SQL queries. One for each question. And many of the queries almost identical. You can imagine 'where sex='M' and agegroup='<5'' etc. Now this was not fhir and you can question the merit of sql for this, but the principle is the same. What the emr module needed was the first form (pre-xslt) in order to reduce the number of indivually mapped sql queries drastically and make the whole process less error prone and more maintainable.

Bob Jolliffe (Jan 19 2017 at 13:32):

Can I legitimately create an extension child element of group which says "for this group of questions disaggregate using these valuesets"? And transmit that. I could of course generate the exploded items using xslt but it is a bit pointless.

Marc de Graauw (Jan 19 2017 at 13:45):

Basically, what you want to exchange is a pivot table-like structure, right? As far as I can see, Q/QR does not really fit that, and using an extension in itself won't help. What you'd need is an "answer type" and for the questions, say "use answer type X for question Y". What 80/20 concerns, this kind of data is very common in BI, so I see the point.

Bob Jolliffe (Jan 19 2017 at 16:14):

In summary your view is that the Questionnaire is the wrong resource to try and twist into this use :-( So I need to define something outside of fhir to represent these reporting forms. I can do that. Though I will part with the idea reluctantly. These monthly reports really are a lot like questionnaires. In a majority of cases (where there is no emr) they are filled in at the health facility on paper forms or directly on web forms. In some cases the data is generated. They are not simple pivot table structures as they typically have different sections which are disaggregated differently. But each section of a form can be a pivot table like structure. Generating routine reports from an emr (what some might call indicator reports) is a common use case which seems worth defining a resource for. I'd prefer to try and base it on questionnaire than create something completely custom. Let me chew on that. Thanks for the input thus far.

Lloyd McKenzie (Jan 19 2017 at 16:26):

You don't need to lose the information about what information is being captured - you have Question.code available, or if you want to capture the specific sub-axis values (gender vs. age group vs. whatever), you could capture those as extensions. (Those could be ignored by those who want to treat it as a straight questionnaire.) So if you have someone who supports your profile, they could understand the extension that says "render these groups and the child questions as a grid" and the extensions that identify the disaggregation groups. But someone who doesn't understand those extensions would still see all of the questions and be able to gather and display all of the data, though not with as much conciseness. That sort of safe degradation of behavior is what you should be aiming for. If you use a custom resource or something that doesn't use individual questions, then no-one who doesn't understand your specific interface will be able to do anything with your forms or information.

Bob Jolliffe (Jan 19 2017 at 16:34):

Thanks Lloyd, there is sense in what you say. Let me try and work through some examples of how that might look. Then I'll come back here looking for critique.

Lloyd McKenzie (Jan 19 2017 at 17:01):

Sounds like an excellent plan. Examples always help moving things forward. Please don't feel that we're not open to change, just that we have to be sensitive to managing complexity and ensuring there's a path for "simple" systems to still interoperate with more complex systems.

Grahame Grieve (Jan 20 2017 at 02:44):

how common is this use case? I think that Bob's point about statistical vs individual is a very good one. We've pretty much scoped Q/QR for the individual use case, but we could consider defining an extension pack for this?

Lloyd McKenzie (Jan 20 2017 at 04:05):

I think it's more about a form of data entry than individual vs. statistical - you can have grid entry for individuals as well as for populations. The question is whether the data gathered should be consumable by those who don't understand the extension(s).

Grahame Grieve (Jan 20 2017 at 09:04):

depends on what the author wants... there's always modifiers

Bob Jolliffe (Jan 20 2017 at 14:17):

You can see a fairly representative sample of routine report forms here - http:// moh.gov.rw/index.php?id=127. (These are from the Rwanda Ministry of Health). You will see that some of the forms using atomic dataelements already map neatly onto Questionnaire. Where there is disaggregation we want to try and retain that structure in the transmitted data (and hence the form description). Different countries do things slightly differently and different reporting sets use disaggregation more or less (HIV/ART related forms for example are always heavily disaggregated).

Bob Jolliffe (Jan 20 2017 at 14:21):

To answer "how common", most countries, even those with very low EMR penetration, make use of such routine reports. Usually with near 100% coverage of all registered facilities, so extremely impactful in terms of population covered. As mentioned above, some facilities will complete paper forms due to not having electricity, internet or facility systems. So "digitization" is an incremental process which must scale across different infrastructural environments.

Last updated: Apr 12 2022 at 19:14 UTC