Can Direct messages be "delegated/forwarded?"

I got this question offline, and know others are wondering too. The question is actually a Policy question. The technology answer is simple.

The Direct Project put policy completely out-of-scope, saying that it was the sender’s responsibility to determine that they have the necessary authorization and that they have chosen the right target. The Direct Project picks up at that point in the workflow, at the point where there is a need for technology to deliver the message. I know some people want Direct to encompass more, but it does not. And I should not, as that would limit policy and creative software.

Further, the Direct Project has no way to carry policy rules from one place to the other. It is true that there is a TO addressee and when using XDM there is an intendedRecipient. But neither of these technical fields have a policy attached. Just like every email that is sent, there is no way to compel the reader to not share the message with anyone (I had an oops like this just today, sorry about that). Hence why some people put various forms of disclaimers at the bottom of their email, things that have been proven not legally binding as well. Some e-mail packages have actually tried to implement some policies, but without universal use this won't work.

Within the NwHIN-Exchange the highest level policy (DURSA) has clauses in it that forbid one party from re-publishing the document that they got from another party. This means that if you receive a document through the NwHIN-Exchange that you can’t republish that document, it does not restrict you from using the document for the purposeOfUse. It does not restrict any derivative works, your medical summary or diagnosis including evidence from my document. This is a Policy that is defined and enforced by the overall NwHIN-Exchange governance. The NwHIN-Direct does not have such a Policy, and there is lots of resistance to an overall organization.

Note that the S&I Framework – Data Segmentation for Privacy – workgroup is working on this problem in an indirect way. That workgroup is working on specific regulations that mandate that policy in English textual form accompany specific types of data; so they are looking at how to do that. They want to send along restrictions on exactly which individuals can see the data, and what long-term rules must always be applied to even the decomposed attributes from the data. The reality is that this is not something that is done outside of healthcare today, so there isn’t free technology we can leverage. The non-healthcare world is using more of the NwHIN-Exchange model, with pre-negotiated policy principles; and policy applies to a whole-document.

The DirectTrust.ORG is also looking into the use-case you bring up. Specifically they want to force the TO or intendedRecipient to truly be the only one that can use the data. I think this is a mistake that the market-place will push back on. Simply because of Medical Records Retention, and Medical Ethics will prevail. If the data is used for treatment, then it must be incorporated into the local medical record (electronic or not).

Lets just imagine one can come up with a solution, we would need to certify that everyone involved in healthcare, including patients, are all using compliant software. And that it was impossible to hack around it. Impossibility. The sooner we get to that understanding, and lean on policy that is backed by regulation and punishment; the sooner we will make progress. 

A middle ground is that there be e-mail addresses (Direct addresses) that are clearly the individual-for-no-other-eyes, and the individual-and-medical-records. This is not much different than the discussion of an organizational e-mail address, or a departmental one. 

I have covered this before:

• Handling the obligation to prohibit Re-disclosure
• ConfidentialityCode can't carry Obligations
• NHIN-Direct Focus and Scope Creep
• Policy Enforcing XDS Registry
• Critical aspects of Documents vs Messages or Elements
• Proposal for confidentialityCode vocabulary
• IHE - Privacy and Security Profiles - Conclusion

IHE Document Digital Signature - Non-Repudiation

I presented the Document Digital Signature profile to the S&I Framework - esMD workgroup. This group is looking for ways  to have non-repudiation proof of authorship and are hell-bent on using digital signatures. I am not convinced that they yet have the compelling use-case to overcome the 'costs' that come along with Document Digital Signatures. These costs are money, but more so they are resources, changes to workflows, and a long-term commitment. It is  this long-term commitment that usually stops most projects short.

My presentation leveraged much of the things that I have blogged about.

• IHE - Privacy and Security Profiles -- Webinar
• Non-Repudiation is a very old art
• Signing CDA Documents
• IHE - Privacy and Security Profiles - Document Digital Signature

I didn't cover:

• Using both Document Encryption and Document Signature

Trusted Identity of Physicians in Cyberspace Public Hearing

ONC did another FANTASTIC job of putting together an agenda and gathering experts. Not only that but the coverage of the healthcare space and coverage of the identity space was exceptional. I hope you all were watching this testimony, if not please get the recording. This was also not just the HIT Standards Privacy and Security workgroup but also the HIT Policy Privacy and Security tiger team. The intention was to inform these groups, not to make any decisions. The decisions and discussion will happen in future meetings.

I am a member of the  HIT Standards Privacy and Security workgroup. I really wanted to be physically at the hearing. I had booked hotel and flight; but the day-job got in the way at the last minute. This day-job took me away from the call a few times, each time I really felt I was missing something useful. Pulling the presentations is not sufficient to get the depth of the presentations. 


I duplicate the agenda below, but encourage everyone to go to the HIT Standards site to get any updates or recording. I include the  agenda simply to inspire you to go get the information.

