View
161
Download
1
Category
Tags:
Preview:
Citation preview
Berlin October 9 2002Timaru Eye Clinic, New Zealand.
CDA Access Control
The Immunological MetaphorMike Mair and Stephen Chu October 9, 2002, Berlin
Stephen Chu, PhD, FACS Mike Mair FRACOAssociate Professor of Health Informatics OphthalmologistDepartment of Management Science & Information Systems Timaru Eye ClinicUniversity of Auckland POB 319P.O. Box 92 019 TimaruAuckland New ZealandNew Zealand
Phone: 64 9 373 7599 Ext 7716 Phone: 64 3 6848515Fax: 64 9 373 7430 Fax: 64 3 6848531
Email: stephen.chu@auckland.ac.nz mikemair@eyetech.co.nz
Disclaimer: Although the Health Event Summary and Clinical Document Architecture have caused a lot of interest in New Zealand, we cannot claim to be part of an official NZ project at this time.
•The Clinical Data Architecture (CDA) is proposed as a common currency for electronic healthcare. •It might also be complemented by a single global technique for access control. •Gunnar Klein (who chairs CEN 251 and ISOTC/215 WG4 Security) recently said:
‘Do not expect quick solutions to the dream for a universal shared record which takes privacy concerns seriously’
He suggests that security is the ‘forgotten requirement for interoperability.’
•In order to fulfill the dream of a universal shared record standard, there must also be a shared technique for discriminating legitimate from illegitimate sharing. •That technique must be endlessly customizable because of the great diversity of access practices in global healthcare. •Kai Heitmann said in discussion on 8.10.02: “ we need an agreed way of doing transport and security mechanisms where local legislative requirements can be embedded”
•A New Zealand team prepared an Access Proposal to WG1 of ISOTC/215.
•We called for the creation of a universal healthcare packet, which we termed the ‘attestable unit’.
•It was paired with an ‘access lock’ for a universal access mechanism.
•This was modeled on the ‘bifunctional’ immunoglobulin family of molecules of immunological science.
In the immune system
….a single class of molecules, the immunoglobulin, exhibits bi-functionality in that each molecule has a ‘recognition’ end and a ‘business’ end. The recognition end which is highly variable, targets antigen, which is usually but not always material foreign to the organism. The ‘business end’, which is not variable, determines what action the molecule performs when the template match to antigen is made.
The ‘effector’ end of the IGG molecule
The recognition ends of the IGG
Immunoglobulin Structure
The amino acid sequence in the tips of the "Y" varies greatly among different antibodies. This variable region, composed of 110-130 amino acids, gives the antibody its specificity for binding antigen. The variable region includes the ends of the light and heavy chains. The constant region determines the mechanism used to destroy antigen.
IGM, the IGG pentameter
The universal role for immunoglobulinIn the body the immunoglobulin molecule
is pervasiveActs as a transmitter, a hormone, an
activator, a switch, a bullet...it can be extremely specific in its target, or
very generalNature has implemented a single design, If we can get a universal access control
process for the CDA, could it do the same for health informatics?
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
•The ‘access lock’ concept for the attestable unit was to act as a pointer to the attestable unit.
•We suggested that a ‘search object’ should activate it.
•We evoked dual key cryptography for the actual retrieval of the unit.
•The data would remain with the system of origin, along with the audit trail of the 5 WH of instances of access to the data
The ISOTC/215 Access Proposal
6.5.4 Class Diagram of Access Control Mechanism
request manager
access request
patient idrequest templateuser iduser rolereason for access
access controller
access lock
patient idcontent definitionaccess rulesreference to dataencryption keys
demographic data
audit trail
clinical objects
attestable unit
financial objects
6.5.5 Sequence Diagram of the Request Patient Information Usecase.
: Data User
: request manager
: access controller
: demographic data
: attestable unit
: audit trail : access request
: access lock
1:
14:
2:
3:
4:
12:
13:
11:
5: 6: 7:
8: 9:
10:
“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. “
Detachable Header
The Health Event Summary (HES)
derived originally from the Australian ‘Health Connect’ organization
It is a summary ‘package’ of healthcare data in standard format to be created with every ‘health event’, and is planned as a ‘shortcut’ to interoperability of healthcare data.
Its implementation was one of the recommendations of the NZ Ministry of Health ‘Wave’ project (Working to Add Value to Electronic Medicine)
The Clinical Document Architecture as HES (Chu et al 2002)
The CDA is designed to be just such an attestable global unit of healthcare. Its definition includes:
Persistence WholenessStewardship Potential for authentication.
“For communications over public media, cryptographic techniques for source/recipient authentication and secure transport of encapsulated documents may be required, and should be addressed with commercially available tools outside the scope of this standard.”Bob Dolin, CDA release 1
Is Access Control ‘out of scope’ for the CDA?
The Proposal from FinlandItala and Virtahen ‘Seamless care and the CDA’
“When certain pre-defined packages are ready for viewing, the original system creates a reference to that package of data……The package of data is defined as a CDA document. When the reference is created, the original system sends a CDA header of the document to the regional system……The entry contains the document id as a pointer to the original system (which)_...keeps a similar list of pointers to those documents it has created.. When the doctor wants to look at the patient data the regional system looks up the entry from the list of pointers…creates a full CDA document and sends it back to the original system.”
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.
Access process proposalAn 'Access-Lock' Object is created when the
clinician creates attestable clinical data and specifies the data's access right level(s).
This can be done at the clinical interview, directly on the instructions of the patient, although it is likely that ‘default’ access behaviour will apply in most implementations unless specifically countermanded.
The ‘lock’ object is stored with the data on the provider system
.
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.
Access Process Proposal
The CDA header is ‘detachable’ as in the suggestion from Finland,
The body can be ‘virtual’, that is only the header need actually be created at the time of data creation, which can be on any system whatsoever
A copy of the CDA header plus referent to the data is also sent to the regional server.
We suggest four stages for a universal access control mechanism to accompany the CDA as the universal ‘attestable unit’ of healthcare.
Stage One
• There is a ‘Login’ stage to gain access to the regional network, which includes presentation of a digital certificate with ‘role’ and ‘ID’ information.
Stage Two• A request/search object is constructed
which contains this user role information, along with the ‘id’ of the target patient, and an ‘index’ of the information required.
• It also contains the public key of the requestor’s institution. It is used to search the ‘CDA header lists’ on the network of regional servers.
Stage Three• When a match is made, including the
access lock role match, the searcher gets access to the referent of the stored or virtual CDA.
• The digital signature/certificate and public key certificate enclosed within the (SOAP) envelope authenticate the identity of the requestor and the public key that he/she sends with the request.
Regional Server data store
List of CDA Headers(or Access Objects)
Provider Server data store
Match found
LocatesCDA documentsource
Attestable UnitDocument informationEncounter dataService actorsService targetsClinical digest
Attestable UnitDocument informationEncounter dataService actorsService targetsClinical digest
Which may be onits own data store
Regional Server data store
List of CDA Headers(or Access Objects)
Provider Server data store
Attestable UnitDocument informationEncounter dataService actorsService targetsClinical digest Locates
CDA documentsource
Accessapproved
Encrpytionkey transfer
Stage Four
• The holder of the CDA data/document can then use the public key from the sender to encrypt the data/document, which can then only be decrypted by the requestor, ensuring confidentiality and integrity of the data transmitted across the Internet.
Regional(SOAP)Server
Datastore
Regional(SOAP)Server
Datastore
Requestor
Datastore
Provider(originatingOrganization) SSLSOAP security
SOAP EnvelopeDigital signaturePublic key certificateSOAP encryptionRole-base access control
Secure Socket Layer (SSL) SecurityCleint/Server authenticationSupporting SOAP encryption
SSL
SSL
2 CDA request in SOAP envelope
3 Route
request
to
neig
bour if n
ecessa
ry
3 Get com
plete CDA from
Provider if request and
access role matched
1 Request t
o neighbour server
CDA Documentin SOAP Envelop
SOAP Security
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.
CDA Confidentiality Attributes
The CDA does provide confidentiality attributes (or ‘hooks’ as Liora Alschuler called them) to aid application systems in managing access to sensitive data. Confidentiality status may apply to the entire document or to specified segments of the document. Some confidentiality levels have been demarcated, along with their ‘roles’.
Vocabulary domain for <confidentiality_cd>
Code Print DisplayName
Definition
C celebrity Celebrities are people of public interest includingemployees, whose information require specialprotection.
D clinician Only clinicians may see this item, billing andadministration persons can not access this item withoutspecial permission.
I individual Access only to individual persons who are mentionedexplicitly as actors of this service and whose actor typewarrants that access.
N normal Normal confidentiality rules (according to good healthcare practice) apply, that is, only authorized individualswith a medical or business need may access this item.
R restricted Restricted access, i.e. only to providers having acurrent care relationship to the patient.
S sensitive Information for which the patient seeks heightenedconfidentiality. Sensitive information is not to beshared with family members.
T taboo Information not to be disclosed or discussed withpatient except through physician assigned to patient inthis case. Example use is a new fatal diagnosis orfinding, such as malignancy or HIC.
Role Words
Role words in a language, like most other words, are language specific.
Is ‘Verstehen’ the same as ‘Understanding’?Is ‘Spirituel’ the same as ‘Spiritual’?Most role words simply do NOT translateThe ‘Chess’ analogy for language: SaussureThe concept of ‘autopoiesis’ : Varela
Roles as self defining ‘autopoietic’ sets
Access OntologyC,D,I,N,R,S,T….. CHESS
Diagram to summarize how an autopoietic (self defining) set, whose values are internally derived, can neverthelesstrigger a finite list of access options/attributes in the ‘body’
Cross border role mapping
Dynamic, like roles themselvescomplex, difficult, somewhat arbitraryachievable however, This kind of activity already exists e.g.The Ontology Interface Language (OIL) for
the ‘semantic web’The CDA design itself should be ‘empty’ of
cultural definitions.
Provider Regional Network Requestor
Retrieving CDAs from the network…….they might cling to the search sticks, like termites!
The ‘end dream….’A single pervasive device, the CDAA simple shared access processendlessly customizable, can act as a stand alone, a component, an
EHR extract (GEHR/CEN), a ‘fix for now’, a stage in a global evolutionJust let it go, release it in global healthcarefacilitate the emergence of ‘implicate’ orderLet’s give Gaia an immune system, maybe
she will heal...
Thank you for your attention
Many thanks to the organizers of this wonderful event
Recommended