Proposal for confidentialityCode vocabulary

I have been complaining about the definitions of the confidentiality codes both in the active HL7 development and in my past posts: 

• Data Objects and the Policies that Control them
• ConfidentialityCode can't carry Obligations
• Data Classification - a key vector enabling rich Security and Privacy controls

My main reason for not simply providing my own definitions was to allow for discussion on my concern that we have conflated the confidentialityCode meaning with consent status. My point is that the current consent status can affect all of the confidentialityCodes, not just the R or V.

I figured we should learn from the experience of the military data classification, a system that deals with very sensitive data in a different way. (Note that we are already ahead of the military in that we have a global vocabulary, take a look at the mapping mess that is military data classification).  In the case of the military classifications they use relative “harm to the country” as their measure. Yes this is different than healthcare information, but I think we can see that “harm to the patient” is what we have been discussing. Especially if we look at ‘harm’ in a broad sense that includes 

• reputation damage, 
• emotional damage, 
• family relationship damage, 
• financial damage, and 
• physical damage (safety). 

(possibly more, I haven’t fully described patient harm in this context yet).

I think it is very legitimate to include in our definitions contemporary examples from well-known countries policies. Such as in the USA with HIPAA vs 42 CFR Part 2.

So, here is a potential draft using the existing codes, just new definitions

• U – Unrestricted – No specific patient is identified and thus there is no patient harm risk
• L – Low – Data has been de-identified and there are mitigating circumstances that prevent re-identification such that there is remote harm risk to the patient if the data were exposed. The data however still requires protection from exposure outside intended use.
• M – Moderate – Data are identifiable but consists of modest clinical information that would present moderate harm risk to the patient if the data were exposed. Example include an emergency-data-set made up of non-sensitive problems, allergies, and medications.
• N – Normal – Data are identifiable and of typical health information that would present typical harm risk to the patient if the data are exposed. This code is used for the majority of clinical information. Examples include what HIPAA identifies as Protected Health Information.
• R – Restricted – Data are identifiable and of an especially sensitive nature that would present a high risk to the patient if the data are exposed. Examples include the data topics identified in USA 42 CFR Part 2 – “CONFIDENTIALITY OF ALCOHOL AND DRUG ABUSE PATIENT RECORDS”.
• V – Very Restricted – Data are identifiable and of extreme sensitive nature that would present a very high risk to the patient if the data are exposed. Data in classified Very Restrictive should be kept in the highest confidence.

Just a start, feel free to take, leave, or update

MetaData - got questions, here is my answers

The ANPRM Metadata Standards to Support Nationwide Electronic Health Information Exchange has been the focus of my blog article One Metadata Model - Many Deployment Architectures. I will now fill in my answers to the questions that are asked in the ANPRM. These are not my formal answers, but simply my take on the questions. I hope that these answers do get people thinking. I don't include links in my answers because the details are in the article One Metadata Model - Many Deployment Architectures.

Question 1: Are there additional metadata elements within the patient identity category that we should consider including? If so, why and what purpose would the additional element(s) serve? Should any of the elements listed above be removed? If so, why

The proposal defines many patient identity attributes that should not be part of the core metadata model. The metadata model should center around describing the document (object) and not around describing the patient. Yes, the metadata needs to be sufficient to link the document content to the patient. Further inclusion of the additional attributes; such as Address, Zip, Date-of-Birth, and Display Name; present both a Privacy/Sensitivity/Security concern but also present an accuracy concern. A HIE is a longitudinal record, so it will include useful documents that are 20+ years old. Further these attributes should be looked to be inside the document. They are not as valuable as metadata. Finally the current and most accurate meta information about the patient's identity is the domain of the patient identity system (e.g. PIX, PDQ, XCPD). This should not be duplicated at the document level. They are different vectors through the information space.

Question 2:  In cases where individuals lack address information, would it be appropriate to require that the current health care institution’s address be used?

When any metadata value is potentially not available there should be well defined behavior. Substituting the institutions address in place of the patient's address is a bad idea, unless the patient really is permanently living in the hospital. Specifically many metadata attributes are defined not because they are mandatory, but because when they are known there needs to be a consistent way of communicating them. Specifically Address is not an appropriate metadata at the document level as my answer to Question 1 indicated.

Question 3: How difficult would it be today to include a “display name” metadata element?  Should a different approach be considered to accommodate the differences among cultural naming conventions? 

