Creating and using Unique ID - UUID - OID

Standards often need to have a way to identify an object in a way that is impossible to be confused. A way to come up with a 'name' for an object that no other object has - A Unique Identifier. Standards have solved this multiple times, with two primary ways common today. One of those common ways being able to incorporate the other. I am not going to fully describe these unique identifiers, but rather point at the few references that you need to use.

When I say a Unique Identifier of an Object. I truly mean any object. This goes for things like Patient Identifiers, DICOM Study Instance (DICOM calls these a UID), and CDA Documents. To a computer a communications protocol, these are just a Unique Identifier of an Object.

When I say a Unique Identifier I also want to make it clear that it is an opaque identifier; meaning it is either the identifying the object or it is not -- True or False. Some Unique Identifiers are hierarchical and one could possibly determine something about the object by looking at the identifier; but this should NOT be relied on, it should be worried about (Risks to Privacy-Security). Meaning that the structure of the unique ID is important when creating a new one, to assure you are truly creating a new one that doesn't exist today or in the future. But also that when 'using' a unique ID one compares the whole thing to determine if it is the unique ID you  want or not. Any attempt to see if it is close to the ID you want will only result in trouble down the line.

There are generally 2 types of unique identifier that I am going to cover

1. UUID - Universally Unique IDentifier. These are not absolutely unique, but statistically unique. Not that there is ever a way to prove that any Unique ID is absolutely unique, but UUID is a fixed size and without a structure that tries to guarantee uniqueness. That said, there are different ways to create UUIDs that get so close to statistically unique that one must ask how close to tangent must one get.
2. OID - Object Identifier. We tend to want to use these more often as they are more structured and thus allow for some additional ways to create Unique Identifiers. The structure also allows for more accurate TRUE/FALSE comparisons. And when it comes to diagnosing problems, their structure can also come in handy.
3. Yes, I know there are others. but for the purposes of this blog post, these are king.

So, how does one create a Unique Identifier in a way that is globally unique? 
The easy way is to use your platform to create a UUID. I can't encourage everyone more strongly to use their platform. Not because I have total faith in the platform to have not messed things up, because we all know that mistakes happen. If we all use the platform provided functionality then we will all be watching for the mistakes in the same code. Where as if everyone writes their own algorithm, then mistakes will only be detected by a handful of people who inspected the code, thus a mistake will happen at a bad time. Yes, an open-source platform implementation would make this even better.

• JAVA http://download.oracle.com/javase/6/docs/api/java/util/UUID.html  
• Wikipedia does a good simple explanation http://en.wikipedia.org/wiki/UUID
• IHE Appendix B on Document OIDs IHE ITI TF Vol2x
• The formal definition of the algorithms is the ITU-T X.667  http://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf 
• equivalent IETF  http://www.ietf.org/rfc/rfc4122.txt 
• More background from the ITU-T http://www.itu.int/ITU-T/asn1/uuid.html 
• And David Clunie is always good to review http://www.dclunie.com/medical-image-faq/html/part2.html - UID

How do you create an OID?
The above is all about createing UUIDs, not OIDs. But, if one creates a UUID then you can encode that as an OID very simply. An OID that begins with "2.25." is an OID encoded UUID. The value after "2.25." is the streight decimal encoding of the UUID as an integer. It MUST be a direct decimal encoding of the single integer, all 128 bits. It must not be broken up into parts. E.g., the UUID "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" becomes the OID "2.25.329800735698586629295641978511506172918". (thanks David)

It must be decimal because OIDs are all decimal. This has the additional benefit of being more easy to compare for TRUE/FALSE as one doesn't need to worry about the case of the non decimal characters (typically UUIDs are encoded as hex values, so one must compare them using case-insensitive methods). Yes you must work with very large integer math.

Note: Some protocols have limits to the size of a Unique ID. For example DICOM has restricted some OIDs to 64 characters. When encoding a UUID in an OID the proper way, you will not overflow 64 characters. This is because the largest decimal value that can fit in a 128 bit integer encoded as a string is 39 characters long. (Note, another reason to do this as a single integer, as some have tried to encode the parts and ended up with strings that were too long).

How do you create an OID that is not a UUID?
The UUID encoded OID is really not adding much value, but it is very important where UUIDs are well understood. Sometimes one really needs a native OID. For example a native OID is very helpful when it is used to define something that is going to be documented as part of a standard. For example a vocabulary, Value-Set, Service-Endpoint, etc.

1. First one must get a OID prefix. There are plenty of places to get these. See David Clunie's article on how to do this. 
2. Second one must Manage their OID space. Like managing any 'directory', creating a structure that meets your needs helps you organize and control the OIDs. Some good examples are found in the IHE Vol 2x Appendix B For example when you need to build OIDs in a distributed space (like isolated medical-devices), then manage the OID space to assure that each machine gets a unique branch.
3. Third one must Manage each instance. some will use methods similar to those used for UUIDs. Such as using the MAC address and timestamp (be careful to be thread safe).

Other
Note: MAC addresses (e.g. the ethernet address of your machine) is assigned using a manufacture assigned code and a code assigned by that manufacture in a way that they are globally unique. But the MAC address can also be changed by a talented user. And some abstractions (Virtual Machines) don't use manufacture controlled MAC addresses.

There is a URI (URN) encoding for both UUID and OID. For example:

• urn:oid:2.25.329800735698586629295641978511506172918
• urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Conclusion
Don't reinvent, there are plenty of Unique ID standards and widely used implementations of those standards.

Medical Device Security and Privacy

There are some really good white papers on Security and Privacy associated with Medical Devices. I often point at these because they are well written, yet pointed papers. I also point at them because I worked hard on the content, as I am a member and past chairman of the committee. This committee is a joint committee of the NEMA (an international organization, but tends to be somewhat North America based), JIRA (a European organization), and JIRA (a Japan based organization).

There isn't anything new from the group at this time, but I am posting this because they have changed their web site and just lately recovered all of the good white papers.The following are the most important and still relevent papers. There are more white papers on the site

Joint Security and Privacy Committee.  

• Certificate Management for Machine Authentication
• This paper is still very relevant to mutual authentication used in IHE ATNA. This paper discusses a couple of methods that can be used to manage these certificates, and how each way scales.  See Designing a Secure HIE
• Defending Medical Information Systems Against Malicious Software
• This paper covers some really important concerns that Medical Device vendors have regarding the unintended consequences that AntiVirus can have. Patient Safety is priority number one in healthcare. More importantly there are more ways to address malware (virus, worms, etc) than to simply apply AntiVirus.
• Patching Off-the-Shelf Software Used in Medical Information Systems
• This paper covers patch management relative to security patches from the third party software that the medical device vendor included in their product, such as the operating system. This paper was initially published back when Medical Device vendors were wrongly placing blame on the FDA for their non-action. Patching does need to be done in a controlled way, to protect patient safety.
• Break-Glass – An Approach to Granting Emergency Access to Healthcare Systems
• This is a view of 'break-glass' that is responding to a large scale disaster where the normal IT infrastructure may not be fully functional
• Information Security Risk Management for Healthcare Systems
• This paper helps Medical Device manufacturers manage IT security risks in healthcare systems by detailing the steps in security risk assessment in the context of security risk management. IT security risks are risks to data and systems. As a best practice, patient and operator safety risk management and IT security risk management processes should be separate but linked. They differ in both the vocabulary and expertise required for proper risk management. If combined as a single assessment process, one or the other is not treated appropriately.   This concept has received renewed interest including  IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network

• Security and Privacy Auditing In Health Care_Information_Technology
• This paper discusses the aspects of Security and Privacy audit logging and log analysis in Healthcare. This paper was an important step to the creation of the IHE ATNA profile.See Accountability using ATNA Audit Controls and ATNA and Accounting of Disclosures

Data Objects and the Policies that Control them

