METHOD AND APPARATUS GENERATING AND APPLYING SECURITY LABELS TO SENSITIVE DATA

Info

Publication number: 20180048650
Type: Application
Filed: Oct 2, 2017
Publication Date: Feb 15, 2018
Applicant: EDMOND SCIENTIFIC COMPANY (Chantilly, VA)
Inventors: Duane DECOUTEAU (Missoula, MT), John PITALE (Fairfax Station, VA)
Application Number: 15/722,496

Abstract

The disclosure comprises a method, an apparatus, and instructions for controlling a computer to implement a security labeling service (SLS) to tag an electronic record or data stream with security labels to ensure compliance with access restriction requirements. The SLS tags a record or data stream with security labels according to constraints including jurisdictional (government regulation), organizational policy, and authorization of a subject of record (e.g. patient consent). The SLS consumes a vocabulary dictionary to interpret the record and the constraints to generate rules for tagging the data. The original record or data stream is then tagged according to the rules. The tagged output is used to ensure compliance with the security labels.

Description

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Ser. No. 14/293,651, filed Jun. 2, 2014, and claims the benefit of U.S. Provisional Patent Application No. 61/831,059, filed on Jun. 4, 2013, in the United States Patent and Trademark Office, the disclosure of which is incorporated herein by reference.

BACKGROUND 1. Field

Example embodiments relate to a method, a computer-readable medium and an apparatus that may apply security labels to sensitive data based on authorization of a subject of record, organizational policies, and jurisdictional policies.

2. Description of the Related Art

Dissemination of sensitive data requires controlled, conditional access according to different levels or types of authorization. Examples of sensitive data include medical records, classified documents (e.g. DOD top secret), and the like. Access of such records may need to be limited according to both the sensitive nature of particular records as well as the purpose for requesting the records. For example, if a medical record contains data relating, e.g. HIV or psychiatric treatment, current Federal laws prohibit unrestricted distribution of such records, allowing access only in specific circumstances.

Enforcement of data handling requirements can become a problem upon records being transferred from an original custodian source. Once records are transferred, proper enforcement of data handling agreements or obligations may or may not occur. For example, medical records could be exchanged between service provider organizations. Once the records are transferred, it becomes difficult to police the handling of the data.

Solutions have been proposed based on maintaining separate databases for different versions of data, each with different levels of access privileges. One such example involves compiling the databases and subsequently providing access to the appropriate version of the data according to access rights. However, this method poses a new problem whenever access rights change. For example, if jurisdictional laws or regulations change to require different access rights to sensitive data, the entire database would need to be recompiled each time this occurs. This problem renders this particular method expensive, and potentially introduces down time when the databases are being recompiled.

Accordingly, there is a need for a solution that avoids maintaining separate databases and recompiling databases upon changes in access rights.

SUMMARY

Accordingly, one or more embodiments provide a method to tag at runtime an electronic record or an electronic data stream with a security label that enables automated compliance and enforcement with each of a subject of record authorization, an organizational policy, and a government regulation.

According to another aspect of an exemplary embodiment, the method may receive a retrieval request to retrieve an electronic record associated with a subject of record. The method may further determine a rule, by a computer, for tagging the electronic record based on a vocabulary dictionary, an authorization constraint, an organizational policy constraint, and a government rule constraint, where the authorization constraint is provided by the subject of record. The method may further retrieve the electronic record from a repository. The method may further decompose the electronic record into a decomposed data source. The method may further tag the electronic record at runtime with a security label according to the determined rule and the decomposed data source. The method may further transmit the tagged electronic record.

According to another aspect of an example embodiment, a Security Labeling Service (SLS) may be provided to tag the electronic record or electronic data stream. The SLS may comprise a rule generation service, an extraction engine, a rules engine, and a transformation engine. The rule generation service may generate rules using a vocabulary dictionary, decision considerations, and rule constraints. The extraction engine may decompose the electronic record or data stream into a decomposed data source. The rules engine may output a directive based on the rules from the rule generation service, the decomposed data from the extraction engine, and rule languages. The transformation engine may tag the electronic record or data stream using the directives from the rules engine.

