Thursday, August 11, 2011

IHE - Privacy and Security Profiles - Conclusion

IHE provides Security and Privacy Profiles to handle the interoperability needs. These profiles enable but do not address all of Security and Privacy. There is much more to Security and Privacy in  systems design and operational deployment

This table was introduced at the beginning. It summarizes how IHE Profiles address typical Security and Privacy Controls. IHE produces only Integration Profiles, so there is much more that is needed in system design and system deployment. Using Risk assessment in profile design, system design, and system deployment assures that the most important risks are addressed and that they are addressed with reasonable methods.

I ask a few simple questions in the Introduction:
  • Which profiles should we use to prevent the wrong people from looking at PHI? 
    • ATNA will prevent non authorized systems from communicating 
    • EUA, XUA, and PWP can be used to identify users and their roles 
    • BPPC can be used to identify patient specific privacy policies 
    • DEN shows how to encrypt at many levels and many transports 
    • Essentially almost all of the profiles play some part in preventing the wrong people from looking at PHI. 
  • Which profiles would you use in an investigation of a potential incident? 
    • ATNA includes an Audit Trail, with consistent timestamps synchronized 
    • EUA, XUA, and PWP are critical for identifying users 
    • These will not produce the investigation report, but they are the key components to having an audit log that is complete and longitudinal. 
  • Which profile would give you strong assurances that a document hasn't been modified? 
    • DSG gives strong assurance with Digital Signatures. 
    • PWP provides access to Public Digital Certificates for validation 
  • Which profiles would inform an accounting of disclosures 
    • ATNA includes an Audit Trail, with consistent timestamps synchronized 
    • EUA, XUA, and PWP are critical for identifying users 
    • An Accounting of Disclosures is a very special report that has many exclusions. This report is a complex report that could be based on some of the ATNA audit log, but likely needs to include entries for many other events. 
There is room for improvement, some identified projects that might happen in the future:
  • Better coded vocabulary for confidentiality codes. Codes that can better represent simple sensitivity data classifications. 
  • Enabling Patient Access while addressing sensitive health topics, emergency data sets, patient reported data, amendments and removal 
  • Complex Privacy ‘consent’ Policy capabilities to support inclusion lists, exclusion lists, exceptions, obligations and more 
  • Access Control as a service with independent Policy Information, Policy Decision Point and Policy Enforcement Points 
  • Accounting of Disclosures reports, alerts, messaging 
  • Environments such as Un-Safe Client machine (home-computer) 
At this time these are addressed with functional, non-functional, and environmental methods. The standards are not yet developed to support these in interoperability profiles, but the standards are being developed.

For more information
Back links
No comments:

IHE - Privacy and Security Profiles - Miscellaneous

There are other profiles, white papers, and governance that is important to Privacy and Security from the IHE perspective.

Personnel White Pages (PWP) and Healthcare Provider Directory (HPD) are covered by a different Webinar. These profiles are primarily focused on delivering attributes about Individual Healthcare Providers, Healthcare Provider Organizations, and the workforce inside a Healthcare Provider organization. These profiles are based on a widely deployed Directory standard used in all industries, LDAP v3, specializing them only where healthcare have special needs. These profiles can assist Security and Privacy through their ability to uniquely and positively identify an individual, provide attributes about an individual, and can be used to authenticate users.

A new profile under development is the Document Encryption (DEN) Supplement. This supplement contains a comprehensive analysis of encryption needs and identifies two gaps in existing Profiles. It then fills these gaps through creating a transport agnostic document encryption and adds encryption on XDM media.

IHE Governance that considers security during profile developmentIHE has instantiated a process to be used by all IHE domains when they develop new Profiles. This process utilizes risk assessment methodology to identify unique security and privacy risks that would need to be mitigated by the profile through some requirements or are identified to be addressed by system development or system deployment. The profile should include "Security Considerations" sections in Volume 1 that are profile wide, and in Volume 2/3 to cover technical requirements at the transaction level.

For example some profiles will recommend the use of the Audit Trail and Node Authentication (ATNA) profile, others will require it. Often times the profile will include specific instructions for accurately encoding the Audit Message.

