Layered security services model
Security issues can be grouped into the concepts communication security and application security. Communication security deals with the connection to, and the communication between, systems, thereby preventing attacks on system and communication channel. Application security concerns the use of a system’s functions and data. Figure 2 presents the layered security services model covering the security system from concepts through services, mechanisms, algorithms and data. Just mechanisms, algorithms and data might be specific for pathology.
While communication security is domain-unspecific, by that way enabling the re-use of advanced communication security services developed in other domains like banking, application security is highly specific for health due to the social impact of personal health information. So, application security is the challenge we have to deal with, covering safety, security and privacy of health-related services and personal health information. While technical specifications such as the identification and authentication of entities are manageable depending on the distinguishing features used such as knowledge, tokens, properties, privacy-related services such as privilege management, authorization, access control, etc., summarized as policies, are defined in legislation, regulations, rules, consent statements or documents, codes of ethics, etc. They are usually not formally expressed and a matter of interpretation (so keeping myriads of lawyers busy). All aspects of an eHealth system such as the medical, legal, administrative and technical ones have to be managed (analyzed, specified, implemented and maintained) in an architecture-centric and formalized way. Therefore, they must be related to the architectural framework chosen, as presented in Figure 3 for security and privacy services using the GCM.
Thereby, the system’s components, their functions and interrelations – in other words, its architectural description – can be instantiated for any object such as documents, messages, devices, specimen, images, holograms, etc. So, integrity check for images can be provided by an image signature, using special algorithms to characterize color histograms, texture properties, global and local attributes. Authentication of origin or ownership can be provided by watermarks, frequently used for managing copyrights. Here, visible or invisible information is provided to an image in a way that is difficult to remove. Digital watermarks can be modified by, e.g., lossy compression of data, cropping an image or video, or intentionally adding noise. In this paper, we do not tackle steganography which enables the transportation of secret information hidden in an image.
In the next step, the architectural specification has to be developed for a security and privacy sub-domain: the domain of policies. In its general definition, a policy is a complex of legal, organizational, functional, medical, social, ethical and technical aspects, which must be considered in the context of security and privacy. A security policy defines the framework, rights and duties of principals involved, but also consequences and penalties in the case of disregarding the fixings taken (limited to persons). Using the GCM according to ISO 22600 “Health informatics – Privilege management and access control” , Figure 4 presents the architectural composition/decomposition of policies.
The knowledge representation challenge
As introduced in above, interoperability is based on knowledge shared between the involved principals about the common business objectives, the business context, motivation, etc., as well as the appropriate actions taken. Therefore, knowledge representation (KR) is crucial for advanced cooperation. Since this is a difficult task within one domain already, among others depending on the complexity of a certain domain, the aforementioned challenge is even bigger in a multi-disciplinary approach like pHealth.
The science dealing with the representation of structure and behavior of systems is called ontology. To avoid the endless battle between philosophers and domain experts who consider general aspects of reality vs. domain-specific specializations, a layered system of ontologies has been introduced providing an architectural approach to the system “ontology”, thereby reflecting the different granularity levels of the GCM (Figure 5).
Application ontology describes the business concepts the ICT solution should support. For achieving interoperability between different applications within a certain domain (e.g. medicine), the involved application ontologies have to be mapped using the domain ontology. Integration of different disciplines represented by different domain ontologies is moderated by top-level ontologies. Health-related ontologies contributing to an interoperability environment have been checked, harmonized, and approved as member of the Open Biomedical Ontology Foundry (OBO Foundry). They have been derived from the Basic Formal Ontology (BFO), which is a formal top-level ontology based on tested principles for ontology construction, subdividing reality into two orthogonal categories and thereby bridging the gap to the next ontology level . They can be used as references to overcome weaknesses and inconsistencies of existing terminologies claiming for an ontology, and to reflect the aforementioned system of ontologies appropriately. The final criterion proofing the correctness of the approach is the universal reality (philosophically the thing itself, or the philosophical categories) independent of the scientific interpretation of special instances of the universe. So, the generalization leads from the representation of scientific concepts and their relations as knowledge representation up to the definition of universal building blocks (components) and their interrelations within the classic ontology.
Practical interoperability models describe the business case (Enterprise View) of multi-disciplinary pHealth solutions, where pathology is one domain with several sub-domains. They represent the systems in question using the corresponding application ontologies harmonized by a domain ontology. Different domains are integrated by mapping them through top-level ontologies. The resulting business model is informationally represented using ICT ontology and thereafter implemented according to a unified development process. This is, by the way, the least challenging part in the game, even if computer scientists or informaticians usually like to be the most prominent player in eSociety solutions.
The representation of both knowledge and high level ontologies is also a matter of the representation language, ranging from natural language through vocabularies, dictionaries, thesauri, meta-languages such as XML, frames, formal languages, prepositional logics, predicate logic and modal logics up to universal logic . The abstraction or formalization level depends on the level of commonality achievable. As more different the domains are as more knowledge including meta-knowledge about the representation style has to be communicated, guaranteeing commonality in “understanding” just at a level of higher abstraction.
Examples for formal policies represented in XML, predicate logic, or formal languages can be found in .
Privilege management and access control
Managing rights and duties of actors regarding the different personal information objects of an identified subject of care has traditionally been ignored or as much as (or even more than) possible simplified, leading to privilege or authorization attributes in databases or role-based privilege management and access control solutions in open and distributed environments. Here, actors have been grouped according to their role in a business process. Furthermore, the information objects have been classified according to their sensitivity. As a result, the relations between actors as well as between them and related objects have been dramatically reduced.
In pHealth including pPathology, such coarse-grained approach does not appropriately reflect the process context with its environmental as well as personal conditions. So, all the components have to reflect those constraints expressed by corresponding policies, as shown in Figure 6.
Structural and functional roles thereby represent the relations of a principal to an organization or to an activity within a process respectively according to ISO 21298 Health informatics – Functional and structural roles . Design and specification of all architectural components of the selected business case and their binding is done highly dynamically. This concerns all domains involved including the policy domain ruling privileges and access control.
A generic reference model for the informational representation of privilege management and access control in a business context has recently been standardized in the HL7 Common Security and Privacy Domain Analysis Model. This specification, provided as Draft Standard for Trial Use and thereby offering the opportunity to implement, to test and to improve the specification, is the first international standard which took up the challenge to combining the very advanced definitions of, e.g., ISO 22600, ISO 21298, OASIS SAML 1.1 , OASIS OASIS XACML 2.0 , OASIS AVDL 1.0 , etc., to one harmonized and comprehensive view, as demonstrated in Figure 7.
The offered model provides a combination of the composition/decomposition schema of policy base classes, of informational references (to be developed and refined in the future), the actor schema (to be developed and refined in the future) as well as the actions defined. Here, the reference to Figure 3 is recommended. The standard document also provides specifications to migrate to existing HL7 solutions like the HL7 RBAC Permission Catalogue , the Patient Consent Policy Document , and many others.