Codesystem-resource-security-category.xml

Definition for Code System ResourceSecurityCategory

<?xml version="1.0" encoding="UTF-8"?>

<CodeSystem xmlns="http://hl7.org/fhir">
  <id value="resource-security-category"/> 
  <meta> 
    <lastUpdated value="2021-12-20T14:08:35.086+11:00"/> 
    <profile value="http://hl7.org/fhir/StructureDefinition/shareablecodesystem"/> 
  </meta> 
  <text> 
    <status value="generated"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p> This code system http://hl7.org/fhir/resource-security-category defines the following
         codes:</p> 
      <table class="codes">
        <tr> 
          <td style="white-space:nowrap">
            <b> Code</b> 
          </td> 
          <td> 
            <b> Display</b> 
          </td> 
          <td> 
            <b> Definition</b> 
          </td> 
        </tr> 
        <tr> 
          <td style="white-space:nowrap">anonymous
            <a name="resource-security-category-anonymous"> </a> 
          </td> 
          <td> Anonymous READ Access Resource</td> 
          <td> These resources tend to not contain any individual data, or business sensitive data. Most
             often these Resources will be available for anonymous access, meaning there is no access
             control based on the user or system requesting. However these Resources do tend to contain
             important information that must be authenticated back to the source publishing them, and
             protected from integrity failures in communication. For this reason server authenticated
             https (TLS) is recommended to provide authentication of the server and integrity protection
             in transit. This is normal web-server use of https.</td> 
        </tr> 
        <tr> 
          <td style="white-space:nowrap">business
            <a name="resource-security-category-business"> </a> 
          </td> 
          <td> Business Sensitive Resource</td> 
          <td> These Resources tend to not contain any individual data, but do have data that describe
             business or service sensitive data. The use of the term Business is not intended to only
             mean an incorporated business, but rather the more broad concept of an organization, location,
             or other group that is not identifable as individuals. Often these resources will require
             some for of client authentication to assure that only authorized access is given. The
             client access control may be to individuals, or may be to system identity. For this purpose
             possible client authentication methods such as: mutual-authenticated-TLS, APIKey, App
             signed JWT, or App OAuth client-id JWT For example: a App that uses a Business protected
             Provider Directory to determine other business endpoint details.</td> 
        </tr> 
        <tr> 
          <td style="white-space:nowrap">individual
            <a name="resource-security-category-individual"> </a> 
          </td> 
          <td> Individual Sensitive Resource</td> 
          <td> These Resources do NOT contain Patient data, but do contain individual information about
             other participants. These other individuals are Practitioners, PractitionerRole, CareTeam,
             or other users. These identities are needed to enable the practice of healthcare. These
             identities are identities under general privacy regulations, and thus must consider Privacy
             risk. Often access to these other identities are covered by business relationships. For
             this purpose access to these Resources will tend to be Role specific using methods such
             as RBAC or ABAC.</td> 
        </tr> 
        <tr> 
          <td style="white-space:nowrap">patient
            <a name="resource-security-category-patient"> </a> 
          </td> 
          <td> Patient Sensitive</td> 
          <td> These Resources make up the bulk of FHIR and therefore are the most commonly understood.
             These Resources contain highly sesitive health information, or are closely linked to highly
             sensitive health information. These Resources will often use the security labels to differentiate
             various confidentiality levels within this broad group of Patient Sensitive data. Access
             to these Resources often requires a declared Purpose Of Use. Access to these Resources
             is often controlled by a Privacy Consent.</td> 
        </tr> 
        <tr> 
          <td style="white-space:nowrap">not-classified
            <a name="resource-security-category-not-classified"> </a> 
          </td> 
          <td> Not classified</td> 
          <td> Some Resources can be used for a wide scope of use-cases that span very sensitive to very
             non-sensitive. These Resources do not fall into any of the above classifications, as their
             sensitivity is highly variable. These Resources will need special handling. These Resources
             often contain metadata that describes the content in a way that can be used for Access
             Control decisions.</td> 
        </tr> 
      </table> 
    </div> 
  </text> 
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-wg">
    <valueCode value="fhir"/> 
  </extension> 
  <url value="http://hl7.org/fhir/resource-security-category"/> 
  <identifier> 
    <system value="urn:ietf:rfc:3986"/> 
    <value value="urn:oid:2.16.840.1.113883.4.642.1.0"/> 
  </identifier> 
  <version value="4.3.0-snapshot1"/> 
  <name value="ResourceSecurityCategory"/> 
  <caseSensitive value="true"/> 
  <content value="complete"/> 
  <concept> 
    <code value="anonymous"/> 
    <display value="Anonymous READ Access Resource"/> 
    <definition value="These resources tend to not contain any individual data, or business sensitive data. Most
     often these Resources will be available for anonymous access, meaning there is no access
     control based on the user or system requesting. However these Resources do tend to contain
     important information that must be authenticated back to the source publishing them, and
     protected from integrity failures in communication. For this reason server authenticated
     https (TLS) is recommended to provide authentication of the server and integrity protection
     in transit. This is normal web-server use of https."/> 
  </concept> 
  <concept> 
    <code value="business"/> 
    <display value="Business Sensitive Resource"/> 
    <definition value="These Resources tend to not contain any individual data, but do have data that describe
     business or service sensitive data. The use of the term Business is not intended to only
     mean an incorporated business, but rather the more broad concept of an organization, location,
     or other group that is not identifable as individuals. Often these resources will require
     some for of client authentication to assure that only authorized access is given. The
     client access control may be to individuals, or may be to system identity. For this purpose
     possible client authentication methods such as: mutual-authenticated-TLS, APIKey, App
     signed JWT, or App OAuth client-id JWT For example: a App that uses a Business protected
     Provider Directory to determine other business endpoint details."/> 
  </concept> 
  <concept> 
    <code value="individual"/> 
    <display value="Individual Sensitive Resource"/> 
    <definition value="These Resources do NOT contain Patient data, but do contain individual information about
     other participants. These other individuals are Practitioners, PractitionerRole, CareTeam,
     or other users. These identities are needed to enable the practice of healthcare. These
     identities are identities under general privacy regulations, and thus must consider Privacy
     risk. Often access to these other identities are covered by business relationships. For
     this purpose access to these Resources will tend to be Role specific using methods such
     as RBAC or ABAC."/> 
  </concept> 
  <concept> 
    <code value="patient"/> 
    <display value="Patient Sensitive"/> 
    <definition value="These Resources make up the bulk of FHIR and therefore are the most commonly understood.
     These Resources contain highly sesitive health information, or are closely linked to highly
     sensitive health information. These Resources will often use the security labels to differentiate
     various confidentiality levels within this broad group of Patient Sensitive data. Access
     to these Resources often requires a declared Purpose Of Use. Access to these Resources
     is often controlled by a Privacy Consent."/> 
  </concept> 
  <concept> 
    <code value="not-classified"/> 
    <display value="Not classified"/> 
    <definition value="Some Resources can be used for a wide scope of use-cases that span very sensitive to very
     non-sensitive. These Resources do not fall into any of the above classifications, as their
     sensitivity is highly variable. These Resources will need special handling. These Resources
     often contain metadata that describes the content in a way that can be used for Access
     Control decisions."/> 
  </concept> 
</CodeSystem>