La experiencia para el reconocimiento de las mariposas en estudiantes

Object Management Group

OMG was founded as a non-profit corporation in May 1989 by eight companies: 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems and Unisys Corporation. OMG is committed to

“developing technically excellent, commercially viable and vendor independent specifications for the software industry”. The consortium now includes over 800 members.

Health Domain Task Force

The HDTF, formerly known as CORBAmed, has over fifty members representing vendors, health care providers, payers and end users. HDTF is developing standardised object-oriented interfaces between healthcare related services and functions, to provide compatibility for a wide range of software components and to provide software developers with access to larger markets. The work of the group spans the Information and Computational ODP Viewpoints, and therefore overlaps with the development of EHR architectures, messages, classifications and term sets. The activities within HDTF are not restricted to the implementation of object oriented systems. The main CORBA HDTF specifications potentially relating to or interfacing with EHR services and systems are listed below in Table 4.

Roadmap Global perspective and direction for HDTF

standardisation activities (as a set of healthcare specific functional areas).

Person Identification Service (PIDS) Services to identify and locate a person and their associated records across systems, be subject to the confidentiality concerns and the right for anonymous care.

Clinical Observations Access Service (COAS) Query, retrieval and display of clinical observations.

Decision Support Services (DSS) Integration of decision support technology Lexicon Query Service (LQS) Common access to medical terminology

resources.

Security Identify and implement security requirements

specific to the security and confidentiality profile of medical domain.

Chapter 5: Published contributions to the FHR Design Health Level 7 (HL7) Seamless CORBA object interoperability with

HL7 messages.

Workflow Work flow and event passing between medical

components and activities.

Schedule and Calendar Physician, patient and resource scheduling Electronic Commerce Payment Facility Payment of electronic medical claims

Biomedical Imaging Object oriented access to radiology, endoscopy and related imaging technology.

CORBA/M (Mumps) Interoperability Wrappers and IDL bindings to integrate Mumps- based systems into a CORBA-based

environment. Transcription

Table 4: CORBA HDTF specifications potentially interacting with an EHR Clinical Observations Access Service (COAS)

COAS defines a set of services that may be offered by a clinical application or data repository to enable other components or applications to request and to receive one or more clinical observations on a patient ( CORBA Health Domain Task Force 2001b). COAS is underpinned by a basic information model of an observation, which is a simple hierarchy comprising name value pairs (ClinicalDataElements) that may be grouped under a Header and may have links to other ClinicalDataElements via ItemRelation and ItemRelationSeq classes. Each ClinicalDataElement may have a data value that is drawn from a comprehensive set of data types defined in the specification. This information model is relatively simplistic in comparison with the EHR information models proposed by the European research projects described above in Sections 5.2. The service itself relies upon other CORBA HDTF services such as the PIDS to confirm the identity of the patient about whom observations are requested, and the LQS to determine the rubrics and knowledge relationships of the terms within any textual observation.

Person Identification Service (PIDS)

This specification defines the interfaces that organise person identity management to meet healthcare needs ( CORBA Health Domain Task Force 2001a). These services identify and locate person identifiers and their associated records across facilities, enterprises and systems, subject to the confidentiality concerns and the right for anonymous care. (Forslund, Smith et al. 2000) have, for example, used the CORBAmed PIDS services as a means of federating multiple patient master index systems.

Lexicon Query Service

The Lexicon Query Service (also known as Terminology Query Service - TQS) defines a specification to support the use of multiple vocabularies in a heterogeneous application

Chapter 5: Published contributions to the FHR Design environment, based on the notion of a terminology service ( CORBA Health Domain Task Force 2000). This specification has been informed by demonstrator terminology servers such as those produced by GALEN and the Mayo Clinic MetaPhrase terminology server (Chute, Elkin et al. 1999).

Although the CORBAmed PIDS and TQS are regarded as good middleware specifications, uptake of these has been limited. Almost no implementations of COAS have been developed outside research contexts. These specifications are now being reviewed by HL7 but little active work appears to be taking place inside the HDTF itself.

5.6.3. DICOM

The Digital Imaging and Communications in Medicine (DICOM) standard was first published in 1993 jointly by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), building on two previous ACR-NEMA specifications originating from 1985. It addresses the issue of vendor-independent data formats and data transfers for digital medical images. Both CEN and ANSI have adopted DICOM by reference in their imaging standards. DICOM is presently in version 3, comprising 14 chapters relating to the acquisition, storage and communication of different kinds of image data.

(Brown, Britton et al. 1998) stress the importance of the data that may be associated with medical images. Although strong standards exist for the technical data associated with image acquisition (e.g. DICOM, HL7), they suggest that the clinical and descriptive data elements also need to be profiled to enable interoperability with clinical systems to support patient care. (Bidgood 1997) describes the requirement for a standardised information architecture to facilitate the exchange of imaging procedure descriptions and DICOM image interpretation reports. He has led the development of a standard information model for the representation of medical image structured reports (DICOM-SR). This work is related to a controlled vocabulary for reporting imaging studies to permit their semantic analysis. This has been published as the SNOMED DICOM Microglossary (see Section 5.3.1).

The DICOM-SR specifications provide a simple generic structure for an electronic report document that is also a candidate for inclusion within the EHR. However the present model, in the view of the author, is not sufficiently rich in medico-legal and revision attributes to satisfy the requirements documented in Chapter 6.

The inclusion of multimedia data within the EHR is of great importance to clinicians. The authors of DICOM-SR and others in the field are collaborating with HL7 on the RIM and Clinical

Chapter 5: Published contributions to the FHR Design Document Architecture, and with European research and standarisation groups in order to advance current EHR specifications to include multimedia reports.

