Abstract submission by Tim Benson

Identification IIP-20060517-1464-6376

Contact/Biographics

Email: tim.benson@abies.co.uk

Tim Benson
Abies Ltd
93 Milespit Hill, Mill Hill, London NW7 2RS
Tel: +44 (0)20 8906 3121
Fax: +44 (0)20 8906 3206
email: tim.benson@abies.co.uk
web: www.abies.co.uk

Tim Benson is Director of Abies Ltd, specializing in SNOMED and HL7 education and interoperability models. In 1980 he founded Abies Informatics, which developed the original Read Codes, one of the two ‘parents’ of SNOMED CT. Originally trained as a mechanical engineer, Tim has contributed to the development of healthcare computing for more than 30 years. He is co-chair of the HL7 Education Committee and is a certified trainer. He has written two books on health informatics.

Title

DAM Profiles: Using UML to Specify Interactions Precisely

Abstract Covers

research

Description

Abstract

Poor communication creates misunderstandings between users and technicians who develop the HL7 specifications and the sender and receiver software applications.
A stringent specification is needed for every interaction, in a form that can be understood and checked by both users and technicians. Traceability is required throughout the interoperability project lifecycle.
The conventional top-down, technology-centric method of developing interoperability specifications needs to be modified to become user-centric and bottom-up.
The key deliverable should be a UML specification for each interaction. This is referred to as a domain analysis model profile (DAM profile). Each DAM profile is then mapped to an appropriate interchange language (e.g. HL7 V3 or V2). The superset of related DAM profiles is their DAM.

User-Developer Communications Problems
Poor communication is a major issue in creating misunderstandings between users and the people who develop the technical specifications and the software applications, which send and receive messages. This is critical in data interchange, because the information to be exchanged has to be what the receiver needs and the sender is able to provide. For a single message between two computers, at least five parties need to share the same semantics: (1) the person responsible for specifying the actual message, (2) the users and (3) software developers at the sending end, and (4) the users and (5) the software developers at the receiving end. The problem increases rapidly with the number of different computers and messages involved.
Unfortunately most users don’t understand what they want, let alone what other parties can or cannot provide; they won’t commit to a set of written requirements, but insist on new requirements after the budget has been fixed; they are technically unsophisticated, do not understand the development lifecycle and may be incapable of reviewing partly-completed work.
Users and developers have different vocabularies and often believe that they are in perfect agreement until they see the final product. Developers may not have enough domain knowledge to understand the business process properly. They may also try to shoe-horn the users’ requirements to fit an existing system or pattern, rather than focusing on understanding what the user really wants and delivering that. These problems are not unique to healthcare data interchange, nor to the IT industry, but are endemic in any complex technical field.
One well-established approach to this problem, widely used in engineering and architecture, is to develop visual models (blueprints) of the specification before starting to build the finished thing. This is the only option when piloting is impossible. Visual modeling, using unified modelling language (UML) is increasingly the norm in the software industry. The Object Management Group defines modelling as “designing software applications before coding”.
In the context of this paper, HL7 Version 3 is as an interchange language, which uses a reference information model (RIM) to produce an intermediate level specification (RMIM), which in turn is mapped to one or more implementation technology specifications (ITS). The HL7 Version 3 artifacts are difficult to understand without specialized training. Charlie Mead has argued the need to specify a Domain Analysis Model (DAM) for each domain, defined as an implementation-independent view of the problem space from the domain expert’s perspective (which must be readable by the “domain expert on the street”). This paper adopts the idea of the DAM, but proposes that it be developed bottom-up, not top-down.
Interoperability project life-cycle
The problem and the solution become clearer if we consider the lifecycle of a typical interoperability project, at its simplest, a single interaction between two computers. There are eight steps:
(1) agree the scope (who, what, when, where and how), the business case and objectives (specific, measurable, achievable, realistic and time-bound) including a clear statement of what is out of scope;
(2) analyse the business process and design new information flows(s) that take full advantage of the features of electronic systems;
(3) create detailed functional design (model) of the message(s), independent of the technologies to be used. This is a DAM profile (see below);
(4) design the actual scheme to be implemented in the chosen interchange language (e.g. HL7 Version 3 or Version 2), including test criteria;
(5) develop applications software for the sending and receiving systems;
(6) test and certify participating systems;
(7) deploy systems, educate and train users, migrate legacy data and go live;
(8) support and maintain.
Limitations of HL7
Standards such as HL7 V2 and V3 are interchange languages and their scope is stage (4). They cannot be blamed for treating the remainder of the life-cycle as out of scope. However, everyone agrees that detailed HL7 specifications are highly technical, prone to inconsistencies and difficult to check.
Furthermore, HL7 standards cover broad business processes (such as patient administration, prescribing treatment, patient care and clinical investigation requests and reports) and all possible options found throughout the world. They are open to ambiguous interpretation and contain a great number of optional elements.
Bottom-up Specification
We need to work bottom-up not top-down, and focus on solving actual problems. Each service or interaction is documented by a DAM profile, in a UML diagram or diagrams, that can be understood, checked and reviewed by domain experts. The DAM profile is mapped to HL7, to produce an HL7 profile, which can be implemented. The mapping from DAM profile to HL7 profile shall not involve any change in the semantic content.
Related DAM profiles are views into a DAM – the super-set of DAM profiles. This is a single UML (Unified Modelling Language) model. UML is the industry standard for modeling information systems. Such a model should be comprehensive within scope and complete in detail, consistent and coherent internally, and composed of re-usable elements.
UML models are computer-readable, so that software tools can map to and from HL7 tools, providing traceability through the lifecycle from the user requirements to applications development, testing and certification. Most importantly both users and developers it should be understood by in the same way.
The scope of a DAM is limited to the design of interactions between computers in a form that the users, HL7 developers and the implementers of all participating software applications can understand. A DAM is not a model of the real world, or of existing information flows. A DAM does not specify the functionality of software used by sender or receiver, or what interchange language shall be used. It is simply a means of specifying the detailed design of electronic messages in a way that users and technical staff can understand and review.
The same message content (as represented in a DAM profile) can be expressed using different interchange languages. The choice of syntax-specific specifications, HL7 V2, V3, CDA, DICOM etc may be based on local business reasons. Technologies change and evolve much faster than functional requirements.
If two technology profiles, using different interchange languages, have the same semantic meaning, represented by a single DAM profile, then they can be translated.
In Lewis Carroll’s Through the Looking Glass, Humpty Dumpty famously remarked: “The question is, which is to be master – that’s all”. It is suggested here that the DAM profile should be the master specification of what is to be done.
The development of DAM profiles requires skill and experience of healthcare processes, modelling, clinical terminology and data interchange standards.
Conclusions
The benefits of joined-up healthcare are predicated on the availability of standards that enable computer systems across the service to talk to each other in a way that is safe, secure and reliable.
A crucial issue is the difficulty of communication between users and the people who develop and implement technical specifications. If users do not understand the specifications they cannot check them before the systems are built.
A way forward is to develop detailed syntax-independent specifications (DAM profiles) using UML modelling tools, which are precise and specific to the task in hand. The DAM profiles are then mapped precisely to the selected interchange language to produce an implementable message specification (HL7) profile.