In reading the President's Council of Advisors on Science and Technology (PCAST) report on "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward"; among the many comments that I could make on it, I want to focus this blog article on one very specific point. The point I want to discuss is the directionality of the relationship between the Data Object and the Policies that Control them. This point is not specific to PCAST, and has been discussed many times over the years.

In the PCAST report Section "V. Privacy and Security Considerations", on page 49 in the following sub-section quoted below is the part I highlight in yellow:

A Health IT Architecture for 21st-Century Privacy and Security
We believe that a universal exchange language based on tagged data elements will allow the design of much better privacy and security protection than currently exists for either paper or electronic sys­tems, for two principal reasons.  First, the ability to tag an individual piece of data with privacy ­related information, as part of its metadata, enhances privacy safeguards.  Second, because tagged data ele­ment exchange protocols are designed to be efficient for the rapid exchange of small pieces of data, it is feasible to use security protocols that involve multiple exchanges of challenge and response.  We illustrate these points in this and the next subsection.

I will note that I am reading the PCAST report as a set of principles brought together by the small group invited by the Whitehouse. So, First I will note that this is a small group; Second this was a closed group; Third it was not a very transparent process, and Fourth this was a group with some suspicious membership. But this is not what I want to focus on.

I have no problem with 'tagged data elements', I speak highly of this in Data Classification - a key vector enabling rich Security and Privacy controls. The actual value of  these tags is part of the discussion.  In the future I would like to have a discussion about the practical realities of their implied definition of an 'element', where I would like to recommend that a 'Document' is a reasonable size to manage today. 

Data Objects pointing at the Policies that control them:


What I want to focus on is the directionality of the model being propagated by the PCAST report. They indicate that the individual piece of data has a tag (metadata) with the privacy related information. I read this that the Metadata points at the privacy policies that describe how to control the individual peice of data (the 'element').


Data Object  --> Privacy Policy

Policies point at the Data Objects that they control
This seems like a logical approach, and indeed was the approach that BPPC took in the first version. In the first version of BPPC the confidentialityCode of any document could hold the OID of the BPPC policy. This seemed logical to us at the time too. But what we found out was that this doesn't scale with the age of the data-set. What I mean is that as a patient changes their mind regarding sharing (opt-in, opt-out, etc), one needs to go and change all the metadata tags on all the data, rather than just change the policies.

So BPPC now has the confidentialityCode as a sensitivity/confidentiality classification, and the BPPC policy is self-contained. If the BPPC policy needs to have special rules about a specific Document, the the BPPC policy points at the document. For example when a patient wants a specific episode summary hidden, it is identified by the unique number in the privacy policy.

Privacy Policy --> Data Object

Indeed as the patient changes their privacy policy, or the organization changes their privacy or security policies; these changes should be reflected in the privacy/security policies, not in changes to the data. The data hasn't changed, the policy has changed.

Metadata describes the Data as facts, and Policies have the specifics about how to control the data 
In fact the Data object does have metadata that is used in the Access Control decision. Metadata that does include a confidentialityCode, classCode, formatCode, Patient Identifier, Facility Identifier, Author Identifier, etc. But I don't see these as 'pointers', but rather 'security context attributes'. See the IHE white paper Access Control - Published 2009-09-28

I am optimistic that the authors were not trying to impose an architecture, but rather identifying a principle. As a principle the directionality should not matter.

PS. software engineers might find this useful, or might be confused by it -- this is like the first-year school assignment in linked-lists, stacks, and fifo... the obvious direction of the pointers is not the right direction to implement. Ok, that might not help at all...

Most popular blog entries of 2010

The blog tools make this post easy, but it is still useful to record an annual perspective on what seemed important at the time. Clearly the popularity contest is won by 'ranting'.

