![]() HL7 V3 INFOBUTTON, R2 HL7 Version 3 Standard: Context-Aware Retrieval Application (Infobutton); Knowledge Request, Release 2 April 2013 |
![]() HL7 V3 IG INFOBUTTON, DSTU R4 2013JAN HL7 Version 3 Implementation Guide: URL-Based Implementations of the Context-Aware Retrieval Application (Infobutton)Domain, Release 4 January 2013 |
Content Last Edited: 2013-08-15T16:04:38
The HL7 Version 3 Context-aware Knowledge Retrieval (Infobutton) topic, DSTU Releas2 1 was approved as a DSTU following a successful ballot in September 2012.
Publication of this draft standard for trial use and comment has been approved by Health Level Seven, International (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 24 months from teh date of publication. Suggestions for revision should be submitted at http://www.hl7.org/dstucomments/index.cfm.
Following this 24 month evaluation period, this draft standard, revised as necessary, will be submitted as a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard.
Topic Overview
Clinicians face numerous knowledge needs during the course of patient care. To a large extent, these knowledge needs are related to gaps in medical knowledge that clinicians need to fill in order to make, confirm, or carry out a patient care decision. Ultimately, knowledge gaps lead to suboptimal decisions, compromising the quality of care.
With the advent of the World Wide Web, numerous online health knowledge resources have become available. Although these resources have demonstrated great potential to resolve clinicians' and their patients' knowledge needs, a number of barriers hinder a more efficient and effective use of these resources, slowing their dissemination. In essence, both patients and providers become overwhelmed with the vast amount of information available, raising the need for tools that help them identify relevant, context-specific, high quality knowledge in a timely manner.
To lower barriers to the access of knowledge resources at the point of need, researchers have proposed context-aware integration of knowledge resources into electronic health record (EHR) personal health record (PHR) systems. Tools that provide this type of integration have been generically denominated infobuttons. The goal of the present specification is to facilitate the context-aware integration of knowledge resources into EHR and PHR systems.
Technical Background
In a typical infobutton implementation, EHR/PHR systems place hyperlinks adjacent to clinical concepts, such as medications, laboratory tests, and problems. These hyperlinks embed a knowledge request with a set of attributes that capture the context of the interaction between the user and the EHR. Context can be expressed in terms of attributes that characterize (1) the clinical concept of interest (e.g., a medication, a laboratory test result, a problem list entry); (2) the patient demographics and other observations; (3) the EHR task (e.g., order entry, laboratory results review, problem list review); (4) the knowledge user (e.g., discipline, specialty, language, patient vs. provider); and (5) the care setting (e.g., outpatient, inpatient). When a user clicks on an infobutton, the following steps are followed: 1) a request for knowledge is sent to a decision support system known as infobutton manager; 2) Using these context attributes, the infobutton manager produces a refined knowledge request, for example, asking for specific content topics that are thought to be most relevant in the particular context (e.g., diagnosis, treatment). The refined knowledge request is submitted to one or more relevant knowledge resources; 3) the knowledge resources responds with knowledge content that fulfills the knowledge request; 4) the infobutton manager processes the content from the multiple resources and sends it to the EHR.
Figure 1 depicts a typical implementation approach to knowledge integration using the Context-Aware Knowledge Integration standard specification. As indicated in the diagram, the present Knowledge Request specification enables EHR/PHR systems to request context-specific knowledge from knowledge resources. A specification for the response of knowledge resources is addressed in the <loc href="V3_IG_SOA_KM_INFOBUTTON_DSTU_R1_2011MAR.zip">Context-Aware Information Retrieval, SOA-based Implementation Guide.</loc>
Infobutton managers are one of many possible implementation mechanisms for context-aware knowledge integration. In other alternative implementations, infobuttons submit requests for knowledge directly to a knowledge resource without the mediation of an infobutton manager. In addition, knowledge can be integrated into EHR systems through mechanisms other than infobutton hyperlinks. This standard specification is agnostic of any particular implementation and is designed to support a variety of context-aware knowledge integration approaches.
The following notes should be considered when reading this specification:
Although both the knowledge request and knowledge response interactions are described in this specification, the specification only includes the knowledge request information model.. A specification for the knowledge response is included in the <loc href="V3_IG_SOA_KM_INFOBUTTON_DSTU_R1_2011MAR.zip">Service Oriented Architecture (SOA) Implementation Guide</loc>.
The specification does not determine how the components involved in a knowledge integration scenario should be implemented.
The specification does not specify a standard indexing and content structure for knowledge resources. However, knowledge resource developers can use this standard as a guideline to define their indexing and content structure, enabling their product to more effectively respond to EHR systems that submit knowledge requests based on this specification.
Encoding Rules and Processing
To be compliant with this standard, implementers are not required to handle all the data elements defined in the knowledge request RMIM. In order to promote rapid adoption, the following directives should be followed:
An EHR SHOULD formulate knowledge requests as completely as possible, using as many context data elements as possible, preferably using coded data.
Except for required classes and attributes, knowledge resources MAY process only the elements that they can handle, ignoring other elements. For example, if a knowledge resource does not use patient.administrativeGender as a content index, the resource MAY ignore this attribute whenever it is included in a knowledge request.
These directives allow EHR systems to create knowledge requests that can be fulfilled by knowledge resources with varying levels of sophistication. The approach also enables less sophisticated knowledge resources to quickly achieve compliance without major modifications to their content and indexing structure. Still, resources MAY be gradually enhanced aiming at fully exercising the message model described in this specification.
|
||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
The following storyboard depicts a typical context-aware knowledge retrieval transaction. Although the present specification focuses primarily on the Knowledge Request step, the storyboard also includes the knowledge response step in which a knowledge resource fulfills a knowledge request. As previously mentioned, the latter step will be covered in a separate future specification.
Infobutton Knowledge Request | ![]() |
Table 1 - Storyboard: Knowledge request originated from a problem list.
Step | Specification | Actor | Description |
1 | Knowledge request | EHR | A clinician is reviewing a problem list module of an EHR and is unfamiliar with a rare disease (Camurati-Engelmann Disease) that the patient, a 15-year-old female, has. The problem list module provides an infobutton link next to the "Camurati-Engelmann Disease" problem. The user clicks on the infobutton link. |
2 | Knowledge request | EHR | Context data available to the EHR captured and submitted in a knowledge request to the knowledge resource. |
3 | Knowledge response | Knowledge resource | The knowledge resource receives the request and looks for content in its content collection that is deemed to be relevant based on the elements included in the knowledge request. |
4 | Knowledge response | Knowledge resource | The knowledge resource submits a knowledge response with content that may be relevant in this particular context. |
|
||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
|
||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
Type: | User request |
State Transition: | InfobuttonEventNotification (REDS_RM010002UV01) |
Context-aware knowledge request event initiated by the EHR (e.g., as a result of a user clicking on an Infobutton).
|
||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
Parent: | Structured Document (REDS_DM000001UV) |
KnowledgeRequestNotification class
This class represents the root of the KnowledgeRequestNotification RMIM. The following are definitions of the attributes of the KnowledgeRequestNotification class:
KnowledgeRequestNotification.id: Represents the globally unique instance identifier of a knowledge request.
KnowledgeRequestNotification.effectiveTime: creation time of the knowledge request.
KnowledgeRequestNotification Relationships
This section describes classes related to the root KnowledgeRequestNotification class:
MainSearchCriteria: represents the main subject of interest in a knowledge request (e.g., a medication, a lab test result, a disease in the patient's problem list). When multiple instances of this class are present, knowledge resources MAY determine whether to join the multiple instances using the AND vs. OR Boolean operator.The following are attributes of the mainSearchCriteria class:
MainSearchCriteria.code: indicates that the type of this Observation class is KnowledgeSubjectObservationType (i.e., KnowledgeSubjectObersvationType.code="KSUBJ").
MainSearchCriteria.value: the primary knowledge subject of interest (e.g., a medication, a laboratory test, a condition).
CD data type restrictions for mainSearchCriteria.value: 1) If code is present, displayName MAY also be present, so that knowledge resources that do not support a given code system MAY still process the request using displayName as a search keyword. 2) If code is present, codeSystem SHALL be present. 3) If the code, the displayName, and originalText are all present, knowledge resources MAY decide whether to process the code, the displayName, and/or the originalText to retrieve relevant content. 4) If code is not present, the text displayed to (or entered by) the user SHALL be represented in the originalText attribute.
SeverityObservation: specifies the interpretation of a laboratory test result (e.g., 'high', 'low', 'abnormal', 'normal'). This class MAY be used to support implementations where the MainSearchCriteria consists of a laboratory test result. Supports questions such as "what are the causes of high serum potassium?"
SeverityObservation.code: a code that defines that the type of the observation is SeverityObservation (i.e., SeverityObservation.code="SEV").
ObservationInterpretation.code: a code that represents the value of the observation interpretation (e.g., high, low, normal).
SubTopic: narrows down the knowledge request by specifying a subdomain of interest (e.g., indications, contra-indications, dose) related to the MainSearchCriteria knowledge subject. In Infobutton implementations, the SubTopic may be selected by the user from an Infobutton page that presents a list of content areas that are relevant in a specific context (e.g., "contra-indications of digoxin", "adverse effects of digoxin").
SubTopic.code: defines that the type of this Observation class is KnowledgeSubtopicObservationType (i.e., KnowledgeSubtopicObersvationType.code="KSUBT")
SubTopic.value: a code that represents a knowledge subtopic of interest (e.g., diagnosis, treatment, adverse effects).
TaskContext: the task that the user is performing in the EHR/PHR when a knowledge request is initiated (e.g., order entry, laboratory results review, problem list review, medications list review).
TaskContext.code: a code that represents the task that is being performed in an EHR/PHR system..
Encounter: the type of patient encounter (e.g., inpatient, outpatient) in which the knowledge request takes place..
Encounter.code: a code that represents the type of encounter (e.g., inpatient, outpatient).
LocationOfInterest: Address of a physical location that may be relevant for the context. For example, a knowledge request may include the postal code of locations recently visited by the patient so that a knowledge resource may retrieve a list of current disease outbreaks in these locations. NOTE: LocationOfInterest SHALL NOT be used to specify the complete address of a patient.
LocationOfInterest.addr: The address itself. For most use cases, the location's postal code is sufficient.
DeliveryLocation: clinical facility where the patient care is taking place at the time the knowledge request is initiated. MAY be used by the request filler to identify potential local knowledge resources (e.g., local protocols) that are specific to the facility where the patient care is being delivered.
DeliveryLocation.id: identifier of the facility where the patient care takes place.
KnowledgeRequestNotification Participants
This section describes participants of the KnowledgeRequestNotification RMIM.
AssignedEntity: entity (e.g., institution) that initiated the request. May be used by a knowledge request recipient to determine the knowledge resources that the requesting entity has access to (e.g., based on subscriptions). In addition, MAY be used to allow the identification of an individual within the institution, so that personal preferences can be considered by a knowledge request filler when processing the request.
NOTE about authentication approaches: Although the approach below MAY be used by a knowledge reosurce to authenticate a knowledge requestor (organization or person), the best approach is to handle authentication at other implementation layers outside the scope of the clinical content.
AssignedEntity.name: username used by the entity (typically as part of an institutional subscription to a knowledge resource)
AssignedEntity.certificateText: password associated with the username of the entity
Organization: the entity within which the request is initiated.
Organization.id: identifier of the organization within which the request was initiated
AuthorizedPerson: the individual who initiated the knowledge request
AuthorizedPerson.id: username of the person who initiated the request. MAY be used by a knowledge request filler to apply personal preferences during the user's session.
PatientContext: information about the patient that MAY be used by the EHR in a knowledge request to further specify the context in which a knowledge need arises.
PatientPerson.administrativeGenderCode: gender of the patient represented in the knowledge request.
Observation: additional information (e.g., kidney function, height, weight, pregnancy status) about the patient context that may be used to refine the content retrieved by online knowledge resources. For example, a physician prescribing atenolol to a patient with impaired renal function may want to know how to appropriately adjust the dose of this drug given the patient's condition. Although this class is very flexible and captures several kinds of observations, the use of this class will be driven by use cases and specific constraints defined in an implementation guide. This class SHALL NOT be used to represent the patient's age or age group. Implementers SHALL use the Age and/or AgeGroup classes for this purpose.
Observation.code: A code that defines the type of observation documented about the patient (e.g., LOINC 29463-7 for the patient's weight, HL7 code ASSERTION for problems, signs, and symptoms).
Observation.value: A code or quantity that represents the actual information observed (e.g., 70 mL/min).
Observation.InterpretationCode: One or more codes specifying a rough qualitative interpretation of the observation, such as "normal", "abnormal", "high", "low", etc.
Age: age of the patient as a numeric value.
Age.code: a code that indicates that the type of this observation is AgeObservationType.
Age.value: the patient's age as a numeric quantity. Units SHOULD be expressed in one of the following units (per the Unified Code for Units of Measure): years (a), months (mo), weeks (wk), days (d), or hours (h).
AgeGroup: an observation that represents the patient's age in terms of a predefined coded age range (e.g., infant, neonate).
AgeGroup.code: a code that indicates that the type of this observation is AgeGroupObservationType.
AgeGroup.value: a code that represents the patient's age group.
PerformerChoice: defines the type of Participants that act as the Performer (user who interacts with the system) and InformationRecipient (person who will consume the content). The performer and informationRecipient can be instantiated as a Patient , HealthCareProvider , or Payor class.
The following are examples for the use of PerformerChoice: 1) when a care provider interacts with the system seeking knowledge to fulfill his/her own needs, both the performer and informationRecipient SHALL be a HealthCareProvider; 2) when a care provider initiates the knowledge request, but looking for educational information to be given to the patient, the performer SHALL be a HealthCareProvider and the informationRecipient SHALL be a Patient; and 3) when a patient is looking for information to fulfill her own needs, both the performer and the informationRecipient SHALL be a Patient.
It is expected that knowledge resources will develop their own business rules to process the information conveyed in PerformerChoice. For example, if the performer is specified, but the informationRecipient is not, the knowledge request filler MAY assume the informationRecipient to be the performer. On the other hand, a knowledge resource that provides patient education content MAY assume that the informationRecipient is always the patient.
PerformerChoice Relationships
LanguageCommunication: language of the performer or informationRecipient. In implementations, language of the performer MAY be used by to determine the language of the individual who initiated a knowledge request, while language of the informationRecipient MAY be used to determine the language of the individual who will consume the content. For example, when a clinician looks for patient education information, the clinician's language may be English, while the patient is a Spanish speaker. In this case, while the user interface for the clinician can be presented in English, the requested patient education content will be presented in Spanish.
LanguageCommunication.code: A code that represents the person's language (e.g., English, Spanish).
CDS Message Model | REDS_HD010002UV02 |
|
||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
|
||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
Infobutton knowledge request initiated by the EHR (typically as a result of a user clicking on an Infobutton). The knowledge request is submitted to the knowledge resource.
Trigger Event | Knowledge Request | REDS_TE010001UV01 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | Event Notification | REDS_MT010002UV02 |
Sender | Electronic Health Record | REDS_AR010001UV01 |
Receiver | Knowledge Resource | REDS_AR010002UV01 |
Knowledge resource response to an infobutton knowledge request. As previously mentioned, note that the message payload for this interaction is outside the scope of this specification.
Trigger Event | Knowledge Request | REDS_TE010001UV01 |
Reason | Trigger Event | Interaction |
REDS_TE010001UV01 | REDS_IN010002UV01 |
Sender | Knowledge Resource | REDS_AR010002UV01 |
Receiver | Electronic Health Record | REDS_AR010001UV01 |
The HL7 Version 3 Implementation Guide: URL Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain topic, DSTU Release 4 was approved as a DSTU following a successful ballot in September 2012.
Publication of this draft standard for trial use and comment has been approved by Health Level Seven, International (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 24 months from teh date of publication. Suggestions for revision should be submitted at http://www.hl7.org/dstucomments/index.cfm.
Following this 24 month evaluation period, this draft standard, revised as necessary, will be submitted as a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard.
Infobutton IG: The URL-Based Implementations of the Context-aware Information Retrieval (Infobutton) Domain, Release 4. Click here to download a copy of the Draft Standard for Trial Use URL-based Implementation Guide.
Return to top of page |