IHE profiles that leverage De-Identification and Pseudonymization
IHE is developing a handbook that will instruct IHE profile writers that want to leverage De-Identificationa and/or Pseudonymization. These instructions leverage existing standards and existing knowledge, and set up a specific process to follow when developing a profile. There has not yet been a public comment on this paper.

Additional Comments

Back links
No comments:

Wednesday, August 10, 2011

IHE - Privacy and Security Profiles - Access Controls leveraging the Security/Privacy Profiles

Access Controls utilize Interoperability profiles but are implemented functionally. This is why one does not find an Access Control profile from IHE. It is not because it is not important, but rather the solution is functional code that leverages the security and privacy context information provided to it by existing Interoperabilty Profiles. IHE does provide a very comprehensive white paper on the topic of Access Controls and how they can be implemented.

Access Controls in environments like XDS and XCA would be federated, that is there would be multiple places where access is controlled that are distributed throughout the environment, and each leverages information from others and from trusted third parties. Access Controls use information from the 'security context', that is the context of the transaction. This context is also federated, not necessarily always centralized. Things in the security context are the user identity, their roles, the patient identity, the consents on file, metadata about the resource that is being accessed, and the reason for the access.
This diagram shows this security context broken down into three possible domains and maps how to get these security context values using IHE profiles. There is a circle of trust, federation, between these different domains of context.
  • Context Domain - information about the requesting environment 
  • Subject Domain - the user identity, roles, and purpose of the request 
  • Resource Domain - the 'thing' that is being requested and which patient it is about 
An important part of Access Control is to determine who has access to what kind of resources. This is often shown in a 'truth table'. There can be multiple of these tables, where the table that is used could be controlled by the consent that is acknowledged.

This table shows a Role-Based-Access-Control map that might represent what is allowed if the patient has chosen an OPT-IN Patient Privacy Policy. The Rows are made up of example “Functional Roles”, these are roles that any user could be assigned to based on their job classification. The Columns are examples of “Sensitivity” classifications, and the HL7 confidentialityCode is shown that might be used for each. In the table an X indicates that the specific Role would have access to the kind of data classified with that Sensitivity or confidentialityCode.

This is the same table as before, except this one shows what the table might look like if the Patient has chosen an OPT-OUT. In this case the table has an additional Permission that if a user holds this permission they are allowed to “break-glass” and if they do that then access would be allowed. This allowance for break-glass is common where patient safety is a concern (e.g Life and Limb is at risk).
Note that there are far fewer X marks, indicating that only the Direct Care Provider is allowed access.

This slide shows that IHE has not constrained where Access Controls are enforced, and have enabled that Access Controls can be enforced in many places.

A) This is the classic Access Control where the Requesting System (e.g. the system implementing the XDS Document Consumer) enforces all Access Controls. In this example the XDS Registry is only assuring that it is communicating with a system that it explicitly trusts (using ATNA Secure Communications). This assure that the XDS Registry is not accessed by rogue systems, but is only system level Authentication. This model is the most simple to build, especially if it is leveraging the Access Controls that might already be available in the Requesting System (e.g. EHR).

B) In this figure the Responding System (e.g XDS Registry) is enforcing the Access Controls. This is enabled by including the XUA identity assertion. This model can gain through having the Access Controls implemented in one place, thus saving on complexity and assuring consistency. This model however suffers in that it is much harder to handle use-cases where the context at the client is complex. Such as when there is a case that would normally be denied, but under emergency-mode would be authorized (i.e., Break-Glass).
C) The third figure is a more balanced environment. Where gross access controls are enforced at the Responding System (e.g. XDS Registry), and more fine-grained controls are enforced at the Requesting system (e.g. XDS Document Consumer)

It is often not recognized that in Healthcare, especially in cross-organizational transactions that the data communicated will be copied for future use. Thus what ever data is returned to the Requesting system (e.g. XDS Document Consumer) will likely be copied and thus future access control decisions to that copy are in the control of the Requesting system. Thus there is really an important consideration that the Requesting System have robust access controls.

