PASS Audit: Ballot Pool is now open

The HL7 Privacy Access and Security Services (PASS) project team is pleased to announce that the result of our efforts to define a Healthcare Audit service specification is now ready for membership review. The PASS project is a joint effort between the HL7 SOA, Security, and CBCC Workgroups and has had the benefit of active participation from members and Co-Chairs of each of those Workgroups.

 

The ballot pool for the latest specification entitled "HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) - Audit Services, Release 1" is now open until September 20, 2010. We'd like to encourage anyone interested to to sign up for the ballot pool and provide support for this work in the form of review and comments. The HL7 Ballot Desktop can be accessed at: http://www.hl7.org/ctl.cfm?action=ballots.home&ballot_cycle_id=521&ballot_voter_id=0

Healthcare Provider Directories

This is where all the buzz is right now. Although it would seem that this is a NHIN-Direct item; it is not. NHIN-Direct has been rather ignorant of these efforts. I have tried to get them to recognize the use of Provider Directories, especially related to distribution of the digital certificates that secure the communications. The Provider Directory should be a way to discover a Provider or Providing Organization; their address information including their NHIN Direct address; and the mechanisms to securely communicate including their NHIN Direct endpoint certificate. There is still hope, and movement lately on the topic.

The Provider Directory is far more than a way to assist with NHIN Direct. The first reason to have a provider directory is for all the normal reasons to have a directory. Discovery of a type of healthcare provider in a geographic area.

IHE Has profiled this  Healthcare Provider Directory (HPD) - Published 2010-08-10

This is the list of use-cases included in the IHE profile.

• Yellow Pages Lookup: A patient is referred to an endocrinology specialist for an urgent lab test. The referring physician needs to get the contact data of close-by endocrinologists in order to ask whether one of them can perform this test in their own lab. The patient prefers a female endocrinologist who can converse in Spanish regarding medical information.
• Identification in planning for events: Emergency response planning requires the identification of potential providers who can assist in an emergency. Providers must meet specific credentialing criteria and must be located within a reasonable distance of the emergency event.
• Provider Authorization and lookup during an emergency event: During Hurricane Katrina, health care volunteers were turned away from disaster sites because there was no means available to verify their credentials. At an emergency site, the Provider Information Directory
• Forwarding of Referral Documents to a Hospital : A PCP refers a patient to the Hospital for admission. The PCP needs to send various documentation to the Hospital to be part of their EHR when the patient arrives. The PCP needs to identify the Hospital‘s electronic address such as email or service end point where the patient‘s documentation should be sent.
• Keeping agency provider information current: A German government agency dealing with healthcare services for its constituents wishes to keep its agencies healthcare provider information current. The agency determines that it will use the Provider Information Directory to access the most current provider information. The German agency only requires a subset of the Provider Information Directory available information. On a regular basis, the Provider Information Directory provides to the agency a list of the updated information needed.
• Providing Personal Health records to a new Primary Care Physician: An individual has changed health plans. As a result that individual must change his Primary Care Physician. The individual has a Personal Health Record and would like to provide that information to his new Primary Care Physician. The individual needs to determine where to have the Personal Health Record transmitted to.
• Certificate Retrieval: National regulations in many European countries require that an electronically transmitted doctor‘s letter be encrypted in a way that only the identified receiver is able to decrypt. In order to encrypt the letter, the sender has to discover the encryption certificate of the receiver.
• Language Retrieval: An individual who only speaks Italian requires healthcare services at an Outpatient Clinic. That individual would like to be able to communicate with the Clinic personnel, if at all possible. The individual or his caregiver needs to determine which clinic supports Italian and provides the service that is required.

NIEM - making lemonade out of lemons

Yesterday I learned yet more about NIEM, attending the same session that Keith blogged about. He has some good references worth looking at to get some background. It is clear that NIEM is here to stay. Good, Bad, or Indifferent. So, lets figure out the best way to use this tool.

The NIEM process as visualized by ONC

Overall I think the NIEM process will be a good thing. It is a high level model for dealing with the issues we have been looking at for years. It includes steps that HITSP never got to (although I think this was more a funding problem than anything).
            *** So, will funding be provided to make the WHOLE process work? If it is going to be underfunded or cut apart; then it is not going to be very useful.

The NIEM process is actually very similar to the IHE process.

Except that IHE doesn’t require a 'reference model'. Rather they expect real products to show up at Connectathon, and until three independent products show interoperability at Connectathon then the specification can’t progress. The Reference Implementation model drives ‘academic’ proof, which is not always a good indicator of reality. I have seen how OASIS members abuse this. IHE is a partnership of those that have a problem and would like a solution, and those that could solve the problem if they were given assurances that the solution would be universal and desired. This is critical to why IHE continues to be successful. Yes sometimes what was thought to be desirable at one point is not later on.

            *** The ‘reference model’ is a fine thing, if it happens. But a reference model does not prove the spec will work in real-world situations.
            *** I would like to add the IHE product centric proof step into the NIEM process.

Re-use, don’t Re-invent; I think I heard this in the latest meetings on NIEM. But it needs to be emphasized as important. Most importantly it needs to be communicated that Re-Use is allowed and encouraged. I think NIEM can be very useful at the high level, it needs to be kept very thin. Similar to the overall approach in HITSP, only better (because we have learned).

           

           *** The biggest risk to success is that NIEM offers consultants unending work.
            *** The NIEM documentation tools are impressive and if they work as advertized the answer to world hunger.


Legacy. Healthcare is not a new, green field. Therefore part of the analysis must include this legacy. The analysis does not need to choose the legacy method, but it must consider the impact. This seems to be totally missing in the NIEM process. Further the focus of NIEM on producing XML and web services will be unproductive in some use-cases (it will be fine in others).

            *** How is the impact on existing investment included in the NIEM process

            *** When there is no single solution, how can NIEM indicate that there are 2 solutions acceptable?

            *** When the solution is not XML or web services, we need a light weight way to document this.


SOA. The process we saw is very heavy on SOA, and the use of SOA terms. This is not a bad thing. The concern is that some will take this as a directive that everything must be reformulated and relabeled using SOA modeling and SOA terms. IHE wrote a white paper that tried to show that there is synergy between the new SOA modeling and terminology; and the IHE modeling and terminology. Unfortunately this renaming exercise wasted lots of valuable time in HITSP and resulted in multiple layers of documentation with no value-add.  Religious wars are unproductive.
            *** We need a more light weight method of handling this.



International. This is not as big of a concern to providers, although they do benefit without knowing. But it is very critical to big vendors that don’t want to have to do things two ways. I suspect the attitude expressed by Doug Fridsma at the NHIN-Direct meeting, that of re-use where standards exist and fit the need, will take care of this issue. But it is still a force to consider. Often times it looks like inventing something special for USA is the right thing to do, it should be resisted. This is not limited to healthcare either, there are plenty of good international security standards to re-use rather than invent something special for USA. Overall I have not come up against a problem being internationally friendly.

            *** Be aware of and guided by experience in the international community


Coordination. ONC needs to Coordinate all of these National initiatives. Hopefully they allow the 10 contracts to coordinate directly rather than force all communications through ONC. I am hopeful that this will happen.

            *** Enable coordination, don’t become a bottle neck


I welcome NIEM, and want to help it succeed by focusing it and keeping it lean. NIEM should be leveraged to add value and clarity; not duplicate what others do and have done. Where a gap is found, NIEM can be leveraged to best describe the gap and determine the best SDO/PDO to fill the gap. Reuse, not Reinvent.

Privacy from the other perspective

Often times people are very quick to understand Privacy from the Patient's perspective. Often times these discussions include many overt violations of the Provider's Privacy. There is an article on "Doctor records taken offline". This article title doesn't hint at the actual article content. I am not going to side one way or the other on the actual problem. I will point out that Privacy has many perspectives, and focusing too closely on one perspective can cause unintended consequences.

Illinois once provided the public with detailed histories of the state's doctors — including whether the physician was convicted of a crime, fired by a hospital or forced to make a medical malpractice payment within the previous five years. Judging from online traffic, there was great hunger for that information: During the two years that they were posted, the physician profiles generated 130,000 clicks per week. But access to the profiles came to a screeching halt in February, when the state Department of Financial and Professional Regulation removed them from its Web site and placed them under lock and key — the latest chapter in a long political battle that has pitted patients' advocates against the state's medical lobby.   Read More

Top O' the Week

Keith has shown me the blogspot beta tool that can be used by a blogger to see the statistics on their blog. I find that it gives somewhat radically different results than Google Analytics. The likely reason is that Google Analytics requires my readers to have JavaScript enabled, where as blogspot uses simple page hits. Given that my blog audience is sensitive to security and privacy topics, it is not too surprising that Google Analytics shows about %25 fewer hits than the blogspot tool. But the top hits from each tool is also different. Given that I have not posted anything in over a week, it is nice to see that I have any traffic at all.


The Top O' the Week according to blogspot results

1. Meaningful Use Security Capabilities for Engineers...
2. IHE IT Infrastructure Technical Framework Suppleme...
3. Healthcare use of Identity Federation
4. Consumer Preferences and the Consumer
5. Data Classification - a key vector enabling rich ...

The Top O' the Week according to Google Analytics

1. IHE IT Infrastructure Technical Framework Suppleme...
2. Meaningful Use Security Capabilities for Engineers...
3. Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent 
4. Data Classification - a key vector enabling rich ...
5. Healthcare use of Identity Federation

While in DC this week I heard a few people saying that my piece on Data Classification and the Redaction and Clinical Documentation has been the topic of discussions. I am very glad for this, as I fully want to get people discussing these ideas

IHE IT Infrastructure Technical Framework Supplements available for Trial Implementation

The IHE IT Infrastructure (ITI) committee has published the Trial Implementation specifications. This is the version of the supplements that have been through a 30 day public comment, and now are ready for testing at the coming Connectathon. The following supplements are now in Trial Implementation

• Cross-Enterprise User Assertion - Attribute Extension (XUA++) 
• These updates add three named options: Role-Based-Access Control, Consent/Authorization, Purpose of Use, and adds Other Descriptive Attributes
• Healthcare Provider Directory (HPD) 
• Creates a way to discover and get attributes about both Individual Providers and Organizational Providers
• On-Demand Documents - 
• This extends XCA/XDS with support for publication of 'on-demand' documents
• Sharing Value Sets (SVS) -
• This was enhanced with a new transaction "Retrieve Multiple Value Sets"
• XDS Metadata Update - Published 2010-08-10
• New administrative interface to allow for direct manipulation of metadata entries

Also updated, but still in Trial Implementation (all changes are fixes from experience/connectathon. Previously documented in Change Proposals)

• Asynchronous Web Services Exchange
• Cross-Community Access (XCA)
• Cross-Community Patient Discovery (XCPD)
• Document-based Referral Request (DRR)
• Document Metadata Subscription (DSUB)
• Multi-Patient Queries
• Notification of Document Availability (NAV)
• Patient Identifier Cross-Reference (PIX) and Patient Demographic Query (PDQ) HL7 v3
• Pediatric Demographics Option for PIX and PDQ
• Retrieve Form for Data Capture (RFD)

Of course the Technical Framework, where Final Text profiles are published, has been revised too

Current Technical Framework - Revision 7.0
August 10, 2010
Copyright © 2010: IHE International, Inc.
Final Text Version

• Vol. 1 (ITI TF-1): Integration Profiles
• Vol. 2: Transactions - Volume 2 is divided into three separate sub-volumes:
• 
  
  • Vol. 2a (ITI TF-2a): Transactions ITI-I through ITI-28. These transactions are used in the following profiles CT, PSA, EUA, PIX, RID, XDS, ATNA, PDQ, PWP, NAV
  • Vol. 2b: (ITI TF-2b): Transactions (cont'd) ITI-29 through ITI-50. These transactions are used in the following profiles PAM, XDM, XUA, XDS
  • Vol. 2x (ITI TF-2x): Appendices A through W and Glossary
• Vol. 3 (ITI TF-3): Contains Section 4 Cross-Transaction Specifications and Section 5 IHE Content Specifications
  

These volumes provide specification of the following profiles:

• Audit Trail and Node Authentication (ATNA)
• Basic Patient Privacy Consents (BPPC)
• Consistent Time (CT)
• Cross-Enterprise Document Media Interchange (XDM)
• Cross-Enterprise Document Reliable Interchange
• Cross-Enterprise Document Sharing (XDS.b)
• Cross-Enterprise Sharing of Scanned Documents (XDS-SD)
• Cross-Enterprise User Assertion (XUA)
• Enterprise User Authentication (EUA)
• Patient Administration Management (PAM)
• Patient Demographics Query (PDQ)
• Patient Identifier Cross-Referencing (PIX)
• Patient Synchronized Applications (PSA)
• Personnel White Pages (PWP)
• Retrieve Information for Display (RID)

Redaction and Clinical Documentation

I seemed to touch a nerve yesterday in my blog about  Data Classification - a key vector enabling rich Security and Privacy controls. A minor part of this blog was a few paragraphs where I laid out a way to produce related documents that would have different Data Classifications. The main goal was to show that documents could be transforms that have lesser content thus resulting in a lesser sensitivity. IT seems that I hit a nerve (Data Classification, Redaction and Clinical Documentation)  in Keith Boone, who I always defer all CDA discussions to. But, like Keith yesterday, who said he defers discussions of Security and Privacy to me, then goes on to make statements about Security and Privacy; I will do similar.

My post yesterday was about the original author making privacy informed decisions to post a second document that is a logical transform of their original document. This surely could be assisted by technology, but I was not trying to say that this would be automatic. I am, just like Keith, concerned with CDA documents that are built by an automated process without a clinical human involved.

I am not going to claim that there is no use for a CDA document or an automated transform of a CDA document. Seems to my non-clinician mind that knowing something is better than knowing nothing; especially if you are well informed that what you are given is less than total knowledge. The Author of a document is a very important part of the metadata on or in a document. Surely an automatically generated document needs to be authored by the computer that generated the document.

I have seen a presentation Dave Riley did at OSCON on the CONNECT project where I heard of a Redaction Service. I looked into this Redaction Service, and it turns out to be exactly that service that Keith and I are worried about. It claims to be able to automatically apply privacy rules to strip out sensitive content. I applaud the CONNECT project for trying, but I am very worried that the risks of this approach are not being made fully clear. These risks are no just Privacy risks, but clinical risks, safety risks, integrity risks, and other. I certainly hope that the resulting CDA document is authored by the CONNECT Redaction Service and does NOT indicate that it is authored by the original author. It is clearly a NEW document.