Monday, August 15, 2011

One Metadata Model - Many Deployment Architectures

There is a now an Advanced Notice of Proposed Rule Making out asking about Metadata Standards for Healthcare Information Exchange. This is a good thing to be thinking about as we look at exchanging health information beyond the use of the Direct Project. There are many reasons why one might want Metadata, and it is important that each reason be fully understood.

  • Object Identification - how is the object being described identified and managed, what is it a replacement for, what replaces it, what is it a transform of, what does it transform.
  • Subject Identification - who is the object describing. The patient identity is a touchy topic, but in order to use the data for treatment we must be able to identify the human subject that is described. When the data is not used for treatment we should be aware of how to modify this value through blocking, fuzzing, or pseudonym. 
  • Object Lifecycle - From where did this object originate? Who is the author? Who is managing the life-cycle of the object? Where do I go to get more information or request a correction?
  • Type of Data - What type of object is this? What is the healthcare relevance of the object? These are broad categories. 
  • Timeframe - What is the timeframe the object describes? 
  • Object Privacy- how sensitive is the information?
  • Object Security - metadata necessary to aid in protecting against risks to Confidentiality, Integrity, and Availability. 
These are not mutually exclusive reasons to have metadata. For example when it comes to Privacy controls, we leverage almost all of the other metadata. When the patient wants to restrict documents published by a specific doctor, we use the Author Metadata. When the patient wants to restrict access to a specific healthcare episode, we can write policy against a timeframe. When a patient wants to blank out a specific Object, we use it's unique ID value. 

The term Provenance is used in the ANPRM, this word is a very loaded word as it is inclusive of many of the metadata reasons above, but can also include data changes. That is within a document what is the provenance of a specific lab result value. This more detailed definition of provenance should be left to the object encoding, and not be brought up into the metadata. At least in the beginning when we are working to get agreement on roadmap stepping stones. This more detailed definition of provenance is absolutely needed at the local Medical Records department level. I am just pushing it out as not critically important for Health Information Exchange sharing. It must be discoverable, hence why the Object Lifecycle metadata is important.

Metadata vs Layers: Security need to be discussed in depth as we need to be very careful to not muddy the layers of abstraction. In systems that have proven scaleability a prime characteristic is that they are based on layers, a separation of purpose. For example the Internet protocols are based on the 7 OSI layers, where any one layer totally trusts that the other layers exist and focus only on the task assigned to that layer. I suggest that we must continue this design approach of layers. This is not to say that there is no security in the Metadata layer, but what does exist there is Metadata centric. For example: We don't force the security control of encryption as a metadata attribute, but we expect that the layer below will appropriately protect against risks to confidentiality. What is this layer 'below'? It is the transport packaging. Same can be said for the other risks.  But as with Privacy, Security will use many of the metadata attributes. Another example of abuse of metadata, vs use of layers, is the ANPRM inclusion of digital-signature in the metadata. A digital-signature is important, but it should be handled as a layer.

Metadata vs the Data it-self: The recommendation given in the ANPRM is to simply use CDA header as the metadata. This has some unintended consequences:
1) It means that in order to have a service operate on the metadata, that service must have access to all the data. For example, a service that is gathering data in preparation for a scheduled appointment.
2) It means that all objects either must be CDA, or be wrapped in CDA. I like CDA, but it is not the only document type used in healthcare today. DICOM has their Structured Report. Many still use PDF and CCR. The future might hold yet some other document type. 
3) It means that any probes to discover the data, must return all the data. Having a subset of the data, metadata, allows for minimal exposure during the discovery phase. 
4) This definition doesn't assist with the indexing task. The metadata values should be focused on those things that are most likely to be search criteria, meaning most valuable to be indexed. 

This puts metadata on a knife edge between being fully expressive of the content of the object, and expressing as little as possible so as to not expose privacy and security concerns. Thus for each metadata item we need to be clear exactly why it is minimally necessary, especially if the value could be considered sensitive it-self. Often when a value could be considered sensitive it will have a reasonable, non-sensitive, default value. 

Meta-Metadata: The ANPRM suggests that part of the Patient Identity metadata would be the patient's real name, address, zip, date of birth, and display name. I am not against these being potentially part of the metadata, but are they mandatory, are they valid metadata? Can an organization that has a strong Master Patient Identity (or multiple patient identity cross-reference) use simply the numeric patient id value, and not include the patient name and date of birth in the metadata? Remember, the document it-self should include this patient name and date of birth. So, lets not force it into the metadata unless we know it is needed. If we think it might be needed then lets make a place for it, and define how it would be encoded. This is another example of scaleability enabled through separation of function. Patient Identity is a layer it-self. There are services and data-models dedicated to defining Patient Identity. We should not flatten that layer into the Metadata layer. Lets leverage that layer. That layer focuses only on the patient identity and thus can track the identity of the patient across the lifecycle, independent from changes to their medical condition. The documents should be focused on the instant in time that they are documenting. If that moment in time is 20 years ago, prior to a marriage then the patient name will be different.  Which brings up the point that metadata should be an abstraction of the data it is describing, a relatively static set.

