April 12, 2011 CBCC Conference Call
Community-Based Collaborative Care Working Group Meeting
- Milan Petkovic
- Richard Thoreson CBCC Co-chair
- Ioana Singureanu
- Serafina Versaggi
- Tony Weida
- Craig Winter
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (15 min) Relationship of the SDWG projects (HQMF and QRDA) to SHIPPS Project
- (15 min) Project Scope Statement - Confidentiality Codes REVIEW
- (15 min) Item3
- (5 min) Other Business
Meeting Minutes - DRAFT IN PROGRESS (Minutes are incomplete)
Relationship of the SDWG projects (HQMF and QRDA) to SHIPPS Project
Agenda for HL7 Working Group - Orlando, Florida
Roll Call, Approve Minutes & Accept Agenda
Project Scope Statement - Confidentiality Codes – Discussion postponed to next meeting This is an item for the Joint Security-CBCC meeting. High level conversation on the Level of Effort—we should have a fairly simple plan of what we want out of this project. And the effort in order to complete; three will be a lot of interest from other WGs in using these codes; does someone has a vision of that?
The key is ‘’harmonization activities’’ that need to take place. Calvin circulated CDA R3 list of tasks for the SDWG meeting today--there is an item about confidentiality codes;
“ Confidentiality codes: work with CBCC on consent and confidentiality code extensions for x_BasicConfidentialityKind. We potentially need the confidentially code attribute at the entry level. May need to increase the cardinality of the confidentiality code attribute (across the board for CDA ) (First issue, however, is more general and requires RIM harmonization proposal.) Need to consider how the confidentiality code in a document relates to the authorization processing which is policy based.”
It looks like they are grappling with ‘’ (First… is more general and requires RIM harmonization..’’ ~which I’m not sure why it requires RIM harmonization… ‘’Need to consider how the confidentiality code in a document relates to the authorization processing which is policy based.” How the confidentiality code set is based on specific policy. which is something that we can help define , since we’ve already looked at the elements of the policy, what makes information protected and what criteria would you use to segment that protected information from non-protected information for instance—as your desired criteria – this is something that could be included in the project scope statement.
It relates to how the code relates to the authorization processing, which reminds me of the EHR security-privacy support functions The fact that they are saying authorization makes me think of access control.
It may be that the word ‘’authorization’’ is used too much. Vs. ‘’access control’’ and the term may not be used consistently
There are several extensive notes from November 30, 2010 as well as in March 1st, 2011—so in any of these discussions we may want to review these meeting minutes. There are actual recommendations and we did talk about RBAC. We also talked about a go forward plan on March 30th.
Maybe we can summarize those meeting minutes and bring those forward rather than re-hashing the entire conversation again. We recorded some things made from creating the Domain Analysis Model that were made during those meetings---if we can extract those decisions that would be very helpful. ‘’’ACTION ITEM: Mary Ann to extract any decisions made during the noted meeting minutes to bring forth as support for the go forward plan and the project scope statement’’’
Another level of conversation is also ‘’where do these codes go…?’’ In the header, in the body of whatever is being transferred. You don’t want to put stuff in the header that may disclose critical information—that one level of conversation, but I don’t’ know if that’s what this is about
It may not be part of this work item---what you’re saying in very important. One thing we need to do first, We need to have a thorough analysis of the current coding system for confidentiality—half of our trouble is that confidential code is intended for anonymized information and not for identified information. That is one big problem that we’ve seen in the NwHIN Privacy WG discussions. There are codes—i.e. HIV related; it’s a confidentiality code—according to the HL7 Terminology spec—it’s only appropriate if attached to anonymized information. It’s not appropriate and it says that in the spec that it cannot be used for Patient identified information and this is but it doesn’t appear to be the way people have implemented it. And maybe that’s because in the spec there is not clear distinction in the coding system between those things that are exclusively prohibited from use in a document which is patient-centric or other exchange that are patient centric. This sort of code is not appropriate for registration meta data of the document. But we’ve gotten push back by people who have implemented it---saying that’s the way they like it now. so the first thing we have to do is to look at all the small print of the HL7 Terminology spec and see if we have any other instances of code that are specifically associated with certain use cases…used in any of the use cases wherein that should be used outside of that particular use case. You have to read the small print in the spec to see that , confidentiality by info type is specifically ONLY for anonymized information…it's in there with codes that are applicable to all use cases.
- 15:30 Recording Mark*
This pre-dates any work done by CBCC---these codes were introduced for use Canada, they were used by a pilot project in the US. They are not being used in a production environment in Canada. It may be we run across a pilot project that becomes into live production overnight. If you use indiscriminately, but confidentiality by info type is the issue. Confidentiality by info type vs. confidentiality by access kind. It’s almost an authorization by confidentiality. It’s not a good way to accomplish something in two different ways.