Privacy is not dead, but does need reinforcement

The sky is falling... is the general feeling in the Privacy community.. Businesses are out to take your Privacy from you... There is no privacy left.... Give up...

I am a Privacy advocate. I sometimes give myself the title "CyberPrivacy" specifically because I do focus on  Electronic Information Privacy and not physical privacy. I am very angry at the Privacy failures.  I just have a more pragmatic perspective. A perspective from experience. A perspective that is grounded in both 

• Occam's razor - The most simple solution is the best.
• Hanlon's Razor - Never attribute to malice that which is adequately explained by stupidity.

Privacy is not on the top 5 things to do, and therefore not done... 

Anyone who has ever worked on some kind of an application, will recognize that all the outstanding things to work on (the backlog) get prioritized. The priority is very simply based on how important that outstanding issue is to the overall functionality. Most weighted in priority are those things that are differentiators from your competitor, those things that the most people are asking for.  Of the resulting prioritized list, the team will be focused on the top 5, sometimes just the top one... 

This is especially true in "Agile", where there is a unrelenting focus on "Minimally Viable Product", and "Continuous Deployment". Agile is very quick to get features into the customer hands, but really slow at getting the foundational capabilities into the product. Things like Performance, Modularity, Robustness, Security, and Privacy... 

Privacy-By-Design still takes effort

Privacy-By-Design is a fantastic approach. I have promoted it in many ways. Privacy-By-Design is a process that one would use when designing a system so that one includes privacy into the design. When done this way, the overall energy it to implement is minimized. When done this way, the overall design has a 'privacy' feature. But it does require that someone decide to use Privacy-By-Design, which does require that someone decide Privacy is worth acting upon. 

Although Privacy is a great feature, it is a dangerous feature

Another reason Privacy doesn't get into the top 5 priorities is because it is a double edged sward. That is to say that it might be a fantastic feature, but if anything goes wrong it becomes your most damaging failure.

If you market your product/service/software as "Privacy Protecting", then you better do a perfect job. Given that Privacy has some Principles that are very deterministic. Some Principles are a bit harder, like Consent and Transparency. However there are some Privacy Principles that are risk based; De-Identification, and Security. That is to say that there is always some risk that private data will escape containment. You design to keep it as well contained as possible, but accidents happen. Most accidents happen because of human error, but not exclusively.

Facebook as exemplar

The Facebook case around Cambridge Analytica is a good exemplar... Facebook ignored privacy for a long time, never a business priority. Things are changing in the market where privacy might be able to break into top 5 priorities. But I'm not sure. The threat of penalty upon privacy failure is far harder to justify as a priority, over a positive money flow caused by some business action. Even when both are equal dollars. Business leadership is mildly smart, but investors are dumb and focus only on actual dollars. So potential loss due to unlikely privacy issue simply doesn't factor into the picture.

Many people expected this of Facebook, and are less outraged. I have always figured everything I have given Facebook is public. So to me, this incident was not shocking. Made me angry, yes.

Apple is not without scars

Apple, who everyone likes to think is a perfect company, is not without privacy scars. Easiest case for me to point at is their failure around their De-Identification mechanism "Differential Privacy", fails. A fantastic capability, and I think well done. But as I stated above, some of these things fall into a 'risk' classification where all one can do is lower the risk as much as possible.

Conclusion

Business is not fundamentally the issue. Businesses are not out to hurt you. Businesses are being pushed to deliver products faster, focus on flashy features. The reason, Consumers demand it and will leave your product for a more flashy product. Stupid society plus capitalism are the problem. 

 In the EU the population seems to be smarter about this. GDPR might save us all. 

I continue to fight. I continue to develop standards. I continue to blog. I continue to be selective about what I do as a consumer. I educate everyone I can. I don't worry about those that don't want to be educated. Privacy is not dead, but it does need reinforcement.

Blockchain as a platform for Supply Chain

I went to a Supply Chain Management on Blockchain panel event at Marquette University last night. The recording of the session is available. It was on the topic of using Blockchain to manage provenance of supplies throughout the Supply Chain. This was on the general topic of supply chain, not specific to healthcare, or the most specific example of drug components in healthcare. However the general concept of supply chain use of blockchain is directly transferable into drug supply. I might argue that drug supply chain likely has more opportunity to take advantage of blockchain, and more money available to fund that kind of research leading to an implementation.

