This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Trust Label

From HL7Wiki
Jump to navigation Jump to search

Back to Security Main Page

Trust Label Purpose

Trust codes are required to meet stakeholder use case for a discoverable and computable set of metadata to convey asserted trust attributes of an exchange partner.

Trust Library

HL7 Security WG Trust Work

Block Chaining

Blockchain in Healthcare Mike Davis presentation that references some current thinking on using block chaining for healthcare provenance and trust.

Is Blockchain the Answer to Healthcare’s Big Data Problems?

bitcoin a peertopeer electonic cast system satoshi nakamoto

Can Trust-Based Private Blockchains Be Trusted?

What is Proof of Existence

  • What is proof of existence? Use our service to anonymously and securely store an online distributed proof of existence for any document. Your documents are NOT stored in our database or in the bitcoin blockchain, so you don't have to worry about your data being accessed by others.
  • All we store is a cryptographic digest of the file, linked to the time in which you submitted the document. In this way, you can later certify that the data existed at that time. This is the first online service allowing you to publicly prove that you have certain information without revealing the data or yourself, with a decentralized certification based on the bitcoin network.
  • The key advantages are anonymity, privacy, and getting a decentralized proof which can't be erased or modified by anyone (third parties or governments). Your document's existence is permanently validated by the blockchain even if this site is compromised or down, so you don't depend or need to trust any central authority. All previous data timestamping solutions lack this freedom.

Proof-of-work 'paradigm shift'

  • Let us digress for a moment to a prior argument in order to elucidate the immense paradigm shift that proof-of-work delivers in the form of a trustless environment. Many would argue that cheating by, or collusion amongst, regulated parties is an illegal act with associated and significant deterrent costs which are sufficient to enforce the rules.
  • As evidenced above, we know this line of reasoning to be faulty. The reason for this is because when practicably employed, traditional deterrents generate both a non-deterministic and dynamic environment whereby deterrent costs inevitably become cost/benefit estimations – that is, zero cost for successful evasions versus more money due at some future point in time for unsuccessful cheating.
  • Contrary to the traditional deterrents approach, proof-of-work is entirely deterministic, whereby parties know the cost of cheating and collusion and must decide to pay this cost upfront.
  • If efficiency is greatest when the countermeasures are most expensive and immediate, then proof-of-work in the context of a distributed ledger and the trustless environment it helps to generate is a massive paradigm shift that is foundationally new and revolutionary.
  • It should be apparent by now that trust-based systems are merely unsecure and non-empirical software 'workarounds' (if you can even call them that) to the provision of a real security work-product, proof-of- work. In addition, it should be equally apparent that the arguments in support of workarounds to proof-of-work arise, not from a wisdom that it is prudent to build a distributed ledger without proof-of-work, but rather they arise solely from the historical inability to attain proof-of-work in an economical way.
  • It should also be obvious from the discussion that the proof-of-work protocol is factually the underlying key to unlocking the huge paradigm shift and efficiency of distributed-ledger blockchain technology – no traditional deterrents and countermeasures required – there really is no other viable alternative.

Incorporating the proof-of-work protocol into private blockchain technology taps directly into the immense efficiency of the bitcoin blockchain paradigm shift. Without it, all you've built is an old-fashioned (and inefficient) distributed database.

CommonAccord Provenance Blockchain

Problem: No mechanism to track provenance of digital contracts exchanged between machines No method for verifying non-repudiation beyond digital e-signatures on contracts Weak method to sharing versions of contracts among negotiating parties Solution: Enhance CommonAccord architecture with hash-chains for tracking state of negotiated contracts Publish hash-chains to ledger (public or private) Provide mechanism for parties to access private repositories containing contracts Legal documents are mostly handled as text blobs, in a complex, semi-proprietary format. Authoring, reviewing, sharing, managing are all difficult. Establishing provenance is often impossible The impact is delay, cost, risk, fear, imbalance, and a systemic advantage for large actors Data Model and Version Tracking:

  • Data model expresses contracts in modular parts
  • GitHub model for change mgmt & version tracking
  • Parties check-out contract into private repositories

Access control to contracts and metadata:

  • UMA model for access control to private repositories
  • Parties access repo, do changes, send Metadata
  • Each change generates hash-points in doc hash-tree

Ledger system:

  • Captures current state of contracts exchange/flow
  • Hash of Metadata added to ledger
  • Can use today’s Blockchain or future technology

DirectTrust

Federal Trust Bundle

GTRI - IDESG

NATE

ONC

ONC Governance Framework Trusted EHIE

State Health Information Exchange Cooperative Agreement Program Guidance on Privacy and Security Frameworks

This guidance addresses the core domains of the Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information2, built from the fair information practice principles (FIPPs) that have guided privacy and security efforts worldwide for decades: 1. Individual access 2. Correction 3. Openness and transparency 4. Individual choice 5. Collection, use and disclosure limitation 6. Data quality and integrity 7. Safeguards 8. Accountability State HIE Cooperative Agreement Program recipients should use the following guidance to evaluate their current privacy and security policies and practices and determine if alignment gaps exist. State policy makers and other stakeholders can use the guidance to determine, assess and fill gaps in current policies and practices to assure trusted health information exchange. The guidance outlines a core set of privacy and security expectations that should be consistently applied, but it is not exhaustive. Recipients will have additional policies and requirements that are critical to their efforts. NATIONAL STRATEGY FOR TRUSTED IDENTITIES IN CYBERSPACE Appendix A – Fair Information Practice Principles (FIPPs)

Fair Information Practice Principles To truly enhance privacy in the conduct of online transactions, Fair Information Practice Principles (FIPPs) must be universally and consistently adopted and applied in the Identity Ecosystem. FIPPs are the widely accepted framework of defining principles to be used in the evaluation and consideration of systems, processes, or programs that affect individual privacy.1 In brief, the Fair Information Practice Principles are:  Transparency: Organizations should be transparent and notify individuals regarding collection, use, dissemination, and maintenance of personally identifiable information (PII).  Individual Participation: Organizations should involve the individual in the process of using PII and, to the extent practicable, seek individual consent for the collection, use, dissemination, and maintenance of PII. Organizations should also provide mechanisms for appropriate access, correction, and redress regarding use of PII.  Purpose Specification: Organizations should specifically articulate the authority that permits the collection of PII and specifically articulate the purpose or purposes for which the PII is intended to be used.  Data Minimization: Organizations should only collect PII that is directly relevant and necessary to accomplish the specified purpose(s) and only retain PII for as long as is necessary to fulfill the specified purpose(s).  Use Limitation: Organizations should use PII solely for the purpose(s) specified in the notice. Sharing PII should be for a purpose compatible with the purpose for which the PII was collected.  Data Quality and Integrity: Organizations should, to the extent practicable, ensure that PII is accurate, relevant, timely, and complete.  Security: Organizations should protect PII (in all media) through appropriate security safeguards against risks such as loss, unauthorized access or use, destruction, modification, or unintended or inappropriate disclosure.  Accountability and Auditing: Organizations should be accountable for complying with these principles, providing training to all employees and contractors who use PII, and auditing the actual use of PII to demonstrate compliance with these principles and all applicable privacy protection requirements. Universal application of FIPPs provides the basis for confidence and trust in online transactions. 1 Rooted in the United States Department of Health, Education and Welfare's seminal 1973 report, “Records, Computers and the Rights of Citizens” (1973), these principles are at the core of the Privacy Act of 1974 and are mirrored in the laws of many U.S. states, as well as in those of many foreign nations and international organizations. A number of private and not-for-profit organizations have also incorporated these principles into their privacy policies.

cooperative agreement with the Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services.

THEWS

Trust Label Harmonization Proposal

Back to Security Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=Trust_Label&oldid=121929"