The `cube` meta-model for the information system of large health sector organizations - a (platform neutral) mapping tool to integrate information system development with changing business functions and organizational development László BALKÁNYI Dept. of Medical Informatics, Semmelweis University, Budapest, Hungary e-mail:
[email protected] Abstract To develop information systems (IS) in the changing environment of the health sector, a simple but throughout model, avoiding the techno-jargon of informatics, might be useful for the top management. A platform neutral, extensible, transparent conceptual model should be established. Limitations of current methods lead to a simple, but comprehensive mapping, in the form of a three-dimensional cube. The three `orthogonal` views are (a) organization functionality, (b) organizational structures and (c) information technology. Each of the cube-sides is described according to its nature. This approach enables to define any kind of an IS component as a certain point/ layer/domain of the cube and enables also the management to label all IS components independently form any supplier(s) and/or any specific platform. The model handles changes in organization structure, business functionality and the serving info-system independently form each other. Practical application extends to (a) planning complex, new ISs, (b) guiding development of multi-vendor, multi-site ISs, (c) supporting large-scale public procurement procedures and the contracting, implementation phase by establishing a platform neutral reference, (d) keeping an exhaustive inventory of an existing large-scale system, that handles nontangible aspects of the IS.
1. The scope and goal of a `cube` meta-model of the information system Most health sector organizations undergo continuous development/changing concerning functions and organizational structure. There is a need for the top management to understand these changes in terms of needed IS services. This understanding must be shared among the members of the top-management, hence the method used to discuss the IS problems should avoid the techno-jargon of informatics. A model is needed, that is (a) platform neutral in terms of information technology, (b) extensible in terms of level of details, (c) retains transparency for all kind of management. `Off the shelf` software development tools or methodologies (i.e. traditional SSADM and the new generation of fast tools like XP, the Crystal Family, HASD, Scrum, Coad's FDD, DSDM or RUP, [1] large project management methods (i.e. PRINCE2, [2]) and general IS modeling methodologies (i.e. UML, [3]) offer a wide range of enterpriseview level models for understanding the IS, but none of these tools offers understandability for non-IT trained top-level managers. A simple, but comprehensive mapping solution is suggested by establishing three `orthogonal`1 views of the IS, as (a) system functionality: what are the supported business functions? (b) organizational structures: what are the operational organiza1
A common failure in modeling the information system is not to recognize the orthoganality i.e. the independence of the later explained views. The orthogonality enables the abstratction of multidimesnional infromation space.
tional units and what is their relation to each other, (c) information technology: what are the applied methods/tools, the actual IS components? These views can be mapped to a three dimensional conceptual space [4]: a `cube` meta-model seems to be the most adequate tool to visualize the result of mapping. Cube-sides are described according to the nature of that relevant side. From a conceptual point of view the descriptions are different kind of structured lists:
Functions supported by the information system
1, 2, 3, …
X
Organizational structures: a, b, c, …
A, B, C, …
Information system technology layers:
Fig. 1. `Tagging` a component of the info-system cube: component ‘X’ has value ‘B2a’ This approach enables to define, later to locate or identify/register any kind of IS component (hardware, software, communication or network item, even orgware or other components as a certain point, layer or domain within the cube. To identify any component, three values (or ranges) ensure unambiguous labeling: `Component X` will have the `value` of `B2a`. Obviously, the most ‘health-sector-specific’ side of the cube is the front side, the business functions. The organizational structure will have also ‘health sector specific’ characteristics. The infosystem side will be probably the least health-specific one. The management will be able to label all IS components independently form any supplier(s) and its system planning or platform conventions. At first glance the method seems to be very simple, but in case of a large system each of the mentioned lists might have items in the order of tens and hundreds, therefore without a mapping system, even keeping a comprehensive inventory will be almost impossible, except tangible components (e.g. computers) of an IS. Such a model can handle independent changes in the organization structure, business functionality and the serving info system without hurting the overall integrity of the model. Practical application of the model extends to (a) planning complex, new ISs, (b) guiding development of multi-vendor, multi-site ISs, (c) supporting large-scale public procurement procedures and the contracting, implementation phase, (d) keeping an exhaustive inventory of an existing large-scale system. 2. The method for structuring the concepts of meta-model of the information system The nature of the `lists` describing sides of the cube is not trivial. The ‘lists’ can be understood as sets. Describing the organizational view or the IT system layer view, relations among set items must be handled as well, e.g. the relation of headquarters of a large organization to its regional offices. Relations can be mapped as of two basic kinds, ‘is a type of’ and ‘is a part of’ relations. It is very important not to mix those two aspects on the same level of classification. A good, consistent model will combine the methods of set theory and concept mapping, coming from semiotics [5]. Separate `ontologies` (concept hierarchies) are needed for all sides
of the cube. A simplified structure for each of the ‘lists’ is suggested below, based on experiences with planning and managing development of large-scale health sector ISs. The advantage of the cube model (compared to the traditional hierarchic system descriptions) is that it connects IT supported functions and ‘tangible’ IT system components directly to the organization units independently form each other. 3. The three sides of the cube: detailed description of model constituents 3.1.
Front side: Functions of a health sector organisation
The functionality of a health sector organization depends on its core task. If it is a delivery service organisation, a hospital, the supported core business functionality will be the process of healing the patient. If it is a public health organization, or a health insurance fund, the core processes can be defined accordingly. In any case altogether three basic functions are the following2: (a) supporting the (core business) operations, (b) supporting the internal administration, (c) functions related to the IT system maintenance. This is an `is a type of` functional classification, independent form the type of the actual organisation. The `core business functions` list will be the most important and healthcare specific. Often this list can be structured into a hierarchy itself. The top class of the hierarchy can be based on the relevant legal framework. Changes of this list will follow the legal system. An experience for the Macedonian Health Insurance Fund shows, that a ‘simple’ functions list might not be able to map the functioning correctly. Most probably a concept hierarchy of functional areas > functions > processes, procedures must be established, where some of the processes will serve more functions. It is important to understand that if we build processes from a number of functions, we use the `is a part of`` relation mapping among concepts. The stability of such model can be established on the process level, whereas functions and their associated sets, functional areas might change according to the relevant legal framework. Functional area 1 Function 1.1 Function 1.2 Process 1
Process 2
Functional area 2 Function 2.1 Function 2.n Process 3
Process n
Functional area n Function n.1 Function n.n
Process m
Process o
Process p
Fig. 2. Relation of functions to processes All non-health sector specific functionalities can be grouped into an `internal administration and documentation` category, e.g. pay roll, accounting, internal logistics etc. Let us only mention that similarly to the description of the core business functionality, a hierarchy is usually described, starting from the functions supporting the transactional level up to the management support. IS maintenance functions are on two levels, first: functionalities supporting physical maintenance, like WAN and LAN network administration, server-farms and workplace systems software administrations etc, second: the so-called back office jobs maintaining the usability and integrity of the applications and the databases behind them.3 3.2.
Top side: Information system layers
2
this is an ‘is a kind of’’ partition
3
These functions can be better understood in relation with the three-layer model of the information system offered below in the next section.
The description of a highly complex IS of a large organization4 needs its own conceptual model / a standardized approach. One such approach, based on the relevant ISO standard is the ‘three layer’ model used by a number of European health IT (CEN TC251) standards e. HIF, HISA. The three layers are the following:
application layer
common, shared databases, middleware
bitways (computers, system sw, network)
Fig. 3. The three layers IT system model This approach emphasizes a differentiation among the quickly obsolescing bitways layer, the robust and in its life cycle modest middleware layer and to the `end-user specific` application layer. The bitways layer consists of all IT equipments, including computers, peripherals, all active and passive elements of the network and all software components that are responsible to operating the system. Unfortunately the most stable layer of any IS, the middleware is quite often the less documented. Recent IT development moves data representation from the world of relational data bases to object oriented data modeling, but the data themselves are really significant, not their presentation technique. It is strongly suggested to use international standards5 for establishing long term, stable data-structures. In case of needed applications, ‘front office applications’ cover the needs of core business functions and some of the administration / documentation functions mentioned in section 3, and ‘back office functions’, cover some of the centralized administrative /documentation functions and the IS administration/housekeeping. Comprehensive listing of all bitways, middleware and applications can be a full and ready technical specification for a tendering process. 3.3.
Right side of the cube: organizational environment
The organizational environment of a health sector organisation can be very simple (i.e. a primary care praxis) and can be very complex i.e. a national public health service, with a hierarchy of offices across a whole country. Organograms describing actual situation of an organisational network or within an organisation are well-formed tools for representing this side of the cube. 3.4. Completing the cube The complete cube meta-model is the following: 4
built from workstations, servers, their peripherals, active and passive network items, all the systems / operating software, applications and background sw engines, databases and other constituents 5 The upcoming version of HL7 (V3) or the HISA standard might be used to define the data model behind the middleware.
Fig. 4. the complete 'cube' model 4. Using the cube model: the pragmatic approach In most cases system development does not start from scratch. Existing IS components are of different time line, technology and vendors. It is far from trivial to find a tool for planning the future system that can describe the inhomogeneous legacy systems. The renewal of the IS is often accompanied by a change in the organization and in the covered functions as well. Using the cube model in a consequent way enables to map all these problems into a single conceptual framework, that is platform neutral, thereby supporting also the transparency needed to spend financial resources from public or non-profit resources, which is again a common characteristics of health sector investments. Extending each side of the cube by further dimensions (i.e. adding human resources distribution to the organization side or a standardization requirement list to the IT side can strengthen the model further on. But just keeping the three offered dimension in a coherent representation already repays the efforts building the model. 5. References [1] http://www.martinfowler.com/articles/newMethodology.html [2] http://www.esi.es/ESSI/Reports/All/10616/Report/013.htm [3] http://www.metamodel.com/uml-metamodel.html [4] Balkányi, L., Surján, Gy.: Towards a Quantitative Approach of Medical Information Part 1. Measures of a Multi-dimensional Medical Information Space,. Medical Informatics, 1993, vol. 18. no.4. 339-346 [5] Gangemi, A., Galanti M., Galeazzi E., Rossi Mori, A.: Beyond UMLS: Computational Semantics for Medical Records in: Lun KC, et al eds., MEDINFO, 92, Amsterdam, Elsevier, 1992
