WO2009069043A2

WO2009069043A2 - Method of managing data in communication network comprising at least a first and a second node

Info

Publication number: WO2009069043A2
Application number: PCT/IB2008/054870
Authority: WO
Inventors: Julien Kunzi; Milan Petkovic; Robert P. Koster
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2007-11-26
Filing date: 2008-11-20
Publication date: 2009-06-04
Also published as: WO2009069043A3

Abstract

This invention relates to a method and a system for managing data in a communication network comprising at least a source node and a destination node acting independently of each other. At the source node side, directives are sent to the destination node, where the rules define directives for the data to be followed by the destination node. At the destination node side, a response is given to the received liability rules and therefore it is indicated whether or not the liability rules are to be followed by the destination node. In case the destination node agrees on the directives,actions are performed on the data and the received response is used as a confirmation that the destination node will follow the directives.

Description

METHOD OF MANAGING DATA IN COMMUNICATION NETWORK COMPRISING AT LEAST A FIRST AND A SECOND NODE

FIELD OF THE INVENTION

The present invention relates to a method and a system for managing data in a communication network comprising at least a first node and second node acting independently of each other.

BACKGROUND OF THE INVENTION

Computer systems, e.g. a network of hospital computer servers, communicating via a communication network are often referred to as nodes. A node that wants to perform an action is referred to as source node and other nodes are referred to as destination nodes .

In such node systems, the source node cannot control destination nodes since, although the nodes cooperate, they are still independent and self-governing. The source node however knows which nodes are destinations for one of its actions. As the source cannot control the destination, there is a problem of trust. Next, an example is given in which the nodes are hospitals and the system is a network of hospitals. A patient P is on holiday in Spain. He has an accident and must go to a local hospital HSpain, where an x-ray image of him is taken (E). HSpain shares the files it produces with other care providers, but does not allow usage for research purposes: this hospital sells high-quality de-identified medical data to commercial partners. Therefore, it does not want to disclose data to companies that haven't paid for them. Back in his home country, P visits his GP at hospital HHome. The GP wants to access E and copy it on a local repository for usage convenience (caching). HHome must then contact HSpain for downloading E. However, HSpain cannot be sure that HHome will respect their policies relating to document handling, e.g. that HHome agrees on the fact that E shall not be disclosed for research purposes.

In another example, the nodes are again hospitals and the system is a network of hospitals. A patient P usually goes to hospital Ha. However, the patient moves to another city and now visits hospital Hb. This latter hospital downloads the EHRs concerning P on a local repository. Ha, which may be considered as a source node, is aware of the fact that P definitely left the city and wants Hb, which may be considered to be a destination node, to take full responsibility of the transferred data, thus still enforcing policies (e.g. patient- defined ones). Such a policy may e.g. include retaining the EHRs for the 10 years set by the law on retention of medical information. This would allow Ha to delete the EHRs from its local database and hence save storage space. Again, here Ha does not have any guarantee that Hb, even though Hb is considered to be an honest node, follows the data retention policies. Accordingly, the source node (Ha) has no assurance that this is the case and should not delete its copy. Such systems consisting of nodes acting independently of each other may be considered as non-trusted systems because the source node can never rely on the destination node.

If all nodes receiving a directive are guaranteed to follow it, the conformance between destination and directive is guaranteed. When comparing fully trusted and non- trusted systems, one can notice that in a non-trusted system it is not appropriate to execute an action, e.g. sending an electronic file or deleting files, if the source node has no guarantee that the destination node will follow its directives and policies. Referring to the second example hereinabove, even if the destination is actually going to keep the data for at least the minimally required data retention period because it is a compliant and honest node, the source has no assurance that this is the case and should not delete its copy.

SUMMARY OF THE INVENTION

The object of the present invention is to overcome the above mentioned drawbacks by providing a method and a system for managing data in a network of nodes for providing the nodes with a sufficient level of trust such that certain actions may be performed on the data.

According to one aspect, the present invention relates to a method of managing data in a communication network comprising at least a source node and a destination node acting independently of each other, the method comprising: at the source node side, sending directives to the destination node, which directives are to be followed by the destination node, at the destination node side, responding to the received directives and thus indicating whether or not the directives are to be followed by the destination node, wherein, in case the destination node agrees to the directives, actions are performed on the data, the received response being used as a confirmation that the destination node will follow the directives.

Thus, proof of liability or a "legal document" is provided proving that a directive related to the data is understood and that it will be enforced by the destination node. Thus, a sufficient level of trust is provided in such a network of nodes, allowing either the source node or the destination node or both to perform certain actions on the data, without the risk that the directives for the data will not be followed. The term actions means any kind of data handling, such as sending data, copying data, deleting data, moving data, data editing and the like. Such a system of nodes is typically a system where it is difficult or impossible to have full trust, e.g. a system of multiple service providers, vendors, health care systems and the like.

