FHIR Questionnaires and exchanging information

I had an interesting conversation on the skype ‘Implementers chat’ last week.

Like many others who are attending the FHIR connectathon in a couple of weeks, I’ve been working on scenarios involving  the Questionnaire resource (I’m writing a ‘template designer’ as well as a ‘form renderer’), and it occurred to me that it would be good to be able to share completed Questionnaires with others. I saw a similarity with sharing documents, and so asked the question whether the DocumentReference resource should be extended to permit the discovery and sharing on questionnaires as well.

Lloyd commented that his view was that the Questionnaire should not be a primary means of data exchange – that other resources are intended for that purpose, and that the Questionnaire doesn’t have ‘primacy’ over other resources. Grahame also commented that if you did wish to share a completed Questionnaire, then do so as you would any other resource.

That got me thinking.

A few years ago in New Zealand we developed a standard called the ‘Forms Server’ standard. The basic idea was that we would have a standardized way of representing a form template that could be shared between those needing to complete a form, and those needing the structured data within the completed form. A good example of this (and the one we were working with at the time) was a referral: in most cases when referring a patient to a specialist, there is data that is specific to that specialty that needs to be collected – a referral to a cardiologist will have different elements than one to a dermatologist.

We envisaged a central server that held these templates, and a standard that described their structure, plus the completion and transmission of the completed form. Potential referral recipients would upload templates containing the information they needed, and people making referrals would select the appropriate template to make the referral with. (We weren’t thinking of service discovery – just the templates and forms, and the manner that they could be shared). There was an associated standard way of getting data from referring systems (in our case primary care system), and another standard way of representing the actual referral, so in summary 3 major components:

• Template structure and discovery (local standard)
• Template pre-population (local standard)
• Referral form and workflow (based on HL7 v2).

In the end, although the standards were implemented, it didn’t go the way we hoped. It was more of an implementation architecture than a standard, and because they were local to New Zealand, they were only ever implemented by one vendor (though the primary care vendors who were creating the referrals hosted the components and made a local pre-population service available), and so the only way of creating and updating templates was through that vendors system – as was the dissemination of the referrals.

We had achieved the goals of a particular project, but not in a way that encouraged other vendors to join the market, nor established any kind of re-use for other purposes.

So, fast forward to FHIR.

With the Questionnaire resource (and the Referral resource that is being worked on at the moment), there are now the pieces need to fulfil our vision in a truly standardized way. (In the following discussion, do remember that the Questionnaire resource fills the purpose of both template and completed form, using the status property to distinguish between them).

Template Structure and discovery is, of course, the Questionnaire resource and the standard FHIR query mechanisms. I think that there need to be a couple of extra fields to support discoverability – so you can categorize Questionnaire templates and search for specific ‘types’ of template. There are some proposals that we’ll discuss in Phoenix, but we can always use extensions if we need to.

Pre-population needs a couple of things. First the template needs a coded way of describing what information is needed, and the ‘filling’ system needs to be able to locate that data within it’s own data stores.

Well, each question in the Questionnaire has a ‘name’ property of type CodeableConcept, so all that’s needed for that is a standardized terminology like SNOMED, and possibly agreement between users about which codes to use – SNOMED is vast, and not that easy to navigate after all. So, a ValueSet containing the common terms (like usual medications, conditions, allergies etc.) to use might make sense.

In fact, the Questionnaire also allows us to use ValueSets to directly define the options for a question.

We might also want to describe the relationship between entries in a Questionnaire, and other FHIR resources or CDA documents to make it easier for implementers to convert between the two.

And the Referral resource is the final piece for this particular use case.

So we can imagine a workflow like this:

1. The user locates the Questionnaire Template they wish to use
2. The system downloads the Questionnaire and pre-populates it from the local data store based on the individual question.name entries.
3. The user enters the remainder of the data described in the Questionnaire.
4. When complete, the system constructs a Referral resource, and likely a number of other resources (like MedicationStatement, Observation, Condition) which are placed in a bundle and sent to the recipient using any of the described paradigms of exchange.

This workflow (and the implementing systems) is completely generic, and can be re-used in any other scenario where there is some standardized form of data collection and exchange – like routine assessments, progress notes, discharge summaries etc.

It’s important to appreciate that we’re using the Questionnaire as the interface between the user and the local system – not as the unit of exchange between systems, which would use resources specific to each purpose. In this case a Referral resource, but another example could be a Discharge Summary, which is a document. (I’ve glossed over some of the details of this exchange, which actually uses other resources like Order and OrderResponse, and of course there are security /privacy considerations as well.)

In fact, if we were half way clever we’d also re-use any appropriate FHIR server. For example, we’re currently looking at creating a ‘Record Locator Service’ (which could be a FHIR server hosting DocumentReference resources) – why not use the same infrastructure to store the Questionnaire templates?

So I’m starting to think that the Questionnaire could replace the List as my favourite FHIR resource.

Let’s see what happens in Phoenix…