Blockchain, keeps fidgeters occupied, not bothering others

The talk was mostly about the general concept, general need, and generally how blockchain would help. Nothing shocking, but it is useful to hear it from people who have done it. The panelists were Dr Mark Cotteleer from Deloitte, Chris Kirchner of Slync, and Paul Biwer from Biwer & Associates. The guest speakers were from organizations involved in actual use (pilot) in the Food supply-chain, and in package shipping.

The first caution was that the larger the network of supply chain participants, the more complex; the more complex the harder to make a working system. Hence the very narrow usecase focus in the package shipping usecase to track packages given into their control. In this case the speaker indicated there were about 5 participants, so I am guessing these would be a few out-sourced transport or handlers.

What data should go into Blockchain vs managed classically?

I spoke to them afterwards. Given that they have experience, I asked if any patterns have emerged as to what data actually goes into the blockchain, vs what data is managed in classic ways. Looking for patterns from experience. I got a very strong answer: "As little as you can get away with goes into the blockchain". One reason given was that the more you put there, the more fragile the system is to improvements. Once data is in the blockchain, it is there forever. It is far easier to later add an element of data that wasn't previously shared. But once something is there it is permanently there.

Permissioned blockchains

They are both using Permissioned chains, where a small subset are authorized to add to the chain, and where a subset of them have validation and counter-signature responsibilities. The validation requirements are use-case specific, and data accessibility specific. Where little data is on the chain, little can be validated. Where that data approaches nothing, the only validation is the date/time stamp freezing that data in time. So clearly there is a balancing task of putting enough into the chain to make validation valuable, but not so much as to make the solution fragile or dangerous.

Danger of public accessibility

I then approached the topic of negatives. That is to say, the blockchain use-case will work fantastically when everything is running smoothly and everyone does their duty properly; but the reason a blockchain is used is because at some point someone will slip up and something bad will happen. It is at this point that the blockchain is used to determine from something bad happening, back to who caused that bad thing. Without this need, there is no need for blockchain. So, it by definition will happen.

IF this investigation is done in public, the participants will all get very nervous, possibly deciding to stop participating. I point out that the FDA does these kinds of investigations, and 'almost always' does them in secret. This because the bad actor usually has made a mistake, and not done something malicious. A penalty from the FDA gets them to change their ways, without scaring everyone. Or scaring the whole public. The FDA choses some cases to make public, usually due to malicious intent, or to 'make an example' out of a big player. With blockchain, especially public accessible, everyone can do the homework to determine who the bad actor; thus it will be very publicly known… and all the good actors will start to question if they should participate, as everyone knows that they will slipup at some point…

The answer I got was… hmmm, never thought of that…

The big Aha moment

In the discussions I got an insight that for some reason had escaped me till that point... For any specific use-case, like Supply Chain Management, one does not necessarily have just one chain. I had been thinking that all of the blockchain features that the use-case would benefit from should / would be provided by one blockchain. But this is not necessarily the best approach. The specifics were that one need is to track the flow of supplies, where another need is to know that there is a confirmed demand for that specific supply. These interact in that the supply should not be shipped without a confirmed purchase of that supply. But both functions don't need to be on the same blockchain. There are actors that should have access to the flow of supplies, and they are slightly overlapping Venn diagrams with those that should have access to the confirmed purchase facts. Only a few of these actors belong in both camps, most are not.

I think in the healthcare use-case of using Supply-Chain Management specifically of drug components likely has similar needs/functionalities that would benefit from Blockchain, but are exclusive audiences.

Some actors might be in the Privileged group for tracking movement, but only readers of the other use-cases. Some might not have any visibility into the purchase chains...   

Simple concept once it is laid out... 

Summary

1. Start with a use-case that has fewest actors to keep it as simple as possible. You can always add actors later.
2. Design each blockchain to handle the right audience and active participants. You can always add more functional chains later.
3. Put as minimal data into the blockchain as you can get away with for the use-case need. You can always add more data elements when they are found to be critical.
4. Augment blockchain functionality with classic data management methods. Don't abuse the blockchain, use it carefully.
5. Think through abuse scenarios up front. Happy-path is nice, but not why you are designing to use blockchain.

My other blockchain articles

FHIR really was positively different

