Hi all.
To operationalize the consent management flag, our client registries will need to support the saving of a Y/N flag in a PD1-12 segment associated with a client’s “golden key” (their enterprise client ID, ECID). If the PD1-12 segment is sent to the CR via an ITI-8 transaction (our specified OpenHIE patient demographic add and update transaction) then our CR applications will need to be able to save it. As a useful and immediate source code modification, it would be likely easier to provide this ability (to save the PD1-12 field for an identified ECID) as a feature in the console application.
Of course, our CR applications will need to return the PD1-12 field as part of the results of an ITI-21 transaction. This is not at all outside the existing IHE standard. The top of page 158 in IHE ITI TF vol 2a (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2a_FT_2011-08-19.pdf) reads: In addition, the Patient Demographics Supplier Actor shall
return all other attributes within the PID segment for which it is able to supply values.
For the Interoperability Layer – it will need to have branch logic in its orchestration on the Query Patient-level Clinical Data workflow. This may require replacing the present ITI-9 transaction (at step 2 of the workflow) with an ITI-21 transaction; ITI-9 is not required to provide the full set of PID content. The logic would then be IF PD1-12 = ‘Y’ THEN return exception message ELSE process the query normally. The content of the exception message is something we should think carefully about. It might be useful to contemplate future “break the glass” capability by at least indicating that content for the client DOES EXIST… but it is not disclosed.
I hope this gets the ball rolling re: our support for consent management. 
Have a good weekend, everyone!
-Derek.