 |
Page History
...
| Table of Contents |
|---|
Introduction
The NCI-supported caBIG program is facing a major expansion of its mission and of the community of stakeholders that it must engage. The success of the program to date has been widely recognized by numerous thought leaders, technology innovators, and program managers in the fields of biomedical computing and health information technology. These leaders have been influenced by both the technological sophistication and the open community processes of the caBIG program, and are seeking to adapt caBIG to meet the much broader agenda of health care information management, sharing, and integration across institutions, communities of practice, and patients.
As a means towards engaging this larger community and contributing to the creation of solutions for its needs, the BIG Health Consortium was formed, a non-governmental organization that is affiliated with caBIG, but which has a complementary agenda that is focused on enabling the integration of research, care delivery, and patient-driven decision making in practical ways. As a consequence, the institutional stakeholders associated with BIG Health Consortium extend well beyond the cancer centers, universities, and cooperative groups that make up the core NCI-funded constituencies that have participated in caBIG since its original incarnation. The extended community thus goes beyond what is considered caBIG-proper today, and includes groups that are not yet connected to caGrid.
Background
The primary goal for this Architecture, Development, and Deployment of a Knowledge Repository and Service is to address the needs of this extended community for a scalable, decentralized infrastructure for managing and disseminating operational metadata and information models, and their associated semantic constructs. The vision for the project is to re-imagine the caBIG technology environment as a more open and more readily extensible framework, one that can grow with less dependency on the centralized processes and systems that are manifest in the first generation of caBIG technology. In particular, the role of the central metadata registry, the caDSR, must be redefined as a federation of metadata registries that can be instantiated and plugged into the caBIG grid or an extended community "cloud" by any qualified entity.
The caDSR has a suite of tools and APIs that support workflows for metadata development, browsing and retrieval. In addition, the caDSR has been adapted to support the UML model-driven development paradigm adopted by caBIG. UML-defined information models such as those from the BRIDG project, caArray, caTissue, and others are each registered in the caDSR through conversion of the model elements into ISO11179 metadata constructs. This functionality, and the workflows that it supports, has evolved over an 8-year period and is now quite mature. It satisfies the current requirements for semantic representation in the current caBIG developer and user community, but it is ill-suited to serve the new requirements for decentralization and indefinite scalability in the broader health care community. The goal of this program is therefore to harvest and recycle the best elements of the first generation of caBIG metadata infrastructure, and to then incorporate those elements into a redesigned and modernized technology stack that is engineered from the start to support a federated deployment topology with far less centralized administration.
Scope
This program calls for the design and implementation of a metadata registry and model repository that can be instantiated in multiple physical locations in a federated manner, and which supports the caBIG and BIG Health community needs for operational semantic metadata management and integration. The program must provide a number of capabilities and services:
- Design and implementation of the ISO 11179 Edition 3 standard in a metadata repository (MDR) architecture. The current caDSR implements Edition 2 of the standard, and the NCI has published a gap analysis between caDSR and ISO 11179 Edition 3 that will inform this effort.
- Implementation of an information Model Repository that supports caBIG/BIG Health information model registration and alignment of models with ISO 11179 metadata elements.
- Extension of the metadata standard and associated workflow tools to cleanly accommodate ISO 21090 data types. Some work has been done to represent ISO 21090 in caDSR, but a number of gaps remain.
- Service-oriented programming interfaces that can be registered and exposed in caGrid, and which are compliant with emerging W3C standards.
- Tools to support an updated and revised semantic integration workflow that enables decentralized and localized additions of models and data elements.
- Transformation services that can traverse and extract the various semantic metadata constructs, including information models, data elements, and associated Description Logic (DL)-based terminologies. The preferred or native format for the representations should be available through these services rather than forcing users to interpret one format through the lens of another. Moreover, higher level services that cater to use cases for run-time semantics of consumer systems will need to be defined and implemented.
- Migration path from the current caDSR and associated tooling to the new MDR and Model Repository architecture.
Users and Characteristics
...
| Include Page | ||||
|---|---|---|---|---|
|
Background/Scope
| Include Page | ||||
|---|---|---|---|---|
|
Users and Characteristics
| Include Page | ||||
|---|---|---|---|---|
|
Related Documentation
| Include Page | ||||
|---|---|---|---|---|
|
Resources
The following is a list of documents that provide background material, requirements, and related topics:
- Con Ops Supplemental Page for Requirements Gathering: Supplemental VCDE Requirements Elicitation Initiative 2009 - 2010;
- Semantic Requirements Forum: https://cabig-kc.nci.nih.gov/Vocab/forums/viewforum.php?f=34
- Con Ops Stakeholders: Semantic Infrastructure Concept of Operations Stakeholders
- Con Ops Requirements: Requirements Questionnaires
- Con Ops Use Cases: Use Cases for Semantic Requirements
Terms & Definitions
Term | Definition |
|---|---|
MUST | This word means that the definition is an absolute requirement of the specification. |
MUST NOT | This phrase means that the definition is an absolute prohibition of the specification. |
WILL | This word means that the definition is an absolute future requirement of the specification. |
WILL NOT | This phrase mean that the definition is an absolute future prohibition of the specification. |
SHOULD | This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
SHOULD NOT | This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. |
MAY | This word means that a requirement is truly optional. The developer may choose to include the item based on the needs of their design. |
Use Case Level Criteria
When designing use cases, it is important to maintain a consistent approach to determining at which level use cases are placed when they are authored. The granularity of the use case directly relates to its implementability, so maintaining a leveling scheme will insure that use cases are implemented, tested, etc. at a consistent level. In alignment with this, we will maintain the following use case leveling criteria:
- Global statement
Example: manage patient's health - Use Case Level 0: most general, high level business process
Example: treat this patient for cancer - Use Case Level 1: next level of business flow, such as inter-department level
Example: treat this patient for cancer by using diagnostics, education, treatments, etc. - Use Case Level 2: specific enough to drive major model dimensions (static/information model, behavioral model, governance model, etc.) and can include some exception conditions
Example: treat this patient for cancer by ordering these lab tests, evaluating the results, customizing a treatment or treatment plan to specifically address concerns - Use Case Level 3: includes details of each exchange of information, as well as assumptions about system boundaries
Example: treat this patient for cancer by ordering these lab tests in the caEHR system
i. find the patient, if new add patient, if not check for update
ii. create request(s) for testing for patient, then evaluate the results,
ii-a. read the faxed copy of the result or
ii-b. receive notification in Provider email that a result is ready for viewing, etc... - Use Case Level 4: project-specific solution for exchanges detailed in use case level-3 (could be MSG, SOA, or both)
Example:Standard Process Flow
1. Provider Refers Patient for Cancer Treatment
2. Provider and Patient have an encounter
3. Provider evaluates Patient's condition, treatment plan, current statistics, requests diagnostics
4. Provider updates treatment plan
5. Patient is treated, outcomes documented
6. Flow returns to any of the above steps or patient is released from cancer treatment
Assumptions and Dependencies
Usability
The user interface shall be designed for ease-of-use by the designated end-users, shall use terms common to the user's normal business environment, and shall require little to no additional training on the system. Drop down menus, Google-like searches, and tooltips should be used wherever appropriate.
Accessibility
The user interface should be accessible via a web browser.
General Assumptions
Following is a list of basic assumptions:
- Federated Discovery Services: Knowledge Repository Services will be distributable and discoverable in a federated manner
- Security Considerations: services and underlying data will be secured using the caBIG security architecture
- Subscriptions/Notifications: services requiring subscription and notification functionality will be enabled by the caBIG pub/sub architecture
- ISO 11179 Ed 3: the Knowledge Repository will comply with ISO 11179 Ed 3 specifications. See here for our analysis.
- Ability to have non-administered items: the Knowledge Repository will provide for non-administered items in the ISO 11179 notion
- Duplication/identification: in compliance with the Federated Discovery Services assumption, reference of data, data duplication, and unique identification of data will be handled
Dependencies
TBD
Functional Requirements
Model Services
Some basic description of model services.
ID | Requirement | Source | Release |
|---|---|---|---|
MOS-1 | The Model Service MUST support the abilities to record new model elements. | --- | |
MOS-2 | The Model Service MUST support the abilities to record new assertions. | --- | |
MOS-3 | The Model Service MUST support the abilities to record new rules. | --- | |
MOS-4 | The Model Service SHOULD support the abilities to record queries. | --- | |
MOS-10 | The Model Service MUST allow for the discovery of models based on querying model parts. | --- | |
MOS-11 | The Model Service MAY support the federated discovery of models. | --- | |
MOS-12 | The Model Service SHOULD allow the discovery of related model parts. | --- | |
MOS-20 | The Model Service MUST support the comparison of model parts. | --- | |
MOS-21 | The Model Service MUST support the harmonization of models through the comparison of model parts. | --- | |
MOS-30 | The Model Service SHOULD support the merging of different parts of different models. | --- | |
MOS-40 | The Model Service MAY support the graphical visualization of models. | --- | |
MOS-50 | The Model Service MUST support the versioning of models. | --- | |
MOS-60 | The Model Service MUST allow the retiring of models. | --- | |
MOS-70 | The Model Service MUST allow the of updating of parts of a model. | --- | |
MOS-80 | The Model Service MUST allow the deletion/unregistering of models. | --- | |
MOS-90 | The Model Service SHOULD support the transformation of models. | --- | |
MOS-100 | The Model Service SHOULD support the validation of models. | --- | |
MOS-110 | The Model Service MUST support the reuse of model parts. | --- | |
MOS-111 | The Model Service MUST support the entire reuse of direct copies of model parts. | --- | |
MOS-120 | The Model Service MUST support the extension of model parts. | --- | |
MOS-121 | The Model Service MUST allow the extension of classes. | --- | |
MOS-122 | The Model Service MUST allow the extensions of model part relationships. | --- | |
MOS-123 | The Model Service SHOULD allow the extension of attribute value lists. | --- | |
MOS-130 | The Model Service SHOULD support the constraining of model parts. | --- | |
MOS-131 | The Model Service SHOULD allow for classes to be subsetted. | --- | |
MOS-132 | The Model Service SHOULD allow for attribute value lists to be subsetted. | --- | |
MOS-140 | The Model Service MUST support the discovery of services related by model similarities. | --- | |
MOS-150 | The Model Service SHOULD support the discovery of related documentation. | --- |
Metadata Services
Some basic description of metadata services.
ID | Requirement | Source | Release |
|---|---|---|---|
MDS-1 | The Metadata Service MUST support the notion of data elements. | --- | |
MDS-2 | The Metadata Service MUST allow the recording of data elements. | --- | |
MDS-3 | The Metadata Service MUST allow new data element assertions to be made. | --- | |
MDS-4 | The Metadata Service MUST allow for data elements to be updated. | --- | |
MDS-5 | The Metadata Service MUST allow for data elements to be versioned. | --- | |
MDS-6 | The Metadata Service SHOULD allow for data element business rules to be validated. | --- | |
MDS-7 | The Metadata Service MUST allow for data elements to be retired. | --- | |
MDS-8 | The Metadata Service MUST allow for data elements to be deleted/rolled back. | --- | |
MDS-9 | The Metadata Service MUST support the discovery of reusable data element content. | --- | |
MDS-10 | The Metadata Service SHOULD support the notion of data element usage information. | --- | |
MDS-11 | The Metadata Service MUST support metadata to be queried by data element. | --- | |
MDS-12 | The Metadata Service SHOULD support metadata to be queried by data element in a federated manner. | --- | |
MDS-13 | The Metadata Service MUST support the comparison of data elements | --- | |
MDS-14 | The Metadata Service SHOULD support the creation of a new data element from an existing data element. | --- | |
MDS-15 | The Metadata Service MUST support the discovery of related models by data element. | --- | |
MDS-16 | The Metadata Service SHOULD support the discover related metadata items by data element. | --- | |
MDS-17 | The Metadata Service SHOULD support the discovery of related services by data element. | --- | |
MDS-18 | The Metadata Service SHOULD support the discovery of related data element rules. | --- | |
MDS-19 | The Metadata Service SHOULD support the discovery of forms related by data element. | --- | |
MDS-101 | The Metadata Service MUST support the notion of value domains. | --- | |
MDS-102 | The Metadata Service MUST allow the recording of value domains. | --- | |
MDS-103 | The Metadata Service MUST allow new value domain assertions to be made. | --- | |
MDS-104 | The Metadata Service MUST allow for value domains to be updated. | --- | |
MDS-105 | The Metadata Service MUST allow for value domains to be versioned. | --- | |
MDS-106 | The Metadata Service SHOULD allow for value domain business rules to be validated. | --- | |
MDS-107 | The Metadata Service MUST allow for value domains to be retired. | --- | |
MDS-108 | The Metadata Service MUST allow for value domains to be deleted/rolled back. | --- | |
MDS-109 | The Metadata Service MUST support the discovery of reusable value domain content. | --- | |
MDS-110 | The Metadata Service SHOULD support the notion of value domain usage information. | --- | |
MDS-111 | The Metadata Service MUST support metadata to be queried by value domain. | --- | |
MDS-112 | The Metadata Service SHOULD support metadata to be queried by value domain in a federated manner. | --- | |
MDS-113 | The Metadata Service MUST support the comparison of value domains | --- | |
MDS-114 | The Metadata Service SHOULD support the creation of a new value domain from an existing data element. | --- | |
MDS-115 | The Metadata Service MUST support the discovery of related models by value domain. | --- | |
MDS-116 | The Metadata Service SHOULD support the discover related metadata items by value domain. | --- | |
MDS-117 | The Metadata Service SHOULD support the discovery of related services by value domain. | --- | |
MDS-118 | The Metadata Service SHOULD support the discovery of related value domain rules. | --- | |
MDS-119 | The Metadata Service SHOULD support the discovery of forms related by value domain. | --- | |
MDS-120 | The Metadata Service SHOULD support the ability to create a value domain through subsetting/constraining. | --- | --- |
MDS-121 | The Metadata Service SHOULD allow value domains to be extended through the creation of new from existing. | --- | --- |
MDS-130 | The Metadata Service SHOULD support semantic transformations that would be explicitly based on value domain mapping, e.g. to the same value meaning. | --- | |
MDS-131 | The Metadata Service MAY support syntactic transformations that would transform source value domain representation to target value domain representation. | --- | |
MDS-201 | The Metadata Service MUST support the notion of data element concepts. | --- | |
MDS-202 | The Metadata Service MUST allow the recording of data element concepts. | --- | |
MDS-203 | The Metadata Service MUST allow new data element concept assertions to be made. | --- | |
MDS-204 | The Metadata Service MUST allow for data element concepts to be updated. | --- | |
MDS-205 | The Metadata Service MUST allow for data element concepts to be versioned. | --- | |
MDS-206 | The Metadata Service SHOULD allow for data element concept business rules to be validated. | --- | |
MDS-207 | The Metadata Service MUST allow for data element concepts to be retired. | --- | |
MDS-208 | The Metadata Service MUST allow for data element concepts to be deleted/rolled back. | --- | |
MDS-209 | The Metadata Service MUST support the discovery of reusable data element concept content. | --- | |
MDS-210 | The Metadata Service SHOULD support the notion of data element concept usage information. | --- | |
MDS-211 | The Metadata Service MUST support metadata to be queried by data element concept. | --- | |
MDS-212 | The Metadata Service SHOULD support metadata to be queried by data element concept in a federated manner. | --- | |
MDS-213 | The Metadata Service MUST support the comparison of data element concepts | --- | |
MDS-214 | The Metadata Service SHOULD support the creation of a new data element concept from an existing data element concept. | --- | |
MDS-215 | The Metadata Service MUST support the discovery of related models by data element concept. | --- | |
MDS-216 | The Metadata Service SHOULD support the discover related metadata items by data element concept. | --- | |
MDS-217 | The Metadata Service SHOULD support the discovery of related services by data element concept. | --- | |
MDS-218 | The Metadata Service SHOULD support the discovery of related data element concept rules. | --- | |
MDS-219 | The Metadata Service SHOULD support the discovery of forms related by data element concept. | --- | |
MDS-220 | The Metadata Service MUST support the discovery of related data elements by data element concept. | --- | |
MDS-221 | The Metadata Service SHOULD support the discovery of related value sets by data element concept. | --- | |
MDS-230 | The Metadata Service SHOULD support the creation of a data element from an existing data element concept and value domain. | --- | |
MDS-231 | The Metadata Service SHOULD support the creation of a new data element concept from an existing data element concept. | --- |
Registry-Registry Service
ID | Requirement | Source | Release |
|---|---|---|---|
RRS-1 | The Registry-Registry service MUST support the import of content from one registry to another. | --- | |
RRS-10 | The Registry-Registry service MUST support the export of content in a convenient data format. | --- | |
RRS-20 | The Registry-Registry service SHOULD support the update of edited content from one registry to another. | --- | |
RRS-30 | The Registry-Registry service MAY support the search of one registry from another. | --- | |
RRS-40 | The Registry-Registry service MUST support content to be submitted from one registry to another. | --- | |
RRS-50 | The Registry-Registry service MUST support the registration of content from one registry to another. | --- | |
RRS-60 | The Registry-Registry service MUST support the updating of the registration of content from one registry to another. | --- |
General Service
ID | Requirement | Source | Release |
|---|---|---|---|
GEN-1 | Services SHOULD support the notion of annotating any data with well defined concepts. | --- | |
GEN-10 | Services SHOULD allow users to subscribe for notifications of changes to data. | --- | |
GEN-20 | Services MUST support the notion of data reuse. | --- |
Metadata Registry Tools
ID | Requirement | Source | Release |
|---|---|---|---|
MRT-1 | A Metadata Registry Tool MUST support a clinician friendly browser. | --- | |
MRT-10 | A Metadata Registry Tool MUST support an information specialist browser. | --- | |
MRT-20 | A Metadata Registry Tool SHOULD support a customizable browser. | --- | |
MRT-30 | A Metadata Registry Tool MAY support a generalized portal that integrates various metadata registry tools. | --- | |
MRT-40 | A Metadata Registry Tool SHOULD allow workflow management to support ECCF artifact creation. | --- | |
MRT-50 | A Metadata Registry Tool MUST support an interface of browser/editing models and metadata with modeling tools. | --- |
...
Related Documentation
The following is a list of documents that provide background material, requirements, and related topics:
- Con Ops Supplemental Page for Requirements Gathering: https://wiki.nci.nih.gov/display/VCDE/Supplemental+Page+for+Requirements+Gathering
- Semantic Requirements Forum: https://cabig-kc.nci.nih.gov/Vocab/forums/viewforum.php?f=34
- Con Ops Stakeholders: https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/SI_Conop_Stakeholders
- Con Ops Requirements: https://wiki.nci.nih.gov/display/VCDE/Requirements+Questionnaires
- Con Ops Use Cases: https://wiki.nci.nih.gov/display/VCDE/Use+Cases+for+Semantic+Requirements
Terms & Definitions
Term | Definition |
|---|---|
MUST | This word means that the definition is an absolute requirement of the specification. |
MUST NOT | This phrase means that the definition is an absolute prohibition of the specification. |
WILL | This word means that the definition is an absolute future requirement of the specification. |
WILL NOT | This phrase mean that the definition is an absolute future prohibition of the specification. |
SHOULD | This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
SHOULD NOT | This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. |
MAY | This word means that a requirement is truly optional. The developer may choose to include the item based on the needs of their design. |
Assumptions and Dependencies
Usability
The user interface shall be designed for ease-of-use by the designated end-users, shall use terms common to the user's normal business environment, and shall require little to no additional training on the system. Drop down menus, Google-like searches, and tooltips should be used wherever appropriate.
Accessibility
The user interface should be accessible via a web browser.
General Assumptions
Following is a list of basic assumptions:
- Federated Discovery Services: Knowledge Repository Services will be distributable and discoverable in a federated manner
- Security Considerations: services and underlying data will be secured using the caBIG security architecture
- Subscriptions/Notifications: services requiring subscription and notification functionality will be enabled by the caBIG pub/sub architecture
- ISO 11179 Ed 3: the Knowledge Repository will comply with ISO 11179 Ed 3 specifications
- Ability to have non-administered items: the Knowledge Repository will provide for non-administered items in the ISO 11179 notion
- Duplication/identification: in compliance with the Federated Discovery Services assumption, reference of data, data duplication, and unique identification of data will be handled
Dependencies
TBD
Functional Requirements
Model Services
Some basic description of model services.
ID | Requirement |
|---|---|
MOS-1 | Record |
MOS-2 | New assertions |
MOS-3 | Rules/results |
MOS-4 | Queries/assertions |
MOS-10 | Discover |
MOS-11 | Federated query |
MOS-12 | Find related metadata |
MOS-20 | Compare |
MOS-21 | Harmonize |
MOS-30 | Merge |
MOS-40 | Graphical/visualize |
MOS-50 | Version |
MOS-60 | Retire |
MOS-70 | Update |
MOS-80 | Delete/unregister |
MOS-90 | Transform |
MOS-100 | Validate |
MOS-110 | Reuse |
MOS-111 | Copy |
MOS-120 | Extend |
MOS-121 | Extend classes |
MOS-122 | Add relationships |
MOS-123 | Extend attribute value list |
MOS-130 | Constrain |
MOS-131 | Subset classes |
MOS-132 | Subset/constrain attribute value lists |
MOS-140 | Find related services |
MOS-150 | Find related documentation |
Metadata Services
Some basic description of metadata services.
ID | Requirement |
|---|---|
MDS-1 | Data Element |
MDS-2 | Record (no rules) |
MDS-3 | New assertions |
MDS-4 | Update |
MDS-5 | Version |
MDS-6 | Validate business rules |
MDS-7 | Retire |
MDS-8 | Delete/rollback |
MDS-9 | Discover reusable content |
MDS-10 | Usage information |
MDS-11 | Search/query |
MDS-12 | Federated search/query |
MDS-13 | Compare |
MDS-14 | Create new from existing |
MDS-15 | Discover related models |
MDS-16 | Discover related metadata items |
MDS-17 | Discover related services |
MDS-18 | Discover related rules |
MDS-19 | Discover related forms |
MDS-101 | Value Domain |
MDS-102 | Record (no rules) |
MDS-103 | New assertions |
MDS-104 | Update |
MDS-105 | Version |
MDS-106 | Validate business rules |
MDS-107 | Retire |
MDS-108 | Delete/rollback |
MDS-109 | Discover reusable content |
MDS-110 | Usage information |
MDS-111 | Search/query |
MDS-112 | Federated search/query |
MDS-113 | Compare |
MDS-114 | Create new from existing |
MDS-115 | Discover related models |
MDS-116 | Discover related metadata items |
MDS-117 | Discover related services |
MDS-118 | Discover related rules |
MDS-119 | Discover related forms |
MDS-120 | Create subset/constrain |
MDS-120 | Extend (create new from existing) |
MDS-120 | Semantic transformations (Explicitly based on mapping e.g. to the same Value Meaning) |
MDS-120 | Syntactic transformations ( Source representation to Target representation) |
MDS-201 | Data Element Concept |
MDS-202 | Record (no rules) |
MDS-203 | New assertions |
MDS-204 | Update |
MDS-205 | Version |
MDS-206 | Validate business rules |
MDS-207 | Retire |
MDS-208 | Delete/rollback |
MDS-209 | Discover reusable content |
MDS-210 | Usage information |
MDS-211 | Search/query |
MDS-212 | Federated search/query |
MDS-213 | Compare |
MDS-214 | Create new from existing |
MDS-215 | Discover related models |
MDS-216 | Discover related metadata items |
MDS-217 | Discover related services |
MDS-218 | Discover related rules |
MDS-219 | Discover related forms |
MDS-220 | Discover related data elements |
MDS-222 | Discover related value sets |
MDS-223 | Create data element from existing data element concept and value domain |
MDS-224 | Create new data element concept from existing data element concept |
Non-functional Requirements
...
ID | Requirement |
|---|---|
SE-1 | The system must limit access to authorized individuals. |
SE-10 | Electronic Signatures should meet necessary requirements as described in 21 CFR part 11. |
SE-20 | The application will address section 508 of the Rehabilitation Act of 1973 where appropriate and reasonable. |
SE-30 | System developers must adhere to the caBIG™ caBIG Data Sharing & Intellectual Capital Policy and Procedures |
...
