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.
- 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.
- 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.
- 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:
- It supports multiple responses to the query.
- It allows just the key metadata to be returned as a response, with subsequent retrieval of the detailed data when needed.
- 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.
- 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.