Display Name is an attribute of the Patient Identity Domain; not the document. It should not be considered a required document metadata value.

Question 4: Are there additional metadata elements within the provenance category that we should consider including? If so, why and what purpose would the additional element(s) serve?  Should any of the elements listed above be removed? If so, why?

Provenance metadata attributes are important, but should be kept at the whole-object (Document) level. The specific attributes inside the document must show their own provenance in the context of that document. This layered approach is important for scalability and growth. Document non-repudiation through digital-signatures is a very helpful standard functionality, but should not be incorporated into the metadata model. Digital-Signatures are a layer that can be applied independent of the metadata. This does not mean that provenance values such as author be removed, these are appropriate metadata attributes. Simply separate out the metadata needs from the technology used to deliver specifically non-repudiation. More basically not all uses of data require the very high level of assurance of non-repudiation that a Digital-Signature provides. Forcing Digital-Signatures as metadata will make the model very expensive. This is the same as your correct justification of separation of the confidentiality layer.

Question 5: With respect to the provenance metadata elements for time stamp, actor, and actor’s affiliation, would it be more appropriate to require that those elements be expressed in XML syntax instead of relying on their inclusion in a digital certificate?  For example, time stamp could express when the document to which the metadata pertain was created as opposed to when the content was digitally signed.  Because this approach would decouple the provenance metadata from a specific security architecture, would its advantages outweigh those of digital certificates?

Please separate the technology of Digital-Signatures and PKI credentials from the minimal metadata used for authenticity and integrity protection. Some uses will need minimal controls, while other uses will demand Digital-Signatures. By separating, you enable multiple policies. Knowing the origin of a document is a fundamental query parameter, not necessarily only needed for non-repudiation.

Question 6: Are there additional metadata elements within the privacy category that we should consider including? If so, why and what purpose would the additional element(s) serve?  Should any of the elements listed above be removed? If so, why

The metadata model should be describing the object (Document), not trying to duplicate the Privacy or Security layers. Privacy and Security policy will leverage all of the metadata provided. Sometimes a privacy policy will request that a specific document be tightly controlled, it will do this by referring to the document unique ID. Other times a Privacy policy will tightly control an episode of care, through the object's time/date ranges. The privacy and security policies are part of the Access Control design layer. These do not need to be duplicated in a metadata model, but rather the metadata model needs to include sufficient metadata to enable Access Controls. The identified Data-Type and Sensitivity are good examples.

Question 7: What experience, if any, do stakeholders have regarding policy pointers?  If implemented, in what form and for what purpose have policy pointers been used (for instance, to point to state, regional, or organizational policies, or to capture in a central location a patient’s 27 preferences regarding the sharing of their health information)?  Could helpful concepts be drawn from the Health Information Technology Standards Panel (HITSP) Transaction Package 30 (TP30) “Manage Consent Directives?”  

Having the data point at the policy does not scale as objects age. You already enable individual objects to be controlled through having a unique identifier for the object. This is a much more sustainable model. Note that the document already discusses using layers of functionality, such that a wrapping layer (security layer) can include the policies that would need to be met before that layer allows the data to be unwrapped. So, please separate the layers and keep the metadata layer as attributes describing the object (document). I am advocating the model defined in TP30, that is separation of Privacy Policies from Access Control from the objects they protect.

Question 8: Is a policy pointer metadata element a concept that is mature enough to include as part of the metadata standards we are considering?  More specifically, we request comment on issues related to the persistence of URLs that would point to privacy policies (i.e., what if the URL changes over time) and the implication of changes in privacy policies over time (i.e., how would new policy available at the URL apply to data that was transmitted at an earlier date under an older policy that was available at the same URL)?

See answer to 6 and 7. Policy pointers are not appropriate at the object metadata layer.  Policy is a different layer. 

Question 9:  Assuming that a policy pointer metadata element pointed to one or more privacy policies, what standards would need to be in place for these policies to be computable?

There is a lack of current standards for encoding privacy and security policy in a interoperable and computable form. In the mean time we leverage vocabulary such as confidentialityCode, and regional vocabulary for consent types (BPPC).

Question 10: With respect to the privacy category and content metadata related to “data type,” the HIT Standards Committee recommended the use of LOINC codes to provide additional granularity.  Would another code or value set be more appropriate? If so, why?