In one embodiment, the data is health data and the at least source node and destination node are health care computer systems, the actions to be performed on the data including sending the health data from a first health care computer system possessing the health data to a second health care computer system.

In one embodiment, the health data is picture archiving and communication (PACS) images.

Since very strict documentation protocols must often be followed when handling health data such as PACS images, (e.g. very strict privacy and security policies defined by the patient or legislation such as HIPAA and European Directive 95/46, or that medical images must be kept for at least 10 years), the source node now has a guarantee that the destination node will follow these policies. In this particular case, the directives would typically define access control policies or the retention period of the data, e.g. the 10 years, which the destination node has agreed to.

In one embodiment, the actions to be performed on the health data further include deleting the health data after sending them to the second health care computer system.

Referring to the example above, since the source node now has a guarantee and legal proof that the destination node will follow the minimum retention period of the data, the source node can now delete the data from its storage space without the risk that e.g. an external node will accuse the source node of not following the minimum retention period policies. In one embodiment, the actions performed on the data include sending the data from the source node to the destination node, the method further comprising: prior to sending the data, or the directives, or both the data and the directives from the source node to the destination node, sending an initial directive to the destination node, requesting that the said directives of the data be followed by the destination node, wherein in case the destination node commits itself to the initial directive, said directive for the data is sent to the destination node, wherein the commitment to the initial directive is adapted to identify the destination node and is used as a confirmation that the destination node will follow the initial directive.

Accordingly, an "additional round" of the protocol is performed before the normal round, in which the source can require from the destination that the latter commits itself to the directives on the metadata, e.g. "it is not allowed to disclose the metadata to other parties". Metadata is defined below as certain fields comprised in a directive. The initial directive applies to the directive on the data. The directive on the data applies to the data. This commitment can e.g. be provided via a digital signature, using e.g. RSA, or an integrity code using e.g. HMAC. As an example, one could send the metadata to the destination node, after the destination node has committed itself to said initial directive, together with the directives. If the destination node commits itself to the directives, e.g. via a digital signature, the source node sends the actual data. However, if the metadata itself is sensitive, e.g. contains patient ID and a type of information that is sensitive, e.g. that the record is about venereal diseases, the source, after receiving the signed initial directive, will first require a guarantee that the metadata will be handled according to the directives and e.g. not be misused. After receiving the commitments from the destination node to the directives relating to the metadata from the destination node, the source can start said protocol or steps of sending the directives to the destination node, defining directives for the data to be followed by the destination node, after which the destination node sends a response. The initial directives can have the same structure as normal directives for data. Both would contain metadata, e.g. for directives for data: metadata.type-of-data = "venereal disease record" metadata.patientID = "12345" metadata.policyexpression = "only doctor X has access" and for initial directives: metadata.type-of-data = "metadata" metadata.policyexpression = "confidential" not present: metadata.patientID

In one embodiment, the directives for the data further include at least one of the following items: the source node, the destination node, a transaction code of the data, the size of the data, the format of the data, the type of data, and the source of the data. The term "right" may indicate what may be done with the data and the term "obligations" may indicate what must be done with the data.

In one embodiment, the response from the destination node further includes a request for adjustment of the directives, the source node further being adapted to adjust the directives in accordance with the received request from the destination node and subsequently send the adjusted directives to the destination node, the steps of requesting the adjustment and sending the adjusted directives being continued until the parties either agree or disagree on the directives. In one embodiment, the actions to be performed on the data include: deleting data on either the source node side, or the destination node side, or both, or sending data from the source node to the destination node, or vice versa.

In one embodiment, the actions are triggered after receiving confirmation indicating a credit transfer from the source node side or the destination node side.

In one embodiment, the directives comprise: liability rules, control policies, security policies, policies and obligations related to data management, or a combination thereof.

According to another aspect, the present invention relates to a computer program product for instructing a processing unit to execute the above mentioned method steps when the product is run on a computer.

According to still another aspect, the present invention relates to a system for managing data in a communication network comprising at least a source node and a destination node acting independently of each other, the first node being a source node and the second node being a destination node, the system comprising: a transceiver located on the source node side for sending directives to the destination node, which directives are to be followed by the destination node, a processor located on the destination node side for responding to the received directives, thus indicating whether or not the directives are to be followed by the destination node, the response subsequently being forwarded to the source node, a processor for performing actions on the data in case the destination node agrees to the directives, and at least a first memory for storing the received response. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will be described, by way of example only, with reference to the drawings, in which

Figure 1 shows a flowchart of a method according to the present invention of managing data in a communication network comprising at least a first node and a second node acting independently o f each other,

Figure 2 shows another embodiment of a flowchart of a method according to the present invention,