1. Meaningful Use Security Capabilities for Engineers This is where I describe the Meaningful Use security capabilities and provide recommendations on what they mean and how to implement them
2. Meaningful Use clearly does not mean Secure Use I am amazed at how many hits this got and continues to get. It is a rant on the MU draft, yes they did fix some of the things I rant about. See item 1.   
3. Meaningful Use Certification issue with Encryption of data-at-rest This is where I rant about how the Meaningful Use rules messed up and defined tight requirements for encryption and integrity controls but failed to say anything about key management, content packaging, or portability. 
4. Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent  Another rant...Yup, privacy is still missing... 
5. Meaningful Use - Security Plan This is where I ranted less, but gave advice to how to read the Meaningful Use draft.
6. Accountability using ATNA Audit Controls This is where I explain how to achieve the requirements of Accountability with simply an Audit Control. (Watching what people do is very important. It is sometimes the only way to detect users misbehaving, like looking at VIP patients or downloading thousands of documents)
7. Data Classification - a key vector enabling rich Security and Privacy controls This is where I demystify the confidentialityCode as a part of segmentation, and explain how this is metadata to be used by access control engines as one of the factors used to determine if a specific use of data should be allowed or not. (For those reading PCAST, read this as if it is the PCAST concept of 'tagged data element approach'. It is part of the whole picture but not completely... )
8. Meaningful Use Encryption - passing the tests This is where I explain just how bad the data-at-rest requirements are and how screwed up the testing is.   
9. 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)
10. Meaningful Use takes Security Audit Logging back a decade It is unfortunate that we work hard to advance security and privacy only to have regulation take us back to the dark ages.

I have some articles that I think are more long-term explanations of a concept. They are not so much popular at any given time, but are references:

IHE Security/Privacy primer
Meaningful Use Security Capabilities for Engineers
User Identity

• Healthcare use of Identity Federation
• Federated ID is not a universal ID 

Access Controls - Including enforcing Privacy

• ConfidentialityCode can't carry Obligations
• Data Classification - a key vector enabling rich Access Controls 

Consent Management

• Stepping stones for Privacy Consent 
• Consumer Preferences and the Consumer  
• Availability of Consent Documents and their rules 

Audit Controls

• Accountability using ATNA Audit Controls 
• ATNA and Accounting of Disclosures 

Other Controls

• Signing CDA Documents
• Redaction and Clinical Documentation  
• How to Write Secure Interoperability Standards
• Designing a Secure HIE

S/MIME vs TLS -- Two great solutions for different architectures

John Halamka with help from Dixie Baker wrote about a topic that came up on HIT Standards discussion asking why the Direct Project secure transport couldn't just be TLS.

Arien Malec responded with a good discussion of some issues that were uncovered during some prototyping. I am not convinced that this was fully investigated, but it still is a good read and a well done description of SSL, TLS server authentication and TLS mutual authentication.

My answer is: Security is hard, Trust is hard…

All the posts I have read today are all not looking at the total picture. I recommend one look at the Security and Trust workgroup output (Yes, I am a very active member). I think that the Threat Models are most important here:

Threat Models (WG Consensus Achieved)
Direct Project Security Overview (WG Consensus Achieved)
Certificate Pilot Recommendations Discussion (WG Consensus Achieved)

With TLS, you MUST create a walled garden. Any hole in the wall causes the whole thing to fail. If TLS was used there would be a private e-mail network just for trusted organizations, all organizations would need to be trusted.

TLS is not as care-free – PKI free - as Dixie tries to say it is. The comments about not being able to know if you are connecting to the right place is exactly evidence that PKI is need here. What is not needed with TLS is an out-of-band mechanism to distribute certificates, since TLS includes certificate discovery/distribution inline. But one must have a trust relationship.

It is this distribution of certificates that is the hard part of S/MIME. I send signed email messages to people that I want to be enabled to send me encrypted content. This mechanism of certificate distribution, sending a prior signed message, is the one that is used in practice today. I have tried to argue that any use of NHIN Direct messaging very likely was preceded by conversations that were not patient specific but were related to building a relationship. Between organizations this conversation was about what services one might offer another. These conversations likely included discussions about legal restrictions. These conversations could have easily have transmitted the certificate and setup a trust relationship.

