Definition for Code SystemResourceSecurityCategory

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

<CodeSystem xmlns="http://hl7.org/fhir">
  <id value="resource-security-category"/> 
  <meta> 
    <lastUpdated value="2022-09-10T04:52:37.223+10: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 
        <code> http://hl7.org/fhir/resource-security-category</code>  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.4.1902"/> 
  </identifier> 
  <version value="5.0.0-ballot"/> 
  <name value="ResourceSecurityCategory"/> 
  <status value="draft"/> 
  <experimental value="false"/> 
  <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>