1. Berlin October 9 2002 Timaru Eye Clinic, New Zealand. CDA Access Control The Immunological Metaphor Mike Mair and Stephen Chu October 9, 2002, Berlin

7. The ‘effector’ end of the IGG molecule The recognition ends of the IGG

9. IGM, the IGG pentameter

11. Suggestions for inclusion in the Header : searchable meta-data to facilitate its use in access control. Will the rules for a document ontology do this? Document-class service+ condition, clinical category, practice setting, +role Include ‘role for access’ , similar to the CEN ‘distribution rule’ part 3 of the 4 part standard ENV 13606

15. “ At the presentation to WG1 meeting in March 2001, Seoul, Korea, I mentioned that the CDA might function as the attestable unit, and the access lock might derive from a ‘detachable header’ for the CDA. “

16. Detachable Header

22. checkDocInfo( ) - object operation/method defined for the CDA Header/Access Object to get the meta-data information about the document as part of the matching function required to determine whether there is a match between the document requestor wants and the CDA header stored checkServeTarget( ) - also object operation/method defined for the CDA Header/Access Object to get the patient identified by the requestor for the CDA document required is the target patient for whom the CDA header (in the regional server list) was created for getOriginatingOrgNetID( ) is an operation/method defined for the the CDA Header/Access Object stored on the regional server. This operation will interrogate the CDA Header List stored in the regional server which should hold the Network ID/address of where the original attestable CDA data/documents are held - the Provider Organisation that created and stores the data/document, or the regional server itself.

24. matchReq&DataAccessRole( ) - an object operation defined for the 'Access Lock' object to detemine whether the 'Role for Access' supplied by the 'Request Object' is of the legal role for access the data for which the 'Role for Access' attribute has been defined.

26. We suggest four stages for a universal access control mechanism to accompany the CDA as the universal ‘attestable unit’ of healthcare.

31. Regional Server data store List of CDA Headers (or Access Objects) Provider Server data store Match found Locates CDA document source Attestable Unit Document information Encounter data Service actors Service targets Clinical digest Attestable Unit Document information Encounter data Service actors Service targets Clinical digest Which may be on its own data store

32. Regional Server data store List of CDA Headers (or Access Objects) Provider Server data store Locates CDA document source Encrpytion key transfer Attestable Unit Document information Encounter data Service actors Service targets Clinical digest Access approved

34. SSL SOAP security SOAP Envelope Digital signature Public key certificate SOAP encryption Role-base access control SSL SSL Regional (SOAP) Server Data store Regional (SOAP) Server Data store Requestor Data store Provider (originating Organization) Secure Socket Layer (SSL) Security Cleint/Server authentication Supporting SOAP encryption 2 CDA request in SOAP envelope 3 Route request to neigbour if necessary 3 Get complete CDA from Provider if request and access role matched 1 Request to neighbour server CDA Document in SOAP Envelop SOAP Security

35. If the regional server that received the request for the CDA document cannot find a match on its CDA header list, it will pass on the request to a neighboring server, which will pass onto the next ...... until a match is found and the procedure of the previous paragraph will be performed, or it returns a ‘no find’ result. NB: This model assumes continuous ‘on line’ availability of data from providers.

39. Roles as self defining ‘autopoietic’ sets

41. Provider Regional Network Requestor Retrieving CDAs from the network…….they might cling to the search sticks, like termites!

43. Thank you for your attention Many thanks to the organizers of this wonderful event