also see: Healthcare Provider Discoverability and building Trust

TLS is great for point-to-point communications, or for communications with trusted-intermediaries. But it fails for end-to-end asynchronous message communications, and is NOT the right approach for e-mail.

Wrapping:
There is a little bit of discussion about 'wrapping'. The wrapping that is being discussed is S/MIME wrapping… that is to take an email message and put it inside another email message… Think Russian dolls… The theory is that if you keep wrapping enough times it must be secure. This can hide the ‘subject:’ line, but doesn’t hide the ‘to:’ or ‘from:’.

Yes one can have a highly intelligent email router that puts false ‘from:’ on the outside email, and somehow uses a trusted-intermediary-endpoint-address (‘to:’). Clearly lots of discovery problems here, or configuration and databases. But if you are going to configure this kind of a system, then we should just use a more capable system.

Scope of NHIN Direct
People keep forgetting that NHIN Direct is a transport for VERY SMALL providers with VERY LITTLE technology. These people only need to communicate with a few ‘others’. We need the NHIN Direct solution to help low-tech people. We needed it to work with little beyond off-the-shelf software, or exactly commercial (or open-source) off-the-shelf.  The NHIN Direct transport should NOT be looked to as a solution for more intricate workflows.

As part of this NHIN Direct has also recommended that email addresses could be departmental or organizational. That is one address that represents a whole department or whole organization. Thus there isn’t a huge number of addresses, one for each organization. I don’t think this is a great solution, as it basically brings us back to organization-to-organization rather than end-to-end; but it does put the policy decision in the hands of those that should make the policy decision.

So, I suggest they keep the scope clear for NHIN Direct… Allow simple e-mail with slightly complicated security… and get working on robust health information exchanges. Use NHIN Direct as a stepping stone, and stop thinking it is a long term solution.

See:  Directed Exchange vs Publish/Discover Exchange and NHIN-Direct Privacy and Security Simplifying Assumptions

Healthcare needs to watch and learn from the cascade of security failures

Wikileaks is the big news today. This blog article has NOTHING to do with WikiLeaks, but has everything to do with using the event which are associated with WikiLeaks today as a useful use-case to analyze in the context of Healthcare Security and Privacy.

It scares me that someone might think that exposing PHI on WikiLeaks would be an appropriate way to ‘expose’ a healthcare abuse. As much as the current exposure of the diplomatic cables has resulted in mostly embarrassing gossip, exposing PHI would be far more dramatic. The methods that WikiLeaks seems to use don’t give me any comfort that exposure of PHI might not happen. I hope that it would not. But this is not what I want to cover here.

I want to look at the security failures upstream of what we are seeing on WikiLeaks. I think there are very useful lessons to learn.

Data Classification: I understand that originally the Diplomatic Cables were classified ‘confidential’ or ‘top secret’ at one point. Which was later considered too restrictive, so they were re-classified to ‘secret’. This re-classification clearly was a key to the exposure of these cables, as about 3 million people have ‘secret’ clearance. This re-classification was felt necessary to give more access, which might have been the right thing.

It is my understanding that when data gets re-classified there should be new assessment of the data that might result in some information being blinded. I don’t think that this would have removed the gossip, but do wonder why such a bulk of data was either (a) originally classified wrong, or (b) so easily reclassified without recourse. I want to point out clearly, that I am still strongly for Data Classification and totally agree that there needs to be functionality for re-classification (up or down). It simply seems like sloppy process was used in this case.

What we can learn, is something we are struggling with in healthcare. That Data Classification is a rather blunt instrument, it doesn’t work very well to support fine-grained access controls. But it is a start, and better than no Segmentation.            See: Data Classification - a key vector enabling rich Security and Privacy controls

Access Controls: The re-classification gave access to a broader range of individuals. It is not clear why this was necessary. I will not try to figure out if this specific user should have access to this specific set of data. What I do wonder though is why this user also had the permissions necessary to export the reports, and put them on a non-secured storage. People are very creative, and I suspect this individual was creative enough to have overcome many Access Controls. Military or Diplomatic secrets would seem to need many layers of protections. Either they existed or this individual is more creative than most.

