Your SlideShare is downloading. ×
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Dunedin accessppt
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Dunedin accessppt


Published on

Published in: Technology, Health & Medicine
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Access to the health record Draft report ISO/TC215/WG1
    • Prepared by the New Zealand Delegation
    • Wednesday 21 June 2000
    • Vancouver
    • Canada
    • something we could achieve ...
  • 2. From the TC215 Scope Statement
    • “ Standardization in the field of information for health, and Health Information and Communications Technology, to achieve compatibility and interoperability between independent systems.”
  • 3. From the WG1 scope statement
    • The scope of WG1 is to develop standards for the trusted management of information concerning health and the healthcare process.
    • WG1 will address health record standards that are independent of setting and technology. The standards will enable the availability of the appropriate information at the place and time of decision.
  • 4. From the WG1 scope statement ‘Terms of Reference’
    • create a framework of standards that enables health information to be created, used and shared across any and all boundaries including systems, jurisdictions, disciplines and professions
    • adopt a consistent modelling approach across all health informatics standardization activities, based on an existing modelling notation.
    • include, but not be limited to, the content, structure and documentation of the health record, integration of patient information, interoperability and decision support
  • 5. From the resolutions of the WG1 meeting, Tokyo, Nov.’99
    • The agreed title of the Work Item is “Access to the Health Record”
    • The objectives of this Work Item are to define concepts for modelling access, not to determine a set of rules for access
    • A further recommendation was that the work item should lead to a 'technical report', not a 'specification’, and that it should be done in collaboration with WG4.
  • 6. Role of WG1 within ISO/TC215
    • WG1 is the ‘pilot’ committee which should integrate the work of all working groups
    • Interoperability is a key goal of the TC215 process, and of the access item in particular. In our view, this will demand solutions which are both simple and flexible
    • Mention of a ‘shared notation’ indicates we should be developing ‘concepts for modelling access’, ie Models
    • UML was identified as an appropriate notation
  • 7. Overview
    • The ISO/TC215 process has a strictly defined time span
    • there is an urgent need for an accepted access model, and for its implementation
    • We discuss policy issues and propose a model of/for EHR access
    • An agreed access model would be of relevance to all WGs in the TC215 process
  • 8. WG4 defined the task
        • 'To define the essential elements of a health care public key infrastructure to support the secure transmission of health care information across national boundaries.
        • The specification must be Internet based if it is to work across national boundaries.’ from the Technical Specification Draft for Secure Exchange of Health Information, February 2000
    • It seems likely that the public key infrastructure proposed by WG4 will provide the basis for implementation of a global system.
    • The concept of ‘attribute certificates’ would seem to be crucial to the implementation of access control by ‘role’, and
    • our task is to develop a model of the ‘access’ process which will enable that synthesis.
  • 9. Beyond reviewing current concepts and practices, the ‘access control’ task for WG1 can thus be re-stated:
        • To propose a global policy to both accommodate jurisdictional and national differences in access control and facilitate cross border access
        • To marry these concepts with the evolving work from WG4 (including the Technical Specification Draft for Secure Exchange of Health Information, February 2000)
  • 10. (a brief anthropological detour…) The Definition of Social Man
    • Different cultures have distinct views of social responsibility and distributive justice
    • Western industrialised societies tend to emphasise individual autonomy
    • Many others regard the concept of 'self' as more socially constituted
    • In order to be truly international, an Access Standard would need to accommodate diverse definitions of self and society
  • 11. The ISO Access Standard -
    • must contain a framework which permits diverse solutions to the age-old questions of self and society
    • should facilitate exchange of health information between systems with different 'set up' configurations in the networks of rights, obligations, access, and privacy considerations that surround health records
  • 12. The Concept of Ownership
    • The concept of ‘ownership’, which can be deconstructed into rights and reciprocal obligations, is problematic when viewed cross-culturally
    • A decision was taken by WG1 members at the Tokyo meeting November 1999 to delete the ownership concept from the title of the work item
  • 13. Review of international literature on access to health records
    • We presented a critical overview of national standards and procedures, including assessment of the extent of international consensus on principles relevant to access(please refer to this in the document on the WG1 web site)
    • many OECD countries have broadly similar rules and restrictions regarding access, but:
    • details vary considerably, and
    • relatively little information is available about practices and procedures in other countries
  • 14. Types of Access Control
        • Client hostname and IP address restrictions
        • User and password authentication
        • Role based Access Control
    • Strong authentication techniques
      • Digital and Attribute Certificates
      • Public-Private key encryption (eg PGP)
  • 15. Role Based Access Control (RBAC)
    • The decision to allow access to objects is based on the role of the user, rather than on permission based on another user.
    • The determination of the role membership and the allocation of each role's capabilities are determined by the organisation's security policies.
  • 16. Developing operational concepts and their interrelationships
        • Roles and Rules
        • Self–defining systems of roles
        • The Role concept in Messaging
        • The Role concept in Security processes
  • 17. Rules and Roles
    • Cultural concepts regulating access can be considered as sets of ‘roles’, and ‘rules’ relating those roles.
    • Operationalizing is challenging and will show up redundancies, inconsistencies (eg David Jones’ UK scenarios, see Form 4 attachment)
    • Systems of roles and rules are mutually defining. Our task is not to try to evolve some sort of ‘definitive set’ but rather to develop a model that can accommodate different sets of rules and roles yet remain globally interoperable
  • 18. Self–defining systems
    • The concept of ‘self defining system’ comes from linguistics, cybernetics etc.
    • The game of chess is an example.
    • The concept of ‘roles’ has its own extensive literature in sociology
    • a truly international standard must accommodate and express cultural variation in such systems of roles
  • 19. Maori concepts in Aotearoa/New Zealand
    • the notion of an extended family group ( whanau ) helps to explain the Maori’s greater collective interest/input bearing on access to personal information
    • infirm or incompetent individuals often have a 'minder' ( Kai Awhina ) consensually assigned by the whanau , who is then responsible for decisions relating to, the individual's health care
    • whanau in practice may overrule the decision of an individual to undergo a medical procedure (e.g., abortion) based on cultural values and extensive social supports.
  • 20. The Role concept in Messaging
    • the concept of role is defined (Hinchley CEN "A role of a healthcare agent is undertaken in the context of their relationship with another agent".
    • the ‘messaging’ standard role appears to comprise an agent , a context and an action .
    • Thus a role can be considered a simple syntactic structure
  • 21. The Role concept in WG4
    • The WG4 paper uses the concept of ‘role’ in relation to ‘attribute certificates’.
    • control decisions about request and disclosure can be rule-based, role-based and rank based .
    • ‘ attribute certificate’ supply role information
    • bound to a health professional’s public key.
    • a health professional may have many of these, which reflect multiple roles.
    • attribute certificates are typically more short lived than the identity certificates
  • 22. Minimum ‘Access’ Concept Set
    • Four Related Concepts
      • Access
      • Failure of Access
      • Rights
      • Obligations
  • 23. Three irreducible outcomes
    • Access - Access Criteria Matched, information identified and and available
    • Failure of Access - information identified, access denied - PRIVACY
    • Failure of Access - information not identified to requester - SECRECY
    • Failure of Access may also occur because of system failure or because the information simply does not exist
  • 24. The Access Control Matrix
    • The level of rules and roles can be modelled at a higher level, and triggering one of three outcomes
    • This would depend on the match between the reasons for access offered by the request and the criteria required to access the target data.
    • The computations involved can be modelled with an Access Control Matrix (ACM). This can have as many dimensions or variables as are found necessary.
  • 25. The Generic ACM
    • A generic ACM would specify the dimensionality of the variable space on which roles can be defined.
    • It would not specify any particular role or rule set.
    • Each jurisdiction would need to define this, although much is shared, eg OECD
    • The generic ACM is EMPTY.
  • 26. Jurisdictional boundaries
    • Part of the scope is to develop concepts and models of EHR access control across jurisdictional and national boundaries.
    • . Differences in access control policies are one of the defining parameters separating jurisdictions.
    • . A jurisdictional boundary is not necessarily the same as a national boundary, and could be as small as a single provider
    • Some big companies ignore present jurisdictional boundaries, or want to!
  • 27. Requirements for EHR Access
        • Availability
        • Data Integrity
        • Auditablility
        • Confidentiality
        • Accessibility
  • 28. Availability
        • What : there should some indexing system for classification and retrieval. (It is the task of WG3 to determine this)
        • When : a method should be defined for regulating access to health information with respect to time.
        • Who : personal identity information, regulating ‘who’ can access a demarcated segment of information, based on their role and the situation (e.g., urgent medical need for records).
        • Where : there should be a location of source identifying system applied to health information, which determines where information can be accessed
        • Why : there should be a ‘reason for obtaining’ information applied to demarcated segments of health information
  • 29. Auditablility
    • EHR should be auditable, with regard to content and
    • by an ‘audit trail’ of access (an ‘access history’ for health information should be traceable)
    • It should be possible to discern modification/updating of EHR using version control
  • 30. Data Integrity
        • There should be processes which verify data as unchanged when communicated
  • 31. Confidentiality
    • Procedures should be in place which restrict access to health information by defined criteria (e.g. the ‘what’ ‘when’ ‘who’ ‘where’ and ‘why’ list above)
    • The criteria, which may be culture- or jurisdiction-specific, must be able to be locally defined according to ethical precepts current in that jurisdiction. These may or may not include individual consent, depending on the situation
  • 32. Interoperability
    • There should be a process or processes mediating the exchange of health information at jurisdictional boundaries
    • This should allow EHR to interoperate in a way that is truly global yet respects local customs and culture. It follows that the process should be both simple and be amenable to customisation in different jurisdictions
  • 33. Accessibility
            • There should be open access to a EHR standard for suitably credentialled workers.
            • Like a currency, the interoperable standard should not be owned or privately controlled
            • ISO-compatible records should be able to be ‘open source’ in principle (if only because some record systems are!)
  • 34. Policy or Model?
    • Should this draft technical report on Access proceed further?
    • Was the ‘Technical Report’ to be limited to WG1?
    • We understood that it was to be collaborative with WG4
    • In the absence of their input, we developed the matter further ourselves
    • We believe that further progress depends on active collaboration
  • 35. The Access Object Model
        • Axiom 1: Data collection in medical practice occurs at the clinical interview and other clinical encounters.
        • Axiom 2: Access to EHR and other health resources will be significant determinants of how medical and personal narratives develop.
        • Axiom 3: There is a need for a generic technique to de-identify data. This facility must be built in to any global system.
  • 36. Access Objects 1
    • We propose a class of metadata (data about data) objects, which are created alongside health data at the clinical encounter or interview
    • These contain the referent to the data. They are “proxy” data objects
    • Access to data is through them, employing public/private key encryption
    • The audit trail is kept with the data.
  • 37. Access Objects 2
    • Access Objects could serve different schemata for data structure and architecture. (USAM, CEN,GEHR etc)
    • They would also be functional for linkage to data objects with little formal structure, e.g. word processed documents,
    • this would serve technologically unsophisticated environments
  • 38. Access Object attributes
    • Patient ID
    • Content definition / index
    • Access Rules and Roles (ACM)
    • Reference (address) to data
    • Encryption keys
  • 39. Request Object attributes
    • Patient ID
    • Request content template
    • User ID
    • User Role
    • Reason for Access
    • Consent (if applicable)
  • 40. To Summarise the process
        • The collection of clinical objects formed at the clinical encounter has an access object assigned to it.
        • These contain a key to the data contained –(patient ID), a content definition, indicating the type of information contained in the object, the ACM applicable to the object, a reference by which the data can be located, encryption keys
        • The definition and grain of the clinical objects is not defined by the access system
  • 41. Summary 2
        • The Request Object made by the request manager would also contain encryption keys verifying ID and role of requesting agency, and the access rules for that role (what classes of data can be accessed, as well as a content template, and a statement of ‘reasons for request’).
        • If the ACM of the access object, and the roles and reason for request as well as the content search criteria from the request object are met, the requesting agency gets access to the referent in the access object
  • 42. Summary 3
        • There is a final verification stage for the source of the requested data using the encryption key which is part of the access object, and then a ‘secure socket’ connection is established which permits exchange of data.
    • This concept might bridge the work of WG1,2 and 4, but WG3 would need to address content coding.
    • The access objects might be web-based, stored on smart cards or other mobile media (WG5)
  • 43. Integration with WG4 model
    • The proposed model would work by authentication of identities and roles occurring like 'welds' or 'rivets' in the ongoing process of medical work.
    • In UML models of the access process, we can now identify where these ‘rivets occur’.
  • 44. The ‘Access Object’ model in UML notation
    • These diagrams use this notation to express the concepts, and are not intended to specify an implementation
    • the diagrams are incomplete because they do not specify the cardinality and multiplicity of the classes displayed
    • this is corrected in the latest version (19 June 2000
  • 45.  
  • 46.  
  • 47. Conclusion
    • Our legitimate task is modelling the Access Process for the ISO standard
    • Fair concordance is found in some models of the process, enough to start from.
    • We have suggested a particular model, but it is not a specification, and the policy part of our document can be considered a ‘stand alone’
    • We advocate that the matter be explored further with WG2,3,4, and 5.
  • 48. Policy or Implementation
    • The comment has been made that we have presented an implementation rather than a policy statement.
    • We remain convinced that a report which did not point the way toward an implementable standard would be a waste of time.
    • Our work in pursuing the standard is preliminary, and is more in the domain of proposed policy than technical detail.
    • Our hoped for collaboration with WG4 is thus a logical necessity
  • 49. Dangers of ‘de facto’ standards
    • Small players excluded
    • Culturally insensitive
    • Interoperability problematic
    • Inefficient use of resources (human, time)
  • 50. The reality of cultural differences
    • there is broad sympathy among Western industrialised nations in access policies but..
    • many cultures including some with ISO representation and others not well represented in TC215 see things differently.
    • We require a solution which is flexible enough to allow for these cultural differences in roles and rules for ‘access’
  • 51. Global interoperability is the goal. What would it be like?
    • It should be possible for health care workers, with the minimum of resources or technical sophistication other than their skills in health care to create and use ISO compatible and conformant records.
    • The standard should not be a barrier to healthcare, but should facilitate it.
    • The simple process model described is argued to be in some sense to be necessary.
  • 52. We should work to facilitate global healthcare But it will not happen of itself, we would need to decide to do it...