How the metadata is used should also be considered. That is think not just about the sender, but also the receiver and any value-add intermediaries. Encoding using XML is the cool thing to do now days, but XML is not always the right form for processing. We have come across a few metadata values where encoding using XML seemed like the right thing to do, but when we looked closer at the use of the value we realized that a compact string encoding would be better. The reasons are not obvious, but they come out when you look closely at how the value would be used in comparisons. Think of a metadata value that one wants to know if the value is equal or not equal; such as a Patient Unique ID. With XML there are many options for encoding, so one must do comparisons using the full encoding options. If however you force a specific string encoding, such as an HL7 v2 CX, then one can do a simple string comparison. Now scale this up to a NationWide Health Information Network and think about indexes of Patient Unique ID values that can use simple database searching, vs XML encoded searches. More important to this is that although the sender understands the components, the receiver should treat the whole as either matching or not. To have the receiver pulling apart the components of the Patient Unique ID will ultimately result in broken processing.

Conclusion: The XDS Metadata model meets and exceeds all the criteria outlined in the ANPRM. The XDS Metadata model is derived from CDA, as IHE knew that the CDA header had a well thought out structure. But IHE didn't adopt the CDA header outright, as the ANPRM suggests we should, because it recognizes the need to keep the metadata minimal for all the reasons I give above. In fact the model has the extensions that the ANPRM feel they need to do to the CDA header, so the extension is already available. The XDS Metadata model also supports any document type that can be defined with a MIME-TYPE; which means it is not restricted to CDA and can hold any document type that the Internet can define. 

The XDS Metadata is not tied to XDS, it has been abstracted out and available for many models (XDM, XDR, and XCA). I guess it should have been given an independent name, but it didn't. A well written white paper by the HIMSS-EHRA explains how this metadata model applies to the different architectures for Health Information Exchange. This is the metadata model used in the NwHIN-Exchange, which uses XCA and XDR. This is the metadata model used in the Direct Project, where metadata is used XDM is mandated.  This is also the metadata model that bridges the Direct Project and the NwHIN-Exchange Project, that being XDR.

There is an important role to be filled. Where as IHE provides the metadata model, they don't bind it to specific realm vocabulary. So there is a need for some USA focused guidance to bind specific vocabulary. This effort was started by HITSP, but not continued. This effort is necessary to further constrain the XDS metadata.

Also on my blog elsewhere

3 comments:

Friday, August 12, 2011

Can an HIE forbid copies?

There have been discussions in privacy circles where some would want an HIE to forbid making copies. That is when a doctor pulls a document (or it gets pushed to them), that they use the data but don't keep a copy. Typically the reason for wanting this is to limit the risk of accidental or intended secondary exposure.

I struggle how in the current Medical Legal Records environment this can be done when the custodian of the data is not the same as the user of the data. Care givers have a Legal responsibility to maintain copies of any evidence they used to come to a medical decision. This drives the need to keep a 'secured' copy.

I can imagine a HIE that has strong governance such that any custodian is required to produce exactly the same evidence when asked for it in the future. With this we might be able to fulfill this vision. The XDS profile allows for this, as any update to a document is a 'replace' of the previous. The previous and new are still available, although the old one is not in a ready state. Meaning if you ask for only currently ready documents you would only see the new document. But if you asked for deprecated documents, or asked for the original by unique ID, then it would show up.

The data user might want to validate that the data has not changed by saving a digital hash of the original document to prove in the future that the data returned by the custodian is the same as that they saw.  But what would legally happen if the custodian produces different data and can't match the hash the user stored? How would this legal dispute be handled? There simply is no precedent for this.

Note: Some of the reasons why people want to forbid copies is to allow for changes to be made to the data without needing to change all copies. This is simply not a reasonable request at all. If the data was wrong and it has been corrected this is a very important legal medical records thing to track. What was the old data, what is the new data, why was it changed, who changed, what authority allowed the change. etc. There is a real risk, based on drug seeking behavior, for medical records to be modified to allow for narcotics to be prescribed then changing the records to indicate that they were not prescribed. There are lesser likely risks around malpractice, ambulance chasers. An HIE governance should spell out what the expectations are when data changes. Right now it seems changes will NOT be automatically propagated or notified. I think this will change as technology can better support it. For now keep it simple.

I think a far more reasonable policy is one that indicates that copies can be used only for treatment, and that further propagation is not allowed (re-publishing). This is focusing on the risk of secondary use. I am not sure if this is the most important risk, but it is a start. I am also not sure if 'used only for treatment' covers any 'operational' use for things like quality outcomes reporting. It would clearly need to include the 'operational' use for medical records legal challenges (e.g. malpractice).

The big problem with this is that we are modifying EHR technology from an environment where the EHR was the center of the medical record, and thus all data in the EHR was considered original. We hook an EHR to an HIE (Push or Pull) and now it is the receiver of 'copies' that it somehow needs to indicate it is not the originator of but must still protect. This is on paper a simple change, but in design not necessarily so simple.

1 comment:

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:
Subscribe to: Posts (Atom)