I had a short but very satisfying interaction with a developer at HIMSS 2018. They had implemented a pilot project using FHIR. Their use-case was to instrument the DoD systems with a FHIR Server API, and similarly instrument a VA Vista system with a FHIR Client. The goal was to show how providers at the VHA could see the DoD data while using the Vista experience they are familiar with. 

They found that adding a FHIR Server API in the front of the DoD system to be quite achievable. 

They found that placing a FHIR Client API behind an instance of a VHA Vista to be quite achievable. I spent a bit more time to understand this, as I have been working within the VHA for over a year. What he actually did was stand up a new instance of Vista. It should be noted that each VHA site has their own instance of Vista. Vista is an open-source project. So it is easy to stand up your own instance of Vista. What he did differently is that rather than have a data-base under that Vista instance, he placed a service that implements FHIR Client. Thus as Vista would want to hit its own database, he would intercept that database request, and he would make the equivalent FHIR API call, providing the response to FHIR Client request as the database response. I suspect he did some optimization, but you get the picture.

He had this fully working, and it worked very fast. A VHA user could interact with this instance of Vista just as if it was their own site data. The interaction, User Experience, was identical to what they are used to.

Knowing that VHA might be switching over to Cerner, and knowing that Cerner has a FHIR sandbox available... He directed his Vista FHIR Client to speak to the Cerner sandbox FHIR Server. With only making the endpoint configuration and security token settings; he found that his Vista instance worked almost flawlessly. This system was not designed to work with Cerner FHIR Server... BUT... because FHIR is actually delivering on Interoperability, by being simple and well defined, the system just worked.

When I presented that I am part of the FHIR standards development team, he wanted me to know how overly excitedly happy he was at this experience. He expressed that he has had long experience with networking standards, including HL7 v2, CDA, and others. He wanted me to know that "FHIR really was [positively] different."

I have no idea what will happen with this pilot. It was not part of the VHA Lighthouse project. It was also not part of the FHIR work going on with MyHealthVet (The project I am now assigned).

FHIR Consent Resource mapping to Kantara Consent Receipt

I really like the work that Kantara is doing with Consent Receipt. I think they are doing what is needed. Specifically they are not trying to define an internal consent resource, nor one that would go from one data controller to another data controller. They are focused on giving the Individual something (a receipt) that is evidence of the Consent Ceremony, and contains the terms agreed to. In this way, the Individual has evidence that can be used later when their consent terms have been violated. Much like a retail receipt is used by a consumer when the thing they bought turns out to be broken or defective.

The diagram here is the Kantara Consent Receipt

Perspective difference between FHIR and Kantara: 

The FHIR Consent is shown here

The Kantara Consent Receipt is intended to be a self-contained message, where the FHIR Consent is one Resource to be used within a FHIR infrastructure.   The FHIR Consent is just focused on the consent specifics.

Thus to create a complete equivalent one would need to assemble from FHIR:

Bundle { MessageHeader(1..1), Consent (1..1), Provenance(1..1)}

Where:

• Bundle assemblies everything together
• MessageHeader explains to whom the message is going, and from who it originates
• I am assuming a pushed message, but FHIR clearly can be used RESTfully, or a Document could be created.
• Provenance carries the proof of origination (signatures)
• Consent specifics

Mapping FHIR Consent to Kantara Consent Receipt.

FHIR Consent	Kantara Consent Receipt
identifier	4.3.5 Consent Receipt ID
status	(N/A - would be active)
scope	(N/A - would be fixed at privacy-consent)
category	4.5.5 Consent Type
patient	4.4.1 PII Principal ID
dateTime	4.3.3 Consent Timestamp
performer	4.4.3 PII Controller 4.4.5 PII Controller Contact 4.4.6 PII Controller Contact 4.4.6 PII Controller Address 4.4.7 PII Controller Email 4.4.8 PII Controller Phone 4.4.9 PII Controller URL 4.4.4 On Behalf
organization	4.4.3 piiControllers (including all contact information)
source[x]	4.7 Presentation and Delivery
policy
authority	4.3.2 Jurisdiction
uri
policyRule	4.4.10 Privacy Policy
verification
verified
verifiedWith
verificationDate
provision	4.5.1 Services
type	PERMIT
period	4.5.9 Termination
actor
role	4.5.10 Third Party Disclosure
reference	4.5.11 Third Party Name
action	4.5.2 Service
securityLabel	4.5.12 Sensitive PII 4.5.13 Sensitive PII Category
purpose	4.5.3 purposes 4.5.4 Purpose 4.5.5 Purpose Category 4.5.8 Primary Purpose
class	4.5.7 PII Categories
code	4.5.7 PII Categories
dataPeriod
data
meaning
reference
provision