The use of LOINC might be sufficient. A USA Realm management of the codes used for metadata 'data type' would be a good mechanism to build. This was a positive output from HITSP, but needs to be further refined and managed. The actual codes used will evolve over time, and there needs to be consideration of this evolution. However the full LOINC vocabulary may be too fine-grained and present a privacy violation. We need to be careful to balance the needs to discover/describe with the needs to protect.

Question 11: The HIT Standards Committee recommended developing and using coded values for sensitivity to indicate that the tagged data may require special handling per established policy.  It suggested that a possible starter set could be based on expanded version of the HL7 ConfidentialityByInfoType value set and include: “substance abuse; mental health; reproductive health; sexually transmitted disease; HIV/AIDS; genetic information; violence; and other.” During this discussion, several members of the HIT Standards Committee raised concerns that a recipient of a summary care record tagged according to these sensitivity values could make direct inferences about the data to which the metadata pertain.  Consistent with this concern, HL7 indicates in its documentation that for health information in transit, implementers should avoid using the ConfidentialityByInfoType value set.  HL7 also indicates that utilizing another value set, the ConfidentialityByAccessKind value set which describes privacy policies at a higher level, requires careful consideration prior to use due to the fact that some items in the code set were not appropriate to use with actual patient data.  In addition, the HIT Standards Committee recommended against adopting an approach that would tag privacy policies directly to the data elements. What kind of starter value set would be most useful for a sensitivity metadata element to indicate?  How should those values be referenced?  Should the value set be small and general, or larger and specific, or some other combination?  Does a widely used/commonly agreed to value set already exist for sensitivity that we should considering using?

 The data classification for sensitivity is an important metadata value. It needs to be sufficiently varied to allow for proper segmentation, but also sufficiently broad so as to not expose privacy. This is not to say that metadata be restricted to non-sensitive values, but rather that limiting the risk should be considered. Specifically the ConfidentialityByInfoType is a very bad value-set for exposure outside a controlled environment. This value-set was defined in HL7 for purposes of policy encoding, not use as metadata. The metadata values in the ConfidentlityByAccessKind is defined for interoperability. This poor documentation by HL7 has been identified earlier this year and the HL7 committees are in the process of correcting the documentation. Part of this documentation will be a clarification of the proper uses of each value-set. The other part will be a more clear differentiation of the purpose of confidentialityCode vs other attributes that are used by Privacy Policy and Access Control enforcement such as author, time, unique identifiers, authentication, user-role, etc.

Question 12: In its recommendations on privacy metadata, the HIT Standards Committee concluded that it was not viable to include the policy applicable to each TDE because policy changes over time.  Is this the appropriate approach?  Are there circumstances in which it would be appropriate to include privacy preferences or policy with each data tagged element? If so, under what circumstances? What is the appropriate way to indicate that exchanged information may not be re-disclosed without obtaining additional patient permission? Are there existing standards to communicate this limitation?

Please separate out the Privacy Policy functionality from the Object metadata. These are separate domains. They are related and function as layers for scalability.

Question 13: With respect to the first use case identified by the HIT Policy Committee for when metadata should be assigned (i.e., a patient obtaining their summary care record from a health care provider), how difficult would it be for EHR technology developers to include this capability in EHR technology according to the standards discussed above in order to support meaningful use Stage 2?  

The definition of metadata given is not sufficient to assure interoperability. I recommend that the Metadata definition foundation be the XDS Metadata, with a USA Realm vocabulary bindings. In order to assure interoperability the XDS Metdata must also be bound to transport. This is the role of the XDS, XDR, XDM, and XCA profiles - but the XDS Metadata can also be bound to other transports or API. The binding to these transports is specific to their environment of use. The use of XDS Metadata in the context of XCA is already in practice as part of the NwHIN-Exchange. The use of XDS Metadata in the context of XDM (e-mail media) is already in practice as part of the Direct Project. The use of XDS Metadata is common between these two NationWide projects, and is the basis of the common XDR protocol between these two projects. Under the XDM profile there is an encoding for use on USB-Memory Drives and CD-ROM. There is now a supplement that shows how encryption is handled in all of these environments including a new profile for transport agnostic encryption.