Figure 3 shows a system according to the present invention for managing data in a communication network comprising at least a first node and a second node acting independently of each other,

Figure 4 depicts an example of components of a protocol message, Figure 5 shows an example of executing the protocol, Figure 6 depicts graphically the liability proof protocol to establish an electronic contract, Figure 7 depicts graphically an exchange of directives between a source node

(Ha) and a destination node (Hb),

Figure 8 depicts graphically Liability Proof IOD, Figure 9 depicts graphically a protocol to run in DICOM, and Figure 10 depicts graphically an example of policies (digital liability rules) in a DICOM file.

DETAILED DESCRIPTION OF EMBODIMENTS

The main aim of the present invention is make it possible for a source of a transmission to trust the destination before performing an action. This trust is based on the commitment of the destination node to follow a set of policies related to the target data. These directives can contain information about data management (e.g. data retention period), confidentiality (e.g. access control rules) or other relevant conditions and obligations on the use of the data. Figure 1 shows a flowchart of a method according to the present invention of managing data in a communication network comprising at least a first node and a second node acting independently of each other so as to allow the source node to trust the destination node before performing an action, the first node being a source node and the second node being a destination node. The data used as an example is health data and the first and the second node are health care computer systems. The actions performed on the data may include sending the health data from a first health care computer system possessing the health data to a second health care computer system.

On the source node side, directives concerning the data that are to be followed by the destination node are sent (Sl) 101 to the destination node. The destination node then responds to the received directives (S2) 103 and thus indicates whether or not it follows the directives. In case the destination node agrees to the directives, actions are performed on the data (S3) 105. These actions may be deleting the data from a memory after sending the data from either the source node side to the destination side, or vice versa, all kinds of editing operations performed on the data, removing portions of data, storing the data for some specific time period, e.g. 10 years, sending data from either the source node to the destination node, or vice versa, or both, and any types of data handling. The received response is then used as a confirmation, e.g. as evidence in court, or to discourage misuse etc, that the destination node will follow the directives (S4) 107.

The term directives according to the present invention may comprise or be equivalent to: liability rules, or control policies, or security policies, or other policies and obligations related to data management, and a combination thereof. Thus, as an example, the expression liability rules may include a policy expression such as a retention period. The control policies may represent access control policies (e.g. who should be able to access this data etc.) or usage control policies (e.g. what may be done with the data, and how long somebody may use it, etc.). The policy may use a syntax from a policy expression language, e.g. XACML, ODRL, XRML, etc.

The directives may further include the following fields: transactionID: unique identifier for the actual request and response exchange; sourcelD: public key identifying the source. This field is certified by a Trusted Third Party (TTP); destinationID: equivalent to the previous field but for the destination side; policies: policies expressing the conditions and obligations that the destination has to respect and commit itself to regarding the considered data. The content of the policies can either be a detailed description of the directives to be implemented by the destination or a reference to such a description stored on a remote server. In both cases, because of the presence of the policies Integrity field, its validity can be verified. Moreover, this field must contain at least the following information: an identification interpreterID of the semantic that is used for describing the policies. This allows semantic interoperability and prevents semantic attacks; a specification of the data target dataID with, if necessary, a digital data signature for integrity purposes; metaData: piece of data containing general information such as the file type and size, study type, hash of data, etc. for helping the destination to make a decision on the compliance with policies. If the concerned data have not yet been sent to the destination, this field should contain enough information to infer a decision (e.g. file size if purpose is data storage). If the data is already stored by the destination, then this field should make it possible to uniquely identify the data (e.g. hash of the file); policieslntegrity: signing of the policies (integrity check); metaDatalntegrity: signing of the metaData (integrity check); cooperationRequest: signing of the previous fields (the cooperation description) by the source of the transmission. Note that for cases where a signature provides integrity protection also equivalent mechanisms can be used such as integrity codes using HMAC algorithms.

In one embodiment, the response from the destination node further includes a request for adjustment of the directives (S5) 109. Accordingly, a negotiation process is initiated between the destination node and the source node. Based on the request for adjustment, the source node may adjust the directives in accordance with the received request from the destination node (S6) 111 and subsequently send the adjusted directives to the destination node (S 7) 113. Steps (S5)-(S7) are then repeated until the parties either agree or disagree on the directives. The source node may of course just a well, in step (S6) 111, not agree to the adjustments suggested by the destination node, and thus the whole process may be aborted.

In one embodiment, the data is health data such as picture archiving and communication (PACS) images and the at least first and the second node are health care computer systems. The actions performed on the data include sending the health data from a first health care computer system possessing the health data to a second health care computer system.

In one embodiment, directives further include metadata uniquely identifying at least one of the following: the source node, the destination node, a transaction code of the data, the size of the data, the format of the data, the content of the data, the type of data, the source of the data, the retention period of the data.

