clair054

There is a need where an individual or team needs to record chronological facts privately, and in the future make these facts public in a way that the public can prove the integrity and chronology.  Where the chronological facts need to be known to within some timeframe, typically within a day. Where the sequence of the facts needs to be provable. Where a missing recorded facts can be detected. Where an inserted fact can be detected. Where all facts can be verified as being whole and unchanged from the date recorded. Where all facts are attributable to an individual or team of authors. Description These proofs are used to resolve disputes and prevention of fraud. Areas like in intellectual property management, clinical research, or other places where knowing who and when in a retrospective way is important. Aka: Lab Notebook , Lab Journal, Lab Book, Patent Notebook. Here is an image from the Laboratory Notebook of Alexander Grahame Bell, 1876., Historically, tamper-evident notebook...

This article covers the constraints often placed on an approved use of healthcare data. These are the conditions, restrictions, obligations, or handling caveats. When a Patient allows use of their data, there is almost always restrictions. Some restrictions are supported in access control rules. That which I have already covered in  Vectors through Consent to Control Big-Data Feeding frenzy . I am not going to re-describe "Vectors". The Vectors are used in rules to determine if an access is allowed or denied. Some of those Vectors are similar to constraints, such as the discussion about "Treatment", "Payment", or "Operations. That I covered in  Consent Basis in Controlling Big-Data Feeding frenzy . An important message from that specific example is "Purpose Of Use". This is both a "Vector", and a "Constraint". That is a rule can be based upon a user requesting, where the request indicates that the user is asserting that t...

In the last article I wrote about all the Vectors through the healthcare data access control space that are commonly needed by Patient Privacy Consent Authorizations. In this article I will describe the residual policy rules and Obligations. When a Patient says YES to authorize access to their data, they are saying it within some context. This authorization comes with metaphoric strings. Overall Policy context A Consent Policy is a multi-layered thing. Let me illuminate this by looking at a simple and most common Privacy Consent in healthcare is: The Patient says YES to authorize use of their data for Treatment, Payment, and normal hospital Operations. One might think that this is a very simple Consent. Simply "YES". Others might notice that there are some restrictions to "Treatment/Payment/Operations". Both are very important attributes of the consent, and would be seen clearly in the consent.  The Consent that would be on file will likely just say these simple tru...

This is part of a series of articles on the various  Privacy Consent  mechanisms that are being developed in  HL7, IHE, and HEART . This article will detail the various vectors that Patients desire to control. This discussion will not be on any of the specific solutions, but rather the overall requirement. For some background, please see my prior article  Controlling Big-Data feeding frenzy with Privacy Consent Authorization First step is to recognize that  Privacy Consent  must enable the Patient to define Rules and Obligations. This is abstractly represented by their Policy -- My Policy -- which follows their Data. Thus when someone or something tries to access the their Data; there is an authorization (AuthZ) check done. This authorization check assures that the Patient would be happy allowing their data to be used in the way that the someone or something is going to use their data. I am speaking abstractly, so no specific authentication, context, method...