Question 14: Assuming we were to require that EHR technology be capable of meeting the first use case identified by the HIT Policy Committee, how much more difficult would it be to design EHR technology to assign metadata in other electronic exchange scenarios in order to support meaningful use Stage 2? Please identify any difficulties and the specific electronic exchange scenario(s).

See answer 13: The use of a common metadata model is very important to enable interoperability, privacy, security, and safety. Metadata is more than a transaction specification, but a factor in the longitudinal use of that data. Metadata needs to consider object types beyond HL7 CDA. DICOM has a document defined by their Structured Report specification. There are many who continue to use unstructured documents in PDF form (e.g. EKG report). There are others using CCR. There are documents that are based on W3C (Digital-Signatures). There are documents based on OASIS (Workflow). There are others that might be using a totally new form. The Metadata defined in XDS was derived from CDA but distanced it-self from CDA to allow for other document types. In this way the XDS metadata needs only that there be a MIME-TYPE defined for the document. If a CDA document, or CDA Header fragment was used, there would be significant overhead for very little value.

Question 15: Building on Question 14, and looking more long term, how would the extension of metadata standards to other forms of electronic health information exchange affect ongoing messaging and transactions?  Are there other potential uses cases (e.g., exchanging information for treatment by a health care provider, for research, or public health) for metadata that we should be considering?  Would the set of metadata currently under consideration support these different use cases or would we need to consider other metadata elements?  

Over time we need to recognize that patients are free to move globally. Thus a metadata model needs to consider the patient as the center in an environment that is beyond the USA. The XDS Metadata model is being globally adopted.

Question 16: Are there other metadata categories besides the three (patient identity, provenance, and privacy) we considered above that should be included?  If so, please identify the metadata elements that would be within the category or categories, your rationale for including them, and the syntax that should be used to represent the metadata element(s).

Metadata categories are better described as uses of metadata. This is to say that the different needs drive a set of metadata. Each metadata attribute tends to have many uses. A good example of this is the use of protecting privacy, which leverages just about all metadata values.

Question 17: In addition to the metadata standards and data elements we are considering, what other implementation factors or contexts should be considered as we think about implementation specifications for these metadata standards?  

Metadata must also be bound to an encoding, this is typically specific to the transport. For example in the use of XDS Metadata as bound to XDS, XDR, XDM, and XCA.

Question 18: Besides the HL7 CDA R2 header, are there other standards that we should consider that can provide an equivalent level of syntax and specificity?  If so, do these alternative standards offer any benefits with regard to intellectual property and licensing issues?

Please re-assess the XDS metadata. It was created through a global initiative over many years of analysis, prototyping, and implementation. IHE started with the evaluation that the CDA Header had the right elements, which seems to be a common understanding expressed in this ANPRM. Yet the CDA Header is not laid out to be Metadata, and is restrictive of the content type. Most important is to separate metadata from privacy/security policy and enforcement.

Question 19:  The HL7 CDA R2 header contains additional “structural” XML elements that help organize the header and enable it to be processed by a computer.  Presently, we are considering leveraging the HL7 CDA R2 header insofar as the syntax requirement it expresses relate to a metadata element we are considering.  Should we consider including as a proposed requirement the additional structures to create a valid HL7 CDA R2 header?

The use of the CDA header is overly exhaustive, and yet the encoding of the attributes as defined by CDA is not necessarily the proper encoding for metadata. Being pure XML is not always the right solution.

Question 20: Executive Order (EO) 13563 entitled “Improving Regulation and Regulatory Review” directs agencies “to the extent feasible, [to] specify performance objectives, rather than specifying the behavior or manner of compliance that regulated entities must adopt;” (EO 13563, Section 1(b)(4)).  Besides the current standards we are considering, are there performance oriented standards related to metadata that we should consider?

I agree that regulations should be more performance related, for example focusing healthcare advancements on better outcomes. However when defining an Interoperability layer exacting detail needs to be specified. This allow the communicating systems to be developed in isolation and yet fully interoperate. It is the outcome of the interoperability that should be measured through performance. That is to say that the goal is not interoperability or metadata; the goal is to provide better outcomes through some proven workflow that needs interoperability.

Conclusion
I am very pleased with this ANPRM. Although I disagree that the CDA Header is the solution, there is much that is right. My main concerns are that there is too much reliance on CDA vs an independent metadata definition that can handle other objects; there is too much expectations that the patient identitiy description be included in the metadata;  and that privacy policy is too tightly bundled.

