Project Plan for HL7 Technical Architecture

Project Plan for an HL7 Architecture

The initial guidance from the Strategic Initiative and the Board suggests that a completely defined, accessible Architecture for HL7 standards is an essential element to developing, promoting and maintaining the inter-operable standards to which HL7 aspires.

The T3F is in full agreement with this suggestion, yet has not found the band-width to do more than pay lip service to this need. This simply reflects inevitable trade-offs between tactical and strategic objectives. In this case, the tactical objective has been to get the Technical Steering Committee "off the ground."

In order to avoid having tactical issues continue to dominate, the T3F will prepare a Project Proposal in the near future to:

• define HL7's objectives for a effective architecture,
• do a "gap analysis" between what HL7 has today and what it seeks, and
• recommend a specific plan of action to achieve the goal.

At one point, the T3F aspired to have a Project Proposal for review at the upcoming Working Group Meeting, but will not meet that objective. At this point it is the T3F's intent to develop such a proposal in coming weeks so that it might be available for Board review this summer.

In preparation for that effort, Berndt Blobel, a member of the T3F, has provided the following background material. It provides a glimpse of what is needed, and a cursory assessment of where HL7 stands in this regard.

Architecture for Inter-operable Health Information Systems

For establishing sustainable and semantically inter-operable health information systems, an appropriate architectural approach has to be developed, referring to approved knowledge and existing standards as much as possible.

Definition

An architecture of a system is a (formal) model of the real system, describing the system's components, their functions and relationships.

Architecture Characteristics

The architecture has to be

• business-driven (for meeting user requirements and process needs),
• following a unified process (for definition, design, implementation, evaluation, testing, and maintenance to support semantic interoperability),
• service-oriented (for meeting business requirements and users' expectations (acceptance) by serving the users' business processes, based on domain knowledge expressed in corresponding concepts and aggregation schemes),
• model-driven (separating computation-independent models, platform-independent models, and platform-specific models for enabling portability, flexibility, and semantic interoperability),
• component-oriented (for supporting scalability and flexibility),
• lawful (for providing user acceptance and trust).

Model Characteristics

In that context, models as reality representation, communication tools, and representations of business interests, intentions, etc., have to possess certain characteristics such as

• the separation of computation-independent models, platform-independent models, and platform-specific models, always starting with the business model and tackling all views of the ISO 10746 Open Distributing Processing reference model,
• deriving the models by constraining reference models for information and processes,
• the consideration of structural and behavioral aspects of the considered system (reflecting the semantic and the pragmatic aspect of information),
• the provision of appropriate concept representations including the aggregation schemes (rules) at different aggregation levels,
• the deployment of appropriate (reference) terminologies and ontologies.

HL7's Position in This Space

For those who have wrestled with "Version 3" for the last decade, these are familiar concepts and objectives, most of which have been recognized and some of which have been addressed, if not fully achieved.

For example, HL7 meets some but not all of the paradigms for establishing sustainable and semantically inter-operable health information systems, defined in the Generic Component Model, such as:

• Component orientation and the distribution paradigm;
• Unified process of definition, design, implementation, evaluation, testing, and maintenance;
• Common reference models for information and processes;
• Common terminologies and ontologies;
• Separation of logical and technological views by platform-independent and platform-specific models, respectively;
• Specification of the components' structure and behavior as well as of the rules being applied based on knowledge, concepts and contexts;
• Enhanced security and privacy services.

HL7 has developed an advanced unified process, the HDF. It provides a model-driven approach, a vocabulary with references to existing terminologies. It is component-oriented at different levels of granularity. HL7 V3 describes most (in future perhaps all) views of the RM-ODP, starting with business requirements (e.g. EHR-S Functional Model), business process models (e.g. Templates, SOA), and thus is, step by step, establishing a service-oriented architecture.

The most obvious weaknesses are immature development in some areas and missing integration between the paradigms and methodologies needed for establishing a sustainable architecture. This is a question of time and development, and the project to be proposed will seek to define how much time, and how much development.