I will not profile policy, I will not profile policy, I will not ... x100

I probably need to write this more than 100 times, since I wind up doing it so often.

We reviewed the work I had done on the GAO profile I talked about yesterday.  For a lot of what the CDS system needs to do, it is:

1. Not interested in certain details.
2. Would prefer not to know other details.

From an interoperability perspective, it can simply ignore #1, rather than having us profile them out.  For #2, there are questions of liability, in which the receiver really doesn't want to be responsible for dealing with someone else's PHI.

The first case represents the profile's lack of requirements or interest.  Rather than profile these out, we are going to identify those that are permitted by the profile, but which may be suppressed either by the sender or the receiver for business, security or privacy reasons.  These are mostly, in this case, business reasons.

The second case represents the receivers specific requirements in certain cases that some details not be sent, because they then become responsible for dealing with the content in ways that they would rather not have to.  In this case, we'd like the profile to support their use of the content, but we won't impose their policies for integration with their system.  Instead, we'll let them impose those policies. So here, we will identify those data elements for which their may be some concerns in the security considerations section, and note that receivers may prohibit use of certain data elements according to their own policy.

This greatly simplifies the profile.