NIH | National Cancer Institute | NCI Wiki  

Contents of this Page
Summary

Description of the profile

Form Definitions

Capabilities

Requirements traceability

Requirement

Source

Capability

Provide a forms building tool that will express the structure of a form as well as the model elements to which form items are bound in order to describe the form definition (including the persistence model, behavior and structure) so that the definition could be consumed by any form rendering platform and effectively collect standard data.

Gap Analysis::Interface:: 031 - Forms Building Tool

formBuilder,

Import electronic documents / forms to the KR

Gap Analysis::Import:: 047 - Import electronic documents, forms to the KR

formBuilder,

Provide a forms repository and authoring tools for exchange of forms in standard format

Gap Analysis::Register:: 158.2 - Forms repository, authoring, and exchange

formBuilder,

 

Semantic Infrastructure Requirements::Clinical Data Forms Definition and Modeling:: Administer Forms

formBuilder,

Artifact lifecycle management and metadata requirements include the ability to: * Manage lifecycle, governance and versioning of the models, content and forms * Establish relationships and dependencies between models, content and forms * Determine provenance, jurisdiction, authority and intellectual property * Create represention and views of the information, realized through the appropriate transforms * Provide access control and other security constraints * Create annotations for better discovery and searching of artifacts * Develop usage scenarios and context for the information * Provide terminology and value set binding The artifacts are bound to the services via the service metadata. The service metadata combined with the artifacts and supporting metadata provide a comprehensive service specification. The artifact management requirements listed above are derived from the following use cases: * caEHR: The caEHR project has adopted ECCF for specifications and CDA documents for interoperability. The caEHR project requirements include the need for an infrastructure for managing all the artifacts generated during specification process, including HL7 models and documents. The caEHR project also intends to publish these artifacts for the community and vendors. The infrastructure needs to support better discovery, making all the relevant information available in the right context. * ONC and other external EHR adopters: ONC has adopted CCD and CCR for meaningful use. All national EHR implementations are expected to support forms and the semantics of these forms play a critical role in interoperability. The semantic infrastructure must provide a mechanism to create, store and manage these forms. * Clinical Trials: Clinical trials use forms to capture clinical information, and the semantics captured by these forms are critical for interoperability and reporting. The semantic infrastructure must provide a mechanism to manage the lifecycle of these forms.

Semantic Infrastructure Requirements::Artifact Management:: Artifact Lifecycle Management

formBuilder, formBuilder, formBuilder, formBuilder,

The caDSR program is interested in building on its Forms tools to create standards-based data collection forms (e.g., Clinical Data Form).  The caDSR/Clinical Trial tools should be directly usable by the end user (e.g., cancer researcher) and not limited to metadata specialists.  Often, data collection will start in a few days or weeks and harmonized forms (i.e., map into caDSR data elements) are needed in a few days or weeks from when the localized data model is created. In the longer-term (3-to-5 years) CDISC is also interested in generating CDISC-standards based data collection forms (see CDISC-15). *Source:  * * Interview 5/24/2010, Dianne Reeves * CDISC SHARE Team 2 F2F - 06/09/2010, Dave Iberson-Hurst

Gap Analysis::caDSR:: caDSR-5 -  Generate standards-based data collection forms

formBuilder,

There is a need to have tools to support the building of data collection forms

Gap Analysis::HL7 CIC:: CIC-12 -   Provide tools to support the building of data collection forms

formBuilder,

There is a need to define a common set of data element metadata attributes to record these clinical data elements. Process approach that CIC is taking to harmonization of a vocabulary element:   group A puts in their element, then group B, then CIC would harmonize the two views – so this is based on consensus.  If something can’t directly be harmonized there may be ways to reconcile. CIC has voted to work with SHARE and will follow SHARE’s lead. 

Gap Analysis::HL7 CIC:: CIC-2 - Provide the metadata needed to record clinical data elements

formBuilder,

There is a need for a properly appointed governance body: * To curate and manage content Note: Cardiology elements are in caDSR – the curation process for this is very long; users actually need a few hours or less turnaround.  * To provide means to help users obtain and interpret output * To provide means to  answer questions about the repository   No tooling for doing this has been built yet; hence no prototypes have been worked on. Note, besides lack of tooling, another reason that this was not done is the fact that people have not responded to CIC requests for contributions.  CIC does not want to do this type of technology effort (e.g. prototyping of tools) since it is made up primarily of non-IT people.  CIC is considering using parts of the CDISC SHARE effort which clinical people could then map their data to. Need interface to work for people with clinical background; this is very important.

Gap Analysis::HL7 CIC:: CIC-7 -  Provide tools to handle questions and manage content

formBuilder,

 

Semantic Infrastructure Requirements::Clinical Data Forms Definition and Modeling:: Create Forms

formBuilder,

Forms include both ODM and CDA documents. This includes all aspects of the document including the style, definitions and semantics.

Semantic Infrastructure Requirements::Artifact Management:: Forms

formBuilder, formBuilder, formBuilder, formBuilder,

 

Semantic Infrastructure Requirements::Clinical Data Forms Definition and Modeling:: Search and Access Forms

formBuilder,

formBuilder
Description

Provide a forms building tool that will express the structure of a form as well as the model elements to which form items are bound in order to describe the form definition (including the persistence model, behavior and structure) so that the definition could be consumed by any form rendering platform and effectively collect standard data.

Generate standards-based data collection forms

Provide a forms repository and authoring tools for exchange of forms in standard format

Provide tools to support the building of data collection forms.

Import electronic documents / forms to the KR

There is a need for a properly appointed governance body:

  • To curate and manage content Note: Cardiology elements are in caDSR – the curation process for this is very long; users actually need a few hours or less turnaround. 
  • To provide means to help users obtain and interpret output
  • To provide means to  answer questions about the repository   No tooling for doing this has been built yet; hence no prototypes have been worked on. Note, besides lack of tooling, another reason that this was not done is the fact that people have not responded to CIC requests for contributions. 

CIC does not want to do this type of technology effort (e.g. prototyping of tools) since it is made up primarily of non-IT people.  CIC is considering using parts of the CDISC SHARE effort which clinical people could then map their data to.

Need interface to work for people with clinical background; this is very important.

There is a need to define a common set of data element metadata attributes to record these clinical data elements.

Process approach that CIC is taking to harmonization of a vocabulary element:   group A puts in their element, then group B, then CIC would harmonize the two views – so this is based on consensus.  If something can’t directly be harmonized there may be ways to reconcile.

CIC has voted to work with SHARE and will follow SHARE’s lead. 

Requirements addressed
Overview of possible operations

To be provided.

  • No labels