Figure 2 shows another embodiment of a flowchart of a method according to the present invention, including initial steps, prior to performing steps (S1)-(S7) in Fig. 1, which initial steps are executed in case the directives further contain metadata which may be at least partly sensitive and e.g. contain patient ID and specify the type of information e.g. that the record is about venereal diseases.

In this flowchart, the first step (Sl) 201 consists in sending an initial directive (e.g. metadata ID532 is confidential; access control policy: only security officer can access it) to the destination node, where the initial directive is more or less a directive relating to the metadata. The destination may then accept and sign the initial directive and send it back to the source node (S2) 203. As a response to this, the source node sends the metadata (e.g. health record; category: venereal disease; patient ID, 125Kb) to the destination node together with subsequent directives (S3) 205, which could e.g. state: keep the data for 10 years; access control policy: only a specialist in venereal diseases can access this record, etc. By the term subsequent directives is meant the directives discussed previously with respect to Fig. 1. The destination node confirms having received the metadata (S4) 207 and the source node stores the signed initial directive and the confirmation (S5) 209. The destination node decides to accept the subsequent directives, signs the directives and sends them back (S6) 211. The source node then sends the data to the destination node (S7) 213, the destination confirms having received the data (conf 2) (S 8) 215. The source node stores the signed subsequent directives and the confirmation (conf2) (S9) 217.

In one embodiment, the metadata uniquely identify at least one of the following: the source node, the destination node, a transaction code of the data, the size of the data, the format of the data, the type of data, the source of the data, the retention period of the data.

Figure 3 shows a system 300 according to the present invention for managing data in a communication network comprising at least a first node 310 and a second node 301- 304 acting independently of each other, the first node being a source node and the second node being a destination node. The source node comprises a transceiver (T) 312 for sending directives 307 to the destination node 303, defining directives concerning the data, which directives are to be followed by the destination node. The destination node comprises a transceiver (T) 313 for receiving the directives from the source node 310 and a processor (P) 305 for responding to the received directives 307, thus indicating whether or not the directives are to be followed by the destination node. Said processor (P) 305 or a further processor (P) 306 located at the source node 310 is provided for performing actions on the data in case the destination node agrees to the directives. A memory 309, which may be an external memory or a memory on the source node side 110, then stores the received response 311 from the destination node 303. In one embodiment, the response 308 further includes a request 308 for adjustment of the directives, so that the directives sent back to the source node 110 contain a request for adjustments in the directives and thus in the directives for the data, e.g. "we can preserve the data for 10 years, but not for 20 years". The source node 110 is then further adapted to adjust the directives in accordance with the received request from the destination node and subsequently sends the adjusted directives to the destination node 303. This may be repeated several times until the destination node 303 agrees to the directives and the directives for the data.

In a first example, the solution presented will be based on the assumption that the source has no influence on the destination. Hence, the source will discourage the destination from violating policies concerning the data by requiring a proof of compliance from the destination that will be disclosed to a legal entity in case of data misuse. The source thus protects itself from being responsible for inappropriate data handling before performing an action (e.g. sending or deleting the data).

Intuitively, if the source wants to obtain proof of compliance with POLICIES (e.g. access control rules) from the destination before performing an ACTION (e.g. data transfer), it will have to execute the protocol shown below.

send POLICIES to destination; // = LIAB REQUEST wait for a response (APPROVAL or DENIAL); // = LIAB RESPONSE if response is APPROVAL { save APPROVAL; // legal proof perform ACTION; } else { // DENIAL cancel; // roll back to initial state

}

Obtaining the previously discussed legal proof is basically a simple task: the source discloses to the destination the policies that apply to the considered data. The latter then signs and returns them. The source hence has the assurance that the destination understands and agrees to the policies. Therefore, the protocol will only need two messages: a request and a matching response. The liability proof request will consist of the following fields: transactionID: unique identifier for the actual request and response exchange; sourcelD: public key identifying the source. This field is certified by a Trusted Third Party (TTP); destinationID: equivalent to the previous field except for the destination; - policies: policies describing the conditions and obligations that the destination has to respect and commit itself to regarding the considered data. The content of the policies can either be a detailed description of the directives to be implemented by the destination or a reference to such a description stored on a remote server. In both cases, because of the presence of the policieslntegrity field, its validity can be verified. Moreover, this field must contain at least the following information: an identification interpreterID of the semantic that is used for describing the policies. This allows semantic interoperability and prevents semantic attacks; a specification of the data target dataID with, if necessary, a digital data signature for integrity purpose. - metaData: pieces of data containing general information such as the file type and size, study type, hash of data, etc. for helping the destination to make a decision on the compliance with policies. If the concerned data have not yet been sent to the destination, this field should contain enough information to infer a decision (e.g. file size if purpose is data storage). If the data is already stored by the destination, then this field should make it possible to uniquely identify the data (e.g. hash of the file); policieslntegrity: signing of the policies (integrity check); metaDatalntegrity: signing of the metaData (integrity check); cooperationRequest: signing of the previous fields (the cooperation description) by the source of the transmission, proving that the contract is being established by itself.