Audit Controls: The main failure that bothers me the most is that either no Security Audit Logs were produced that indicated that someone was viewing/copying THOUSANDS of documents, or that no one was watching the log. Even an automated program could have triggered easily when a hundred documents were viewed from the same place.  See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures

There has been a lot of press speculation that all of the documents, starting with the helicopter attack video, have come from the same source, a young U.S. Army intelligence analyst, who has been arrested. If that is the case it looks like access to vast databases of secret U.S. government documents was rather broadly available and access was not reasonably logged. None of the documents released to date have been marked top secret so, maybe, the database had some level of data segregation. But, if news reports are accurate, no log was kept of access to the database or, if such a log exists, it was not regularly reviewed, since suspicion was directed at the analyst by a person outside the U.S. military. More

Security and Privacy are not simple, they require checks and balances.

IHE Security/Privacy primer

Most of the IHE profiles in the security space are all simply pointers to common IT security protocols. The message is that healthcare is not special when it comes to security. That healthcare should just leverage the good work common to all IT. The following is NOT a complete explanation. I assume the reader can use a internet search engine to find resources including the specification themselves using key terms I provide. Clearly official profile text and standard text is the best resource.

ATNA - This is a comprehensive profile that indicates that Access Control, Audit Control, and Network Controls are important

• Access Control
  • There is no standards pointed to by ATNA here. There is simply a statement that a system needs to have access controls that can be shown to a local authority are sufficient to protect the systems resources according to the local policies
  • If this can't be demonstrated, then the system should not be authorized to be used. Specifically it should not be given a network identity (see network controls)
• Audit Controls
  • Specifically Security Audit logging
  • This is a very thin profiling of the commonly used SYSLOG protocols for communicating that an auditable event has occurred
  • There is statements that relax size limits
  • This is a FULL PROFILE of the content of that auditable event into an XML encoded message
  • There is a set of 'auditable events'. That is events that when they happen an audit log should capture what happens
  • The audit log message is fully describing: Who, What, Where, When, How, and Why.
  • This requires that the audit event time be kept consistent. Which is why the CT profile exists. The CT profile says use common NTP protocol to keep clocks synchronized to about 1 second, which is generally good enough for security audit logs
  • See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures

• Network Controls
  • There are a set of standards specific to the type of network communications. They all address three aspects of network communications of protected information. Not all network communications are protected, for example DNS is not generally needing to be protected as it is not communicating protected information (mostly)
  • Authentication of both sides of all communications that include protected information
  • This is consistently done using machine/service-end-point identities using public/private keys (certificates)
  • Certificates can be directly trusted. One-by-one
  • Certificates can be trusted because they 'chain' to a known authority (certificate) that is trusted directly
  • Caution: the method used on the internet with SSL certificates is technically the same, but not administratively the same. In the internet browser world the 'known authorities that are trusted' are authorities that your internet browser decides should be trusted.
  • ATNA wants a deliberate decision of trust to be done, not a decision by a vendor.
  • Encryption of the communications that include protected information
  • AES is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least AES needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
  • Integrity control of the communications that include protected information
  • SHA1 is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least SHA1 needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
  • Note also that the communications is transitory, not long-term-storage, so the use of SHA1 is acceptable. SHA1 tends to not be acceptable for long term signature (See DSG below)
  • TLS is the general mechanism when no other mechanism is used. TLS is the 'standardized' protocol that is more commonly called SSL. (mostly)
  • IHE profiles that BOTH sides of the communication need to be authenticated
  • Whereas common SSL only authenticates the server. This is not sufficient as it allows any client to connect. In healthcare we want to know where the data is coming from and where it is going. Not just the server
  • S/MIME is used for e-Mail
  • WS-Security mechanisms are allowed for Web-Services that want to use end-to-end security. Note that none of the IHE profiles leverage this as they are all profiles defining endpoints that need access. But this is specified because there may be deployments where someone puts in the middle of an IHE transaction some form of intermediary that needs partial access
  See Designing a Secure HIE

