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…

 

 

 

 

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

2 Responses to FHIR Questionnaires and exchanging information

  1. The pre-population piece is part of the scope of ONC’s Structured Data Capture (SDC) project which hopes to ballot a FHIR-based implementation guide as part of the Jan. ballot cycle, including declaring the service to allow requesting pre-population and the syntax for identifying where to extract the data from.

  2. This looks great, can we harmonize with the CCDA patient generated health data header in order to: align all of the actors/roles/authors? This would make sure the patient enters the ecosystem consistently across delivery and content structures. Also look at work on the questionnaires the group did there, could be informative. How can we help. The patient/consumer may be the driving force for FHIR as the only “non-legacy” stake holder

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: