If only they could provide the recipe, rather than simply ranting about what it should smell and look like. I am in no way saying that this recipe is an easy thing to produce. In Stepping stones for Privacy Consent, I am actually saying that we need to get going trying a bunch of recipes to see if any of them will work. There are Health Information Exchanges out there that are trying. I just don't think that there is much in the way of lessons to learn yet. This might take a while to determine what really works vs what sounds good in theory.
I like that the Tiger team is starting with the HHS white paper on Consumer Consent Options. This paper is really well written, and does face some reality around priorities. The first instrument should be a blunt one: Opt-In, and Opt-Out. For special cases simply don't publish THAT! . Not a very elegant tool, but for those willing to take the risk, they get the reward of the benefits that a HIE offers. For those not willing, they get to stay out. Then encourage creativity.
Accountability using Audit Controls is critical to success. We must know what happens with the information regardless of the consent rules.
I encourage anyone to let me know if they know of a HIE that has any form of consent, including simple OPT-IN or simple OPT-OUT. I would be very glad to share best practices.
Sunday, October 31, 2010
Obama Administration Receives Harsh Reviews in 2010 Report Card
The Electronic Privacy Information Center (the other EPIC) has graded the Obama Administration harshly this year. It could be viewed that they were simply too generous last year, when we were told how wonderful things would be. I do agree that this year I am less excited about the Privacy policies of the Obama Administration and those promulgated by the Obama Administration. But then I also am close enough to the sausage making to know why things are not as rosy as we all would want them to be.
I have asked for more specific security to be included in Meaningful Use (that Meaningful Use Security Capabilities are Lacking, Privacy Capabilities NON-existent), and for them to include even simple Opt-In/Opt-Out capability (Stepping stones for Privacy Consent). I know that these are not included today because of a need to push the market space slowly. I however am very concerned that an HIE built with out privacy controls, may never get them. The Consent Management using HITSP TP30 is not a difficult to implement system, and it is designed to grow to more comprehensive consent policies.
I do think that this past year far more has been done about Privacy in Healthcare than all the past decade. There is far more visibility of the issue, and privacy advocates and subject matter experts are far more common. A huge step in the right direction was the posting of USA healthcare breach notifications.
Now that there is a way to publicly shame organizations, we are seeing more interest in implementation of Security and Privacy.
I have asked for more specific security to be included in Meaningful Use (that Meaningful Use Security Capabilities are Lacking, Privacy Capabilities NON-existent), and for them to include even simple Opt-In/Opt-Out capability (Stepping stones for Privacy Consent). I know that these are not included today because of a need to push the market space slowly. I however am very concerned that an HIE built with out privacy controls, may never get them. The Consent Management using HITSP TP30 is not a difficult to implement system, and it is designed to grow to more comprehensive consent policies.
I do think that this past year far more has been done about Privacy in Healthcare than all the past decade. There is far more visibility of the issue, and privacy advocates and subject matter experts are far more common. A huge step in the right direction was the posting of USA healthcare breach notifications.
Now that there is a way to publicly shame organizations, we are seeing more interest in implementation of Security and Privacy.
In a special event as part of the Privacy 2010 Campaign, the ElectronicPrivacy Information Center (EPIC) has released the 2010 Privacy ReportCard for the Obama Administration. The Report Card focuses ondevelopments over the past year in the areas of medical privacy, civilliberties, consumer protection, and cyber-security.
The report card was formerly unveiled at the Mott House, on CapitalHill. EPIC's executive director, Marc Rotenberg, briefly discussed thegrades from 2009 and the rationale for the new marks. 2010 gradesinclude two B's (medical privacy and cyber-security), a C (consumerprivacy), and a D (civil liberties). These were significant drops from2009, when the Administration received an Incomplete (consumerprivacy), an A- (medical privacy), a B (cyber-security), and a C+ (civilliberties).
EPIC: Privacy 2010 Campaign Platform
EPIC: Privacy 2010 Facebook Cause Page
EPIC: 2009 Privacy Report Card
EPIC: 2010 Privacy Report Card
Roundtable: Personal Health Records Understanding the Evolving Landscape
This Rountable in December just passed my desk. The PHR can be a very valuable tool for those that want to use them. I think we need to always keep them in the picture.
Among the great healthcare advantages of a PHR, there is a push of a story where Patients with privacy concerns can choose to not participate in Health Information Exchanges, while still providing access to their data. My concern with this is that there are a small number of people that can pull this off. Most will fumble around like they do with facebook today. There are a large number of consumers that are simply not good at protecting themselves. This does NOT reflect on their desire, they want to do the right thing. But the Internet is a difficult thing. There is a large number of individuals that are still not using the internet today, and this population needs the most healthcare and most urgently.
That said, I think a PHR is a powerful tool that MUST be considered when we look at Meaningful Use, Health Information Exchanges, and the improvement of Healthcare. I have spoken about this in the past Re: Personal Health Records May Not Be So Personal and Personal health records most likely to be used when doctors recommend them. There are a few more notes on how a PHR can and should be considered a full member on a Health Information Exchange (HIE). I hope to participate in this roundtable, but at this point only web participation is available.
Among the great healthcare advantages of a PHR, there is a push of a story where Patients with privacy concerns can choose to not participate in Health Information Exchanges, while still providing access to their data. My concern with this is that there are a small number of people that can pull this off. Most will fumble around like they do with facebook today. There are a large number of consumers that are simply not good at protecting themselves. This does NOT reflect on their desire, they want to do the right thing. But the Internet is a difficult thing. There is a large number of individuals that are still not using the internet today, and this population needs the most healthcare and most urgently.
That said, I think a PHR is a powerful tool that MUST be considered when we look at Meaningful Use, Health Information Exchanges, and the improvement of Healthcare. I have spoken about this in the past Re: Personal Health Records May Not Be So Personal and Personal health records most likely to be used when doctors recommend them. There are a few more notes on how a PHR can and should be considered a full member on a Health Information Exchange (HIE). I hope to participate in this roundtable, but at this point only web participation is available.
The Office of National Coordinator for Health Information Technology (ONC) will host a free day-long public Roundtable on "Personal Health Records — Understanding the Evolving Landscape." The Roundtable is designed to inform ONC’s Congressionally mandated report on privacy and security requirements for non-Covered Entities (non-CEs), with a focus on personal health records (PHRs) and related service providers (Section 13424 of the HITECH Act).
The Roundtable will include four panels of prominent researchers, legal scholars, and representatives of consumer, patient, and industry organizations. It will address the current state and evolving nature of PHRs and related technologies (including mobile technologies and social networking), consumer and industry expectations and attitudes toward privacy and security practices, and the pros and cons of different approaches to the requirements that should apply to non-CE PHRs and related technologies.
Public comment will open at the beginning of November.
Friday, October 29, 2010
Directed Exchange vs Publish/Discover Exchange
The NHIN-Direct Project - now trying to re-brand to "The Direct Project" - is addressing the use-cases where the very small healthcare clinic that has little or no current Healthcare IT technology can take some initial steps into the Healthcare IT world. This project has now released a formal "Overview" document. Given that I was a contributor to this document, I think it is a good document. This document is a really good introduction, it is not a technical document, specification, or deployment guide. These other topics will be produced over the coming months.
A Directed Exchange (NHIN-Direct) is a useful model and will continue to be a useful model. A Directed Exchange model will not take the place of a Publish/Discover model, primarily because a Directed Exchange (aka Push) model does not work for many use-cases. Directed Exchange only works where the data holder knows that an individual needs information and knows fully what information they need. The receiver generally does not know that they need this information before the sender decides to send it, yes there are exceptions. The sender must pick and choose the specific receivers, they can’t broadcast.
The Directed Exchange, especially the NHIN-Direct specification, are good starting points as they are more simple. They are more simple in the technology given that they are simple point-to-point conversations. They are more simple in the security model, because they are simple point-to-point conversations. They are more simple from a privacy model, because they are simple point-to-point conversations. This means that much of the complexity that is necessary in a Publish/Discover Exchange are not needed. For example: the network infrastructure, policies, operational environment, auditing, authorization, encryption, and consent. See: NHIN-Direct Privacy and Security Simplifying Assumptions
The kind of use-cases for a Publish/Discover Exchange are those where the data user (or hopefully their system automatically in the background) discovers historic information, determines how relevant it is based on metadata, pulls the relevant information, decomposes it into the super-relevant information, and provides all of this at the time of need. These use-cases do require some rich metadata, which is why XDS includes such rich metadata. Some Examples of use-cases where a Directed Exchange doesn’t work (or works less effectively):
The Directed Exchange and the Publish/Discover Exchange are not mutually exclusive. I fully expect some day that all data will be published, but a Directed Exchange will be used to push what the sender thinks are the most critical information along with a work-order (Referral, etc). In this case the receiver can verify that they could have pulled the documents as all documents have globally unique IDs, but they also have access to other historic data. The data user can discover new versions of the document, transforms of the document, related documents, and grouped documents. This combination of the richness of the Publish/Discover Exchange with the directeness of a Directed Exchange work well together. There are strong parallels of this combination in the FAX and HL7 messaging environments.
A Directed Exchange (NHIN-Direct) is a useful model and will continue to be a useful model. A Directed Exchange model will not take the place of a Publish/Discover model, primarily because a Directed Exchange (aka Push) model does not work for many use-cases. Directed Exchange only works where the data holder knows that an individual needs information and knows fully what information they need. The receiver generally does not know that they need this information before the sender decides to send it, yes there are exceptions. The sender must pick and choose the specific receivers, they can’t broadcast.
The Directed Exchange, especially the NHIN-Direct specification, are good starting points as they are more simple. They are more simple in the technology given that they are simple point-to-point conversations. They are more simple in the security model, because they are simple point-to-point conversations. They are more simple from a privacy model, because they are simple point-to-point conversations. This means that much of the complexity that is necessary in a Publish/Discover Exchange are not needed. For example: the network infrastructure, policies, operational environment, auditing, authorization, encryption, and consent. See: NHIN-Direct Privacy and Security Simplifying Assumptions
The kind of use-cases for a Publish/Discover Exchange are those where the data user (or hopefully their system automatically in the background) discovers historic information, determines how relevant it is based on metadata, pulls the relevant information, decomposes it into the super-relevant information, and provides all of this at the time of need. These use-cases do require some rich metadata, which is why XDS includes such rich metadata. Some Examples of use-cases where a Directed Exchange doesn’t work (or works less effectively):
- Onset of a new condition, where some prior conditions may be relevant
- Open Referral, where the patient is allowed to choose the specialist
- Highly mobile patient
- Emergency
- Patient with many medical conditions
- Patient with complex condition
- (Surely there are more)
The Directed Exchange and the Publish/Discover Exchange are not mutually exclusive. I fully expect some day that all data will be published, but a Directed Exchange will be used to push what the sender thinks are the most critical information along with a work-order (Referral, etc). In this case the receiver can verify that they could have pulled the documents as all documents have globally unique IDs, but they also have access to other historic data. The data user can discover new versions of the document, transforms of the document, related documents, and grouped documents. This combination of the richness of the Publish/Discover Exchange with the directeness of a Directed Exchange work well together. There are strong parallels of this combination in the FAX and HL7 messaging environments.
HHS to Host Regional Meeting in Los Angeles as Part of Psychotherapy Notes and Testing Data Study under the HITECH Act
The Data Types that fall under SAMHSA are those considered the most sensitive, and thus the ones that patients may want to control with a finer tool than simple opt-in and opt-out. This data is also more complex to understand exactly when an object contains hints of these topics. Thus making the labeling of confidentialityCode very complex. As I outline in Data Classification - a key vector enabling rich Security and Privacy controls, the publisher of any objects is most likely to know if these sensitive topics are contained within, so they can label the object as "Restricted". But this label does not give any help to the Access Control engine on who should be allowed access.
The harder part is determining who needs-to-know when a access control decision needs to be made. One initial attempt at a solution resulted in a set of confidentialityCodes for each different type of data within this Restricted Classification. I don't think this is a good idea. The metadata that carries the confidentialityCode is Protected Information (aka PHI), but once the restricted information leaks into this metadata then all metadata must be protected at the level of Restricted. This results in a spiral of information that can't be available. We need a better solution.
Right now I don't know what this better solution is, but do have a few ideas. I look forward to opportunities to have strong discussions on this topic. I however likely can't make this meeting.
October 15, 2010
The Substance Abuse and Mental Health Services Administration (SAMHSA) is conducting a Confidentiality and Privacy Issues Related to Psychological Testing Data study, in close cooperation with the Office for Civil Rights (OCR) pursuant to section 13424 of the Health Information Technology for Economic and Clinical Health (HITECH) Act, a component of the American Recovery and Reinvestment Act (ARRA) (P.L. 111-5). This study is addressing whether the HIPAA Privacy Rule’s special protections relating to the use and disclosure of psychotherapy notes should also be applied to “test data that is related to direct responses, scores, items, forms, protocols, manuals or other materials that are part of a mental health evaluation.”
As part of this study, SAMHSA is hosting public meetings to bring together professionals in the areas of mental health and privacy protection to discuss current practices and the policy implications surrounding this very important issue. The next regional public meeting will be held at the Sheraton Los Angeles Gateway Hotel in Los Angeles, California on November 18, 2010. The details of this meeting, as well as the project staff contact information.
The significant concepts and issues being addressed in this project include:
- What activities and information are considered the “test data” that is part of a mental health evaluation? What are the relevant distinctions among test materials, raw data, and reports or assessments with respect to the level of protection currently afforded and/or otherwise necessary?
- Does the individual (i.e., the subject of the test data) need to know, or have an interest in, inspecting or obtaining a copy of such information?
- Are there circumstances under which test data should be disclosed to third parties? Should the individual’s authorization be required prior to such a disclosure? To whom should test data be released?
- How would affording mental health test data a higher level of protection affect the workflow in medical, behavioral health, or psychological practices? Are there any additional implications with respect to clinical integration efforts and the increasing availability of mental health services in general health care settings?
- How is the issue of greater protection for test data affected by State and Federal laws other than HIPAA?
- In light of the increasing reliance on electronic health records and the exchange of electronic health data, what are the implications of setting more stringent requirements for the use and disclosure of test data?
Monday, October 25, 2010
User requirements vs System requirements
Much of the confusion around specific criteria in the MU certification are due to poor engineering principles. The level of the requirements in the regulation are not all the same, more specifically they are not all traceable to User Requirements.
Engineering Science teaches us that good design starts with "User Requirements". These are requirements that the user 'wants' or would 'ask for'. User Requirements are those that can be observed from outside the system. These are requirements that drive the system to some functionality or outcome. These are not criteria that define a specific architecture or specific design. Yes they have some low level detail regarding interoperability (format, vocabulary, etc). But Interoperability also doesn't define an architecture or specific design.
Note that User in this does not necessairly mean only the 'healthcare provider'. This is often a mistake that produce designers also forget. Users in this level of design is anyone that expects something of the system. This includes the IT-Staff who need to keep the system up-and-running; Privacy office that needs to rely on this system to enforce privacy policy and report on potential privacy issues; Security office that needs this system to protect against risks to confidentiality, integrity, and availability; etc. For Meaningful Use the "User" is also the government reporting agencies that want to get reports on outcomes and quality.
Requirements must be testable. That is that they are fully defined in a way that can be unambiguously tested. This means that they are not vague, often seen as things that "I know it when I see it". If the requirements are written such that they are dependent on a human judgement; then they are not requirements.
Where Meaningful Use goes wrong on the security requirements is that they are not traceable up to a User Requirement. I will only speak for the security requirements, there might be other examples. It is this lack of linkage that gets people frustrated at trying to figure out what is really needed. The security requirements are good system requirements, and they are testable. Although the security requirements are good, they are not inclusive or complete.
The result is that the EHR vendors will design to these System Level requirements with no regard for how the User will use the system. They will pass the test, but provide no linkage to a user need and thus produce useless functionality.
All of the Meaningful Use requirements need to be specified at the User Level. Security is very easy to add as a User Requirement. "System shall protect against reasonable risks to Confidentiality, Integrity and Availability". One can even get more specific to the user as Privacy Officer, Security Officer, IT-staff, etc. None of this was done. There was discussion in committees that HIPAA already requires security, but what is not obvious is that HIPAA requires the operational environment to be secure, not necessarily the EHR. So, basic requirements would have closed this loop and made things more clear and smooth. There is even a really nice breakdown of general security into reusable system requirements: NIST SP 800-53 “Recommended Security Controls for Federal Information Systems and Organizations” (http://csrc.nist.gov/publications/PubsSPs.html).
One can have User Requirements that are very close to the Meaningful Use requirements; but differ in that they are related to a user need. For example a better way to express §170.302 (u) would have been: "When data sets are exported for portable use, the system shall provide a user selectable, standards based and interoperable functionality that protects the data set against risks to security and privacy." This does presume that the system protects data sufficiently while it is within it's control, a presumption that should be explicit with the general security requirement.
Engineering Science teaches us that good design starts with "User Requirements". These are requirements that the user 'wants' or would 'ask for'. User Requirements are those that can be observed from outside the system. These are requirements that drive the system to some functionality or outcome. These are not criteria that define a specific architecture or specific design. Yes they have some low level detail regarding interoperability (format, vocabulary, etc). But Interoperability also doesn't define an architecture or specific design.
Note that User in this does not necessairly mean only the 'healthcare provider'. This is often a mistake that produce designers also forget. Users in this level of design is anyone that expects something of the system. This includes the IT-Staff who need to keep the system up-and-running; Privacy office that needs to rely on this system to enforce privacy policy and report on potential privacy issues; Security office that needs this system to protect against risks to confidentiality, integrity, and availability; etc. For Meaningful Use the "User" is also the government reporting agencies that want to get reports on outcomes and quality.
Requirements must be testable. That is that they are fully defined in a way that can be unambiguously tested. This means that they are not vague, often seen as things that "I know it when I see it". If the requirements are written such that they are dependent on a human judgement; then they are not requirements.
Where Meaningful Use goes wrong on the security requirements is that they are not traceable up to a User Requirement. I will only speak for the security requirements, there might be other examples. It is this lack of linkage that gets people frustrated at trying to figure out what is really needed. The security requirements are good system requirements, and they are testable. Although the security requirements are good, they are not inclusive or complete.
The result is that the EHR vendors will design to these System Level requirements with no regard for how the User will use the system. They will pass the test, but provide no linkage to a user need and thus produce useless functionality.
All of the Meaningful Use requirements need to be specified at the User Level. Security is very easy to add as a User Requirement. "System shall protect against reasonable risks to Confidentiality, Integrity and Availability". One can even get more specific to the user as Privacy Officer, Security Officer, IT-staff, etc. None of this was done. There was discussion in committees that HIPAA already requires security, but what is not obvious is that HIPAA requires the operational environment to be secure, not necessarily the EHR. So, basic requirements would have closed this loop and made things more clear and smooth. There is even a really nice breakdown of general security into reusable system requirements: NIST SP 800-53 “Recommended Security Controls for Federal Information Systems and Organizations” (http://csrc.nist.gov/publications/PubsSPs.html).
One can have User Requirements that are very close to the Meaningful Use requirements; but differ in that they are related to a user need. For example a better way to express §170.302 (u) would have been: "When data sets are exported for portable use, the system shall provide a user selectable, standards based and interoperable functionality that protects the data set against risks to security and privacy." This does presume that the system protects data sufficiently while it is within it's control, a presumption that should be explicit with the general security requirement.
Friday, October 22, 2010
Consent Management using HITSP TP30
I was asked to present today the HITSP TP30 solution to the "Upper Midwest HIE" committee of ONC's State Health Policy Consortium. I was invited to speak with a recommendation from my HITSP "Security/Privacy/Infrastructure Workgroup" co-chair Walter Suarez. Walter also helped me by providing some of the slides.
HITSP TP30 is the construct that HITSP put together to capture and manage "consent".
I was asked to cover:
The presentation was about TP30, but I also did cover some of the work that has happened since and some of the work still ongoing. I could have use the HITSP Powerpoint template, but given that project is closed it didn't feel right. So I removed all background template. I am sure I will get a chance to further enhance them.
The Presentation is available in Powerpoint (PPTX) format
I am very proud of the committees that I have participated in to produce this solution. I excited to work through the gaps that continue to exist. We are not done, but we do have a good framework to get Health Information Exchanges going.
References
I had done a presentation on BPPC to the HIT Security committee in April. During that presentation I touch on all the aspects of TP30. The presentation and audio recording of that testimony is available:
In May there was further testimony to the HIT Standards committee on the current HL7 standards developments that have advanced the base standard. This testimony was given by Ioana, a member of the HL7 committee and major contributor to the work. This standards development is still underway. It does give a view of where the standards developments are:
Some other articles on my blog that might be informative.
HITSP TP30 is the construct that HITSP put together to capture and manage "consent".
The Manage Consent Directives Transaction Package describes the messages needed to capture, manage, and communicate rights granted or withheld by a consumer to one or more identified entities in a defined role to access, collect, use, or disclose Individually Identifiable Health Information (IIHI), and also supports the delegation of the patients right to consent.
I was asked to cover:
- Explain the basic functionality of the TP30. What information does it have the capacity to send?
- What are the business flow challenges to implementing the TP30?
- What is the current status of the TP30 in the e-health world? (For example: IHE Profile, NHIN, etc. Is TP30 under consideration for future inclusion in the certification standards?)
The presentation was about TP30, but I also did cover some of the work that has happened since and some of the work still ongoing. I could have use the HITSP Powerpoint template, but given that project is closed it didn't feel right. So I removed all background template. I am sure I will get a chance to further enhance them.
The Presentation is available in Powerpoint (PPTX) format
I am very proud of the committees that I have participated in to produce this solution. I excited to work through the gaps that continue to exist. We are not done, but we do have a good framework to get Health Information Exchanges going.
References
I had done a presentation on BPPC to the HIT Security committee in April. During that presentation I touch on all the aspects of TP30. The presentation and audio recording of that testimony is available:
In May there was further testimony to the HIT Standards committee on the current HL7 standards developments that have advanced the base standard. This testimony was given by Ioana, a member of the HL7 committee and major contributor to the work. This standards development is still underway. It does give a view of where the standards developments are:
Some other articles on my blog that might be informative.
- Designing a Secure HIE
- Stepping stones for Privacy Consent
- Consumer Preferences and the Consumer
- Redaction and Clinical Documentation
- Availability of Consent Documents and their rules
- The meaning of Opt-Out,
- Opt-In, Opt-Out.... Don't publish THAT!,
- Consent standards are not just for consent,
- Consumer Preferences and the Consumer,
- RHIO: 100,000 Give Consent.
- Accountability
- Data Classification
Thursday, October 21, 2010
IHE IT Infrastructure Planning Committee - Candidate Proposals Selected for 2010/2011 Development Cycle
The IHE process starts with the Planning committee evaluating "Proposals". This year the ITI committee had only a few proposals to choose from, so they choose to simply priortize the list. It is now up to the Technical committee to evaluate how hard each one is, including evaluating if it is even feasable. This will happen in December, and will likely result in a smaller list of work items.
The resulting PRIORITY order:
Here is the letter from IHE:
The resulting PRIORITY order:
1 XDS Link/Unlink Support
2 Cross-Enterprise Document Workflow (XDW)
3 XCA Query & Retrieve Caumanns
4 XD* Minimal Metadata
5 (tie) CDA Encryption
5 (tie) Document Sharing Directory Service
7 Pseudonymisation and De-Identification in IHE Profiles (Handbook)
Here is the letter from IHE:
It is our pleasure to announce that the IT Infrastructure Planning Committee has selected profile/white paper candidates for the upcoming ITI development cycle. At this week’s face-to-face meeting in Oak Brook IL, the committee reviewed all proposals and ranked them in priority sequence according to pre-defined criteria. This ranking, together with detailed proposals currently being prepared by the authors (and due November 10, 2010), will serve as input for the consideration of the ITI Technical Committee which meets next month in Arlington, VA.
The Planning Committee also reviewed a number of strategic issues, including an update of domain liaison activities and a schedule of upcoming meetings. Meeting notes will be published on the Wiki shortly… watch for the announcement.
The next step in the process will be a face-to-face Technical Committee meeting, held November 18-19 2010 in Arlington VA, to review of the candidate proposals and recommend which work items will be undertaken in 2010/2011. The Planning Committee will join the meeting on November 19th (after lunch, Eastern time) to vote on these recommendations. You are invited and encouraged to participate, and details can be found at this link. More information will be provided shortly from the TC co-Chairs.
We look forward to a very exciting year of ITI activity, and encourage your broad participation and support of our work item authors.
Thanks to those who attended the PC face-to-face meeting. We had over 20 participants, representing 7 countries!
See you next month in Arlington!
Karen WittingMike NusbaumCo-Chairs
Tuesday, October 19, 2010
Meaningful Use Encryption - passing the tests
Updated August 2014 -- This article seems to be popular for some reason, well beyond the usefulness it brought back in 2010. Please refer to the MU topic, or Secure Communications topic for fresh information.
Wednesday, October 13, 2010
Healthcare Provider Directories -- Lets be Careful
The HIT Policy committee heard testimony a few weeks back on the topic of Healthcare Provider Directories. The committee has already put together an impressive discussion of Healthcare Provider Directories and have a set of questions that they are asking different subject matter experts.
I was asked to testify, but was out at corporate training. I highly recommended the two individuals that were the main driving force behind the IHE Healthcare Provider Directory Profile. There was so much good work done by this committee of IHE, and so much more that could be done. The committe decided to have Keith Boone fill my slot Provider Directories. He did an excellent job of filling this slot.
Generally this HIT Policy initiative needs to be coordinated with National initiatives such as the WhiteHouse “National Strategy for Identities in Cyberspace”. This initiative starts out seeming like it is just politics, but if you read the whole thing they do understand the need and are starting to peel the onion. There is also PKI initiatives like: the Federal PKI, Kantara, and others.
On the technology choices, I would be recommending we re-use technology that other industries use and not create special technology just for healthcare. So lets use LDAP technology which has strong support, tools, knowledge, flexibility, and power. It also has many interfaces besides the classic LDAP. I would recommend against the use of HL7 for this use, although this certainly is a useful schema and vocabulary; the technology is specific to healthcare and is not as widely supported or used.
The Use-cases are not clear, and need to be made more clear. It is clear to me why we are investigating Healthcare Directories, but we need to be very careful. Most of the use-cases that I see would be handled just fine without the need for any standards. There will be a functional directory offered that is web-based. I am not convinced that we need an Interoperability specification at the Nationwide level. We don’t have one for Internet e-mail or Phones today. They are all working just nicely on social mechanisms with backing from general web interfaces. Why would any provider want to publish their contact information to a directory that everyone in the world can discover. If it is no open for anonymous reads, then what is the authorization path?
Related to this is the issues of abuse. Once a directory exists it will be abused. The more available the information, the more abuse it will draw. (eg. SPAM). There are people that think we need to have “Universal Addressability” in the provider space. I don’t disagree with universal addressability, but there are efforts to define this as universal discoverability of your address and your credentials. Thus a malicious user can discover my email address and send me encrypted SPAM.
The negative risks that are created by the solution need to be considered in addition to the positive functionality of providing the solution.. Hence why there is no universal discoverability in internet email and phone numbers today…. And where phone numbers can be guessed, there is now a do-not-call list.
Provider Directories will be a key enabler of nationwide health information exchange. The IE WG has been asked to investigate and make recommendations to facilitate creation of provider directories that enable universal health information exchange across the country. As part of its fact-gathering process, the IE WG will host a public hearing on September 30, 2010, in Washington DC, to hear testimony from a variety of prospective users and industry experts on: 1) obstacles to health information exchange; 2) the role that provider directories could play in addressing such obstacles; 3) the types of directories that exist in the market today; and 4) options for building a directory approach that meets the emerging health information exchange needs of health care providers. More
I was asked to testify, but was out at corporate training. I highly recommended the two individuals that were the main driving force behind the IHE Healthcare Provider Directory Profile. There was so much good work done by this committee of IHE, and so much more that could be done. The committe decided to have Keith Boone fill my slot Provider Directories. He did an excellent job of filling this slot.
Generally this HIT Policy initiative needs to be coordinated with National initiatives such as the WhiteHouse “National Strategy for Identities in Cyberspace”. This initiative starts out seeming like it is just politics, but if you read the whole thing they do understand the need and are starting to peel the onion. There is also PKI initiatives like: the Federal PKI, Kantara, and others.
On the technology choices, I would be recommending we re-use technology that other industries use and not create special technology just for healthcare. So lets use LDAP technology which has strong support, tools, knowledge, flexibility, and power. It also has many interfaces besides the classic LDAP. I would recommend against the use of HL7 for this use, although this certainly is a useful schema and vocabulary; the technology is specific to healthcare and is not as widely supported or used.
The Use-cases are not clear, and need to be made more clear. It is clear to me why we are investigating Healthcare Directories, but we need to be very careful. Most of the use-cases that I see would be handled just fine without the need for any standards. There will be a functional directory offered that is web-based. I am not convinced that we need an Interoperability specification at the Nationwide level. We don’t have one for Internet e-mail or Phones today. They are all working just nicely on social mechanisms with backing from general web interfaces. Why would any provider want to publish their contact information to a directory that everyone in the world can discover. If it is no open for anonymous reads, then what is the authorization path?
Related to this is the issues of abuse. Once a directory exists it will be abused. The more available the information, the more abuse it will draw. (eg. SPAM). There are people that think we need to have “Universal Addressability” in the provider space. I don’t disagree with universal addressability, but there are efforts to define this as universal discoverability of your address and your credentials. Thus a malicious user can discover my email address and send me encrypted SPAM.
The negative risks that are created by the solution need to be considered in addition to the positive functionality of providing the solution.. Hence why there is no universal discoverability in internet email and phone numbers today…. And where phone numbers can be guessed, there is now a do-not-call list.
Tuesday, October 12, 2010
HL7 Tutorial on Security Considerations Cookbook at Boston
The Tutorial on HL7 Security Cookbook at Boston HL7 meeting went really well. See the link for a description of the Tutorial.
I had the additional assistance of Diana, who covered the deep details of 'risk'. She is one of the co-authors of the white paper and the presentation. A clear expert in executing risk assessments on system administration and operational environments.
We had 10 excellent students from various places around the globe and various levels of experience. I didn't look at all the evaluations but those that I did look at were very positive on the subject matter and had good material for us to help improve the tutorial and process. One clear message is that the HL7 Security workgroup needs to create some outreach material that provides a general overview of Security in HL7.
The layout of the tutorial covers two 'quarters':
1) Introduction to the process - Whole Presentation top-to-bottom
- Break
3) Review the risk assessments from the pilot projects (CDA-Consent, and PASS-Audit)
4) Execute the risk assessment process on a class-suggested standard
We do have an updated risk assessment templates (V3), and updated Presentation now available on the HL7 Wiki Cookbook for Security Considerations landing page. You can also find the risk assessments spreadsheets from the CDA-Consent and PASS-Audit projects that were used as a pilot. These pilots showed that the process can be executed and produce reasonable results. The process took about 3 separate 1 hour telephone conference calls.
This Tutorial has been asked for by the Australia HL7 for presentation in Australia in January. I will not be traveling to Australia so I hope we can find someone willing and able to give the Tutorial.
The Risk Assessment Cookbook process is moving into a new phase in HL7. We have been asked to ballot this to a wider audience. I am working with the HL7 leadership to determine how this will be done. Given that it is a process that we want everyone to follow and not a 'standard'; I am unclear on how to use the normal HL7 ballot process. I suspect I will be learning much more about the sausage-maker that is HL7. I welcome this chance to get more input on the process, especially if it gets us closer to creating HL7 standards that have Security Considerations.
I had the additional assistance of Diana, who covered the deep details of 'risk'. She is one of the co-authors of the white paper and the presentation. A clear expert in executing risk assessments on system administration and operational environments.
We had 10 excellent students from various places around the globe and various levels of experience. I didn't look at all the evaluations but those that I did look at were very positive on the subject matter and had good material for us to help improve the tutorial and process. One clear message is that the HL7 Security workgroup needs to create some outreach material that provides a general overview of Security in HL7.
The layout of the tutorial covers two 'quarters':
1) Introduction to the process - Whole Presentation top-to-bottom
- Break
3) Review the risk assessments from the pilot projects (CDA-Consent, and PASS-Audit)
4) Execute the risk assessment process on a class-suggested standard
We do have an updated risk assessment templates (V3), and updated Presentation now available on the HL7 Wiki Cookbook for Security Considerations landing page. You can also find the risk assessments spreadsheets from the CDA-Consent and PASS-Audit projects that were used as a pilot. These pilots showed that the process can be executed and produce reasonable results. The process took about 3 separate 1 hour telephone conference calls.
This Tutorial has been asked for by the Australia HL7 for presentation in Australia in January. I will not be traveling to Australia so I hope we can find someone willing and able to give the Tutorial.
The Risk Assessment Cookbook process is moving into a new phase in HL7. We have been asked to ballot this to a wider audience. I am working with the HL7 leadership to determine how this will be done. Given that it is a process that we want everyone to follow and not a 'standard'; I am unclear on how to use the normal HL7 ballot process. I suspect I will be learning much more about the sausage-maker that is HL7. I welcome this chance to get more input on the process, especially if it gets us closer to creating HL7 standards that have Security Considerations.
Subscribe to:
Posts (Atom)