IHE Profile Proposal for expanding upon the Retrieval of Clinical Knowledge

HITSP started it with T81 Retrieval of Medical Knowledge. IHE continued it in QRPH TF-2 (see page 99) with QRPH-29 Retrieval of Medical Knowledge. I'm demonstrating its use for Public Health Alerting this week, but there is so much more that could be done.

The specification is very simple. You request a resource using a URL. The query parameters to use are specified in the HL7 Infobutton specification.

But the specifications as they stand in either IHE or HITSP are incomplete.

• How do you retrieve medical knowledge on a specific disease? A medication? What are the query parameters to set? What if you want a response suitable for a healthcare provider? A patient?
• What happens when there is nothing to show?
• How do you authenticate the provider using the request?
• What are the error cases?
• What is the format of the response?
• What additional metadata should be returned in the response?
• How can we make responses cachable? Should they be?
• How do we retrieve multiple results?
• Should the request be made using GET or POST?

These are all questions I had to address in the implementation I'm demonstrating at the Public Health Informatics conference this week in Atlanta. Some of the answers can be generalized to any use of InfoButton. Others are more specific to the kind of request being made.

There needs to be a general specification that addresses the common issues. These should be written as Change proposals to QRPH-29.

I have three or four other use cases for which I'd like to see a more detailed specification put together.

1. Accessing Patient oriented education information on a laboratory result, condition or diagnosis, or medication. This is a capability already supported in MedLine Plus as I understand it. I'll be following up with a few people from NLM for more details on that. Note: Access to Patient-specific education information is one of the menu-set objectives in Meaningful Use.
   
2. Accessing information about clinical trials relevant to a particular disease. Many patients with serious life-threatening or chronic illness would love to find out about clinical trials they might fit into. A suitable InfoButton query could be crafted to support access to an Atom or RSS Feed of clinical trials. That could go a long way towards encouraging enrollment in clinical trials.
3. Taking the next step in creating actionable public health alerts. In my current implementation we are getting a HTML page back. But, the content would be easier to handle if it were actually an Atom or RSS Feed in response to the query. This addresses multiple issues:
   
   1. It supports multiple responses to the query.
   2. It allows just the key metadata to be returned as a response, with subsequent retrieval of the detailed data when needed.
   3. It allows each alert seen to be given a unique resource ID that DOESN'T change even when the alert changes. This is critical, as it allows providers to keep track of what they saw, when they saw it, without having to keep a separate copy. When the alert changes, the link in the feed changes, rather than the content of the page. This is an important issue for medical records professionals.
   4. When a feed is used, the URL found is to the appropriate alert. That makes the detailed alert result cache-able. This is another important issue that can help address network latency issues. A simpler response can be returned that points to the potentially cached resource.
      

The Problem

Providers and patients need a simple way to search for web resources that can answer specific questions. The HL7 InfoButton standard provides one such mechanism by which this can be done. However, there are a number of different ways that InfoButton can be used, and there are a number of options in how a system can respond. We need a consistent set of rules for using InfoButton to query for information that is either patient or provider-oriented. We need a consistent way to address and report on errors in the responses. We need a consistent way to return results so that EHRs and PHRs can make these queries, process the results, and display them in a normalized form.

Key Use Cases

A provider using an EHR wants to locate patient oriented education materials on a given condition. How should the query be structured to obtain a selection of available materials? A patient wants to keep track of clinical trials for a specific condition. How should the query be structured to obtain a selection of appropriate clinical trials?

Standards and Systems

InfoButton, HTTP, XHTML, HTML, HTML 5, Atom, RSS EHR, PHR, HIE

Discussion

This should be a joint work item between Patient Care Coordination, and Quality Research and Public Health. IHE would be a good venue to solve this problem because it involves developing a profile across several existing standards. It has the necessary expertise in PCC and QRPH to address content issues, and in IT Infrastrucure to address common infrastructure questions. There may also be cases where a query could actually return a URL to a form that could be used with the IHE Request Form for Data Capture profile. We should examine what the glide path is from QRPH-29 to ITI-34.