gms | German Medical Science

For ensuring quality and efficiency of patients’ care, currently all industrial countries are looking for a change in care paradigm towards highly distributed, labor-sharing care settings. This process of moving from organization-centered care to process-controlled care (managed care, disease management) has to be continued towards the individualized personal care. The aforementioned paradigm shift also concerns the supporting information and communication technology (ICT). Several intents have been provided to deal with systems interoperability, from technical and data exchange interoperability, to semantic interoperability. However the service-interoperability where services are interchanged is still a big challenge.

For ensuring division of labor and the ability for integration in highly distributed architectures, definition and implementation of a unified process is inevitable. This concerns the entire lifecycle of a system from analysis over development up to implementation and deployment. Currently, the software industry has adopted a de facto standard to support the development process of software systems: The Rational Unified Process (RUP) [Ref. 1]. The RUP covers the entire software development lifecycle by the definition of workflows. A workflow is configured by a set of roles (who), activities (how), and artifacts (what) necessary to transform the user requirements into a software system. The process identifies six core workflows: business modeling, requirements, analysis and design, implementation; test, and deployment. Besides, to define how the process rolls out over time, the RUP proposes four iterative phases: Inception, Elaboration, Construction, and Transition. Each phase is implemented as a set of workflows where, according the requirements of the system to be developed and the software development team involved; the number of iterations, roles, activities and artifacts are configured and extended. On the other hand, the HL7 community is on the final stage of defining a unified process for the development of HL7 standards specifications: The HL7 Development Framework (HDF). HDF replaces the former Message Development Framework (MDF) and documents the processes, tools, actors, rules, and artifacts relevant to development of all HL7 standard specifications, not only messaging. HDF defines the route of HL7 on the process of supporting the development of distributed health information systems, moving from a communication standard paradigm towards an architectural paradigm. However, its use as a comprehensive unified process for the specification of semantic interoperable health information systems is not clear enough. In the paper the characteristics of a unified process for semantic interoperability are defined, and then the RUP and HDF methodologies are compared based on the established requirements. The framework for the comparison is the Generic Component Model [Ref. 2] which describes any system from 3 dimensions: the different domains involved, the level of granularity composition/decomposition of components, and the different views of systems architecture described in the RM-ODP process [Ref. 3]. The comparison is restricted to two dimensions: the granularity of components and the RM-ODP.

The requirements defined for designing semantic interoperable health system are separated in two groups: 1) those related to the unified process: iterative process, component-based architecture, reusability, a common representation language and tooling support and 2) those required to reach semantic interoperability defined in [Ref. 4]: composition rules and constraints, agreed terminology and ontologies, common reference model and service-oriented architecture. The results comparing RUP and HDF are summarized in Table 1 [Tab. 1].

From the analysis of both methodological approaches, it was found that the RUP is an excellent methodological approach for specifying semantically interoperable systems because it is a fully iterative process, supports the composition/decomposition of components, uses a unified representation language, is flexible and configurable, and supports reusability. However, its main weakness is its grade of flexibility allowing the different stakeholders to define their own models according to the specific requirements of the system. It creates problems when designing semantically interoperable systems because the models and components obey to different rules. It is not possible to reuse the services if the system structure differs among systems. HDF lacks some best practices of a unified process developed by RUP such as the definition of iterations, configuration and project management. But it adds the constraining process required for RUP for the design of Health Information Systems. Domain-specific requirements and conditions can be consistently described by the RIM using object oriented and UML-based methods. The resulting models can be transformed in architectural components by adding operations to the classes and by defining interfaces to access to the services provided by the components. HDF should take a look to RUP as a complete process. It is possible to define HDF as a RUP plug-in that takes advantage from the knowledge generated in HL7 regarding health systems, reference models, vocabularies, data types, etc. These constraints add the value demanded by software engineering practitioners to realize semantically interoperable health systems.

In the near future, it would be possible for HDF to evolve to a methodology for the design of HIS services, not only messages. The adoption of RUP would facilitate the process, however. The software engineering community would be happy to have a plug-in proposed by the HL7 community, providing not only the process framework for developing eHealth systems, but also service-oriented architectures and tools.