IHE Technical Framework: Volume 0IHE Terminology
Integrating the Healthcare Enterprise
IHE Technical Frameworks
White Paper
2009-2010
Draft for Internal Comment
IHE (internal) Technical Terminology
Not to mix it up with medical terminologies!
all IHE Technical Committees
Editor: / Frank Oemig, Agfa HealthCare GmbHVersion: / 09
Date: / 2009-06-29
Table of ContentsPage
Initial Announcement
Disclaimer
Acknowledgements
1. Open Issues
2. Closed Issues......
3. Introduction......
3.1. Audience
3.2. Relationship to Standards
4. System Architecture
4.1. General "Capability" of a System......
4.2.Interfacing......
4.2.1.Relevance for Interfaces
4.3. Message Routing......
4.4. Serving Interfaces with Data
4.4.1.Relevance for Interfaces
4.5. Delete Indication......
4.5.1. Receiver Responsibility
4.5.2. Impact of Order of Messages
4.6. Message Population (Misinterpretation of Data Elements)......
4.7. Dynamic Behavior......
4.8. Keywords for Use......
5. IHE (internal) Technical Terminology
5.1.Presence/Absence of an element......
5.2.Null values/flavours......
5.3.Profiles
5.4.Conformance
5.4.1. Optionality
5.4.2.mandatory vs. required
5.4.3.Difference between standard and profile
5.4.4.Variations
5.5.Compliance......
5.6. Optionality: Distinction between RE and R2
5.6.1. Constrainable Profiles -> Implementable Profiles
5.6.2. Receiver Behavior
5.7.Length......
5.8.Truncation......
5.9.Cardinality......
5.9.1.Occurrence vs. Repetitions
5.9.2.Notation
5.10.Conditions......
5.11.Default and fixed values......
5.12.Data Types......
5.13.Vocabulary (tables/code values, values sets)......
5.13.1. Different kinds of tables
5.14.Encoding......
5.15.Assignment to Standards......
5.16.Models......
6. Normative Definitions of Terms
7. Mapping to Standards......
8. Testing (Foundation)
8.1. Test Procedures
8.1.1. IHE Connect-a-thon
8.1.2. Mass testing
8.1.3. HL7 Certification
8.1.4. Conclusion
8.2. Conformance Testing of Profiles
8.2.1. Creation of Profiles
8.2.2. horizontal testing
8.2.3. vertical testing
8.3. Test interfaces vs. documentation
8.4. Testing the different aspects of terminology
8.4.1.Testing null values/flavors
8.4.2.Testing Optionality hierarchically
8.4.3.Testing Optionality as Sender/Receiver (Behaviour)
8.4.3.1.Sender/Receiver Incompatibilities
8.4.4.Testing Length
8.4.4.1. vertical: constrainable vs. implementable profile......
8.4.4.2. horizontal: Sender vs. Receiver......
8.4.5.Testing Truncation
8.4.6.Testing Cardinality
8.4.7.Testing Conditions
8.4.8.Testing Data Types
8.4.9.Testing Vocabulary
8.4.10.Testing Encoding
9. Practising Testing
10. References
11. Appendix A
11.1. Optionality: Distinction between RE and R2
11.1.1. Discussion
11.1.2. Definitions from Technical Frameworks
ITI 2:3.23.5.2.3 (Context of PWP query)......
ITI 2: Appendix C......
Rad 2: 2.3......
Lab 3: 2.2.1.1......
Lab 2: 2.3.1 (RE, not R2)......
PCC 2: 3.3.1......
12. Appendix B
12.1. Table of Figures
12.2. Index
Initial Announcement
Normally, a terminology is – in simplified speak – an explanation of the terms in use. However, in the healthcare domain a terminology is mostly identified with a terminology of the medical domain. In contrast to this generic assumption, this document tries to explain the terms (and concepts) which are used to write Technical Frameworks and specifications like standards and implementation guides.
Furthermore, there have been some claims that this document is HL7 centric. However, it can be shown that all concepts are more or less applicable to DICOM and ebXML – as two examples for other standards – as well. Unfortunately, these concepts are not formally introduced/mentioned/used explicitly there. E.g., conformance profiles specify additional constraints onto the base standard. DICOM also provides optional elements (part 5, section 7.4.5). A statement from a vendor about their consideration in an implementaiton can also be declared an implementable profile. But the interested reader is invited to explore this for himself by reading this document.
Disclaimer
Up to now, I haven't taken much care of the wording. Therefore, most probably it needs a lot of improvement – my apologies for that.
Furthermore, this document is still not ready yet. But I would like to distribute it regularly so we can collect comments and discuss them on-/offline. Therefore, quite a lot of the sections only contain keywords so far.
This document is currently not endorsed by IHE but distributed for comments among the co-chairs. A few activists have announced their interest and see a necessity to provide such a document. Therefore, they have submitted the first comments.
Currently, the paper is structured as follows:
- Architectural overview
- Terminology explanations
- Issues with Testing
Acknowledgements
The author wants to thank Keith Boone, John Moehrke, Francois Macary and Manuel Metz for their initial contribution. Furthermore, Rob Snelick, Bettina Lieske, Len Gebase and Marco Eichelberg for their kind reviews and comments.
1. Open Issues
- It should be discussed whether the presence or absence of an (empty) element (in XML) makes a difference or not! Of course, there is a difference, but does it have an impact on interface implementations? E.g. for xPath expressions in XSLTs?
- which terms are still missing?
- some sections are still open, i.e. do not contain content but keywords
- does it make sense to introduce a section "Concepts" followed by another section for the binding to the standards? Or do we need another structure?
- mapping to standards is not finalized
- translation of values during message routing
2. Closed Issues
none
3. Introduction
Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration of the information systems that support modern healthcare institutions. Its fundamental objective is to ensure that in the care of patients all required information for medical decisions is both correct and available to healthcare professionals. The IHE initiative is both a process and a forum for encouraging integration efforts. It defines technical frameworks for the implementation of established (messaging) standards to achieve specific clinical goals. It includes a thorough testing process for the implementation of this framework. And it organizes educational sessions and exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users.
The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards – initially DICOM and HL7, but potentially others, as appropriate in their respective domains – in an integrated manner, defining configuration choices when necessary. When clarifications or extensions to existing standards are necessary, IHE refers recommendations to the relevant standards bodies.
3.1. Audience
The intended audience of this document is:
- Technical staff of vendors participating in the IHE initiative
- IT departments of healthcare institutions
- Experts involved in standards development
- Anyone interested in the technical aspects of integrating healthcare information systems
- and last, but not least, implementers and developers
3.2. Relationship to Standards
The different IHE Technical Frameworks identify functional components of a distributed healthcare environment (referred to as IHE Actors), solely from the point of view of their interactions in the healthcare enterprise. At its current level of development, it defines a coordinated set of transactions based on a set of different standards – HL7 v2.x, HL7 V3 (CDA), DICOM and ebXML just to name a few. As the scope of the IHE initiative expands, transactions based on other standards will be included as required.
IHE is therefore an implementation framework, not a standard. Referencing IHE as a standard is inappropriate.
However, the different Technical Frameworks make use of different standards. When starting reading the different Technical Frameworks – and also the underlying standards – one will become aware, that the used terminologies differ (see chapter 7). Or in other words: the same term is used for different concepts. But when discussing these issues with different experts no common understanding is given. Everyone has a slightly different understanding. Thus the objective of this paper is to clearly define the cross-standard terminology and to provide a common ground of understanding.
This Whitepaper introduces and explains the different terms with the objective of creating a common terminology, although it is unclear, whether it becomes possible to change something in future releases of the different currently existing Technical Frameworks. So at first, a common terminology for IHE must be established – independent of the used/underlying standards! The consequences of this terminology paper upon the different technical frameworks will be evaluated in a subsequent step and are not part of this paper.
IHE provides different Wiki pages with a Glossary containing a list of words; these only explain pure abbreviations and simple terms, but no detailed explanation. It should be noted, that this Whitepaper does NOT provide a vocabulary in the sense of coding systems. It should list the used terms in the Technical Frameworks and provide a detailed explanation for them.
The following[1] is an unsorted/unstructured list of terms/keywords used in the Technical Frameworks:
- required
- "R"
- required but may be empty
- "R2"
- "RE"
- "R+"
- mandatory
- conformance
- conformance indicator
- compliance
- null values
- null flavors
- fixed values
- populated
- present
- absent
- delete indication
- profiles
- integration profiles
- conformance profiles
- message profiles
- conditions
- repetitions
- cardinality
- length
- conformance statements
- integration statements
- …
These terms are explained in the subsequent sections.
4. System Architecture
Although the different messaging standards utilized by the IHE frameworks address the communication between information systems, certain assumptions concerning the capability and architecture of the connected systems must be made in order to ensure interoperability. Those are discussed in this section.
4.1. General "Capability" of a System
The capability of a system acting as an information partner within a given landscape is linked to the way the information that is received or sent is handled internally. Potentially, three different situations might occur:
- The system’s user interface offers a field to type in or present specific information that is not stored internally[2] (A).
- The system stores specific information internally, but does not present it through the user interface[3] (B).
- The system’s user interface offers a field to type in or present specific information that is also stored internally[4] (C)
Figure 1: General System Capability
For interfacing, option (B) or (C) are essential in order to be capable of providing specific information.
Although, systems are typically implemented following option C, the fact that a field is present on the user interface does not necessarily imply that information is also entered, stored and also communicated to another system. In order to ensure data entry, the user interfaces contain mandatory fields that the user has to fill out in order to continue with the application flow (e.g. name and date of birth of a patient).
However, in the medical context, a binary logic whether a piece of information is present or absent is not sufficient. In many situations the information can not be provided (e.g., due to the patient being unconscious) or is not provided. Highly sophisticated applications provide some means to enter some more details about it, e.g., that the patient was asked but unable to answer or that the patient was not asked. In reality, these means are very rare. (e.g., because the patient does not want to answer the question related to this piece of information).
4.2.Interfacing
If it comes to exchanging data between two different systems (See Figure 2) normally two interface modules communicate with each other (1). One is sending data; the other is going to receive it. In doing so, both are using the same protocol (or language). The latter is essential for interoperability however.
The sending system has to collect the data and to convert it into the language of the protocol. Normally, this is done by accessing a database (3). The receiving system extracts the data out of the transmitted data and stores it within its internal database (7).
In most cases the interface modules are not concerned with what the application program for the GUI is doing (4, 5, 8 and 9). Furthermore, it is quite unusual that the interface module takes the data from the screen (2) or directly presents it to the screen (6). However, the latter (6) is perhaps possible for display messages, i.e. messages requesting to directly providing the information from a message instance to the screen.
Figure 2: Interfacing
The question is raised what causes a sending system to send data? Entering data – sometimes is equated with a real-world event – or regularly running services (cron or at jobs[5]) notifying an interface module that there is some data which requires transmission to a communication partner.
The way the notification is conveyed to the interface module – directly (e.g., by message queues) or indirectly (e.g., by specific database tables) – and whether there is a distinction in the application and interface module at all are reasonable technical questions but those are in principle irrelevant for this whitepaper and should not be discussed here.
4.2.1.Relevance for Interfaces
What are the essentials of this analysis?
When talking about interface specifications the architecture of the systems in behind should not matter. It is important whether a system is capable of supporting specific features/information requested from a standard. Therefore, the specification of standards should separate this kind of information: a) whether a system must be capable of supporting specific information (relevant for a developer) and b) under which circumstances this information is populated in a message instance (at runtime).
The first can be achieved by a simple yes/no flag. If it is set to yes, a developer has to write lines of code for it. In derived specifications (i.e., profiles) this flag can only be switched from "no" to "yes".
The latter requires further examination which will be explained following.
4.3. Message Routing
Another question worth discussing is the routing functionality of System B (see Figure 3). This section explores the impact on the data; it does not define the target system nor any receiver responsibilities in case of misrouted messages or error handling. It is important to that the correct handling of received information becomes important if the data is used as input to other actors.
What happens if information received from System A via (1) should be sent to System C via (5)? The easiest way is the unification of the receiving and sending interface. This solution is quite uncommon as the routed information should also be taken care of in the application itself, e.g. because of delays between receipt and subsequent submission. Therefore, the receiving interface stores the information within the database (3) and the sending interface takes it out of the database upon request afterwards (4).
Another option is the internal routing between both interfaces (7) which is also quite uncommon.
Figure 3: Message Routing
But even if information is sent from System A via System B to System C it is not necessarily true that the stored information stays the same (A, A´ and A´´). The different interface modules translate it to and from the used interface protocols into an internal format/value/code. The issues arising from this translation is not part of this whitepaper[6].
But storing this information internally can be defined as "being capable". A distinction between (B) and (C) as explained in Figure 1 above is not necessary here. (Note: (C) would present this value to the user; (B) will keep it hidden.)
4.4. Serving Interfaces with Data
A totally different question is the combination of the general capability of a system in combination with its interface behavior: Is it always true that specific information which is generally available within the database of a system (B or C) is exchanged with a foreign system (3+1 in Figure 2)? Of course it is not. This belongs to the (internal) directives of the corresponding vendor.
From an interface perspective there is no difference whether specific data is hidden for an interface module or whether it is not implemented at all.
4.4.1.Relevance for Interfaces
As a consequence, in order to prove the general capability, a system must create a message where such an element is populated and vice versa. If a system processes specific information there must be a situation where this information is available. Otherwise, the interface specification is not correct.
4.5. Delete Indication
HL7 Version 2.x has the notion of a "delete indication". Most probably it is known as "two double quotes"[7]. The idea behind this concept is to notify a third party about the deletion of specific information. In order to do so, the sending system itself must be capable of maintaining a history about previous information. The typical way of achieving this is the use of a "shadow table"[8] that stores historic information. Refer to Figure 4. So, if the user enters (or deletes) information, the current value is transferred into the database (1). Any previous information is transferred internally into the shadow table (2).
Figure 4: Delete Indication
Without such a mechanism, an interface module is unable to distinguish between a simple missing (empty) value and a deleted value. Therefore, there is a precondition on the sending side.
Having such a mechanism in place allows a system to send the two double quotes to notify the receiving system about the deletion.
The receiving system may handle this information properly –with or without such a means in place.
4.5.1. Receiver Responsibility
Another important issue is the expected behavior for the receiver: The receiver of this information (two double quotes) is now informed that the information sent previously is wrong and must be deleted.
An example may be an errant patient name. The clerk at the front desk realizes that he typed in a wrong name and eliminates the name from the form. The sending application stores this information in the database, also updating the "shadow table". The interface module compares the current empty value in the table with the previous value and realizes that this information has been deleted. As a consequence, it inserts the two double quotes. The receiver takes this information as an indication to delete the value in its database table as well. If the receiver has the same mechanism in place, the "shadow table" must be updated as well.
Deleting information without any history may cause jurisdictional problems if specific information is not available any more, but the patient has been treated based on wrong information! Therefore, a solution must be provided.
4.5.2. Impact of Order of Messages
If two parties are exchanging information, the result is easy to determine[9]. If more than two parties are exchanging the same kind of information, the result depends on the order of the sent messages.