Trusted Identity of Physicians in Cyberspace Public Hearing Wednesday, July 11, 2012 9:00 am to 3:00 pm/EDT The DuPont Circle Hotel 1500 New Hampshire Ave NW Washington, DC 20036
How to Participate	http://altarum.adobeconnect.com/ONChearing/
Meeting Agenda	Agenda [PDF - 101 KB]
Meeting Materials	800-63 for HIT Polk [PPT - 71 KB]* OneID June 2012 HHS Kirsch [PPT - 797 KB]* OneID Written Materials for Trusted Identities Hearing [DOC - 27.1 KB]* Provider Identities Rick Rubin [PDF - 260 KB]* Surescripts Trusted Identity of Physicians in Cyberspace Testimony [DOC - 201 KB]* Federal Advisory Committee Trenkle [PPT - 2,110 KB]* Trusted Identities Hearing [PPT - 202 KB]* NSTIC ONC Meeting Grant [PPT - 1.39 MB]* ONC TS July 2012 [PPT - 368 KB]* ONC Verbal [DOC - 17 KB]* Presenter Biographical Sketches [DOC - 34.4 KB]* Verizon FAC Presentation Evans [PPT - 2.17 MB]* NSTIC Physician Steering Committee [PPT - 588 KB]* Trusted Providers in Cyberspace EHR Bias [PPT - 1.15 MB]*

My biggest concerns:

a) Provisioning identities is important, but MORE important is keeping identities accurate, de-provisioning, and dispute handling.
b) Setting identity assurance levels and authentication assurance levels is important; but there is too much focus on perfecting these identities, vs recognizing that any service that has protected resources will in real-time make the assessment on if the identity and credentials offered on a request are sufficient to authorize that request. Meaning that we can actually be using different levels-of-assurance in the NwHIN; with purpose-of-use and data-classification specific enforcement.
c) Timeframe - In a perfect world we can define great identities and design NEW systems to use them. BUT there is much existing software and systems and organizations involved. Retrofitting everything is expensive.

Are Documents Dead?

As I am looking over potential comments to the mHealth profile, I find Gary's post asking, in the context of the mHealth profile, if Documents are Dead. I don't know why this is relevant to the mHealth profile, except that it is document based, so far. Meaning that the goal of the profile is actually to give access to documents. Thus it does start with the premise that documents do exist and people/systems want access to them. Reminder the profile is actually "Mobile Access to health Documents (MHD)", it is just referred to as mHealth simply for the marketing.

I find it very interesting that Gary uses a Document to indicate that Documents are dead. The blog post is a Document. The format clearly is different than historic documents, but the concept that Gary has taken past experience and research; applied his brain; and produced a new concept that is Documented into a format that tells a story... a document...

The Document is far more the conclusion of a past set of thinking. The blog article is now being split up into datum by the likes of google and bing; it is being recollected in the likes of RSS feeds; and likely republished in some newsletter like deployment. I see these very things happening with healthcare documents. The document is not intended to be an input to a human, it could be; but rather the human is an inference-engine intended to treat a patient given historic knowledge and then document the reasoning and what was done. I certainly hope that humans can get a more relevant format as input than a blunt list of historic documents. But ultimately something must have decomposed the historic information.

There is a circle of information, a document is just one step. And a blog only proves that the "document" has a place on this life-cycle.

RESTful interface to XDS - Comment NOW!

The IHE ITI mHealth Profile is in Public Comment for only a little bit more. The formal due date is today, but anytime is a good time to comment. I will work hard to get any constructive comments worked into the profile. The IHE IT Infrastructure domain has published just this one new supplement for Public Comment. The supplement is formally “Mobile access to Health Documents (MHD)”, but is often referred to as the mHealth profile. 


I have explained the profile
I have explained the user authentication model


I really want comments on the profile, especially the Open Issues

OPEN ISSUES

As a Public Comment version there are many issues that have come up during the development that are not fully locked down. Most of them are due to the learning-curve of the committee. Thus I really want constructive comments on the whole Profile but specifically on these Open Issues. The open issues are far more detailed in the document, they are basically:

• Restricted “Create” to ONE document, with derived SubmissionSet
• No access to SubmissionSet, Folders, and Associations
• Patient ID is needed as part of URL
• Bring in hData as framework and thus ATOM in GET path for multiple entries?
• Conditional get is not supported due to the differences between the semantics of HTTP and XDS concepts of resource age.
• Do we need more on Security, specifically Audit?
• JSON use of anonymous objects or not?

Leap Second, yes it has security and privacy relevance

There is a leap second on June 30th. The security relevance is,  how will your software deal with this leapsecond. Will events that happend during the extra second be properly accounted for? will it be shown as 60 seconds, or will 59 show up for 2 seconds? -- the 'accountability' side of Security.

Will your timers handle a request to delay by 60 seconds, when there actually are 61? Will a deadlock occur? -- the 'availability' side of Security.

Will your software adjust the clock at all? Or will it be terminally behind a second, likely many seconds since we have had almost a half minute of leapseconds. This is what the GPS system does, rather than deal with the accounting mess.

• Leap second: June 30 to be longer than other days

of course on the other side of GMT they see it differently

• Leap second to be added on July 1

and businesses care too

• from Business insider

a good quality implementation of NTP will simply smooth the second out so that there never is simply a leapsecond, but rather a bunch of leap microseconds.

but not all time sync are that advanced

• How the Windows Time service treats a leap second
• Leap second handling in SUSE Linux products

And...

• Warning: Problem with Leap Seconds in Red Hat Enterprise Linux

----------------------------------
Update: July 2, 2012 -- Fantastic analysis done By Rob Horn. Not just what the problem was, but why we find ourselves in this strange space where this matters yet doesn't really matter.

Constructive comments on Data Segmentation for Privacy

The first draft of the S&I Framework -  Data Segmentation for Privacy – Reference Implementation Guide comments are due today. As usual I did leave this exercise to the very end. I spent 10 hours on Sunday to review in fine detail providing constructive comments on everything from a simple typo to a fundamental mistake. I came up with 144 comments, 6 of which I consider major show-stoppers. These 6 are not hard to fix, but they are critical that the be fixed.

I have marked up the PDF and produced a 22 page extract of my 144 individual and detailed comments.

The 6 items can actually be summarized into THREE.

Use XD* family as the Document Level control, not CDA:

The draft today proposes that even for whole document control one must use CDA. This means that if you have a DICOM object, PDF document, text document, CCR, Blue-Button, or some form of workflow (such as XDW); that this object MUST be encapsulated inside of a CDA document. This fundamentally is a waste as the exact same functionality can be achieved simply through the use of the XD* family of transactions, using the rich XD* metadata. Indeed this seems to be the message except for specific sections of chapter 3.

Not only is it unnecessary to encapsulate everything in CDA, but you still MUST support XD* metadata as an external embodiment of the metadata. Let me explain this another way, if you only use CDA then you MUST open up the CDA document only to discover you should NOT. Hence why there is security layers built into the XD* family of profiles, that place the minimal but important metadata in the transaction where the access control service can prevent the opening of the CDA document without first invoking the proper controls.

The XD* mechanism is needed to define the whole document level control, and even if the CDA document contains section or entry controls, the XD* mechanism is still needed to convey the high-water-mark (highest confidentiality code contained within the content)

Thus we MUST define the XD* family mechanism anyway, so the additional functionality inside the CDA for document level control is free, and we enable entry level control.

• Direct – shall use the Direct specified XDM attachment to carry document level controlling metadata
• Exchange – shall use the XDR and XCA mechanisms to carry document level controlling metadata
• HIE – shall use the XDS mechanisms to carry document level controlling metadata

There is concern within the community that the HIT Standards committee had recommended the CDA Header as the proper metadata, and my recommendation is consistent with this. Not in letter, as I disagree that the CDA header should be the primary mechanism, but in spirit as the XD* metadata is a purpose specific metadata that is highly influenced by the CDA header. The difference is that the XD* metadata is a proper metadata, whereas the CDA header is proper documentation.

Sensitivity coding is for Policy, not for communications

There are statements in Section 3.7.5 around sensitivity coding that are misguided and wrong. We have provided expert testimony in both healthcare and military-intelligence to express why this is a bad idea. It is true that the HIT Standards committee did include a recommendation along these lines, but they were misguided and wrong too; but they didn’t have the benefit of the expert testimony that we had. Therefore we should inform the HIT Standards committee that we have learned information that they didn’t know. We must not regressing and ignoring decades of advancement.

Sensitivity codes are needed, they  are needed in privacy policy rules as tags that identify the rules to apply to specific types of data. They need to exist in privacy policy rules to identify what types of data should be handled differently. They can even be used inside of a system in proprietary and non-exposed ways (inside the black box). But sensitivity codes are not appropriate as metadata on clinical content. The use of confidentialityCodes, which are larger chunks, are the appropriate and sufficient metadata.

Entry level functionality is NON-Standard and should be identified as a gap for HL7 CDA R3

The mechanism for providing entry level tagging in Section 3.6 is not standards based. To promote this method will forever force all systems to implement this non-standards based approach. It is true that the method leverages extensions built into the standard, but it is describing a mechanism that no tooling supports today, and would be very difficult to get tooling to support this mechanism. Further it leaves many things completely unspecified, as there is no underlying standards.

We should identify this as a gap for HL7 CDA R3 to resolve.

  

Conclusion

I was asked when I tweeted my progress Sunday afternoon, if I was coming up with typical number of comments for a review. At the time I thought that this was an excessive amount of comments, but looking back at them I must say that the text is in good shape. The majority of my comments are simple constructive change requests. Even the 6 (or 3) big issues are very easy to resolve. I don't think that my recommendation to resolving these big issues is controversial to anyone other than the politically connected. They are well founded in experience and international standards efforts. Yes I am passionate that they be fixed, as I am convinced without these fixes the result will be unusable. I have spent too much time on this project to have it fail due to politics and whim.