Access Controls can actually take place in a trusted intermediary that is not a component of the Requesting or Responding system. This is a much more difficult system to deploy.

Additional Comments

Back links
This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:
No comments:

Tuesday, August 9, 2011

HIPAA Auditor Involved in PHI Breach

This story about a HIPAA Auditor loosing a USB Memory stick that had 4500 patient records on it leaves me with one HUGE question:

What on earth was the reason that the HIPAA Auditor gave for why they needed copies of patient records? I can't imagine any HIPAA regulation item that would need to be audited by taking a copy of patient records. This sounds like a rogue auditor, or a badly broken process.
No comments:

IHE - Privacy and Security Profiles - Basic Patient Privacy Consents

Across organizational boundaries it is sometimes important to have a way to express allowances or restrictions on healthcare data access because of the patients own wishes. There are cases where the allowed use-cases are so tightly constrained that a data-holder can completely make the decision to share or not and there is no need to communicate patient privacy policies, such as in the USA NwHIN-Exchange where the decision is made at the time of access, and a copy is completely transferred into the control of the requesting organization.

The need to include patient wishes in the access control decision is somewhat unique to healthcare, where there is a dual 'ownership' of the data. In most industries any information they have to share have simple one directional ownership, even if there are cases where a service is exposing intellectual property of others, the exposing organization obtains clear use of the data (e.g. images inside a mapping tool). In the case of healthcare information the patient has a stronger desire and need to control the information. This is related to the personal nature of the data, but also to the irrevocableness of the information. Once this information is exposed there is no way to revoke the information, such as there is with credit-card numbers.

IHE started this profile in May of 2006, but could find no standards available that met the complex need.  This is why the profile is clearly identified as "Basic", as we knew that this would not satisfy all use-cases, so we created the Basic Patient Privacy Consents profile. The profile can satisfy a few cases where the policies are simple; essentially pre-coordinated policies.
  • In a cross-enterprise or cross-community environment how are the Privacy Preferences of the Patient (Consumer) made known and thus enforced?
  • Consent is given and retracted
  • Consent in some environments is only for a specific time
  • There may be many consents relevant to different organizations or situations
  • Need to support Privacy Policies beyond consent, such as authorizing research access

Step 1: The first thing that must be done is that organizational policies must be written. That is there needs to be some policy domain that is agreed to that is inclusive of all the organizations participating in the Health Information Exchange. Within this space a set of policies need to be written in detail, e.g. Opt-In, Opt-Out-Fully, Opt-Out-Safe, No-Publish, etc. Not just titles, but exactly what do they mean. For example what is the impact of each of these on Role-Based-Access-Control, Emergency-Override, Chain-of-Command, Patient-Access, Regulatory-Controls, Workflows, etc. Don't forget to define what the rule is when no consent has been obtained. This is truly the hard part, and a part that needs to be done regardless of how capable the privacy consent system is.

Now that you have a set of policies that would be offered to the Patient to choose from, give them each a unique identifier (i.e., privacy-OID). Configure all access control engines to recognize what that privacy-OID means, that is to execute a specific set of access control rules. The mechanism will be unique to each implementation of access control engines. The future 'advanced' consents would support encoding the meaning in computable statements that can be read by the access control engine directly. In this future state the policies are not pre-coordinated, but post-coordinated. This future is still not here today. 

Step 2: This step is all about capturing each patient's consent. The actual human interaction with the patient is beyond an 'interoperability' profile, but some application or human needs to provide the different choices to the patient. This user interface is critical to success as the patient needs to be well informed but not overwhelmed. The patient will choose which of the choices they agree with, this is the 'acknowledgement' step. We use 'acknowledge' as some policies are explicitly denying access, so 'consent' is not descriptive. 

The BPPC profile indicates how to create a CDA document that includes the ACT by the patient of 'acknowledging' the specific privacy policy or policies. This new document is now a representation, token, that captures the act of agreement by the patient and the organization authoring the document. This CDA document can include, embedded inside, a PDF image such as an ink-on-paper signature by the patient. This CDA document could be digitally signed using the Document Digital Signature Profile. This CDA document could have limits placed on the timeframe of the consent, very useful in some regions where consent is only for an episode of care.