I have been involved in many metadata discussions including the derivation of the XDS metadata. I learned alot during these experiences and was fascinated at the combined knowledge that was used to create the XDS metadata model. I am not alone in lamenting the unfortunate choice of ebRIM for this metadata model, but it was the best standard available at the time. The model is still the right model. Further the model has been applied to the various HIE deployment architectures (XDS, XDR, XDM, XCA), and could be applied to others as well. See One Metadata Model - Many Deployment Architectures. 

IHE IT Infrastructure Technical Framework volumes and supplements published

The IHE IT Infrastructure Technical Committee has published the following Technical Framework volumes as of August 19, 2011:

·         Volume 1 (ITI TF-1): Integration Profiles

·         Volume 2 (ITI TF-2): Transactions (volume 2 is divided into three separate sub-volumes)

o   Volume 2a (ITI TF-2a): Transactions ITI-1 through ITI-28

o   Volume 2b (ITI TF-2b): Transactions (cont.) ITI-29 through ITI-64

o   Volume 2x (ITI TF-2x): Appendices A through W and Glossary

·         Volume 3 (ITI TF-3): Section 4–Cross-Transaction Specifications and Section 5–IHE Content Specifications

Newly made final text: Async Web-Services, XCA, MPQ, PIX v3, PDQ v3, and PDO. The documents are available for download at http://www.ihe.net/Technical_Framework.

The Committee has also published the following supplements to the IHE IT Infrastructure Technical Framework as of August 19, 2011:

o   Cross-Community Fetch (XCF) - Published 2011-08-19

o   Cross-Community Patient Discovery (XCPD) - Revised 2011-08-19

o   Cross-Enterprise User Assertion - Attribute Extension (XUA++) - Revised 2011-08-19

o   Document Encryption (DEN) - Published 2011-08-19

o   Healthcare Provider Directory (HPD) - Revised 2011-08-19 

o   On-Demand Documents - Revised 2011-08-19

o   Retrieve Form for Data Capture (RFD) - Revised 2011-08-19

o   Support for Metadata - Limited Document Sources - Published 2011-08-19

o   XAD-PID Change Management (XPID) - Published 2011-08-19

o   XDS Metadata Update - Revised 2011-08-19

These profiles will be available for testing at subsequent IHE Connectathons.  The documents are available for download at http://www.ihe.net/Technical_Framework.

Comments on all documents can be submitted at http://www.ihe.net/iti/iticomments.cfm.

HIT Standards Committee NwHIN vs Direct maturity chart

The view of HIT Standards maturity and adoption is one of the things that HIT Standards Committee has discussed this week. This is fantastic update since the original that I blogged about in July. Please see the John Halamka summary of the HIT Standards August Meeting for all the things that happened. The specific section was what Dixie presented.

Dixie Baker presented the preliminary recommendations for building blocks that support data exchange in both "push" and "pull" models.   The key innovation in Dixie's work is the process for reviewing existing standards for appropriateness, adoption, maturity, and currency. 

The stated charge of this PowerTeam is:

“Using the NwHIN Exchange and Direct Project specifications as primary inputs, recommend a modular set of transport, security, and content components (“building blocks”) that can be selectively combined and integrated to enable the trusted exchange of content in support of the meaningful use of electronic health record (EHR) technology”

I commented strongly during the first presentation of these charts in July, and blogged about it. I would like to believe that it was my blog that caused a 'PowerTeam' to be created to re-examine it. This PowerTeam met on the 11th (3 members if I remember correctly), where I again provided very detailed comments online. I was contacted directly understand and resolve these comments. I also participated in some NwHIN-Exchange meetings where comments were developed and delivered to the PowerTeam. Ultimately trying to provide evidence that the NwHIN-Exchange specifications were more mature than they were being portrayed.

So, on the 17th I expected the slides to be perfect. Well they are better. In fact I think they might be as good as can be expected at this time. I think that further adjustment can only be influenced by a new group of people, that is not Vendors or Consultants. I can't even fault ONC for this fact. ONC should be skeptical of  'facts' that come from Vendors and Consultants.  They want and deserve facts from Hospitals and National/Regional/Local Health Information Exchanges.