Additional aspects, features, and/or advantages of exemplary embodiments will be set forth in part in the description which follows and, in part, will be apparent from the description, or may be learned by practice of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart illustrating tagging data with security labels according to an example embodiment.

FIG. 2 is a block diagram of a security labeling service for tagging data with security labels according to an example embodiment.

FIG. 3 illustrates the rule generation service portion of the security labeling service in greater detail according to an example embodiment.

FIGS. 4A and 4B are a sequence diagram illustrating order of operation of the security labeling service according to an example embodiment.

FIG. 5 is a flow chart illustrating a process for automatic compliance with security labels according to an example embodiment.

FIG. 6 is a block diagram of a system implementing the security labeling service according to an example embodiment.

DETAILED DESCRIPTION

The foregoing and/or other aspects are achieved by providing a Security Labeling Service (SLS) to tag, at runtime, an electronic record or an electronic data stream with a security label. The security label can be applied to any sensitive data which requires access restriction. The use of the security label can thereby ensure proper handling of sensitive data after the data leaves the custodian source.

FIG. 1 is a flow chart illustrating tagging of data. Sensitive data 101 and access rights 102 are input into the SLS 110. The sensitive data 101 may be in one or more formats expressed according to one or more languages or standards. For example, the sensitive data 101 may be expressed in binary format or some human readable format such as XML. Further, when expressed in, e.g., XML, the sensitive data 101 may be in a specific format requiring a standard use of specific XML tags. However, embodiments are not limited to any particular format.

The SLS 110 interprets the access rights 102 in light of the sensitive data 101 to determine whether any access restrictions apply. The access restrictions may include, for example, redaction, restriction or encryption requirements. However, the scope of access restrictions is not so limited by these examples. If access restrictions from the access rights are applicable to the sensitive data 101, the sensitive data 101 is tagged with security labels by the SLS 110 and output as tagged data 107. The tagged data is then used to ensure automated compliance with access rights 102 by enforcement 120.

FIG. 2 illustrates an example embodiment of the SLS. The SLS 110 may include a rule generation service 201, an extraction engine 202, a rules engine 203 and a transformation engine 204.

The rule generation service 201 may generate rules 215 based on the access rights 102. The rule generation service 201 outputs rules 215 to the rules engine 203. The rules 215 are a formatted set of access rights 102 which may be expressed in one or more formats that may be recognized by the rules engine 203.

The extraction engine 202 receives an original data source 250. The original data source corresponds to the sensitive data 101, but may be expressed as either an electronic record or an electronic data stream. The extraction engine 202 may have, for example, two basic functions. First, the extraction engine may indicate to the rule generation service what type of electronic records or data stream will be tagged with security labels. For instance, medical records may be stored as a patient's problem list from a HL7 CDA document. The second basic function of the extraction engine is to consume the original data source and decompose the original data source 250 into decomposed data 230 in a standard form which can be interpreted by the rules engine 203. The decomposed data 230 may occur in XML form, for example. However, the scope of the present invention is not limited to XML data. The decomposed data 230 may occur in any form which convenient for the specific implementation as is well known in the art.

The rules engine 203 may receive the decomposed data 230, rules 215, and rule languages 231. The rules 215 may occur in a variety of formats which can be interpreted according to the rule languages 231. The rules engine 203 generates an array or list of required labeling instructions according to the rules 215 which are interpreted according to the rule languages 231 and the decomposed data 230. For example, if only a subset of the rules 215 are applicable to the decomposed data 230, only a subset of the rules 215 are translated to the array or list of required labeling instructions. The array or list of required labeling instructions is then output as directives 233 to the transformation engine 204.

The transformation engine 204 uses the directives 233 output from the rules engine to apply the security label to the original data source 250. The transformation engine 204 then outputs the tagged data 107 as tagged electronic record or electronic data stream which enables automated compliance and enforcement of the constraints of the subject of record authorization, organizational policy, and government regulation.

FIG. 3 illustrates the rule generation service 201 in greater detail according to an example embodiment. The rule generation service 201 receives a vocabulary dictionary 310, decision considerations 311 and rule constraints 312. The rule constraints 312 represent the access rights 102 expressed in a format which can be interpreted by the rule generation service. The vocabulary dictionary may include vocabulary that can be used to interpret the rule constraints 312. The vocabulary dictionary 310 may include standards generally recognized by an industry. For example, as illustrated in FIG. 3 for the case of medical records, the vocabulary dictionary may include Snomed-CT, RxNorm, ICD, and HL7 terminology. However, this is merely an example, and the vocabulary dictionary may include other standards and languages without departing from the spirit of the present invention.

