Page History

Page info
title title

The semantic requirements provide a framework for a detailed description of services in the architecture section. This section presents the requirements derived as a result of the requirements analysis of the use cases presented in previous section. The analysis includes tracing of requirements up to the use case and stakeholders and down to for semantic infrastructure are defined as they relate to the architecture, use cases, and stakeholders.  This section presents those requirements with tracing up to the use cases and down to the service capabilities specified later in this document. Note that the requirements  Note this section is not complete and this section an exhaustive list of requirements and is expected to evolve as additional requirements are addedanalyzed and defined.

This section includes the following:

...

Artifacts include support for different formats of models, both static and dynamic. Artifact management also includes the ability to manage content and clinical forms. A service specification is made up of service metadata, artifacts and the metadata supporting these artifacts. Artifact management primarily deals with managing artifact lifecycle and authoring of artifact metadata.

Static Models

Static models include a variety of models with different representations. Static models include but are not limited to:

• Schemas
  • XML, OWL, RDF
• Information Models
  • UML, HL7 MIF, 11179
• Meta Models
  • HL7 RIM
  • BRIDG
  • LS-DAM
• Transforms
  • OMG Ontology Definition Metamodel Tranforms
• Model Constraints
  • OCL, Schematron
• Data Types
  • ISO 21090/HL7 R2
  • HL7 R1
  • Primitives

Behavioral Models

In the context of this paper, behavioral dynamic models capture the behavior of services. 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 models include but are not limited to:

• HL7 SAIF behavioral model (which provides a formal model and grammar for service contracts)
• Orchestrations and Workflows
• Business Rules

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 communicaitons. Content includes:

• Service specification content, primarily unstructured text
• Images and other representations of static content

Forms

Forms include 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.

• 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.

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 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.

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.

Service Discovery and Governance

Service discovery and governance allows service developers to specify rich metadata about services. This enables better discovery, and governance of services. Service discovery and governance help to accomplish the following.

Promote Service Reuse: The use of well defined service metadata promotes better discovery and reuse of services during design and run time. Service metadata includes information about service interactions and dependencies. It also includes a classification scheme for organizing services based on business objectives, domain, and usage. It also links services to all the supporting artifacts in the specification and provides a placeholder for conformance statements. This enables better reuse across the enterprise and eliminates redundancy.

Establish Service policies: Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around governance, access control and other design and runtime constraints.

Provide Governance: This includes predefined templates, workflows, and governance policies for governing the service lifecycle as well as an approval and review process for service specifications and the ability to promote services through the stages of the service lifecycle.

Enable Better Discovery: Complex search offers a natural and user-friendly way to find services by progressively refining search results using a variety of criteria including attributes, artifacts, classification, usage scenarios, and dependencies. This includes runtime contract discovery, a powerful query mechanism that allows either the service orchestrator or a program to find the services that best fit the requirements of a given process. This increases both runtime and design time flexibility by enabling selection of services based on computable metadata.

The requirements listed above are derived from the following use cases:

Electronic Health Records: The caBIG® Clinical Information Suite project is developing service specifications and lacks the infrastructure to govern these services. Vendors and external implementations are expected to leverage the caBIG® Clinical Information Suite service specifications and there is currently no infrastructure that allows easy discovery and consumption of this information.

CBIIT Projects: CBIIT has adopted SOA. Service lifecycle management and governance are industry best practices for all organizations adopting SOA. Better service discovery and reuse improves productivity, avoids redundancy and makes it easier for the CBIIT enterprise architecture governance team to manage NCI's enterprise services portfolio.

Life Sciences: Service discovery based on a rich metadata and semantics of the underlying data play a critical role in developing research pipelines. Research pipelines are developed by connecting data and analytical services together to achieve a research objective.

Other National Initiatives: All EHR vendors and national initiatives rely on a services paradigm for integration and interoperability. A standardized services metamodel makes it easier for participating organization to discover and reuse services.

caGRID 2.0 Platform: The caGRID 2.0 Platform provides a runtime registry for service discovery. This service registry relies on a small subset of information for discovery. The semantic infrastructure provides a mechanism to leverage rich service and artifact metadata to extend this capability.

Clinical Data Forms Definition and Modeling

Improve visibility through publication. By providing a service which can be integrated into the development/testing/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.

Annotated 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 make clear the intent of a given artifact.

Support for Governance. By allowing 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.

Types of Artifacts

...

Static Models

...

Static models include a variety of models with different representations. Static models include but are not limited to:

• Schemas
  • XML, OWL, RDF
• Information Models
  • UML, HL7 MIF, 11179
• Meta Models
  • HL7 RIM
  • BRIDG
  • LS-DAM
• Transforms
  • OMG Ontology Definition Metamodel Tranforms
• Model Constraints
  • OCL, Schematron
• Data Types
  • ISO 21090/HL7 R2
  • HL7 R1
  • Primitives

...

Behavioral Models

...

In the context of this paper, behavioral dynamic models capture the behavior of services. 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 models include but are not limited to:

• HL7 SAIF behavioral model (which provides a formal model and grammar for service contracts)
• Orchestrations and Workflows
• Business Rules