This CDA document is then published in the same way that clinical documents are published, it has some specific metadata values to make it easy to find and easy to understand (the natural reason for metadata). Some regional implementations have chosen to create two document sharing infrastructures, one that holds only BPPC consent documents; the other holds all the clinical documents. This is usually done to separate, segment, the control documents from the clinical documents. This separation can be easily done virtually through an administrative confidentialityCode 

Step 3: This step is about Enforcement by the members of the  Privacy Domain. As indicated in Step 1 above, each unique policy identifier is pre-configured in all access control enforcement engines.  Any one of these access control engines could be audited to show that they do indeed enforce the policy appropriately.  These access control policies could leverage profiles such as ATNA for system identity, XUA for user identity and purpose of use, and directory information about users for other attributes.  One specific purpose of use could be a privilege escalation request through the declaration that the user has invoked a break-glass functionality.

Due to the BPPC defined metadata for this CDA document that holds the consent acknowledgement, there are very simple queries for the XDS metadata that are all that is needed to determine which policies have been agreed to. There is no need to pull the copy of the CDA document. The Access Control engine simply needs to do an XDS/XCA query for BPPC type documents. If zero results are returned this indicates that there are no consents on file. For every result that does return, the startTime and stopTime indicate the validity time for that consent, thus allowing for episodic consents.  The resulting entries can be examined for the eventCodeList, the list of consent-OIDs that have been acknowledged. The Access Control engine just looks up these codes internally for the rules to apply (for example where the consent-OID is an XACML policy identifier).

Standards: The key standards are CDA, with optional inclusion of a Digital Signature, and/or Scanned Document (PDF). The intended environment is XDS, XDR, XDM, or XCA. It is also possible to use the BPPC Document in other ways, they are just not explained in the IHE profile.

BPPC has been further developed in HL7 as part of a Draft Standard for Trial Use on Consent templates using CDA. This Draft is a logical extension of BPPC, and the transition of an operational environment to these advanced CDA consent documents, when they are available, should be an easy transition.

Diagram showing a potential implementation of OPT-OUT: The logic shown is not mandatory, but is shown as illustrative of how this might be implemented using XUA in an XDS environment that enforces the BPPC consent, specifically OPT-OUT, in the Health Information Exchange. All accesses shown would also be protected and monitored by ATNA to assure that only trusted systems are involved and that all accesses to sensitive information is recorded in the security audit log.

  1. The user is authenticated, typically as part of their long-term session.
  2. At some point the system queries the HIE and includes a XUA assertion along with the XDS Query parameters
  3. An Access Control service intercepts the transaction and inspects the XUA assertion and XDS Query parameters
  4. The Access Control service looks for any OPT-OUT BPPC documents, If the patient has agreed to OPT-OUT; then the access control service responds with zero-results-found. 
  5. If there is no OPT-OUT, then the query is forwarded to the Document Registry that processes it normally
  6. And returns the normal results
It is possible that the return results could be further filtered based on the ROLE of the user, but that is not shown here. This is the topic of slides later on.

Although BPPC is 'Basic', it does enable communications of the patients agreement to simple pre-coordinated policies such as Opt-In and Opt-OUT. It can enable episodic consents that are time limited. It can be used to enable specific authorizations such as research projects, or clinical trials. It could be used to enable authorizations that are site specific, where the patient might authorize one organization to have access but not others. The profile is designed to be easily integrated into access control environments, yet be on the logical pathway to more advanced consent policy languages.

References:  
  • Status: Final Text
  • IHE ITI Technical Framework
    • Vol 1: Section 19
    • Vol 3: Section 5.1
  • Options added to other transactions
    • Vol 2a:  Section 3.18
    • Vol 2b: Section 3.32, 3.41, 3.42, 3.43
