HL7 Terminology (THO)
3.0.0 - Publication
This page is part of the HL7 Terminology (v3.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
Summary
Defining URL: | http://terminology.hl7.org/ValueSet/v3-SecurityObservationType |
Version: | 2.0.0 |
Name: | SecurityObservationType |
Status: | Active as of 3/26/14 |
Definition: | 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:
|
OID: | 2.16.840.1.113883.1.11.20457 (for OID based terminology systems) |
Source Resource: | XML / JSON / Turtle |
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.0.0 (CodeSystem)
All codes in this table are from the system http://terminology.hl7.org/CodeSystem/v3-ActCode
Lvl | Code | Display | Definition |
0 | SECOBS | 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: * The security policy identifiers shall be identical * The classification level of the initiator shall be greater than or equal to that of the target (that is, there shall be at least one value in the classification list of the clearance greater than or equal to the classification of the target), and * For each security category in the target label, there shall be a security category of the same type in the initiator's clearance and the initiator's classification level shall dominate that of the target. **Examples:** SecurityObservationType security label fields include: * Confidentiality classification * Compartment category * Sensitivity category * Security mechanisms used to ensure data integrity or to perform authorized data transformation * Indicators of an IT resource completeness, veracity, reliability, trustworthiness, or provenance. *Usage Note:* SecurityObservationType codes designate security label field types, which are valued with an applicable SecurityObservationValue code as the "security label tag". |
1 | SECCATOBS | 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: * Compartment: A division of data into isolated blocks with separate security controls for the purpose of reducing risk. (ISO 2382-8). A security label tag that "segments" an IT resource by indicating that access and use is restricted to members of a defined community or project. (HL7 Healthcare Classification System) * Sensitivity: The characteristic of an IT resource which implies its value or importance and may include its vulnerability. (ISO 7492-2) Privacy metadata for information perceived as undesirable to share. (HL7 Healthcare Classification System) |
1 | SECCLASSOBS | 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". |
1 | SECCONOBS | 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: * handling caveats * dissemination controls * obligations * refrain policies * purpose of use constraints |
1 | SECINTOBS | 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: * Integrity status, which indicates the completeness or workflow status of an IT resource (data, information object, service, or system capability) * Integrity confidence, which indicates the reliability and trustworthiness of an IT resource * Integrity control, which indicates pertinent handling caveats, obligations, refrain policies, and purpose of use for the resource * Data integrity, which indicate the security mechanisms used to ensure that the accuracy and consistency are preserved regardless of changes made (ISO/IEC DIS 2382-8) * Alteration integrity, which indicate the security mechanisms used for authorized transformations of the resource * Integrity provenance, which indicates the entity responsible for a report or assertion relayed "second-hand" about an IT resource |
2 | SECALTINTOBS | 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: * translation * syntactic transformation * semantic mapping * redaction * masking * pseudonymization * anonymization |
2 | SECDATINTOBS | 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. |
2 | SECINTCONOBS | 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. |
2 | SECINTPRVOBS | 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: * completeness or workflow status, such as authentication * the entity responsible for original authoring or informing about an IT resource * the entity responsible for a report or assertion about an IT resource relayed “second-hand� * the entity responsible for excerpting, transforming, or compiling an IT resource |
3 | SECINTPRVABOBS | 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: * assertions about an IT resource by a patient * assertions about an IT resource by a clinician * assertions about an IT resource by a device |
3 | SECINTPRVRBOBS | 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: * reports about an IT resource by a patient * reports about an IT resource by a clinician * reports about an IT resource by a device |
2 | SECINTSTOBS | 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. |
1 | SECTRSTOBS | 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. |
2 | TRSTACCRDOBS | 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. |
2 | TRSTAGREOBS | 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\] |
2 | TRSTCERTOBS | 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,** * A Certificate Policy (CP), which is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular Certificate Policy might indicate the applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. \[Trust Service Principles and Criteria for Certification Authorities Version 2.0 March 2011 Copyright 2011 by Canadian Institute of Chartered Accountants. * A Certificate Practice Statement (CSP), which is a statement of the practices which an Authority employs in issuing and managing certificates. \[Trust Service Principles and Criteria for Certification Authorities Version 2.0 March 2011 Copyright 2011 by Canadian Institute of Chartered Accountants.\] |
2 | TRSTFWKOBS | 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\] |
2 | TRSTLOAOBS | 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. |
2 | TRSTMECOBS | 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 |
Source | 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 |