NIH | National Cancer Institute | NCI Wiki  

  • Created by Unknown User (wileyal), last modified on Jul 21, 2012
Current Working Draft

This section will address prototypes and demos and includes the following:

Scope, Objectives and Approach

The caBIG® Clinical Information Suite Clinical Forms prototype has two primary goals. The first goal involves a form designer and the construction of a clinical data entry form for use in the graphical user interface of the caBIG® Clinical Information Suite 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) 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.

Capability Description

The prototype will support the following core capabilities:

  • Create Form Definitions
  • Retrieve form Objects
  • Persist CDA Document

Requirements

The following is a description of the use case that will be realized by the prototype:

Element

Description

Use Case Name

caBIG® Clinical Information Suite Form Development

Use Case Unique ID

 

caBIG® Clinical Information Suite Enterprise Use Case Ref. ID

 

Brief Description

A qualified form builder designs a form for use in caBIG® Clinical Information Suite

Actors

Data Entry Form builder, Data Entry Form end user

Trigger

Data Entry Form end user requests a new form

Preconditions

  • caBIG® Clinical Information Suite is capable of importing forms
  • The ECCF Registry is accessible
  • The Forms Application Server is available
  • Terminology services is accessible

Main Flow

  1. A Data Entry Form builder is notified of a new study or need for a new clinical data capture form by an end user.
  2. The Data Entry Form builder actor begins with the requirements from the end user and opens a form editor.
  3. The Data Entry Form builder selects the form type to build and selects a template for that type from the ECCF registry.
  4. If the template is found, the user gets a pre-populated menu of Common Message Elements (CMETs) or templates that go with that parent document template.
  5. If the Data Entry Form builder is unable to locate a desired form template in the ECCF registry, the Form Builder may search for existing Common Message Elements (CMETs) to populate the menu of form sections identified by the requirements and downloads these to the Form Builder Tool.
  6. The Data Entry Form builder drags a CMET to the build palette to start the form project. This is repeated for each section identified by the requirements. When a template is present, the CMETs self organize according to the template. If a template does not exist, the user connects the CMETs together with the guidance of the system on allowable relations or entry points for the CMET.
  7. The selection of a CMET on the palette exposes the attributes of the CMET in a window where the Data Entry Form builder may then select a value set to bind to the attribute.
  8. Selection of the value set is done by passing the attribute name to the ECCF to identify available value sets for that attribute. If no value set exists the user is passed to the CTS service to construct a value set.
  9. The Data Entry Form builder user adds metadata to the form package and the system adds identifiers to the form and its components requiring new identifiers.
  10. The Data Entry Form builder user next defines the rules for skip patterns and form flow logic that is stored with the form. The form is then submitted to the Forms Application Server and the form identifier and metadata passed to the ECCF registry.
  11. The ECCF registry notifies subscribers of the availability of a new form type.
  12. The caBIG® Clinical Information Suite Data entry user pulls the completed form from the Forms Application Server and imports the form into the caBIG® Clinical Information Suite Forms workspace where form arrangement, customization and data backend bindings occur.

Alternate Flow

 

Postconditions

A Semantically Aware Form is available for use in the caBIG® Clinical Information Suite

Notes

The use case assumes that the caBIG® Clinical Information Suite applications have the responsibility for binding of the form to system middleware components

Community Feedback and Comments

TBD

Lessons Learned

TBD

  • No labels