HL7 Terminology (THO)
4.0.0 - Publication
This page is part of the HL7 Terminology (v4.0.0: Release) based on FHIR R4. The current version which supercedes this version is 5.2.0. For a full list of available versions, see the Directory of published versions
Official URL: http://terminology.hl7.org/ValueSet/v3-SecurityObservationType | Version: 2.0.0 | |||
Active as of 2014-03-26 | Computable Name: SecurityObservationType | |||
Other Identifiers: : urn:oid:2.16.840.1.113883.1.11.20457 |
Type of security metadata observation made about an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security metadata are used in security labels. According to ISO/TS 22600-3:2009(E) A.9.1.7 SECURITY LABEL MATCHING, Security label matching compares the initiator’s clearance to the target’s security label. All of the following must be true for authorization to be granted:
References
This value set is not used here; it may be used elsewhere (e.g. specifications and/or implementations that use this content)
http://terminology.hl7.org/CodeSystem/v3-ActCode
where concept is-a SECOBS
This value set contains 16 concepts
Expansion based on ActCode v6.1.0 (CodeSystem)
Level | Code | System | Display | Definition |
1 | SECOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | SecurityObservationType | An observation identifying security metadata about an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security metadata are used to name security labels. Rationale: According to ISO/TS 22600-3:2009(E) A.9.1.7 SECURITY LABEL MATCHING, Security label matching compares the initiator's clearance to the target's security label. All of the following must be true for authorization to be granted:
Examples: SecurityObservationType security label fields include:
Usage Note: SecurityObservationType codes designate security label field types, which are valued with an applicable SecurityObservationValue code as the "security label tag". |
2 | SECCATOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security category observation | Type of security metadata observation made about the category of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security category metadata is defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995 as: "A nonhierarchical grouping of sensitive information used to control access to data more finely than with hierarchical security classification alone." Rationale: A security category observation supports requirement to specify the type of IT resource to facilitate application of appropriate levels of information security according to a range of levels of impact or consequences that might result from the unauthorized disclosure, modification, or use of the information or information system. A resource is assigned to a specific category of information (e.g., privacy, medical, proprietary, financial, investigative, contractor sensitive, security management) defined by an organization or in some instances, by a specific law, Executive Order, directive, policy, or regulation. [FIPS 199] Examples: Types of security categories include:
|
2 | SECCLASSOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security classification observation | Type of security metadata observation made about the classification of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security classification is defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995 as: "The determination of which specific degree of protection against access the data or information requires, together with a designation of that degree of protection." Security classification metadata is based on an analysis of applicable policies and the risk of financial, reputational, or other harm that could result from unauthorized disclosure. Rationale: A security classification observation may indicate that the confidentiality level indicated by an Act or Role confidentiality attribute has been overridden by the entity responsible for ascribing the SecurityClassificationObservationValue. This supports the business requirement for increasing or decreasing the level of confidentiality (classification or declassification) based on parameters beyond the original assignment of an Act or Role confidentiality. Examples: Types of security classification include: HL7 Confidentiality Codes such as very restricted, unrestricted, and normal. Intelligence community examples include top secret, secret, and confidential. Usage Note: Security classification observation type codes designate security label field types, which are valued with an applicable SecurityClassificationObservationValue code as the "security label tag". |
2 | SECCONOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security control observation | Type of security metadata observation made about the control of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security control metadata convey instructions to users and receivers for secure distribution, transmission, and storage; dictate obligations or mandated actions; specify any action prohibited by refrain policy such as dissemination controls; and stipulate the permissible purpose of use of an IT resource. Rationale: A security control observation supports requirement to specify applicable management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. [FIPS 199] Examples: Types of security control metadata include:
|
2 | SECINTOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security integrity observation | Type of security metadata observation made about the integrity of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Rationale: A security integrity observation supports the requirement to guard against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. (44 U.S.C., SEC. 3542) Examples: Types of security integrity metadata include:
|
3 | SECALTINTOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security alteration integrity observation | Type of security metadata observation made about the alteration integrity of an IT resource (data, information object, service, or system capability), which indicates the mechanism used for authorized transformations of the resource. Examples: Types of security alteration integrity observation metadata, which may value the observation with a code used to indicate the mechanism used for authorized transformation of an IT resource, including:
|
3 | SECDATINTOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security data integrity observation | Type of security metadata observation made about the data integrity of an IT resource (data, information object, service, or system capability), which indicates the security mechanism used to preserve resource accuracy and consistency. Data integrity is defined by ISO 22600-23.3.21 as: "The property that data has not been altered or destroyed in an unauthorized manner", and by ISO/IEC 2382-8: The property of data whose accuracy and consistency are preserved regardless of changes made." Examples: Types of security data integrity observation metadata, which may value the observation, include cryptographic hash function and digital signature. |
3 | SECINTCONOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security integrity confidence observation | Type of security metadata observation made about the integrity confidence of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Examples: Types of security integrity confidence observation metadata, which may value the observation, include highly reliable, uncertain reliability, and not reliable. Usage Note: A security integrity confidence observation on an Act may indicate that a valued Act.uncertaintycode attribute has been overridden by the entity responsible for ascribing the SecurityIntegrityConfidenceObservationValue. This supports the business requirements for increasing or decreasing the assessment of the reliability or trustworthiness of an IT resource based on parameters beyond the original assignment of an Act statement level of uncertainty. |
3 | SECINTPRVOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security integrity provenance observation | Type of security metadata observation made about the provenance integrity of an IT resource (data, information object, service, or system capability), which indicates the lifecycle completeness of an IT resource in terms of workflow status such as its creation, modification, suspension, and deletion; locations in which the resource has been collected or archived, from which it may be retrieved, and the history of its distribution and disclosure. Integrity provenance metadata about an IT resource may be used to assess its veracity, reliability, and trustworthiness. Examples: Types of security integrity provenance observation metadata, which may value the observation about an IT resource, include:
|
4 | SECINTPRVABOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security integrity provenance asserted by observation | Type of security metadata observation made about the integrity provenance of an IT resource (data, information object, service, or system capability), which indicates the entity that made assertions about the resource. The asserting entity may not be the original informant about the resource. Examples: Types of security integrity provenance asserted by observation metadata, which may value the observation, including:
|
4 | SECINTPRVRBOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security integrity provenance reported by observation | Type of security metadata observation made about the integrity provenance of an IT resource (data, information object, service, or system capability), which indicates the entity that reported the existence of the resource. The reporting entity may not be the original author of the resource. Examples: Types of security integrity provenance reported by observation metadata, which may value the observation, include:
|
3 | SECINTSTOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | security integrity status observation | Type of security metadata observation made about the integrity status of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Indicates the completeness of an IT resource in terms of workflow status, which may impact users that are authorized to access and use the resource. Examples: Types of security integrity status observation metadata, which may value the observation, include codes from the HL7 DocumentCompletion code system such as legally authenticated, in progress, and incomplete. |
2 | SECTRSTOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | SECTRSTOBS | An observation identifying trust metadata about an IT resource (data, information object, service, or system capability), which may be used as a trust attribute to populate a computable trust policy, trust credential, trust assertion, or trust label field in a security label or trust policy, which are principally used for authentication, authorization, and access control decisions. |
3 | TRSTACCRDOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | trust accreditation observation | Type of security metadata observation made about the formal declaration by an authority or neutral third party that validates the technical, security, trust, and business practice conformance of Trust Agents to facilitate security, interoperability, and trust among participants within a security domain or trust framework. |
3 | TRSTAGREOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | trust agreement observation | Type of security metadata observation made about privacy and security requirements with which a security domain must comply. [ISO IEC 10181-1] |
3 | TRSTCERTOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | trust certificate observation | Type of security metadata observation made about a set of security-relevant data issued by a security authority or trusted third party, together with security information which is used to provide the integrity and data origin authentication services for an IT resource (data, information object, service, or system capability). [Based on ISO IEC 10181-1] For example,
|
3 | TRSTFWKOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | trust framework observation | Type of security metadata observation made about a complete set of contracts, regulations or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements. [Kantara Initiative] |
3 | TRSTLOAOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | trust assurance observation | Type of security metadata observation made about the digital quality or reliability of a trust assertion, activity, capability, information exchange, mechanism, process, or protocol. |
3 | TRSTMECOBS | http://terminology.hl7.org/CodeSystem/v3-ActCode | trust mechanism observation | Type of security metadata observation made about a security architecture system component that supports enforcement of security policies. |
Explanation of the columns that may appear on this page:
Level | A few code lists that FHIR defines are hierarchical - each code is assigned a level. In this scheme, some codes are under other codes, and imply that the code they are under also applies |
System | The source of the definition of the code (when the value set draws in codes defined elsewhere) |
Code | The code (used as the code in the resource instance) |
Display | The display (used in the display element of a Coding). If there is no display, implementers should not simply display the code, but map the concept into their application |
Definition | An explanation of the meaning of the concept |
Comments | Additional notes about how to use the code |
History
Date | Action | Custodian | Author | Comment |
2020-05-06 | revise | Vocabulary WG | Ted Klein | Migrated to the UTG maintenance environment and publishing tooling. |
2014-03-26 | revise | 2014T1_2014-03-26_001283 (RIM release ID) | Vocabulary (Woody Beeler) (no record of original request) | Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26 |