The rule constraints 312 are a set of access rights which are expressed in a format which can be recognized by the SLS 110. The rule constraints 312 may include, for example, authorization from a subject of record. For example, the authorization from a subject of record could be patient consent for release of medical records that would otherwise not be disclosed. The subject of record authorization may be conditional so that access is permitted only upon satisfying conditions specified by the subject of record.

The rule constraints 312 may further include organizational policy and a government regulation. The government regulation could be, for example, U.S. Privacy Law 42 CFR part 2 which governs medical record privacy. The organizational policy may be additional constraints by an organization which handles the sensitive data, for example, a health care service provider, medical record custodian, or other HIPAA covered entity or business associate. The additional constraints provided by the organizational policy may be, for example, whether to encrypt, mask, or redact records when the records are in transit or at rest.

The rules 215 may be expressed in one or more languages. Also, the rules represent all of the rule constraints 312 without regard to relevance of any sensitive data 101. Therefore, the rules 215 may or may not be applicable to the sensitive data 101 at this stage. Accordingly, as previously indicated, the rules engine 203 outputs a directive 233 which contains only relevant rules.

The decision considerations 311 are a set of conditions which can modify access rights 102 based on the output rules 215. The decision considerations 311 may include, for example, a purpose for request of the sensitive data and also workflow considerations. Taking medical records, again, as an example, the purpose for request may be for treatment, or more specifically, for emergency treatment. Emergency treatment, as opposed to routine treatment such as a physical examination, may allow access to records which would otherwise be redacted from the physician's access. As an alternative example, if the sensitive data 101 is classified information classified as DOD “secret”, then the purpose for request may be for designing electronic hardware to meet a specification regarding signal to noise ration of a radio frequency section. In this case, data access may be granted that would otherwise be redacted.

FIGS. 4A and 4B illustrate an example sequence of operations of the SLS 110 in accordance with an exemplary embodiment. The sequence starts at the top of FIG. 4A and ends at the bottom of FIG. 4B which is a continuation of FIG. 4A. The sequence diagram of FIGS. 4A and 4B illustrates the interaction between the SLS 110 components—rule generation service 201, extraction engine 202, rules engine 203, and transformation engine 204—which are depicted horizontally across the top of FIG. 4A. FIGS. 4A and 4B use medical records, again, only as a non-limiting example.

The sequence begins with operation 401 which is a valid request, external to the SLS, for medical records subject to access control. The next two operations involve the rule generation service 201. In operation 402, the SLS 110 retrieves the jurisdictional and policy rules from rules generation service 201. In operation 403, the rule generation service 201 responds to the request by retrieving the rule constraints 312 and generating the annotation rules as rules 215. Note the dotted line which illustrates when the annotation rules next used which is elaborated below.

The next two operations involve the extraction engine 202. In operation 404, the extraction engine 202 decomposes the original data source 250 which is returned in operation 405 as decomposed data 230 which, in the non-limiting example of FIGS. 4A and 4B, includes clinical facts, e.g. a diagnosis containing sensitive information requiring restricted access.

The next five operations involve the rules engine. In operation 406, the annotated rules (or rules 215) are input via the dotted line discussed above, and used to create, in operation 407, a knowledge session in the rules engine 203.

In operation 408, the clinical facts in the decomposed data 230 (from the second dotted line) are asserted in the rules engine 203, and in operation 409, the rules engine is executed to generate the directives 233. In operation 410, the directives are generated.

The next four operations involve the transformation engine. In operation 411, the transformation engine 204 applies the directives 233 to generate, in operation 412, the original data source tagged with security labels. In operation 413, any handling instructions are asserted. The transformation engine responds, in operation 414, by generating the packaged document for transmission.

In operation 420 of FIG. 4B, the tagged data is output from the SLS.