The liability proof response will contain the same fields and a cooperationResponse which will contain either a DENIAL flag if the destination does not accept the terms presented in the request or a confirmation of approval, i.e. an APPROVAL flag and signature of the cooperationRequest field by the destination. Figure 4 depicts the main components of a message and shows their relationships for this particular example, and figure 5 shows the execution of the protocol. When sending the request, the source saves it along with the action to be performed on reception of the corresponding response. Upon reception of this response, the source also saves it, as the response is the desired legal proof. With this basic protocol, it is strictly speaking not necessary for the destination to save anything on permanent storage. However, it might find it useful for the following reasons: - legal protection against semantic attacks by the source (proof of ambiguous request provided to an authority); back-up of policies for later crash recovery; business value (for demonstrating to its customers that it actually enforces access control rules); - protection against replay attacks.

If the source has to send the data to the destination after having obtained the proof of liability (e.g. the policies concerned some access control rules), the complete response of the liability proof protocol (cooperation description, cooperationRequest and cooperationResponse fields) is preferably transmitted within the message. In this way, the destination will be able to verify that it indeed accepted to respect the specified policies by checking its own digital signature. This behavior is not mandatory but the added value is important: the transmission of the message and enforcement of policies upon reception would consequently be easier.

The liability proof protocol is used for making sure that a destination will enforce policies defined by a source. However, it may also be necessary to protect the policies or data that help the destination to make a decision against inappropriate disclosure. These two types of information are here called meta-data. For example, a patient may not want to allow anyone to guess that he has psychological problems because of unprotected disclosure of policies and meta-data about his files. This distinction between the former and this new level of protection can be expressed in the protocol by introducing an additional field in the cooperation description: the cooperationCommand. It can take two values:

ENFORCE POLICIES: the source requests the destination to enforce the included policies; - PROTECT MET AD ATA: the source asks the destination not to disclose the policies and metaData.

The principle, as explained, remains the same: the cooperationRequest is nothing but a request by the source to sign the cooperation description. It is then signed and returned by the destination, thus constituting the expected legal proof. However, depending on the value of the cooperationCommand, the content of the cooperation description will change. If it is equal to ENFORCE POLICIES, it is sufficient to add the cooperationCommand to the existing protocol messages. If it is equal to PROTECT METADATA, the cooperation description will contain the transactionID, the destinationID, the cooperationCommand, the policieslntegrity and the metaDatalntegrity (integrity check and identification purpose).

It may be necessary for the destination to specify an error message in its responses. For example, considering the scenario where a patient P usually goes to hospital Ha, but after moving to another city now visitshospital Hb. This latter hospital downloads the EHRs concerning P on a local repository. Hb may not want to permanently store Ha's EHR extracts, either because there is a technical issue (not enough free storage space) or because it wants to be paid for this service. Hence, for expressing the reason of denial, a new field in the protocol response is needed: the commentResponse. The cooperationResponse will then be the signing of the cooperation-Request and of the commentResponse. The commentResponse can for example be used upon approval of a request for specifying the location of the archived data (informational field). This is an extension of the previously presented solution that could be added to its content depending on the requirements of the deployment environment. Upon reception of a negative response along with a commentResponse, Ha can analyse this message and chose whether or not it is going to reformulate its request such that it will be accepted by Hb. For example, it can state that it is going to pay the requested price. In this case, the destination is likely to want to save a copy of the request, so that it can sue the source in case it refuses to pay. The liability proof protocol can hence become a way to establish an electronic contract. This is depicted graphically in Figure 6.

The destination must save the liability proof protocol request on permanent storage if it is such an electronic contract. It could then for example sue the source if the source eventually did not pay the amount advertised in the transmitted request. That is, it can also serve as legal proof.

The liability proof protocol is generic. Using this handshake, one can implement an arbitrarily complex workflow between two peers. Referring to the scenario where patient P usually goes to hospital Ha, but after moving to another city now visits hospital Hb, the purpose is to transfer an EHR extract DP from hospital Ha to hospital Hb, which will eventually be responsible for the management of this piece of data, hence allowing Ha to delete DP from its local database. Additionally, Hb will not disclose the policies and meta-data concerning the access control rules on DP. The sequence of messages exchanges can be found in Figure 7 and is represented using a higher level of abstraction than that presented in the formal description of the protocol (Figure 5).