I expected that when John Halamka first introduced this chart that the purpose was to show that Direct was more mature and better accepted than Exchange. It turns out that many members of the NwHIN-Exchange and CONNECT have been providing strong comment and evidence in support of Exchange. The EHRA has also provided input in their White paper on Health Information Exchange types. The result is that the charts now shows that they are almost dead even. However the FACA committee is still taking as more authorative the ‘opinion’ of a few members over ‘facts’ provided by outsiders. Ultimately more adjustments will be made. Ultimately the decision will be, and should be, that both specifications need to be endorsed. More implementer's of NwHIN-Exchange need to speak up.

I don't like their feeling that they get to ‘eliminate’ or ‘reconsider’ specifications. The existence or continued ‘consideration’ will be based on market need, not the opinion of 3-4 people. I am not saying that (from page 12 - not shown here) the access consents or HIEM are good specifications, they are not. However in the case of the Web Services Registry as suboptimal, better alternatives are not yet available; they are in the works and will eventually replace (UDDI).

The NwHIN-Exchange folks were very upset at where Authorization Framework landed, as it is critical for Query/Retrieve patterns. They will surely continue to push a better evaluation of this. There is a perception by a few that the Authorization Framework is much harder than it actually is. The specifications mentioned in the 'consider' category are content or uses; so shouldn't have been evaluated.

I have been asked why XDS isn't included - XDS has never been a part of NwHIN-Exchange. The NwHIN-Exchange is about federating local/regional exchanges into a nationwide exchange. This federation is the role of XCA. There has never been any hint of how one might build a local/regional exchange. However as you likely observed, the XCA Query and Retrieve transactions are derived (by IHE) from the XDS Query and Retrieve transactions. Thus a system that knows how to interact with XDS, knows how to interact with XCA. This is a design principle of XCA. So this is normal, and expected.

What is lost in the chart is that XDR is a common thread between Direct and Exchange. The XDR protocol is being heavily used in Exchange, especially by SSA. The XDR protocol holds a special place in the Direct project as well, as it is tangentially endorsed through the specification that shows how to bridge Direct and XDR. Thus “Document Submission” should be recognized as XDR and re-assessed to mature.  

From EHRA White paper

Of note, from an EHR perspective, if you support XCA Query/Retrieve and XDR PUSH; you fully support XDS. This does not mean that you have XDS infrastructure, that is a big operational aspect. But it does mean that if you have tested your EHR against XDR and XCA that you are XDS compliant. The advantage of XDS is that it identifies a set of services that would be hosted centrally as high-availability; allowing clinics to be off-line at night and weekends. There should be a white paper from IHE on how to make a Regional Health Information Exchange using the XDS family (PIX, PDQ, ATNA, XUA, BPPC, CT, and maybe more). This all does tie nicely into the need for One Metadata Model - Many Deployment Architectures

The only aggravating thing in the whole presentation (page 9-11) is that for every NwHIN-Exchange specification is an alternative of REST or Direct (which I disagree is possible); while the Direct specifications do not include the alternative of XDR (which is proven as being an alternative). 

Conclusion

This is a huge improvement, so much so I have very little that I would request be changed. The biggest recommendation is to get those implementing NwHIN-Exchange to speak up. Surely there are NwHIN-Exchange partners that can show real results. I know of large providers and regional health information exchanges that are planning on using the NwHIN-Exchange independent of the NwHIN-Exchange. These positive uses of NwHIN-Exchange need to be brought forward.  I have expressed my knowledge and opinion; it has been recognized and influenced as far as it is going to.

IHE Educational Webinars

Update: The recordings of the webinars described below are now available.

The IHE Privacy and Security webinar is now scheduled and starts this week. I somehow missed the overall notification of IHE webinar series. They update the schedule on an as needed basis and don't send out specific updates. There are many good webinars available.

What you need to know is when the IHE Privacy and Security Webinar will be. It is broken into two parts:

Security and Privacy Overview – Part 1

• Wednesday, August 17, 10:00am — 11:00am CDT
• Register
• Speaker:
• John Moehrke — GE Healthcare

Security and Privacy Overview — Part 2

• Wednesday, September 7, 10:00am - 11:00am CDT
• Register
• Speaker:
• John Moehrke — GE Healthcare

Now if you are a regular reader of my blog, you have already seen the webinar through my blogging of it. I do still encourage you to attend in person so that I can interact with someone... I presume there will be recordings, I will post links to those when they are available.

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