5.7.

Metadata: representing EHR domain knowledge

In parallel with the work on EHR architectures over the past decade, formalisms have been investigated by which the medical knowledge necessary to interpret and to process health record entries can be represented. The term metadata is sometimes described as "data about data", and commonly illustrated by the schema of a database. However the term is also used for the indices and knowledge models that describe the data content of a statement, a document or a database entry.

There are several published formalisms for the representation of metadata that can be applied to the information model of the EHR. Three specifications are discussed below in this section: the Dublin Core Metadata Specification, ISO/IEC 11179 and Categorial Structures. These are examples of developments focused on a formal and generalised information model to represent metadata. A larger number of specific data dictionaries have been developed to support health care record systems, often within large hospitals. This latter group have often been empirically driven with a principal focus on the accumulation and exploitation of the clinical semantic content; the information models underpinning them are often tightly coupled to the local clinical systems at those sites and so not readily migrated to other settings. They are discussed in Section 5.7.2.

Dublin Core Metadata Specification

The Dublin Core Metadata specification defines a set of header tags that can be used to systematically index and reference the content of web pages (Dublin Core Metadata Initiative 1995). The Dublin Core elements include: title; creator; date; subject; publisher; type; description; contributor; format; source; rights; identifier; language; relation and coverage.

(Munoz and Hersh 1998) have used the Dublin Core elements and terms from the MeSH thesaurus (as rubrics and codes) to capture document subject index terms and other relevant header information from clinical (web based) documents. They have developed tools to include this information as a "meta-header" to the html page for web indexing and searching tools, potentially to enable a Medline-like search facility for the web (Malet, Munoz et al. 1999).

This metadata specification is relatively general, and has recently been adopted in the UK as part of the e-Gov programme to support metadata registries in local government. It is too general to be applied directly to EHR metadata repositories.

Chapter 5: Published contributions to the FHR Design

ISO/IEC 11179

The ISO/IEC 11179 Specification and Standardisation of Data Elements proposes a standard approach for the construction of a metadata dictionary. This is a framework standard rather than a populated dictionary of healthcare elements. The attributes for Data Elements (still in draft form) are listed in Table 5 below. This list resembles those attributes proposed by the author to register archetype definitions in the FHR Archetype Model, described in Section 8.2.

Name Label assigned to the Data Element

Identifier Unique ID assigned to the Data Element

Version Version of the Data Element

Registration Authority An organisation authorised to register the Data Element

Language Language in which the Data Element is specified

Definition A statement that clearly represents the concept and essential nature of the Data Element Obligation Indicates whether the Data Element is required

to always or sometimes be present (mandatory, conditional, optional)

Data type Indicates the type of data that can be

represented in the value of the Data Element Maximum Occurrence Indicates any limit to repeatability of the Data

Element

Comment A remark concerning the application of the Data Element

Table 5: Attributes for Data Elements proposed in ISO/IEC 11179

(Solbrig 2000) notes that, after an initial wave of enthusiasm, work on this standard is progressing slowly. The XMI (XML Metadata Interchange) specification to be published by the World Wide Web Consortium (W3C) may facilitate the standardisation of tools and APIs in this area. The new W3C enterprise business XML (ebXML) specification for metadata registries might also overtake the ISO work in this area.

Categorial structures

(Rossi Mori and Consorti 1999) have carried out an extensive review of the headings and entries within a wide range of clinical documents, in order to populate a three-tier semantic structure that can be used to classify and compare the content of patient records from a semantic perspective: 1. documents and sections;

2. clinical statements;

Chapter 5: Published contributions to the FHR Design

They have proposed methods for representing clinical meaning in each of these three tiers, called categorial structures. The authors propose these as an alternative to standards like ENV 12265 for representing clinical statements (Rossi, Galeazzi et al. 1997). They argue that a basic record structure allows variability in the granularity and hierarchical organisation of a clinical statement because Record Items can be named arbitrarily and populated from any clinical terminology (Rossi Mori and Consorti 1998).

(Harris, Graves et al. 2000) argue that systematic evaluations must be performed of the extent to which categorial structures accurately and completely represent nursing and other non-medical domains.

(Rossi Mori, Consorti et al. 1998a) also describe a system of tags that could be used to represent formally the implied context for the interpretation of a health record entry within its original record system. Such context can easily be lost if data items are communicated to other record systems in isolation. They also point out that it may prove difficult for clinicians to accept a standardised set of record structures or headings, and that their alternative should be sufficient for the “safe” communication of records and for some local processing. The authors suggested system of tags is given below.

C0 Nature: tags to identify the nature of data;

C1 Safety context: essential tags that convey the main context of data;

C2 Interpretation: tags about interpretation of data in the original context by the original user; C3 Intention: additional tags to make explicit the links that reveal a sender's intentions and goals; C4 Organisation: further tags to show the organisation of the original record.

This work fed into and was refined by CEN/TC 251 and published as the CEN Domain Termlist standard ENV 13606-Part 2 in 1999. This is discussed in Section 5.7.2 below. The view of the author is that this system of tags should form part of rather than replace a formal information model for the EHR.

Concepts underlying continuity of care

CEN standard ENV 13940 defines a set of concepts for health care parties, threads of care and mandates (responsibilities) that are needed to ensure the complete documentation of continuing shared care (Mennerat and Booth 2002). These concepts need to be represented consistently and communicated between clinical information systems to support safe and high-quality care. The author, and the lead authors of ENV 13940, believe that the EHR needs to be able to cater for all of these concepts, most of which would be represented through the archetype approach presented in Chapter 8.

Chapter 5: Published contributions to the FHR Design