The protocol consists of 4 parts. Part 3 (transfer of data) is handled by the underlying transmission standard and is completely independent of the liability proof protocol. Each message can be conveyed independently and on different transmission channels (USB key transfer, TCP/IP, serial line, etc.). For each part involving the liability proof protocol (3 runs: parts 1, 2, and 4), the obtained proofs have to be saved in a secure environment by the source and the decision process on the destination depends on the context: for example, the destination would not accept to take the responsibility of the data management (part 4) if the transmission of the data (part 3) had failed. Likewise, the source may not trust the destination enough for taking responsibility of the file (part 4) if it first did not agree to comply with access control rules policies (part 2).

Based on the above EHRcom, see [Health informatics - Electronic health record communication - Part 1: Reference model. CEN prEN 13606-1:2006 (E);Health informatics - Electronic health record communication - Part 2: Archetypes. CEN prEN 13606-2:2005: (E);Health informatics - Electronic health record communication - Part 3: Reference archetypes and term lists. CEN prEN 13606-3:2006 (E);Health informatics - Electronic health record communication - Part 4: Security requirements and distribution rules. CEN prEN 13606-4:2005 (E);New work item proposal for reinstalling prEN 13606-5 rev Health informatics - Electronic health record communication - Part 5: Exchange models, October 2006. CEN prEN 13606-5 rev], full integration is possible.