• Can an HIE forbid copies?
• Stepping stones for Privacy Consent, 
• Data Objects and the Policies that Control them, 
• Consent Management using HITSP TP30
• Data Classification - a key vector enabling rich Security and Privacy controls.
• The Direct Project and IHE/HIMSS
• Signing CDA Documents
• ConfidentialityCode can't carry Obligations
• Directed Exchange vs Publish/Discover Exchange

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.

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

• The IHE Web site for all formal specifications and background 
• The IHE Wiki for committee work, and implementation notes 
• To get involved go to the committees pages

Back links

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

• Introduction to IHE impact on Meaningful Use
• IHE - Privacy and Security Profiles - Introduction
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• IHE - Privacy and Security Profiles - Document Digital Signature
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• IHE - Privacy and Security Profiles - Document Encryption
• IHE - Privacy and Security Profiles - Access Control
• IHE - Privacy and Security Profiles - Miscellaneous
• IHE - Privacy and Security Profiles - Conclusion

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

• Document Encryption (DEN) - new profile being worked on this year - Encryption of documents and/or XDM
• Because this is under development the details are yet to be written
• Document encryption has favor as it would be transport agnostic, but is unclear the usefulness of this for long-term-storage usecases like XDS and XCA.
• XDM encryption would likely leverage the e-Mail option that exists today
• The e-Mail option uses S/MIME to secure the ZIP of the XDM file-system
• The modification from existing profile would be to explain how to save the S/MIME message as a file rather than delivering it over SMTP
• This file would simply be a S/MIME message, thus protected with whatever the S/MIME protections used.
• De-Identification handbook - this is NOT a profile, but is a document being written this year.
• Will be a procedure document that explains how one would evaluate the requirements for a De-Identification scheme specific to a desired use-case
• Would leverage De-Identification and Pseudonymization
• See De-Identification is highly contextual and Redaction and Clinical Documentation
• Directories
• A broadly usable HIE Directory
• Healthcare Provider Discoverability and building Trust
• Healthcare Provider Directories Profile
• Healthcare Provider Directories -- Lets be Careful
• Authentication and Level of Assurance
• Healthcare use of Identity Federation
• Federated ID is not a universal ID
• Risk Assessment
• Cookbook: Preparing the IHE Profile Security Section - Revised 2008-11-10
• How to Write Secure Interoperability Standards

Back links

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

• Introduction to IHE impact on Meaningful Use
• IHE - Privacy and Security Profiles - Introduction
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• IHE - Privacy and Security Profiles - Document Digital Signature
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• IHE - Privacy and Security Profiles - Document Encryption
• IHE - Privacy and Security Profiles - Access Control
• This Page
• IHE - Privacy and Security Profiles - Conclusion

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

• confidentialityCode - this is NOT a profile, but is a security/privacy concept built into almost all of the healthcare standards. 
• Statement of the data security/privacy classification 
• Would be used by access control decisions 
• See: Data Classification - a key vector enabling rich Security and Privacy controls.
• HIE Security and Privacy through IHE- Revised 2008-08-22 
• Access Control - Published 2009-09-28 
• IT security problems continue (Designing a Secure HIE) This is where I explain that point-to-point security doesn't scale and that a walled-garden approach using TLS may be a better starting point. (Yes, this is an old article that still is true today. We see in NHIN Direct something closer to the unconstrained point-to-point, or end-to-end. The solution being discussed is to restrict NHIN Direct endpoints to 'organizations', thus ending up with a smaller map but still quite the spider web) 
• Healthcare Access Controls standards landscape

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

• Introduction to IHE impact on Meaningful Use
• IHE - Privacy and Security Profiles - Introduction
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• IHE - Privacy and Security Profiles - Document Digital Signature
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• IHE - Privacy and Security Profiles - Document Encryption
• This Page
• IHE - Privacy and Security Profiles - Miscellaneous
• IHE - Privacy and Security Profiles - Conclusion

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.

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

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

• Introduction to IHE impact on Meaningful Use
• IHE - Privacy and Security Profiles - Introduction
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• IHE - Privacy and Security Profiles - Document Digital Signature
• This Page
• IHE - Privacy and Security Profiles - Document Encryption
• IHE - Privacy and Security Profiles - Access Control
• IHE - Privacy and Security Profiles - Miscellaneous
• IHE - Privacy and Security Profiles - Conclusion