NIH | National Cancer Institute | NCI Wiki  

Current Working Draft

This section includes the following:

Introduction to Electronic Health Records Use Case

The ambulatory oncology electronic health record (EHR) is defined as a set of services and a semantic software platform to compose a "virtual" medical record. This EHR (caBIG® Clinical Information Suite) is being developed by the National Cancer Institute in collaboration with the community cancer centers and will demonstrate the value of computable semantics that enable interoperability and runtime clinical decision support. The caBIG® Clinical Information Suite has several semantic infrastructure requirements and these are highlighted below using a set of high level use cases.

EHR Clinical Forms: Requirements

The caBIG® Clinical Information Suite is a form driven system for data entry by physicians, nursing staff, and ancillary providers. Changes in the health care landscape across the United States over the last several years has led to new requirements for data structure and semantics. These new requirements have led to the need to deal with "meaningful use" semantics in our form structures. One prominent requirement is the need for any EHR system to use the new semantics in order for providers using these systems to be paid for the care they provide to particular patients. Hence lack of adoption of these data standards could lead to diminished availability for cancer patient care if the physician market shrinks through financial attrition.

Data captured through forms may be re-purposed for business analysis at the institutional level and personal physician level. The data may also be used for adverse event reporting, public health reporting of communicable diseases, and automated reporting to cancer registries. The data may be released for insurance and claims payment and may also be provided to the patient for a longitudinal medical history. Data is exchanged between healthcare providers at the time of referral of the patient for additional care. The caBIG® Clinical Information Suite should also provide data for aggregated and de-identified repositories to support better understanding of healthcare outcomes and best practices.

To serve these many uses, the context and semantics of data entry must be captured and persisted to a backend data store without loss of meaning. To enable this goal of robust data capture, the forms used to capture the data elements must be semantically structured and linked in context using standards-based information models and explicit terminology with traceability through value set identifiers and coded concept identifiers, allowing aggregation and disambiguation of the captured data.

EHR Clinical Forms: Use Case Description

The EHR Clinical Forms use case has two primary goals. The first goal involves a form designer and construction of a clinical data entry form for use in the graphical user interface of the caBIG® Clinical Information Suite. This form must be semantically consistent and based on HL7 Reference Information Model (RIM) objects, HL7 structural vocabulary, and Office of the National Coordinator (ONC) required code systems for meaningful use. (caBIG® wishes to adhere to regulations and rules from the ONC). The second goal involves the data entry person (a physician, nurse or other health care provider) who defines the value set requirements for the form elements, identifies the rules for skip patterns and form element arrangement, and eventually enters and persists clinical data.

The form design scenario aims to enable construction of a form model based on semantic HL7 RIM objects. This allows binding of appropriate code systems and value sets to the form controls of the object, and adding rules for skip patterns and data entry flow. This will allow data capture at the point of care. The forms, their construction objects, and the bound value sets must be persisted for reuse, and the forms must be made available to a user for data entry.

  • A Data Entry Form builder gathers requirements for forms from end users who enter data into the system.
  • This person builds a form by retrieving form components and value set identifiers from either a repository or the terminology services or from both. The end result of the build process is a semantically aware form and its schema and terminology requirements.
  • The form definition is eventually stored on a server. The form metadata is stored in a repository.
  • The form definition schema and metamodel are retrieved and a user invokes these to create a data capture form.
  • Terminology from the Common Terminology Services (CTS) server is bound at form load time to each control requiring standard terminology.
  • The user populates the form with data partially based on retrieved value sets and submits the form and data which is dynamically transformed to a valid Clinical Document Architecture (CDA) document.
  • The document is either persisted in a database or exchanged with an external system through a service.

Note

A "form control" is any UI object such as a drop down menu, a text field, a
submit button. These are all called "form controls".

EHR: Terminology Requirements

The EHR Terminology use case has two primary goals. The first goal involves a data entry form used in the graphical user interface of the caBIG® Clinical Information Suite that requires runtime population of HL7 structural vocabulary, and domain value sets for each coded form control. The second goal involves system requirements for building new value sets when an existing value set is not available for a form control or where large value sets must be subdivided into smaller, nested value sets. Examples of these requirements are the case of localization of geographic value sets or disease specific value sets for new form elements.

EHR: Terminology Use Case

In the graphical user interface form control terminology binding scenario the aim is to enable the query of a repository for a form control bound to a form template or HL7 RIM object using a value set identifier, and subsequently to allow the return of an enumerated CTS value set bound as a pick list to the form control. In cases where the form control has not yet been bound to a value set, the system should be able to query by text strings or metadata of the control and return candidate value sets, or when none are returned in this manner, allow direct query of the CTS API for code system concepts to build a new value set.

  • When a form is loaded in the caBIG® Clinical Information Suite graphical user interface for the first time, the caBIG® Clinical Information Suite system passes the form identifiers to the repository.
  • The repository evaluates the identifiers against known templates or HL7 form objects and passes the identifiers to the CTS service to return all identified enumerated value sets.
  • The enumerated value sets are returned and bound to the form controls as pick lists and cached by the caBIG® Clinical Information Suite system for future use.
  • Subsequent form loading refreshes the cache by value set versions.

Naïve (initial) form submissions from the Enterprise Conformance and Compliance Framework (ECCF) registry perspective are routed to the form design scenario for value set construction invoking the caBIG® Clinical Information Suite Clinical Form Design use case for control binding to terminology.

EHR: Decision Support Requirements

The caBIG® Clinical Information Suite provides services that cover a wide range of clinical and administrative functionality and that depend on a rapidly changing set of data standards and representations. The system has a set of requirements that include:

  • The need to maintain the accuracy and currency of decision support data sources that are dynamic
  • The need to provide runtime clinical decision support
  • The need to provide just in time software updates that allow interoperability across systems
  • The need to interact with systems that can match for clinical trials

Examples of the use cases tied to these requirements are found below.

EHR: Decision Support Use Cases

Drug-Drug Interaction Use Case

A user of the caBIG® Clinical Information Suite starts a patient on a new antiemetic drug. The patient is already on multiple medications, both for treatment of cancer as well as several co-morbid conditions. The user is unfamiliar with a few of the medications the patient is on and the installed EHR has no drug interaction model built in. The user submits the list of medications for the patient to a Semantic Infrastructure decision support service that provides access to runtime drug interaction and contraindication checking.

AJCC Cancer Classification Use Case

A user of the caBIG® Clinical Information Suite uses the 7th Edition of the American Joint Committee on Cancer (AJCC) Cancer Classification system to stage cancer patients. The 8th Edition has now come out and the user would like to upgrade the system to meet the requirements of the state cancer registry. Re-coding the infrastructure for all cancer types in Java is expected to be quite expensive and time consuming. The user queries the ECCF registry for "AJCC Cancer Classification" and finds a plugin reasoner service that implements an OWL version of the AJCC 8th Edition classification system capable of inferring an anatomic stage based on data directly from pathology, imaging, and clinical exam input through a service. The user's system is now able to move with the speed of Cancer Registry requirements rather than the pace of the software vendor.

  • No labels

1 Comment

  1. Unknown User (wileyal)

    Posted in behalf of Jyoti Pathak (Mayo)

    Re: "The user submits the list of medications for the patient to a Semantic Infrastructure decision support service that provides access to runtime drug interaction and contraindication checking."

    Where would such information about drug-drug interaction reside?