Register Functional Profile
Establish relationships and dependencies between models, content and forms.
Some stakeholders expressed the desire to use the KR to store artifacts such as forms, templates, and query results and use the management functionality of the KR to control the lifecycle of these artifacts.
This Functional Profile includes, but is not limited to, the following capability elaborations:
Derived From Requirements
- Gap Analysis::Manage::163 - Curator support Curators need support on two levels, the basic CRUD services and those who need to do more detailed metadata maintenance/clean-up/monitoring functions.
- Semantic Infrastructure Requirements::Artifact Management::Artifact Lifecycle Management 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.
- Gap Analysis::CDISC::CDISC-1 - Provide an asynchronous collaborative environment for widely distributed users and a federated repository system CDISC states that a collaborative environment to harmonize data element definitions and a Metadata Repository to store them in are different sides of the same thing. They want a collaborative environment where they can define workflows, a Knowledge Repository to store the results, and the ability to distribute them. There is a need to be able to define a non-public area where standards developers can create drafts of the proposed context and discuss them among themselves. As noted in CDISC-2, most CDISC standards developers are content experts and not information modelers or IT experts. They are geographically and organizationally distributed volunteers who meet (usually online) once a week. The distributed environment has to support these types of individuals. An asynchronous collaboration environment is central to the success of their work. Initially at least, the content considered by CDISC is strongly local; this implies a federated Metadata Repository with good access control. The CDISC SHARE meta data model calls for the ability to share data among repositories that implement different metadata models (e.g., 11179 Ed 2, 11179 Ed 3, ebXML, proprietary metamodel standard, etc.). A CDISC Knowledge Repository should have Files and Services that support these distributed harmonization workflows. Also, CDISC standards should be deliverable via the proposed Knowledge Repository (see: CDISC-7). *Source: * * Interview 5/20/2010, David Iberson-Hurst * CDISC SHARE: Pathway into the Future for Standards Development and Delivery, April 10, 2010, Bron W. Kisler, CDISC Senior Director
- Gap Analysis::CDISC::CDISC-11 - Support templates as CDISC SHARE reusable entities A Template is an additional constraint on an HL7 RIM information model and is often associated with HL7 Clinical Document Architecture (CDA). A template defines best practices and guides the collection of additional data elements, their relationships, and their validation. They provide facilities for the reuse and creation of groups of clinical concepts, associated terminology, and versions. Source * CDISC SHARE Meta-Model Paper * CDISC 5/27/2010 Team 2 Meeting, David Iberson-Hurst
- Gap Analysis::HL7 CIC::CIC-14 - Support a registration lifecycle for entering data elements There is a need to support a registration lifecycle
cdiscShareTemplates
Support storing templates as CDISC SHARE reusable entities.
curation
Curators need support on two levels, the basic CRUD services and those who need to do more detailed metadata maintenance/clean-up/monitoring functions.
collaborativeCuration
Provide an asynchronous collaborative environment for widely distributed users and a federated repository system
dataElementRegistration
Support a registration lifecycle for entering data elements.
