This section includes the following:
Introduction to EHR Use Case
The ambulatory oncology electronic health record being developed by the National Cancer Institute (caEHR) in collaboration with the community cancer centers is a cornerstone application for demonstrating the value of computable semantics that enable interoperability and runtime clinical decision support. The ambulatory oncology electronic health record has several semantic infrastructure requirements and these are highlighted below using a high level use case.
caEHR Clinical Forms: Requirements
The Electronic Health Record (EHR) is a form driven system for data entry by physicians, nursing staff, and ancillary providers. 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 electronic health record should also provide data to 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. The
diagram to be provided below
shows actors and use cases involved with forms design and the data entry using these forms.
caEHR Clinical Forms: Use Case Description
The caEHR Clinical Forms use case has two primary goals. The first goal involves a form designer and the construction of a clinical data entry form for use in the GUI of the caEHR application, that is semantically consistent and based on HL7 RIM objects, HL7 structural vocabulary, and ONC required code systems for meaningful use. The second goal involves the data entry person (a physician, nurse or other health care provider) that 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 the construction of a form model based on semantic HL7 RIM objects, to allow binding of appropriate code systems and value sets to the form controls of the object, and to add 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 are made available to a user for data entry.
- A Data Entry Form builder gathers requirements for forms from end users who will enter data into the system. They build a form by retrieving form components and value sets 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 definitions are retrieved and a user uses the form to create a CDA document.
- The document is either persisted or exchanged with a external system.
caEHR: Terminology Requirements
The caEHR Terminology use case has two primary goals. The first goal involves a data entry form used in the GUI of the caEHR application that requires runtime population of HL7 structural vocabulary, and domain value sets for each coded form control. The second goal involves the caEHR 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.
caEHR: Terminology Use Case
In the GUI 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 (links to the caEHR Form Design Scenario).
- When a form is loaded in the caEHR GUI for the first time, the caEHR 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 caEHR system for future use.
- Subsequent form loading refreshes the cache by value set versions.
Naïve form submissions from the ECCF registry perspective are routed to the Form Design scenario for value set construction invoking the caEHR Clinical Form Design use case for control binding to terminology.
caEHR: Decision Support Use Case
A user of the caEHR starts a patient on a new antiemetic drug. The patient is already on multiple medications, both for treatment of their cancer as well as several co-morbid conditions. The user is unfamilar with a few of the medications the patient is on and thier EHR has no drug interaction model built in. They submit the list of medications for the patient to a Semantic Infrastructure decison support service that provides access to runtime drug interaction and contraindication checking.
