Policy vs. Technology

Two interesting discussions came up at IHE meetings and IHE CDA training over the last week about where policy collides with technology.  The first issue arose during discussion of a change proposal, when we started talking about whether coded results should be "required" in a coded results section.  The issue raised was that sometimes you have a result such as HIV status that cannot be released due to privacy issues.

What should a developer do when a specification disagrees with policy?  Well, in this case, almost always, policy needs to be able to win.  The reason for that is that regulation and law have much stronger mechanisms for enforcement than standards bodies (e.g., jail and financial penalties).  The debate ensued as to whether this data element should be "required", "required if known", or simply "optional" (these are terms that are disappearing eventually from IHE PCC specifications, but are still in use today and we aren't ready to fix them in one place without fixing them in the entire framework).  My response is that you treat that data that you are prohibited from sharing as if it was either non-existent, or not-available (you don't have it).  But, we shouldn't alter the specification just to address this single policy issue (e.g., make the data element conditional based on policy), because then all data elements would need to be conditional based on policy.

The right thing to do here from a technology perspective is make it easy for implementers to follow policy, but not let adherence to policy (which varies widely) dominate the specification.

From a compliance/conformance perspective, what this means is that the software should demonstrate the ability to do what the specification says.  But then realize that in the real world of implementations, policies will determine how things are employed.

So, IHE says you have to use ATNA with XDS, but there are no IHE police who will descend upon an organization to haul miscreants away if they don't deploy it that way (that's a job for OIC).

The second issue that comes up where an organization that receives clinical information has some concerns over displayName and codeSystemName attributes in code elements.  They want to be sure that the right values of the codes are being sent to them.  Now, according to HL7 these elements are optional, and in most systems, the principal purpose that I've seen them used for is to help with implementation and diagnosis of issues during pre-go-live activities.  I tell people to put them in because they'll thank themselves for it later when they are trying to track down problems.

But the challenge for receivers is that when the data is there, they think they have to do something with it.  In this case, they were considering verifying that the display name is "right".  In this particular case, it gets really challenging, because for many code systems, the display name is NOT an authoritative field.  It is used for human access and understanding of the code, but the code is almost always what carries the correct semantics.  So, if you put in place edits, say to verify that they've sent a valid ICD-9 code, but the display name doesn't match, one of several things could have occurred:

1. The organization is populating display name from a short name instead of the long name.
2. The display name got truncated.
3. The display name is in upper/lower case for easy reading, and you are expecting all upper case.
4. The sender might be working in a different (human) language than the receiver.
5. There might be minor spelling errors in some display names (on either side!).
6. They might have messed up the code table.

The first few are far more likely than the last, and the sender won't thank you for pointing out these inconsistencies to them.  After all, the display names and code system names are there to ensure good maintenance of the product NOT to convey machine readable semantics. 

I've written previously about the propensity of data receivers to insist on organizations formatting data to meet their needs.  That often increases costs because of the lack of re-usability of existing data and and/or workflows. Make it easy on your senders, and they'll thank you for it.