This section includes the following:
Artifact management includes support for different formats of models (for example, Unified Modeling Language (UML), Web Ontology Language (OWL), or text), both static and dynamic, as well as the ability to manage content and clinical forms. Artifact management primarily deals with managing artifact lifecycle and authoring of artifact metadata.
A service specification is made up of service metadata, artifacts and the metadata supporting these artifacts. Artifact management enables creating a service specification and helps to accomplish the following:
Improve visibility through publication. When the management service can be integrated into the development, testing and production cycle, artifacts become available for review and discussion, as well as reference for supporting development. This helps insure proper understanding of applications and services being developed, and provides a standard and controlled method of access.
Annotate artifacts to expand understanding. To further improve the understanding of artifacts, the management service provides the ability to add annotations to both the parts of an artifact (depending on artifact type) and the artifact as a whole. Adding additional semantic definitions to an artifact allows for the searching and location of elements across artifact type, as well as makes clear the intent of a given artifact.
Support governance. When the management service allows for artifact versioning, along with state representation, artifact elements which require governance can be located and interacted with. This functional aspect of the artifact management provides a change history as well as links to external change control systems.
5.1.1 Types of Artifacts
Static Models
Static models include a variety of models with different representations. Static models include but are not limited to:
- Syntactical and semantic models: XML, OWL, RDF representations
- HL7 MIF, UML, 11179 representations
- Meta Models
- HL7 RIM (Reference Information Model)
- BRIDG (Biomedical Research Integrated Domain Group)
- LS-DAM (Life Sciences Domain Access Model)
- Transforms
- Object Management Group (OMG) Ontology Definition Metamodel Tranforms
- Model Constraints
- Object Constraint Language (OCL), Schematron
- Data Types
- ISO 21090 and HL7 R2
- HL7 R1
- Primitives
Behavioral Models
The behavioral models that will be managed by Semantic Infrastructure 2.0 are identified in the context of the Semantic Infrastructure 2.0 Roadmap, and in compliance with the CBIIT implementation of the Service-Aware Interoperability Framework (SAIF) Behavior Framework (BF).
The SAIF BF defines behavior as "a collection of interactions with a set of constraints on when they can occur in a given Working Interoperability/business process context." The "behavioral models" that will be managed by Semantic Infrastructure 2.0 collectively specify the behavioral semantics of services at the interface and NOT at the implementation level. Behavior of services provides an unambiguous definition of the service constraints, capabilities, dependencies and interactions. The metadata and grammar required to realize service behavior is called behavioral semantics. Behavioral semantics provide a mechanism for better service discovery and enforcing the constraints at design and runtime.
Dynamic model semantics, as defined in a CBIIT-defined and SAIF-compliant behavioral metamodel, will collectively define the behavioral metadata. A number of technologies still being explored will be used, including UML (Unified Modeling Language) profiles, OWL (Web Ontology Language), Resource Description Framework (RDF), and rules engines (such as Jess), to produce the metadata necessary to support automated (or at least semi-automated) workflow composition. As-yet-unspecified user-friendly tools will be used to provide various contextual inputs for a given workflow including but not limited to known pre- or post-conditions, input data sources, and desired data operations.
Content
Content includes all unstructured text and other forms of content that make up a service specification. Examples include storyboards and scope. Content is an integral part of service specification, and content is leveraged across the enterprise for documentation and communications. Content includes:
- Service specification content, primarily unstructured text
- Images and other representations of static content
Forms
Forms include but are not limited to Clinical Data Interchange Standards Consortium (CDISC), Operational Data Model (ODM), HL7 Clinical Document Architecture (CDA) documents, and HL7 Version 3 RIM-derived forms. This includes all aspects of the document including the style, definitions and semantics. CDISC and NCI CBIIT require a Distributed, Collaborative Form Template Development Environment and a Distributed Knowledge Repository to capture and manage its metadata. The following are required:
- Form Templates
- Reusable Form Sections
- Form Definitions
Specification Content
The National Cancer Institute has created many specification documents which include extended datatype flavors for the ISO 21090 datatypes as well as the ECCF specifications for the behavioral framework, information framework, and governance framework. The specifications are an integral part of the semantic infrastructure, allowing the user to fully understand and appropriately apply the many artifacts stored in the ECCF registry.
5.1.2 Artifact Management Functions
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 representation 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
- Provide rules and algorithms for the use of the artifacts in a particular service
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:
Electronic Health Records: The caBIG® Clinical Information Suite project has adopted ECCF for specifications and Clinical Document Architecture (CDA) documents for interoperability. Project requirements include the need for an infrastructure for managing all the artifacts generated during specification process, including HL7 models and documents. The project also intends to publish these artifacts for the community and vendors. The infrastructure must support better discovery, making all the relevant information available in the right context.
Office of the National Coordinator and other external EHR adopters: ONC has adopted the Continuity of Care Document (CCD) and Continuity of Care Record (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.