Additional Comments
  • Uses CDA to capture that the patient has agreed to a policy by reference
    • The policy is not actually ever described in the profile or the document, just referenced. This is because there is not sufficient maturity to any standard for encoding of privacy policies. Therefore BPPC assumes that someone can write the policy in human readable language and give that a unique identifier (OID). This OID is used as a reference.
  • Supports the consent being digitally signed with DSG
  • Supports encapsulation of a scanned image of something (e.g. an ink on paper signature) using the XDS-SD profile
  • Supports time limited consents
  • Supports both positive policies (OPT-IN) and negative (e.g. OPT-OUT)
  • Recognizes that the absence of an instance of a policy means that some other policy is in place. Commonly called 'implied consent'.
  • Defined for XDS, XDM, XDR, XCA - and may work for other environments
  • See Stepping stones for Privacy Consent, Data Objects and the Policies that Control them, Consent Management using HITSP TP30

Back links

No comments:

Friday, July 29, 2011

2nd Public Comment -- Cross-Enterprise Document Workflow

IHE IT Technical committee has resolved public comment on the first draft of the Cross-Enterprise Document Workflow profile, and have determined that the changes are dramatic enough to call for a 2nd Public Comment.

This is a key core profile that will enable other use-case specific workflows to happen across different organizational boundaries. It sets forward a basic workflow 'token' system by profiling OASIS WS-HumanTask (the original public comment used CDA). This profile does not define any working workflow, but rather sets a framework that others will use to support HIE based workflows like Patient Transfer, Referral, and many long-term care plans.

This does NOT replace departmental workflows, although it might leverage a departmental workflow as one of the larger steps that are managed by XDW. This does NOT replace centrally managed workflows such as those controlled by BPEL, but might leverage a BPEL controlled workflow as one of the larger steps that are managed by XDW.  The XDW workflow may refer to an externally defined and possibly not computable workflow definition, but is designed to support evolution to completely enclosed and/or computable workflows.






IHE IT Infrastructure Technical Framework Supplement Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following supplement to the IHE IT Infrastructure Technical Framework for Public Comment on July 29, 2011:

·         Cross-Enterprise Document Workflow - Rev. 2.0 (XDW)

The document is available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by August 26, 2011 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement.  Comments should be submitted at http://www.ihe.net/iti/iticomments.cfm 
No comments:

Thursday, July 21, 2011

GreenButton - a bad Marketing term for a good idea

I understand that a new concept was presented to ONC today called GreenButton (see twitter #GreenButton). I reacted strongly to the terse twitter posts (like there is anything other than terse on twitter). This exposed that GreenButton is simply an effort to enable the patient to choose to have their data available for research. ePatientDave posted a blog article.

I think the concept is fantastic. I think marketing it as 'greenbutton' is a bad idea. From the discussions I have seen this morning, the concept is simply to enable the patient to be active in pushing their data into research, studies, teaching-files, etc; without defining the standards that would be used to do this push. Where as BlueButton was both a patient empowering concept with a defined quasi-standardized file-format that was totally different than any open 'standard'.

I think that the greenbutton (wow, hard not to use the marketing term) would need to be an opportunity for the patient to choose which research projects will get their data AND if their data needed to be de-identified. I suspect they will almost always want their data de-identified, and this is why I want the patient to choose each research project. Because successful de-identification can only be done when the context of the research needs are understood.

When the push method is a Health Information Exchange, one could use the existing standards for consent to 'authorize research project X'. The act of the patient 'pushing' the greenbutton will need to be captured as an 'authorization' anyway. The standards we have been working on for Consent are not just for 'Consent' as we know it in the USA, but rather are broad enough to handle any privacy policy (with some stepping stone restrictions).

I like the concept, lets figure out how to make it happen. There is lots of actual work necessary to see it through. In many cases research is being done, without empowering the patient. Some providers are already empowering their patients. Most PHR services enable this kind of thing. I am a 23andMe participant and very much participate in the 23andWe effort. So, there is experimental efforts. Given time these experiments will shakeout the bugs/issues into solutions.
No comments:
Subscribe to: Posts (Atom)