...

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 communicaitons. Content includes:

• Service specification content, primarily unstructured text
• Images and other representations of static content

...

Forms

...

Forms include 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.

• 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.

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 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.

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.

Service Discovery and Governance

Service discovery and governance allows service developers to specify rich metadata about services. This enables better discovery, and governance of services. Service discovery and governance help to accomplish the following.

Promote Service Reuse: The use of well defined service metadata promotes better discovery and reuse of services during design and run time. Service metadata includes information about service interactions and dependencies. It also includes a classification scheme for organizing services based on business objectives, domain, and usage. It also links services to all the supporting artifacts in the specification and provides a placeholder for conformance statements. This enables better reuse across the enterprise and eliminates redundancy.

Establish Service policies: Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around governance, access control and other design and runtime constraints.

Provide Governance: This includes predefined templates, workflows, and governance policies for governing the service lifecycle as well as an approval and review process for service specifications and the ability to promote services through the stages of the service lifecycle.

Enable Better Discovery: Complex search offers a natural and user-friendly way to find services by progressively refining search results using a variety of criteria including attributes, artifacts, classification, usage scenarios, and dependencies. This includes runtime contract discovery, a powerful query mechanism that allows either the service orchestrator or a program to find the services that best fit the requirements of a given process. This increases both runtime and design time flexibility by enabling selection of services based on computable metadata.

Service Discovery Functions

• Identify service endpoint for analysis
• Identify service directory endpoint for analysis
• Extract service interface
• Annotate service interface providing undiscovered features or behaviors
• Manage lifecycle, governance and versioning of the service Interfaces

The requirements listed above are derived from the following use cases:

Electronic Health Records: The caBIG® Clinical Information Suite project is developing service specifications and lacks the infrastructure to govern these services. Vendors and external implementations are expected to leverage the caBIG® Clinical Information Suite service specifications and there is currently no infrastructure that allows easy discovery and consumption of this information.

CBIIT Projects: CBIIT has adopted SOA. Service lifecycle management and governance are industry best practices for all organizations adopting SOA. Better service discovery and reuse improves productivity, avoids redundancy and makes it easier for the CBIIT enterprise architecture governance team to manage NCI's enterprise services portfolio.

Life Sciences: Service discovery based on a rich metadata and semantics of the underlying data play a critical role in developing research pipelines. Research pipelines are developed by connecting data and analytical services together to achieve a research objective.

Other National Initiatives: All EHR vendors and national initiatives rely on a services paradigm for integration and interoperability. A standardized services metamodel makes it easier for participating organization to discover and reuse services.

caGRID 2.0 Platform: The caGRID 2.0 Platform provides a runtime registry for service discovery. This service registry relies on a small subset of information for discovery. The semantic infrastructure provides a mechanism to leverage rich service and artifact metadata to extend this capability.

Clinical Data Forms Definition and Modeling

Clinical Data Forms are the primary channel for capturing information in the healthcare and clinical domain. Forms also play a key role in information exchange and are critical to supporting interoperability in healthcare.

Define data entry forms using robust data representation. Ultimately the data that is captured on a form is used in many ways, but that data must provide a high level of meaningful use to insure the consumer knows how the data was capture and what context it represents.  In this way even a simple question on a form may result in a much more complex representation in the data.  As an example, a Yes or No question on a form may result in a codified representation of an observation.

Reuse of contextual representation. Since a given form my collect data for a context that might be common to many forms, being able to reuse these elements in a way that insures contextual consistency is a must.  Forms created with the form definition tool, must retrieve access from well defined metadata sources that provide common contexts, default values, and coded representations including value set binding.

Reuse of form elements. When defining a form element which is bound to a specific contextual representation, it should be easy to reuse that element with minimal reconfiguration. 

Provide Governance support. Forms and the supporting schemas need to be versioned as well as support the governance workflows.  This insures that documentation follows a consistent and planed  useClinical Data Forms are the primary channel for capturing information in the healthcare and clinical domain. Forms also play a key role in information exchange and are critical to supporting interoperability in healthcare.

A form differs from a document, in that a document is used to capture information, while a form defines skip patterns, validation rules, and other aspects required to capture or render information for a document.

A document in this context is specifically a clinical document which represents information about a clinical activity. The document contains the specific information gained during that clinical activity and supports the broader definitions of a document. Documents can be transformed into human readable forms, and be transferred or transmitted for use across different systems.

Clinical Data Forms Functions

• Define CMET or CMET like objects for reuse
• Define form
• Bind value set to data element
• Provide default form delivery
• Provide form data transformation
• Manage lifecycle, governance and version of forms and document schemas.

Based on the use cases the key forms requirements include:

...

One of the primary reasons for having structured data is to provide the ability to automate decision support and reasoning across information models, data types, and the terminology associated with the attributes of each data type. For the ECCF registry to provide maximal value to end users, it is necessary to support common decision support functions across the enterprise and to extend that through services to the end users.  In effect the semantic infrastructure must provide the tools to support Decision Support solutions.

Identify locations of 

Decision support services and the analytics that resolve to those services depend upon the metadata present in the ECCF registry and the relationships instantiated between objects in the registry.

...