Not well mapped:

I am pleased and very surprised at how well these map. The following items are where there was differences. These differences seem reasonable given the purpose of each, and capabilities of the environments.

The following items from the Kantara Consent Receipt do map, but not perfectly.

• 4.3.4 Collection Method - a description of the method by which consent was obtained
• for FHIR, the current presumption is that the data is collected during treating the patient for healthcare reasons. This current presumption is likely not going to be true as FHIR matues
• 4.5.8 Primary Purpose -- indicates if a purpose is part of a core service of the PII controller
• Seems to be a way to differentiate primary purpose from secondary. 
• FHIR Consent addresses purpose of use regardless of primary or secondary
• 4.5.9 Termination - conditions for the termination of consent. link to policy defining how consent or purpose is terminated.
• FHIR Consent has timeframe to automatically terminate, but does not address how the patient would take action

There are a few additional capabilities of the FHIR Consent that are not yet represented in Kantara

• verification -- these elements are there to hold who verified the consent ceremony. I am not convinced that this is commonly needed. 
• dataPeriod -- often a patient is willing to allow some data to flow, but might want to block data from a specifically sensitive period of time. The timeframe is an easy thing to identify, and to enforce.
• data -- FHIR we can point at exactly which data is controlled by this rule
• nested provisions -- FHIR Consent can defined nested provisions. Thus enable this, but not that...

Consent is a deep topic that I have many articles

Big audit entries

The ATNA audit scheme has been re-imagined in FHIR as the AuditEvent Resource.

The reformatting is only to meet the FHIR audience expectations for readability. For this there is really useful datatypes, structure, referencing, and tooling. There is no intention to change in any fundamental way. There is a mapping between the two that is expected to translate forward and backward without loss of data. The reality is there might be some cases where the mapping might be lacking....

Small entries are large

One of the observations many make about ATNA and AuditEvent is that the schema itself makes what could be recorded in classic log file using a simple unstructured string of about 115 character. The following example comes from the examples in the FHIR AuditEvent for an Accounting of Disclosure Log Entry,

Disclosure by some idiot, for marketing reasons, to places unknown, of a Poor Sap, data about Everything important.

becomes a 4604 character XML object  or a 4156 character JSON object (Hmm, json is smaller, but not by much).

THIS is a ridiculous example, as the string clearly is not sufficient, but the point I do want to make is that adding structure will make the space needed to be larger.

This is a tradeoff that is simply a fact of the difference between unstructured strings, and a structured and coded object. The string might be useful, but often needs special processing to get the data embedded in that string. More often in a string world, on an log analysis must correlate many log entries to get the full story.

The point of ATNA and AuditEvent is that the original record knew exactly the values of Who, What, Where, When, Why, How, etc... so the goal of ATNA and AuditEvent is to provide well defined ways to record this so that it doesn't need to be guessed at.

So reality is that an ATNA or AuditEvent is likely larger than a string... but most 'happy path' audit log entries are 1-2 k in size. Not small, but also not big.

Big log entries

The problem is that there are occasionally cases, failure-modes, where more information would be useful to be recorded. Such as when there is a technical failure, one might want to record the 'stack trace'. Or when a request is rejected, one might want to record more fully the request details and response error message. 

Or some want to record the results of a Query, something I caution against as it fills the audit log with data that is easily re-created.  Often these results are saved in other databases locally, so in that case just link the AuditEvent with that database entry. This could be done by just putting a database index into a AuditEvent.entity.

So sometimes there is a need to record a big amount of data along with your audit log entry... so, how should this need be handled?

FHIR offers an interesting solution. The Binary resource. That is to say you put the big blob into a Binary, and have the AuditEvent point at that Binary. There is an additional feature of Binary that is useful to identify the security that should be applied to this Binary instance, the Binary.securityContext can point at the AuditEvent instance.

More about FHIR and Audit Logging