PWP - This is a very thin profile that simply says that for user directory, use LDAP

• LDAP is a protocol for doing queries of a directory. That directory might be a database or may be specifically a directory
• The schema for describing a user is based 99% on the common user
• The little addition to the schema is really not that important
• This profile also describes how to find the directory. Using a special DNS record that points at the LDAP directory
• There are pointers to how LDAP can be secured using TLS.
• There are pointers to how LDAP can be used to authenticate a user, through the LDAP security mechanisms
• LDAP is the standard that Windows ActiveDirectory uses for accessing directory entries
• Healthcare Provider Directories (HPD) is a profile leveraging LDAP as well for external use
  • See Healthcare Provider Directories. And Healthcare Provider Directories -- Lets be Careful

EUA - Very thin profile that simply says to use Kerberos protocol for safely authenticating users

• Kerberos is a pluggable protocol, but really is only used for username/password
• Kerberos is the standard that Windows ActiveDirectory uses for authenticating users.
• Kerberos is the standard that Windows uses at windows login (with minor Microsoft extensions)
• Kerberos is very common in Unix as it was invented at Berkely
• Kerberos is really good for within an organization, but has real problems that prevent it from being useful on the internet
• There are also Kerberos ways to pass authentication 'tickets' between an application and server
• See: Kerberos required in 2011 then forbidden in 2013

XUA - Very thin profile that simply says to use SAML Identity Assertions for authenticating users on Cross-Enterprise transactions

• This is the solution for the space where Kerberos doesn't work well
• SAML is both a standard for an XML way to describe a user and provide trust mechanisms of that data; and also a protocol
• The protocol is not part of the XUA profile. It is ok, but not as important as the assertion
• There are other protocols that are more common, WS-Trust is one.
• There is also good reason for a product that does its own user authentication to simply create SAML assertions w/o protocol
• See - Federated ID is not a universal IDand IHE ITI XUA++ - Trial Implementation

DSG - A profile of XML-Digital Signatures to provide long-term signature across a 'document'

• Can sign any document type. Not limited to XML type documents such as CDA
• Signature document is created that is an XML-Digital Signature blob
  • Original document to be signed is signed by 'reference'.
  • Encapsulation is not a bad thing, but it does make the original document harder to get at. Especially if that original document is not XML based
  • Signature by reference allows the original document to continue to be accessed normally by applications that don't need to validate he signature. While having the signature present for those applications that do need it.
  • The digital signature includes the Date/Time of the signature. Assuming trustable date/time
  • The digital signature includes the certificate of the signer
  • Note that signatures need to be valid for decades. Which brings up interesting certificate management issues not addressed.
  • The digital signature includes the reason for the signature. Why was it signed? What does the signature mean?

• XDS Metadata shows that the signature document is in a 'signs' relationship to the original document
  • This allows for finding the signature from a document, and finding the document from the signature
• Works for XDS, XDM, XDR, XCA
  • Might work for other environments as well. The main thing that must happen is for there to be a way to dereference the document ID number found in the digital signature document to get to the document that is being signed.
• Might be future work to have an encapsulated flavor
• See: Signing CDA Documents

BPPC - A profile of a document that represents a patient agreeing to a privacy policy (e.g. Consent)

• Uses CDA to capture that the patient has agreed to a policy by reference
  • The policy is not actually ever defined. 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

ENC - 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.

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.

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

Other

• Cookbook: Preparing the IHE Profile Security Section - Revised 2008-11-10
• HIE Security and Privacy through IHE- Revised 2008-08-22
• Access Control - Published 2009-09-28

Secure Design

• All this assumes that your system is secure by design. This includes limiting opportunities for bad guys.
• Risk based approach should be used to assure that all risks are managed appropriately
• Unnecessary services are disabled, security patches applied,
• Multiple layers of defense are in place both within and in the network
• Etc.