The basic requirements are derived from EHRcom which defines a structure for the EHR to be transmitted, see in [Health informatics - Electronic health record communication - Part 1: Reference model. CEN prEN 13606-1:2006 (E)]. Components of this data scheme can refer to policies that have to be enforced [Health informatics - Electronic health record communication - Part 4: Security requirements and distribution rules. CEN prEN 13606-4:2005 (E), section 6.4], hence allowing fine grained protection. The policies are then stored in a dedicated "Access Policies" FOLDER, see [Health informatics - Electronic health record communication - Part 4: Security requirements and distribution rules. CEN prEN 13606-4:2005 (E), Annex A]. Moreover, EHRcom messages are represented in XML. Therefore, XML Signatures [The Internet Society and W3C XML- Signature Syntax and Processing, 2002. \ can be used to ensure the integrity of the different components of the messages.

Part 5 of the EHRcom standard defines the exchange model. It will be rewritten once the 4 first parts have been finalized and no definite information is available until that time. Although it is very likely that this exchange model will support a simple request/response mechanism, see [New work item proposal for reinstalling prEN 13606-5 rev Health informatics - Electronic health record communication - Part 5: Exchange models, October 2006. CEN prEN 13606-5 rev], which is the only feature required for the liability proof protocol to work in this particular example. However, even if this is not available, the standard already states that the implementer is allowed to use other means such as separate communication channels for enforcing legal and users' preferences. The standard also highlights the fact that different peers may have to implement or use different security features. This implicitly implies that the standard will support optional behavior of additional security measures.

The transmission policies are saved in COMPOSITIONS stored in a special FOLDER: the "Access Policies" one. Any instruction can be put in there: for example, the policy could contain the "delete (action) if and only if the file (target) is older than the specified data retention period (condition)" directive. The standard defines little for the content of policies to allow implementers to specify arbitrarily complex rules, which may come with time, see [Health informatics - Electronic health record communication - Part 4: Security requirements and distribution rules. CEN prEN 13606-4:2005 (E), section 6.4.1] . It just defines where this information has to be saved, see [Health informatics - Electronic health record communication - Part 4: Security requirements and distribution rules. CEN prEN 13606-4:2005 (E), Appendix A]. Other message fields can be saved in the payload by creating a new tree branch.

In the next example, an efficient approach to integration of the provided solution is described in detail. It is strongly inspired by the DICOM Storage Commitment Supplement, see [National Electrical Manufacturers Association (NEMA). Digital Imaging and Communications in Medicine (DICOM), Supplement 8: Storage Commitment, 1995]. The technical requirements for this feature and for the liability proof protocol are very similar and both integrations are therefore similar. This solution can be implemented as a vendor- specific feature or proposed as part of the DICOM standard, as it has been designed to be fully compliant with the existing specification.

A new Information Object Definition (IOD) must be created. Hereafter, it will be called the Liability Proof IOD. It consists of the mandatory SOP Common Module, see [National Electrical Manufacturers Association (NEMA). Digital Imaging and Communications in Medicine (DICOM), Part 3: Information Object Definitions, 2007, Appendix C.12.1 ], and of the module built with the fields of the liability proof messages represented as DICOM attributes. The Liability Proof IOD is depicted in Figure 8. The Liability Proof IOD is a normalized IOD as a proof represents a single entity in the DICOM model of the real-world, see [National Electrical Manufacturers Association (NEMA). Digital Imaging and Communications in Medicine (DICOM), Part 4: Service Class Specifications, 2007, section 6.1.2]. Every instance of such an object must be assigned a unique identifier (UID) that will be stored as the content of the transactionID field. The metadata field can be out of the Liability Proof IOD (e.g. another Information Entity of the considered DICOM instance). The digital signatures (policieslntegrity, metaDatalntegrity, datalntegrity, cooperationRequest and cooperationResponse) are performed using the Digital Signature Profile of DICOM.

A new Service-Object Pair (SOP) class must be created. It will be called the Liability Proof Service Class and is a normalized SOP class as it applies to a normalized IOD (the Liability Proof IOD). It will be assigned a unique identifier (SOP Class UID) and its commands will be described below. In the case of association negotiation, if one of the peers does not support the Liability Proof Service Class, the protocol will not be run. Hence, the solution is optional, as expected. The liability proof protocol requires the distribution of the roles of the source and the destination. The source, as the initiator of the protocol, will be the Service Class User (SCU, i.e. the client), whereas the destination will be the Service Class Provider (SCP, i.e. the server). The message exchanges of the service defined within the scope of the Liability Proof Service Class consists of two DICOM commands:

Request: when a source wants to obtain a liability proof, it must send an N- ACTION command to the intended destination. The data-set transmitted along with the command is the Liability Proof IOD, excluding the commentResponse and cooperationResponse attributes. Response: the destination then replies with an N-E VENT-REPORT command along with a data-set consisting of the complete Liability Proof IOD.

This approach is depicted in Figure 9. One could have chosen to include the response within the acknowledgement of the request receipt, but this would have made it impossible to send the response on a different association: the approval of the policies may take some time and the connection between the two peers would consequently be closed in the meantime.

Every time a communication (i.e. association) is established between two peers, an association negotiation procedure must be run. The liability proof protocol must therefore be optimized such that a denial of policy does not require a new run. For that matter, two enhancements are proposed:

Multiple requests in a single message. The source can send multiple requests in a single DICOM message. The destination would then have to analyze each of them and sign the appropriate ones. This enhancement is secure as the implemented policies are eventually signed by both the source and the destination.

Choice of policies and expressive response. If the expressive response feature presented is in use, sources can allow a choice out of multiple policies by the destination. For example, if the policies state that the data consumer must either conform to access control rules (highest priority) or inform an authority of data usage, the destination will be able to express which policy it accepted in the commentResponse field without requiring the source to send a new request if it cannot handle the advertised access control rules. This enhancement does not require multiple requests to be transferred in a single DICOM message: it is sufficient to express the different acceptable policies in the policies field. Again, the policies are signed by both the source and the destination and the protocol is therefore secure.

As an example, a patient P is on holiday in Spain. He has an accident and must go to a local hospital HSpain, where an x-ray image of him is taken (E). HSpain shares the files it produces with other care providers, but does not allow usage for research purposes. This hospital sells high-quality de-identified medical data to commercial partners. Therefore, it does not want to disclose data to companies that haven't paid for them. Back in his home P visits his GP at hospital HHome. HHome wants to access a data but HSpain has to make sure that HHome will enforce its policies. Therefore, it initiates the liability proof protocol as follows. First, the source HSpain and the destination HHome perform the association negotiation. As they both support the Liability Proof Service Class that was just described, they will be able to run the liability proof protocol. Second, the request of the liability proof protocol is sent by HSpain in an N-ACTION command to HHome. It contains the policies expressing the fact that the considered DICOM instance should not be distributed for research purposes. Third, HHome checks if the included policies are acceptable. If this is the case, a digital signature of the cooperationRequest and commentResponse attributes is saved as the cooperationResponse attribute into the Liability Proof IOD. The response (a N- EVENT-REPORT command) is transmitted, including the complete Liability Proof IOD. Last, HSpain verifies if the response contains a valid signature (= acceptance) by HHome. If this is the case, it sends the complete DICOM instance (including the Liability Proof IOD and the data) using usual DICOM transmission methods and saves the Liability Proof IOD on permanent storage: this is the legal proof of approval of the access control rules by HHome.

For archiving policies with the concerned DICOM file, one must add the Liability Proof IOD to the original DICOM instance. This is depicted in Figure 10. By saving the complete IOD in this way and not just the policies, the node holding the archive can see if it signed and therefore understood and approved the policies. This capability is important from management and policies enforcement points of view.

The liability proof protocol increases the level of trust between the different nodes of the medical network by discouraging misuse of EHR extracts. The source, before performing an action (e.g. transmission of data), gets a commitment to related policies (e.g. access control rules) from the destination. This proof can then be transmitted to a legal authority in case of litigation, such that the source can prove that the liability has been transferred to the destination and that it is therefore not responsible for harm induced by the bad behavior of the latter. This approach has many advantages: besides the protocol itself, very few data have to be stored on permanent storage. On the source side, actions and proofs have to be saved. On the destination side, no storage is strictly required, but a mechanism to memorize past transactionIDs is recommended to avoid replay attacks, and it is also advised to store policies for data as long as one has the data, and rights or obligations from the policy still hold on the data; a consequence of the previous point is that the integration in existing communication standards is generally easy. The integration feasibility in the DICOM standard is described, still providing the liability proof protocol as an optional service; as opposed to existing notary services, no Trusted Third Party (TTP) is required for saving proofs. Indeed, they are stored at the source as the purpose of the liability proof protocol is in fact its own legal protection. The source gains no advantage by deleting them: proofs represent an implementation of its policies by the destination and not by the source itself. It therefore runs no risk of being sued because of their content; there is no assumption regarding the compliance of the infrastructure where the solution is deployed (as opposed to DRM-based solutions): the only prior requirement for the protocol to be run properly is the availability of a valid key pair on every participating node (if semantics issues are excluded); the solution has a broad scope of application and can be extended with two useful and easy to integrate features (protection of meta-data and use of expressive responses). Certain specific details of the disclosed embodiment are set forth for purposes of explanation rather than limitation, so as to provide a clear and thorough understanding of the present invention. However, it should be understood by those skilled in this art, that the present invention might be practiced in other embodiments that do not conform exactly to the details set forth herein, without departing significantly from the spirit and scope of this disclosure. Further, in this context, and for the purposes of brevity and clarity, detailed descriptions of well-known apparatuses, circuits and methodologies have been omitted so as to avoid unnecessary detail and possible confusion.

Reference signs are included in the claims, however the inclusion of the reference signs is only for clarity reasons and should not be construed as limiting the scope of the claims.

Claims

CLAIMS:

1. A method of managing data in a communication network comprising at least a source node and a destination node acting independently of each other, the method comprising: at the source node side, sending directives to the destination node, which directives are to be followed by the destination node (101),- at the destination node side, responding to the received directives and thus indicating whether or not the directives are to be followed by the destination node (103), wherein, in case the destination node agrees to the directives' actions performed on the data (105), the received response is used as a confirmation that the destination node will follow the directives (107).

2. A method according to claim 1, wherein the data is health data and the at least source node and destination node are health care computer systems, the actions performed on the data including sending the health data from a first health care computer system possessing the health data to a second health care computer system.

3. A method according to claim 2, wherein the health data are picture archiving and communication (PACS) images.

4. A method according to claim 2, wherein the actions to be performed on the health data further include deleting the health data after sending them to the second health care computer system.

5. A method according to claim 1, wherein the actions performed on the data include sending the data from the source node to the destination node, the method further comprising: prior to sending the data or the directives, or both, from the source node to the destination node, sending an initial directive (201) to the destination node, requesting that the said directives of the data be followed by the destination node, wherein, in case the destination node commits itself to the initial directive (203), said directive for the data is sent to the destination node (205), wherein the commitment to the initial directive is adapted to identify the destination node and is used as a confirmation that the destination node will follow the initial directive.

6. A method according to claim 1 or 5, wherein the directives for the data further include at least one of the following items: the source node, the destination node, a transaction code of the data, the size of the data, the format of the data, the type of data, and the source of the data.

7. A method according to claim 1, wherein the response from the destination node further includes a request for adjustment of the directives (109), the source node further being adapted to adjust the directives in accordance with the received request from the destination node (111) and subsequently send the adjusted directives to the destination node (113), the steps of requesting the adjustment and sending the adjusted directives being continued until the parties either agree or disagree on the directives.

8. A method according to claim 1, wherein the actions performed on the data include: deleting data on either the source node side, or the destination node side, or both, or sending data from the source node to the destination node, or the destination node side, or both.

9. A method according to claim 8, wherein the actions are triggered after receiving confirmation indicating a credit transfer from the source node side or the destination node side.

10. A method according to claim 1, 5 or 6, wherein the directives comprise: liability rules, control policies, security policies, policies and obligations related to data management, or a combination thereof.

11. A computer program product for instructing a processing unit to execute the method step of claim 1 when the product is run on a computer.

12. A system (300) for managing data in a communication network comprising at least a source node (310) and a destination node (301-304) acting independently of each other, the system comprising: a transceiver (3112) located at the source node (310) side for sending directives (307) to the destination node, which directives are to be followed by the destination node, a processor (305) located at the destination node side (303) for responding to the received directives and thus indicating whether or not the directives are to be followed by the destination node, the response subsequently being forwarded to the source node, a processor (305, 306) for performing actions on the data in case the destination node agrees to the directives, and at least a first memory (309) for storing the received response.