clinical domains such as diabetes care. Several of the .... richtlijnen en aanbevelingen voor zorgverleners. ... Hendriks HJM, Dekker J. KNGF Richtlijn Beroerte;.
Intelligent semantic interoperability: integrating knowledge, terminology and information models to support stroke care William TF Goossena, a
Acquest Research, Development and Consulting, Koudekerk aan den Rijn, The Netherlands
Summary Introduction: Electronic patient record (EPR) systems for the continuity of care for stroke patient are under development. These systems are based on standards such as for clinical practice, vocabularies, and the HL7 information model. Problem statement: In order to achieve intelligent semantic interoperability, knowledge about evidence based patient care, vocabulary and information models need to be integrated. Methodology: A format was developed in which the clinical knowledge, clinical terminology, and standard information models are integrated as specification for the technical implementation of electronic health systems and electronic messages. This format is verified by clinicians and technicians. Results: The document structure consists of meta-information such as version control and changes, purpose of the clinical content, evidence from the literature, variables and values, terminology used, guidelines for application and interpretation, HL7 message models, coding, and technical data specification. Further, XML message excerpts, archetypes and screen designs are developed from these documents to facilitate implementation. Conclusion: The combination of these aspects in one document creates valuable content for intelligent semantic interoperability by means of development of messages and systems. Keywords: Evidence based practice; Vocabulary, controlled; Information model; Archetypes; Nursing records; Computerized patient records, Messaging standards; Medical informatics.
Introduction Clinicians realize that electronic patient records (EPR) support their management of data, information and knowledge in order to record and exchange relevant clinical data, to make adequate decisions, to select the best interventions and to achieve proper patient outcomes. However, appropriate use of clinical information and communication technology is only possible when standards are applied. Standards consist of many examples and formats, including professional standards,
vocabularies, information models, workflow and technology, and are often difficult to integrate on the application level. [1] One assumption for clinical information and communication technology is that it needs to integrate data, semantics, knowledge, decisions, pragmatics, and outcomes with technical requirements such as coding, data types, and user interfaces, among others. [2] Ongoing work in the area of standards is the harmonization of these components in order to achieve intelligent semantic interoperability. Semantic interoperability between EPR systems in health care is defined here as ‘the electronic exchange of clinical patient information in such a format that the intended meaning of the information from the sender can be interpreted by the receiver without changes or loss’. The addition of ‘intelligence’ implies that clinically relevant knowledge is applied to the content, structuring and processing of the electronic documentation and of the information exchange. Attempts have been made to integrate some of these components one by one, such as linking terminology models with information models, e.g. on the level of international standards development, or to apply knowledge of a domain in structuring vocabularies. However, to our knowledge few initiatives exist to integrate knowledge, terminology and data/information modeling for the technical realization of EPR and messaging. [3, 4, 5, 6] Further, these attempts merely have an academic approach, except for the OpenEHR system development, which is currently tested in real world software and projects [6, 7]. It therefore is appropriate to test these integration approaches to the practice of systems development and use. The Dutch national infrastructure for information and communication technology in health care offers a good arena for this. [8] One of the projects of the National ICT Institute (NICTIZ) responsible for the infrastructure, concerns an EPR system for stroke patients. In this system a wealth of clinical knowledge, instruments, data and vocabulary needs to be included for continuity of care. The problem statement for this integration approach is: to achieve intelligent semantic interoperability for a stroke EPR, knowledge about evidence based patient care for stroke patients, vocabulary and information models need to be integrated to fully specify the technical requirements of the system and of electronic messages.
Next section will describe the approach taken for this development, and the different materials that are integrated.
codes for all clinimetric instruments for stroke EPR is a meticulous work, that must be carried out with careful attention.
Materials and Methods Information models Stroke patients require multidisciplinary care that spans time, different health care professions, and organizations, including hospital care, rehabilitation, nursing homes and home care. The Netherlands have developed national guidelines for stroke services that offer such care. [9, 10, 11] Following these practice innovations, functional and technical specifications are drawn up to facilitate care documentation in stroke services in order to achieve continuity of care through electronic exchange of clinical patient information. [12, 13] These specifications where determined by clinicians and researchers in the domain of stroke care. [13] The following materials are included in these specifications for stroke EPR: Evidence based materials The Dutch national guidelines for stroke care require a wealth on clinimetric instruments such as scales or indexes (e.g., the Barthel index, a Depression scale) to be applied in the care process, hence in the stroke EPR. [9, 10, 11] During the development of stroke EPR systems, it became clear that scales, indexes and instruments, due to their clinimetric nature, require specific attention in system implementation and electronic messages. Maintaining the psychometric and/or clinimetric characteristics, such as the sensitivity to change on individual patient level in the clinical environment, is important for the correct administration of such instruments. [14]. If for instance the variables and values are changed, they might render an assessment or scale unreliable and not valid. [14] In addition, it is also important to realize that reliability and validity are dependent on the population researched and the circumstances. Vocabulary and coding The specifications include select vocabulary to maintain the semantics of the information about stroke patients stored and exchanged. For the detailed description of the type of stroke, (bleeding, location of bleeding, thrombus, etc.), the International Classification of Diseases version 10 is used. [15] Functioning is described to some extend with the International Classification of Functioning, Disability and Health. [16], and some assessment scales and observations with the Logical Observation Identifiers, Names, and Codes (LOINC). [14] However, not all data that clinicians want [13] can be found in these vocabularies. In addition, the unique coding of each data item is required to prevent errors and misunderstandings. However, sometimes data items seem to overlap, but actually do not due to different value sets or attributes.. White and Hauan discuss the need to take care of psychometric characteristics when assigning LOINC codes. [14] Bakken et al argue that time factors, attributes versus values, and subscale calculations, among others, are particularly difficult in assigning LOINC codes.[17] Hence, finding adequate vocabulary and
The specifications for the stroke EPR system are based on the National ICT infrastructure requirements that use the HL7 v3 message standards (Health Level Seven). [12, 13] HL7 is a standards development organization providing standards for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of healthcare service [17]. HL7 has a core body, the Reference Information Model (HL7 RIM) [18]. The HL7 RIM is a generic, non-discipline specific, Object Oriented information model of patient care and the providers, institutions, and activities involved. [18] The RIM classes can be used to draw models that specify domain information, such as for care provision. From this domain model, specific messages information models can be derived, for instance to transfer patient information from one institution to the other. Also, this process allows to specifically defining clinical observations and instruments for particular clinical areas, including stroke [19]. Both the implementation in the stroke EPR system and the electronic exchange of patient information via electronic messages developed by HL7 are supported by these models. Integration and technical specification A format is developed in which the clinical knowledge, clinical vocabulary and coding, and information models in the form of HL7 v3 Refined Message Information Models (R-MIM) are integrated. Based on this format, the technical specification for development and implementation becomes possible. This does include the selection of the proper attributes in the HL7 RIM class, the data type, cardinality, and code, among others. These features are described in a mapping table. The mapping table functions as the mapping from the domain specific information to the technical environment, i.e., the information model and message definition. Procedure to develop care information models The procedure for the construction of the care information models is as follows. From the specifications, [13] a scale, index or (group of) data item(s) is identified and the content is described. When all data items and their scores and values are listed in a table, and the rules for application are known, it becomes possible to draw the R-MIM and to put the technical specifications in a table. Next, the first version of a document is produced and handed over to the technicians. Technicians check the descriptions in the document and determine if it is realizable in technical sense. Often this leads to changes in e.g. the data types and cardinalities. When the technician is satisfied, a mock up user interface screen is drawn up for the instrument or cluster of observations. This mock up is presented to the users to verify for domain completeness and correctness, and the ease of use to
complete it. Feedback from such sessions mostly leads to a new version of the care information model. The components integrated in these specifications – the care information models – will be described hereafter in the results section.
Results Data items and their organization at system level The information needed for the development of the stroke EPR is gathered by literature review, a Delphi study and interviews with participants of all professions involved.[13] The results are a set of minimal requirements and a list of items that are to be recorded in the stroke system and exchanged for the continuity of care. There are more than 1000 distinct data items required, however organized in different manners. For the support of the development of the EPR the following topics are chosen as the major system functions: overview, personal details of the patient, assessment & physical exam, treatment & care, social data, functions & disorders, tests & scales, discipline specific documentation, consultation, multidisciplinary meetings and discharge / transfer of care. These generic items are further broken down in so called organizers and batteries. These are groupings of data items in larger areas, such as assessment, physical exam, discharge planning checklist, or smaller groupings of similar data items in batteries, such as vital signs and lab tests. Many of the data items are shared among the various disciplines, who have expressed in sessions what they want to enter in the system, change, or alternatively, what they want to see or not to see. The implementation of the stroke EPR and HL7 v3 messages is supported via granular specifications of the observations, clinimetric instruments, and treatment and care, allowing a precise and correct application and documentation. A total of about 90 care information models is available. [13] Ten of these are fully in English, but all have the mapping table in both Dutch and English, to facilitate exchange of these models and international standardization. Structure for the standardized care information models The document structure for the care information models consists of meta-information, detailed description of the clinical instrument, and how it is applied in practice. Also, the variables, vocabulary, values and codes are described in detail. For the technical implementation, the HL7 v3 R-MIM and data specification are included. In most documents, one for every item of clinical instruments in stroke care, the current components include [13]: 1. Version management and authorship 2. Aim of the instrument, index, scale, or observation 3. Scientific foundations / evidence base 4. Description of variables / data items / values 5. Working instructions for practice
6. Interpretation guidelines for the results 7. Literature / acknowledgements 8. An example of the instrument (when available) 9. HL7 v3 R-MIM and description, 10. Mapping table from domain to HL7 R-RIM 11. XML message example (extensible markup language) 12. Remarks, e.g. if a Dutch version is different from English version of an instrument. A current overview of the 90 care information models is available at the website: www.zorginformatiemodel.nl. [13] Example of the content mapping domain to HL7 v3 To illustrate the care information models’ core features, the example of the Functional Ambulation Categories (FAC) is presented here. [20] The FAC instrument is used to document the independency in walking after stroke.[20] Table 1 lists the two variables of the instrument and the score that can be given, one in free text, another with a very specific code set. Table 1 – FAC variables and value set. [13, 20] Variable of Functional Ambulation Categories Use of aid FAC score
Score / value set Free text FAC 0 = Not or not functional FAC 1 = Dependent (level II) FAC 2 = Dependent (level I) FAC 3 = Supervision FAC 4 = Independent but limited FAC 5 = Independent and unlimited
Table 2 presents the mapping from the clinical domain – as example the FAC as described above – to the HL7 v3 message structure. Not all features have been included for ease of reading. The code in this example is a simple mnemonic code. Table 2 – Mapping Table summary for FAC. [13] Variables of FAC
Place in HL7 RIM class
Data type HL7
Cardin ality
stroke-EPR Vocabulary & Code
Use of aid
OBS: value
ST (string)
1..1
FAC-help
FAC score
OBS: value
INT (integer)
1..1
FAC-score
Reuse of process, structure and models The models appear to be usable for the purpose of the stroke EPR, however, at this moment it is also used in other clinical areas. For instance for the perinatology project, the care information models for smoking, alcohol and drug use is 98 %
reusable, and additions from perinatology where considered to improve the document for stroke care. Now this model is used in two National projects. The procedure and structure are also usable in this domain: the Apgar score for instance is now worked out by a team member for educational purposes, but will be useable in the perinatology project. Expansion of the development of reusable care information models is ongoing. A nursing information system is built on the same models. Further, a project is currently underway in the area of home care and welfare, for content that is closely related to clinical care. Many of the care information models, e.g. descriptions of a stroke patient’s house and living conditions, social network, use of walking aids, can be reused in this area. Additionally, NICTIZ is considering expanding this to other clinical domains such as diabetes care. Several of the current care information models are now included as examples in the HL7 v3 standard. [18] They serve as examples of how to specify the generic RIM classes in the Domain model for Care Provision. Example HL7 v3 Message model (R-MIM) Each instrument for stroke care is specified on the most granular level as an R-MIM. Figure 1 shows the R-MIM for the FAC. [13, 20] ClassCode is observation, moodcode identifies if the observation was carried out (Event), the code comes from the mapping table, the time of observation is included, and the value holds the score. methodCode defines the answer option for the value attribute in which the score is included. Conditions links the score to aid use. Functional Ambulation Categories (FAC) (UUDD_RMnnnnnn)
Description
the HL7 standard. [18] Three EPR’s for the continuity of care for stroke patient are currently under development, based on these specifications and care information models. [13]
Discussion Although the approach seems to fit the development of electronic messages and EPR for stroke care, and indeed other projects are taking up the care information models, thus facilitating standardization of clinical knowledge, semantics and data items, we are convinced that this work can be improved. This has led to organizing an invitational workshop with international experts on the development of standards for clinical practice, terminology and data models. This work will be described elsewhere. [21] One particular issue still not resolved is the preferable format for the technical specification. Eventually, the archetype approach [6] would be simpler and easier to maintain for clinicians and researchers. However, at this stage the methodology to include the archetypes in the HL7 v3 RIM based models is not ready. However, anything specified in RMIM format can be implemented in the XML messages. Another limitation of the current approach is the fact that although practical tests have been carried out, no real world implementation has taken place, however the first stroke EPR is due by October 2005. In addition, questions remain such as the nature of, at first sight, single atomic items, like measurement of body temperature often have more characteristics for example where is it measured? Question remains where to fit these attributes in the models? And what coding is preferable? Similarly, linkages to workflow have to be worked out. Guidelines are given for when to apply the instrument in practice, but its handling at systems level is not further specified. Finally, it appears to be necessary to involve local reference groups of professionals for checking the indexes, scales, observations, and the user interfaces.
Functional Ambulation Categories (FAC) classCode*:
