NIH | National Cancer Institute | NCI Wiki  

WIKI MAINTENANCE NOTICE

Please be advised that NCI Wiki will be will be undergoing maintenance on Monday, June 24th between 1000 ET and 1100 ET.
Wiki will remain available, but users may experience screen refreshes or HTTP 502 errors during the maintenance period. If you encounter these errors, wait 1-2 minutes, then refresh your page.

If you have any questions or concerns, please contact the CBIIT Atlassian Management Team.

Error rendering macro 'rw-search'

null

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 a repository and/or the terminology services. 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 persisited 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 in the case of localization of geographic value sets or disease specific value sets for new form elements.

caEHR: Terminology Use Case

Form Control Terminology Binding: In the GUI form control terminology binding scenario that aims 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 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 invokes the caEHR Clinical Form Design use case for control binding to terminology.