FIG. 5 illustrates automated compliance with the security labels after data is tagged by the SLS. Note that the illustrations of FIG. 5 do not involve the SLS 110, but rather occur outside the SLS. FIG. 5 represents details of the enforcement 120 of FIG. 1. The tagged data 107, after being tagged with security labels by the SLS 110 is able to ensure automated compliance and enforcement of handling according to the applied security labels when transmitted from a data custodian to any receiving system. Automated compliance may be cooperatively performed in part by the data custodian and in part by the receiving system after the data is tagged with security labels by the SLS 110.

In order for automated compliance to occur, either the data custodian or the receiving system must guarantee the automated compliance. Therefore, before the data is transmitted, the data custodian must determine in operation 501 whether the receiving system is configured to automatically comply with the security labels. At operation 502, a decision is made whether to proceed to operation 503a or 503b. If the receiving system is configured to automatically comply with the security labels, then the tagged data may be sent to the receiving system according to operation 503a. Otherwise, the data custodian must guarantee compliance instead according to operation 503b. For instance, if a record must be redacted, then the data custodian will redact the record according to the tagged security label of tagged data 107 before sending.

Depending on the rule constraints 312 and the transmission medium used to transmit the tagged data 107 from the data custodian to the receiving system, the data may need to be encrypted before and/or after transmission. At decision regarding encryption is performed in operation 504. If encryption is required, the tagged electronic data stream or records will be encrypted in operation 505 before transmission. Encryption may be required according to constraints 112 if transmission occurs, e.g. via the Internet. Encryption might not be required if transmission occurs, e.g. via a local area network (LAN). Encryption requirements will be indicated in the tagged security label.

After automated compliance with the security labels is guaranteed, the data may be transmitted in operation 506 from the data custodian to the receiving party.

FIG. 6 illustrates an exemplary system which incorporates the SLS 110. In this non-limiting example, the data custodian 601 is one health care provider, and the receiving party 602 is another health care provider. The receiving system is accessed by users 610 to request medical records from the data custodian 601. After authentication by the security authentication system 605, the users 610 may request records.

The data custodian accesses the healthcare classification system 604 which hosts the SLS 110. Note that the hosting of the SLS 110 by the healthcare classification system is only a non-limiting example shown for illustrative purposes. Also in this non-limiting example, the organizational policy is retrieved from a policy engine hosted on the security authentication system 605 for use in the SLS 110.

The data custodian 601 uses the SLS 110 to transform original source data 250 into tagged data 107. After ensuring automated compliance, for example, by the illustration of FIG. 5, the data custodian transmits the packaged data 603 to the receiving system for use by the users 610.

The following is an example of input and output data to the SLS 110 in XML format, particularly pertaining to medical records. This is an example of a base rule for a clinical fact pertaining to a medical record, specifically relating to HIV infection which must be restricted according to Federal privacy laws:

The following is another example of another rule, which happens to be expressed in RedHat Drools Rule language, relating to substance abuse:

rule “Clinical Rule Substance abuse (disorder) REDACT” dialect “mvel” when $xacml: XacmlResult(subjectPurposeOfUse==“TREAT”, eval( pdpObligations.contains( “urn:oasis:names:tc:xspa:2.0:recource:patient:redact:ETH”))) $cd : ClinicalFact(codeSystem == “2.16.840.1.113883.6.96”, code == “66214007”, c32SectionLoincCode == “11450-4”) then ruleExecutionContainer.addExecutionResponse(new RuleExecutionResponse (“ETH”, “REDACT”, (String)Confidentiality.R, “42CRFPart2”, “ENCRYPT”, “NORDSLCD”, $cd.c32SectionTitle, $cd.c32SectionLoincCode, $cd.observationId, $cd.code, $cd.displayName, “SNOMED CT”)) end

The SLS 110 is able to process either of the exemplary above rules because the rules engine 203 uses the rule languages 231 to decode rules 215 which may occur in a plurality of formats and languages.

This is an example of an original data source 250 occurring in XML format, particularly a diagnosis of Acute HIV infection:

<?xml version=“1.0” encoding=“UTF-8”?> <Problem xmlns=“http://hl17.org/fhir”> <text> <status value=“generated”/> <div xmlns=“http://www.w3.org/1999/xhtml”>Acute HIV (Date: 21-Nov 2012)</div> </text> <subject> <type value=“patient”/> <reference value=“patient/@example”/> </subject> <code> <text value=“Acute HIV”/> </code> <category> <coding> <system value=“http://snomed.infor”/> <code value=“111880001”/> <display value=“Diagnosis”/> </coding> </category> <status value=“confirmed”/> <onsetDate value=“2012-11-12”/> </Problem>

The SLS 110, according to the above example embodiments, determines that the first of the two above rules is relevant. Accordingly, the SLS 110 tags the above original data source 250 with security labels according to the relevant rule after the rules engine 203 transforms it into a directive 233. The transformation engine 204 outputs:

<?xml version=“1.0”encoding=“UTF-8”?> <Problem xmlns=“http://hl17.org/fhir”> <text> <status value=“generated”/> <div xmlns=“http://www.w3.org/1999/xhtml”>Acute HIV (Date: 21-Nov 2012)</div> </text> <subject> <type value=“patient”/> <reference value=“patient/@example”/> </subject> <code> <text value=“Acute HIV”/> </code> <category> <coding> <system value=“http://snomed.infor”/> <code value=“111880001”/> <display value=“Diagnosis”/> </coding> <securitylabel> <category> <term>http://hl7.org/security/ . . . /term/restricted</term> <label>RESTRICTED</label> <scheme>http://hl7.org/security/ . . . /confidentiality</scheme> </category> <category> <term>http://hl7.org/security/ . . . /term/NORDSLCD</term> <label>No Redisclosure with Consent</label> <scheme>http://hl7.org/security/ . . . /RefrainPolicy</scheme> </category> <category> <term> http://hl7.org/security/ . . . /term/ENCRYPT</term> <label>ENCRYPT</label> <scheme> http://hl7.org/security/ . . . /Obligations</scheme> </category> </securitylabel> </category> <status value=“confirmed”/> <onsetDate value=“2012-11-12”/> </Problem>

Although many of the foregoing examples specifically involve medical records, the scope of the invention is not limited to medical records. A person having ordinary skill in the art will appreciate that the SLS and other aspects of the present invention can be equally applied to many other forms of sensitive data which require controlled access. As previously indicated, another non-limiting example is the use of the SLS to control access to DOD records, e.g. secret or top secret records. For instance, access may be redacted for a user who has a sufficiently high clearance, but whose purpose for request does not require access to a specific record. Also access may be fully restricted to a user without sufficiently high clearance. Again, these are only non-limiting examples. Further, the present invention is not limited to any particular choice of computer language or format such as the non-limiting examples above which happen to be expressed in XML.

The SLS 110 and other aspects of the foregoing may be implemented in one or more processors or other hardware such as, but not limited to either a programmable gate array or an ASIC. The SLS processing method according to the above-described embodiments of the present invention may be further recorded in non-transitory computer readable media including instructions for controlling one or more processors or other hardware to implement the SLS processing method. The media may include, alone or in combination with the controlling instructions, data files data structures, etc. Non-limiting examples of the non-transitory computer readable media include magnetic media such as hard disks, floppy disks, magnetic tape, etc.; optical media such as CD ROM or DVD disks; magneto-optical media such as floptical disks; and hardware devices that are specifically configured to store and perform program instructions, including but not limited to read only memory (ROM), battery backed up random access memory (RAM), flash memory, etc. Examples of instructions for controlling one or more processors or other hardware include machine code such as produced by a compiler, code in a medium or high level language which may either be compiled (such as C or C++) or executed by a computer using an interpreter (such as JAVA). The various components of the SLS, such as the rule generation service 101, extraction engine 102, rules engine 103, and transformation engine 104 may each be separately implemented in dedicated hardware, or may be implemented together in a single hardware device. For example, the rule generation service 101, extraction engine 102, rules engine 103, and transformation engine 104 may be implemented in at least one computer, or, alternatively, may be implemented in at least one FPGA or ASIC.

Although a few embodiments of the Present Invention have been shown and described, it would be appreciated by those skilled in the art that changes may be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the claims and their respective equivalents.

Claims

1. A method comprising:

tagging at runtime, by a computer, an electronic record or an electronic data stream with a security label that enables automated compliance and enforcement with each of a subject of record authorization, an organizational policy, and a government regulation.