Proceedings of the 9th International Conference on Information Technology and Applications in Biomedicine, ITAB 2009, Larnaca, Cyprus, 5-7 November 2009
INTENSA: Heart Failure Patient’s Follow-up System Using the ISO/IEEE11073 Standard M. Martínez-Espronceda, Student Member IEEE, I. Martínez, S. Led, J. D. Trigo, I. Osés, J. Escayola, L. Serrano, Senior Member IEEE, J. García, Member IEEE, and A. García Abstract— This paper presents a novel implementation methodology of ISO/IEEE11073 standards for use in real monitoring platforms based on patterns paradigm. These monitoring platforms include several medical devices based on low voltage-low power microprocessors. As a proof of the concept, INTENSA project which aims to develop and evaluate a heart failure follow-up interoperable system including weigh scale, blood pressure and HOLTIN devices, is briefly described. Index Terms— Telemedicine, medical devices, interoperability, standardization, ISO/IEEE11073, heart failure, follow-up
T
I. INTRODUCTION
HE fast development of Information and Communication Technologies (ICTs) is fostering the transformation of the traditional health systems into new patient-centered environments. The so-called Patient Empowerment [1] is changing the conventional role of patients and physicians into a novel layout where patients take care of their own health and well-being. On the other hand, the monitoring of different vital constants, for instance, ECG, weight or blood pressure is a key issue in the follow-up of some diseases such as heart failure, Chronic Obstructive Pulmonary Disease (COPD), arterial hypertension (which is one of the main risk factors for heart diseases, strokes and also a prognostic indicator of renal failure), or the obesity, which increases the potential of suffering other illnesses such as diabetes, cholesterol, hypertension, joint diseases, gallbladder malfunction or coronary and respiratory complications, among others [2]. It is essential the availability of Medical Devices (MDs) that can help patients to self-manage the follow-up of their diseases. These MDs should be wireless and wearable in order to be practical and useful, and they have to integrate communication protocols that allow the transmission of
This research work has been partially supported by projects TIN200800933/TSI and TSI2005-07068-C02-01 from Comisión Interministerial de Ciencia y Tecnología (CICYT) and European Regional Development Fund (ERDF), TSI-020302-2008-35/Plan Avanza I+D from Ministerio de Industria, Turismo y Comercio, and FPI grant to M. Martínez-Espronceda (Res. 1342/2006 from Public University of Navarre). M. Martínez-Espronceda, S. Led and L. Serrano are with the Electrical and Electronics Engineering Dep., Public University of Navarre, Campus de Arrosadía s/n, 31006 Pamplona, Spain (e-mail: miguel.martinezde
[email protected]).I. Martínez, J. Escayola, J. Trigo, P. Muñoz and J. García are with the Communications Technologies Group (GTC), Aragon Institute for Engineering Research (I3A), University of Zaragoza (UZ), c/ María de Luna, 3, 50018 Zaragoza, Spain (e-mail:
[email protected]). A. García Quintana is with Cardiology Service of Hospital Dr. Negrín, Las Palmas de Gran Canaria, Canary Islands, (e-mail:
[email protected]).
978-1-4244-5379-5/09/$26.00 ©2009 IEEE
biomedical data. As an example, one platform developed by our group is HOLTIN [3] which consist on a wearable Bluetooth INtelligent HOLTer device that sends cardiac events through a mobile phone gateway to a healthcare center. However, the majority of the MDs as well as the protocols used in the healthcare system are proprietary and thus difficult to extrapolate to other scenarios. In this context, several protocols have arisen to cover the interoperability issue. One of the most widely known is the European standard ISO/IEEE11073 (X73). Initially designed for patient’s Point-of-Care (X73PoC) [4], it has recently evolved to Personal Health Devices (X73PHD) [5], in order to consider the emerging of new transmission technologies (such as Bluetooth, WiFi, or ZigBee) and wearable devices with limited capabilities. The basic topology of an X73based monitoring system comprises three operational subsystems: the MD, the Compute Engine (CE) and the Monitoring Server (MS). The MD (also called Agent) collect biomedical measurements and send them to the CE via X73; the CE (also called Manager) gathers the medical measurements that came from the MDs and transmit them to the MS; whilst the MS has the task of gathering these measurements, coordinating and managing the different CEs and diagnosing patient with an online follow-up. However, there are some drawbacks in the implementation of the X73 standard: its inherent complexity, the time needed to learn and implement it, the integration with other standards, lack of tools for developers or the special hardware needed to run it. These among others are focus of our work, which is being carried out in collaboration with the European Committee of Standardization (CEN) and has produced its first results [6,7] used as basis for the rest of this paper. The paper is organized as follows. Section II presents an explanation about an interoperable X73PHD standard-based pHealth platform proposal for heart failure patients’ followup, showing its main characteristics and the handicaps encountered. Later Section III makes an introduction to X73PHD specially to state the basic concepts needed to be implemented it into microcontroller-based systems, and in Section IV we propose a methodology and an architecture that enables the implementation of the X73 standard into limited resources systems and microcontrollers. In Section V, a review of future trends is presented. Finally, conclusions are drawn in Section VI.
II. HEART FAILURE PATIENT’S FOLLOW-UP SYSTEMS The work carried out during the last years in our research group with the X73PHD interoperability standard and its implementation into wearable MDs or pHealth devices, together with the development of the new healthcare service called HOLTIN, in collaboration with the cardiology service of the Hospital Dr. Negrín (Las Palmas de Gran Canaria, Canary Islands), which allows follow-up of patient with paroxistic arrhythmias and syncope for long periods of time, leads to the proposal of the implementation of a standardbased end-to-end pHealth platform for the specific scenario of heart failure patient’s follow-up (See Fig 1). The X73PHD platform is made up of several MDs which acquire the patient’s health state information and send it to a CE device through wired and/or wireless technologies such as USB, IrDA, Bluetooth or ZigBee. The CE device can be a mobile phone, set-top box or Personal Computer, and it transmits the information received from the MDs to the MS by means of ADSL, GPRS or any other long range technology. All the information at the MS can be analyzed by medical staff and integrated in the Hospital Information System (HIS). There are several medical devices which are suitable in order to be used in a heart failure patient’s follow up system: weigh scale, blood pressure, cardiac rhythm monitor, SpO2 and even thoracic impedance meter between others. The X73PHD pHealth platform proposal presented in this paper uses the following X73PHD compliant MDs: • X73PHD compliant weigh scale [8]. The patient weighs oneself following the indications of the medical staff (measurement frequency and intervals), and the weigh information is sent to the CE device. If the transmission fails the information is temporarily stored in the weigh scale and sent later.
X73PHD compliant blood pressure (BP) [9]. The patient takes the measurement (the device acquires systolic and diastolic BP, and calculates a mean) and the information is sent to the CE device. • X73PHD compliant event cardiac Bluetooth monitor HOLTIN. The wearable medical device is placed at the patient’s chest and carries out all the functionality related to the acquisition, processing of the ECG, detection, storage and transmission of cardiac events to the CE device (Smartphone) via Bluetooth technology. A fully X73PHD compliant specialization for ECG 1-3 lead devices is being drafted at the moment of this writing that will be adopted in the near future once completed. Referring to interoperability in MDs, it is important emphasize the need of wireless transmission technologies such as Bluetooth and ZigBee, that provide specific profiles for eHealth applications and that make use of the X73PHD interoperability standard. In this way, ZigBee Alliance announced recently the beginning of the development of a new Health Care Profile (HCP), and Bluetooth Special Interest Group (SIG) published last year the new Health Device Profile (HDP) [10]. One important feature in a pHealth platform is that all the medical devices are going to be portable and/or wearable devices implemented with microcontroller platforms, and are characterized by strict power consumption requirements (most of these devices are supplied with batteries), reduced RAM/ROM memory resources and process capability. All these factors have an influence on the X73PHD implementation. However the manager functionalities are implemented in devices with more resources and process capabilities, such as Smartphone, set-top box or Personal Computer. •
Fig. 1. Proposed X73 standard based p-Health platform for heart failure patients monitoring
III. ABSTRACT MODEL OF THE ISO/IEEE11073-PHD IMPLEMENTATION The X73PHD standard defines the reference model based on a well defined object oriented paradigm that guaranties extensibility and reusability with the definition of three different models: the Domain Information Model (DIM), the Service Model, and the Communication Model. Basic concepts and characteristics especially interesting for implementation purposes are given as follows: • DIM. It describes an abstract model composed by a set of classes of objects which are instantiated and can be referenced in an X73PHD based communication. That includes their attributes and the methods and actions that can be executed on each of them. The DIM covers the definition of e.g. the Medical Device System (MDS) object (the root object in the MD modeling), scanner objects (for MD data reporting), different metrics (numeric, real time sample array and enumeration objects), and Permanent Metric (PM) store and segments (for data storing). • Service model. It defines the means by which the manager can interact with the agent and distinguish two different types of services: association services and object access services. Association services provide methods to negotiate and agree a common configuration (association request and response), release associations and abort connections. Object access services provide methods that allow a manager interact with an agent by, remotely, executing actions and allowing access object attributes, thorough the link established. These services include event reports (often implemented by scanner objects and the MDS) that are initiated by the agent and used to send its configuration (during the association procedure) or medical or personal health data (once the association has been established), get and set methods that allow the manager access to object attributes, and action that allow the manager execute Remote Procedure Calls (RPCs) over the agent’s objects. Whilst event reports are initiated by the agent’s objects, get, set and action are executed over them and initiated by the manager. • Communication model. It defines Finite State Machines (FSM) for both the agent and the manager that controls the communication state and transport mechanisms. All the transitions in the FSM are well defined and they involve the execution of some actions internally in the agent or the manager, the reception or the sending of a message, etc. The FSM determines the sequence diagrams in any X73 communication and an important key point is that it is transport agnostic that means that stack implementations can be shared among transport technologies (Blueooth, Zigbee, RS-232, etc.). It also defines different Encoding Rules (ER), such as Medical Device ER (MDER), those define the algorithms responsible of the marshaling of the messages generated by the DIM and allow to transform the abstract model given by the DIM into a stream of bytes.
IV. IMPLEMENTATION MODEL IN MICROCONTROLLER-BASED PLATFORMS As it has been shown, agents and managers hardware differs strongly. Whilst agents are usually supplied by batteries and thus build into low-features hardware with low processor and memory capacities in order to reduce power consumption, managers are provided with higher capacity hardware such as a powerful 32-bit microcontroller and enough memory to run e.g. virtual machines (Java) and games. In fact it is difficult to carry out implementations in real agent devices as they are based on microcontrollerbased platforms. Previously proposed implementation solutions usually bring the X73PHD reference model into code in the way that each object in the abstract model is represented by an object into the targeted programming language (usually C++). They also use a buffer in RAM to generate the X73PHD messages what in sum requires a huge quantity of memory and processor usage. That finally forces the developer to modify the system’s design in order to add a new microcontroller or a memory module to manage X73PHD communications. Nevertheless, as X73PHD standard claims, peers can see each other as black boxes that execute actions internally conforming to the standard, which only defines how they must process incoming request messages and produce output result messages. A noticeable point is that typically messages of the same type do not differ ones from others strongly and their structure maintains invariant. That fact leads to the idea that messages used in a X73PHD communication can be obtained from linking a set of constant blocks of bytes (usually located at flash or ROM) and a few variables in RAM (see Fig 2). The blocks are called patterns and are grouped in a library called patterns library. This is similar to the idea of canned messages but uses a more generalized algorithm.
Fig. 2. X73 messages synthesis from pattern-based design
This idea can lead to a highly optimized implementation when applied to X73PHD agents. Once the device’s specialization to be implemented has been selected, the range of patterns than the device needs to process X73 messages is reduced drastically. The architecture proposed for the generic agent is depicted in Fig 3. The basic components are: the patterns library (above mentioned) and the X73-kernel. The X73-kernel is the task that copes with pattern assembling, processing, comparison and transmission. It also manages the state of the FSM, the state of objects in the DIM, and some system signals which include data sent or data received signals, connection established, connection lost, timer signals for scanners (such as PeriCfgScanner), etc. There are also other two important components in this architecture: the MD specialization dependent drivers, those provide basic functions that allow the X73-kernel to manipulate the hardware, and the adaptation layer, that provides services that allow the X73kernel to manage the transport stack. X73- kernel is transport independent thus the implementation can be shared between different devices and different wireless or wired transport technologies (Blueooth, ZigBee, IrDA, USB, etc.). The most complex component in the architecture is the X73kernel since it is in charge of the correct operation of the whole X73PHD stack. As a proof of concept an implementation has been successfully implemented on a blood pressure. To simplify its development has been used Free Real Time Operating System (FreeRTOS), as it provides common programming utilities (task, inter task communication mechanisms, etc.) that fosters the development process and allows the implementation to be portable to numerous hardware platforms with minor modifications.
Fig. 3. Architecture proposed for MDs implementation supported by pattern-based design and X73-compliant
V. DISCUSSION AND FUTURE TRENDS Several points keep open and very active in INTENSA at the moment of the writing of this paper. In the line of implementation methodologies for microcontroller-based platforms we are studying alternatives to the use RTOS that will possibly reduce hardware resource needs and foster the source code’s portability. These alternatives include the use of virtual machines in combination with finite state automatons. Moreover, given that the methodology exposed in this paper seems to be prone to automation, some algorithms to generate automatically the device’s source code firmware from a machine understandable version of the standard are being studied. VI. CONCLUSIONS INTENSA aims to develop a real heart-failure patient follow-up system based on ISO/IEEE11073 in order to test and evaluate interoperability in personal health environments. In the way some challenges appear such as implementation into microcontrollers, remote control, new specializations (Simple ECG specialization for HOLTIN devices), integration with other standards and electronic health records, etc. All of these lines are being worked on by our group. In the case of implementation into microcontrollers, a first experience (a blood pressure) has been achieved using a novel methodology based on patterns. This methodology allows implementing the standard into systems with reduced hardware resources. The first results have been successful and encourage us to continue. REFERENCES [1]
J. L. Monteagudo, O. Moreno, “eHealth for Patient Empowerment in Europe”,http://ec.europa.eu/information_society/newsroom/cf/itemdet ail.cfm?item_id=3448. Last access: 04/09. [2] World Health Organization. Obesity: preventing and managing the global epidemic. Report of a WHO consultation on obesity. Ginebra: World Health Organization, 1998. [3] S. Led, L. Serrano, M. Galarraga, “Intelligent Holter: A New Wearable Device for ECG Monitoring Using Bluetooth Technology”, 3rd EMBEC, Prague, IFMBE Proceedings, Volume 11, 2005. [4] ISO/IEEE11073. Health informatics. Point-of-care medical device communication (x73PoC-MD) [Part 1. MD Data Language (MDDL)] [Part 2. MD Application Profiles (MDAP)] [Part 3. Transport and Physical Layers]. http://www.ieee1073.org. First edition: 2004. [5] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73PHD). [P11073-00103. Technical report Overview] [P11073-104xx.Device specializations] [P1107320601.Application profile-Optimized exchange protocol]. http://standards.ieee.org/. First edition: 2006. [6] M. Martínez-Espronceda, L. Serrano, I. Martínez, J. Escayola, S. Led, J. D. Trigo and J. García, “Implementing ISO/IEEE 11073: Proposal of two different strategic approaches”, 30th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, EMBC 2008, Pages 1805-1808. Digital Object Identifier 10.1109/IEMBS.2008.4649529. [7] M. Martínez-Espronceda, I. Martínez, J. Escayola, L. Serrano, J. D. Trigo, S. Led and J. García, “Standard-based Digital Homecare Challenge: Advances of ISO/IEEE11073 for u-Health”, ICMCC Digital Homecare Book. In press. [8] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73PHD). Part 10407. Blood Pressure. 2008 [9] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73PHD). Part 10415. Weighting Scale. 2008 [10] Continua Health Alliance. http://www.continuaalliance.org/. Accessed July 2009.
Proceedings of the 9th International Conference on Information Technology and Applications in Biomedicine, ITAB 2009, Larnaca, Cyprus, 5-7 November 2009
SCP-ECG in an ISO/IEEE 11073-PHD world: Store-and-Forward Transmission and Messaging Part. Jesús D. Trigo, Franco Chiarugi, Álvaro Alesanco, Miguel Martínez-Espronceda, Luis Serrano, Catherine E. Chronaki, Javier Escayola, Ignacio Martínez and José García va
Abstract—The storage and retrieval of digital ECGs in a standard-compliant way has been a key issue during the last decades. The SCP-ECG standard, one of the top efforts in this area, has been recently approved as part of the ISO/IEEE 11073 (x73) family of standards, a reference standard for medical device interoperability. For the Personal Health Device (PHD) version of the x73 standard several devices have been defined, but an ECG device specialization is not yet available. In this paper, the relationships between the SCP-ECG fields and messages and the particular way of the x73-PHD standard to deal with stored data are investigated and discussed. A proofof-concept implementation of the x73-PHD storage and retrieval method applied to ECGs is also presented, identifying open issues and potential modifications to be considered for the wider interoperability adoption of x73-PHD standards.
Index Terms— interoperability, ISO/IEEE 11073-PHD, SCP-ECG, Store-and-Forward, standards. I. INTRODUCTION
A
wide range of the existing Telehealth applications do not usually require an immediate response, for example, a consultation for dermatology or radiology. The Store-andForward (S&F) technique, due to its characteristics, is the best suited technology to be applied in those situations, and the future points to significant growth of such applications in many areas of health care service delivery [1]. The electrocardiographic (ECG) signal, especially in nonemergency situations, is particularly suitable for S&F telemedicine from a technical point of view [2]. In this context, a large variety of protocols and standards have been proposed. Some of the more widely known are: SCP-ECG (European standard EN1064), HL7 aECG (American standard, ANSI), or DICOM Waveform Sup 30. In the near This work was partially supported by projects TIN2008-00933/TSI and TSI2005-07068-C02-01 from Comisión Interministerial de Ciencia y Tecnología (CICYT) and FPI grant to M.Martínez-Espronceda (Res. 1342/2006 from Public University of Navarre) and a research visit grant to J.D. Trigo awarded by Diputación General de Aragón (DGA), Consejo Asesor de Investigación y Desarrollo (CONAID) and Caja de Ahorros de la Inmaculada (CAI), Ref. IT7/08. J. D. Trigo, Á. Alesanco, J. Escayola, I. Martínez and J. García are with the Communications Technologies Group (GTC), Aragón Institute for Engineering Research (I3A). University of Zaragoza. María de Luna, 1. 50018 Zaragoza. Spain (corresponding author e-mail:
[email protected]). M. Martínez-Espronceda and L. Serrano are with the Electrical and Electronics Engineering Dep., Public University of Navarre, Spain. F. Chiarugi and C. E. Chronaki are with the Biomedical Informatics Laboratory, Institute of Computer Science (ICS), Foundation for Research and Technology – Hellas (FORTH), Heraklion, Crete, Greece. 978-1-4244-5379-5/09/$26.00 ©2009 IEEE
future, the rising ISO/IEEE 11073-PHD (x73-PHD) standard will also be able to cover the S&F transmission of ECG data. In the literature, several projects covering the relationship between two or more of these standards can be found (Fig.1). Examples of those relationships are: SCP-ECG with DICOM [3,4]; SCP-ECG and HL7 aECG with DICOM [5]; SCPECG with HL7 aECG [6]; or SCP-ECG with x73-PHD [7]. [6]
X73-PHD
[7]
SCP-ECG
HL7 aECG [3]
[4]
[5]
[5]
DICOM
Fig. 1. Relationship between the different formats. SCP-ECG [8] and x73-PHD [9] are two close-related standards. In fact, the SCP-ECG standard has recently become an international standard as ISO/IEEE 1107391064:2009, part of the x73 family [10], although an ECG profile for x73-PHD is not yet available [11]. However, in the particular case of S&F transmission, there are still several issues in the coordinated use of SCP-ECG in an x73PHD world that have not been adequately investigated yet. II. ARCHITECTURE The general scheme of an end-to-end standard-based Telehealth system serving as a proof-of-concept can be seen in Fig. 2. In it, an x73/SCP-compliant ECG device (called Agent) records and stores the ECG signal. Later, this Agent connects with an x73/SCP-compliant entity (called Manager) and informs that there are stored data in the Agent not sent yet. The Manager can forward this message to a Management Server which answers, deciding whether to retrieve this information or not. Then, the Manager will proceed and execute the decision, making use of the x73 procedure to deal with stored data. If the selected choice is to retrieve the data, the Manager will retrieve them and generate an SCP-ECG file. After that, the file can be forwarded through eXtensible Markup Language (XML) to an Electronic Healthcare Record (EHR) server for later consultations in compliance with EN13606 standard. Finally, the SCP-ECG file can be observed with all its specific fields by using a HealthCare Information Systems (HCIS). The transmitting protocols in the interfaces beyond the Manager are out of the scope of x73-PHD and they are not covered in this paper. This paper focuses on the Agent/Manager interface (wherein x73-PHD applies), but some other aspects of the whole scheme are discussed.
Agent Manager
XML/ SCP
SCP ECG file
TABLE I TYPES OF FIELDS IN SCP-ECG AND THEIR RELATIONSHIP WITH X73-PHD PM-STORE
Hospital HCIS/SCP
Group
x73/ SCP
X73 ECG Adapter Recorder
Section
Network Network
x73/SCP-compliant ECG device x73/SCP-compliant entity
Management EN13606 Services EHR Server
Patient
1
Device
1
SCP Viewer
Fig. 2. Overall end-to-end standard-based architecture.
B. The SCP-ECG groups of information data The minimum fields required to create an SCP-ECG file can be subdivided into six different groups, according to the information they are related to: patient, device, temporal, lead, waveform, and the data themselves (see Table I). In this study, only the mandatory and the recommended fields of SCP-ECG are covered. The following assumptions are made: no compression, all leads are simultaneously recorded, the SCP-ECG device has no analyzing capabilities and it stores patient information, the SCP-ECG compliance category chosen is Type I (as defined in [8]) and, finally, a RT-SA is used to encapsulate the ECG within the PM-Store. C. x73-PHD PM-Store and SCP-ECG format relationship These are two suitable ways to arrange ECG data. The main difference is that, while SCP-ECG is a standard specially designed for electrocardiography, x73-PHD is a wider standard, so the PM-Store is a broader idea in order to handle the large variety of existing metric data. This makes x73-PHD more versatile. In an SCP-ECG file, all six groups of information must be stored but, not all these groups are needed to be stored from an x73-PHD PM-Store perspective.
Description
0 1 2 5 8 14 25 26 34
Patient Last Name Patient First Name Patient ID Patient Date of Birth Patient Sex Acquiring Device ID Date of Acquisition Time of Acquisition Date Time Zone
Relationship with x73-PHD PM-Store PM-Segment::PM-Seg-Person-Id
Not included PM-Segment::PmSegmentEntryMap. SegmEntryHeader (Time Stamp)
Temporal
1
Lead
3
-
Lead ID
PM-Segment::PmSegmentEntryMap. SegmEntryElem.metric-type.code
Waveform
6
-
Amplitude Value Multiplier Sample Time Interval Sample Size Length
Related to RT-SA (typically one PM-Segment Entry)
Data
6
-
Data
Related to RT-SA (typically one PM-Segment Entry)
III. STORE&FORWARD IN X73-PHD AND SCP-ECG A. The x73-PHD’s persistent metric concept The Persistent Metric (PM) concept in x73-PHD provides a method for representing, accessing, and transferring large amounts of metric data hierarchically stored in the Agent. A PM store consists of the following four key parts [9]: 1) PM-Store: This is the top most object and it contains attributes about the storage object as well as zero or more PM-Segments. Agents typically use multiple PM-Stores if they stores data with different characteristics. 2) PM-Segment: This object contains attributes that describe the segment as well as zero or more entries. Agents typically use multiple PM-Segments if they need to structure the stored data in a more hierarchical form. 3) Entry: Each entry holds an optional header and one or more elements. An entry typically contains a measurement (Numeric, Real Time Sample Array (RT-SA), etc.). 4) Element: Each element holds data from one or more metric measurements. The PM-Store concept of x73-PHD only suggests a hierarchical approach to arrange metric data. The final organization (as well as the internal physical storage) is device-dependent, so it is covered later in Section V.
Tag
Table I also shows the relation of these SCP-ECG fields with the x73-PHD PM-Store concept: 1) Patient: These SCP-ECG fields can be covered using the PM-Seg-Person-Id attribute. The Manager will be able to gather the patient data to generate an SCP-ECG file. 2) Device: This information is related to the ECG device. This kind of information is sent during the configuring process. Thus, storing this information is not required. 3) Temporal: Entries optionally include a time reference. 4) Lead: The SCP-ECG Lead ID can be included when defining the PMSegmentEntryMap attribute. 5) Waveform and Data: These SCP-ECG fields fit perfectly in a RT-SA class. As said before, an entry typically contains a measurement (in this case, a RT-SA). Some other considerations, such as, a different patient approach or the relation of the SCP-ECG fields to the x73PHD RT-SA, were covered in a previous work [7]. IV. MESSAGING PART A. The x73-PHD method to manage stored data When an Agent implements one or more PM-Store objects, the Agent reports about the existence of the PMStore object during the configuration phase (attributes: Handle and PM-Store-Capab). The Manager uses this information to query the PM-Store object(s) of the Agent by using the following methods or services: 1) Retrieve PM-Store attributes: The Manager may query each PM-Store to request all or some attributes be returned. 2) Retrieve PM-Segment information: The Manager can retrieve information on the segments and request to return information from: a) all-segments, b) a particular list of segments, or c) any segments within a given time range. 3) Transfer PM-Segment content: The Manager is able to retrieve specific PM-Segments. The Agent shall decide if the request can be honored and shall return a successful response code or an appropriate error code. The Agent shall send reports until all entries are sent or the transfer is aborted. 4) Clear PM-Segment: The Manager may clear a PMSegment at any time, typically straight after the entire segment was transferred to the Manager. The segment selection criteria are the same as in IV.A.2).
TABLE II SCP-ECG MESSAGES AND THEIR RELATIONSHIP WITH X73-PHD PM-STORE METHODS AND SERVICES Type I R
Description Identification Request
S
Status
A D
Advisory Done
Sub-Type E I L P
Description Uniquely identify the requesting device Send ECG List for Specified Patient Send Patient List for Specified Name Receive ECG List for Specified Patient Receive Patient List for Specified Name
R
Receive ECGs
S X G E -
Send ECGs Escape to Vendor Specific Request Ok Error Provides additional information Completion of a command
Sub-Code 0 1 2 4 8 16 32 Vendor Code Number -
B. The SCP-ECG messaging part The messaging part of SCP-ECG (informative, but not normative) describes the type of information that can be requested and transmitted between a cart and a host in order to manage stored ECGs that are yet to be forwarded. It also describes the format of these messages and its usage. The different data messages (Identification, Request, Status, Advisory and Done) and its usage are shown in Table II. The relationship with x73-PHD is covered in Subsection IV.C). C. x73-PHD and SCP-ECG messages relationship The detailed analysis of the x73-PHD and SCP-ECG messages relationship (see Table II) is explained below: 1) Identification, Status-Ok and Done. These SCP-ECG messages are covered by the x73-PHD Finite State Machine (FSM) itself. 2) Status-Error. This SCP-ECG message provides a little collection of fixed error codes (EC). Some of them are mapped by x73-PHD frames such as, for example, badlystructured-apdu (EC=5). Some other error codes do not make any sense as, for example, patient name invalid (e.g. EC=11), since no patient information is stored in the ECG device. However, these types of error codes can be useful in the Manager/Management Server interface. 3) Request. This SCP-ECG message is further subdivided in the following sub-types: - Sub-Types P and I do not make sense in x73-PHD (since there is no patient information in the ECG device) but may be useful in the Manager/Management Server interface. - Sub-Types E and L. These messages request to receive and send an ECG list for a specified patient. They can be covered by the Retrieve PM-Segment information method, although the procedure is different: while these messages specify a patient by sending a list of her/his identification parameters (ID, Name, Sex and/or Date of Birth), the x73PHD method only uses the Person-Id. Once the x73-PHD method has retrieved the PM-Segment information, the Manager is able to create a list of ECGs for a specific patient. Besides, in x73-PHD, the rest of the parameters (not only the ones related to the person) are susceptible to be the base of a request list.
Description No request mask needed: send all ECGs Requested ECG, will have Date and Time Latest ECG 1st Previous ECG 2nd Previous ECG Baseline ECG if present, otherwise oldest ECG All Since, will have Date and Time Vendor Specific Code Some error codes are provided -
Relationship with x73-PHD Covered by x73-PHD configuring procedure Retrieve PM-Segment information (Response) Does not make any sense in x73 Retrieve PM-Segment information (Invoke) Does not make any sense in x73
Can be covered by using Transfer PM-Segment (Invoke)
Transfer PM-Segment (Response) Not standard Covered by the x73-PHD FSM See IV.C) Not mapped. See IV.C) Covered by the x73-PHD FSM
- Sub-Type R. After retrieving the PM-Segment information, the Manager can choose any segments to be transferred using only the segment handle by means of the Transfer PM-Segment method (Invoke). In SCP-ECG, there are only a few bit-mapped possible choices. - Sub-Type S. Taking into account the differences between these two protocols, this message is directly related to the x73-PHD Transfer PM-Segment (Response). 4) Advisory. In order to avoid the rising of a time-out, this message provides additional information in case that a large amount of time is needed to elaborate the response. There is no such a concept in x73-PHD. Nevertheless, some time-outs can be set (Clear, Confirm, Transfer). Furthermore, some other technical issues have been considered in order to complete this study. The Clear PMSegment idea is not present in SCP-ECG, so the manager is not able to remove ECG data stored in the device. This is done by the ECG devices, which can be usually configured so that the ECG is deleted after a successful transmission. The SCP-ECG request messages Sub-Types P and L (that list files or patients) are blind, to a certain extent, since the Manager does not know what the cart actually stores. Instead, in x73-PHD, the Manager first asks for the parameters he wants to know about and then creates a specifically designed list for retrieving the metric data. However, in SCP-ECG the device is able to initiate the sending of stored ECGs, while in x73-PHD the device just informs of the existence of stored data. Then, the Manager (or further decision entities) resolves either to retrieve this information or not. In SCP-ECG the maximum message size is 256Bytes. This sometimes leads to forced truncations to comply with this restriction, but these shortenings are usually not critical. In x73-PHD, the frames shall be no larger than 63KBytes (from Agent to Manager) and 8KBytes (from Manager to Agent). Finally, in x73-PHD, it is encouraged to pack as many entries as possible into the Event structure to optimize the transmissions. In the particular case of ECGs, probably more than one Event will be needed, so the Manager has to take care of this control with SegmDataEventDescr. In contrast, the control of the SCP-ECG file length is accomplished by lower protocol layers.
V. IMPLEMENTATION
VI. CONCLUSIONS AND FUTURE DIRECTIONS
To the best of our knowledge, there is no previous work in this context. An end-to-end standard-based platform was implemented by our group [12]. It was developed using C++ and included all the required x73-PHD classes, attributes and specifications. The first device specializations implemented were: pulse-oximeter, blood pressure and weighing scale. Later, a custom-defined x73-PHD/SCP-ECG specialization was added [7]. Within the project described in this paper, the simulated ECG device was used to record, store and later transmit an ECG by means of the PM-Store concept. In our application, it has been organized as follows: - PM-Store: It contains all the ECGs stored in the device. The attribute Number-Of-Segments specifies the number of stored ECGs. - PM-Segment: An ECG. The PM-Seg-Person-Id attribute identifies the patient/user. - Entry: It encapsulates one lead (per Entry) in a RT-SA structure. Thus, it contains the data itself but also the information related to this lead (e.g. sample size, scale…). - Element: One single ECG sample. The first elements in the entry correspond to the information related to this lead. The x73-PHD standard establishes that only complete entries shall be included in a SegmentDataEvent. Depending on different parameters (sample rate, simple size or time recorded) the total length of one lead could exceed the limit of 63KBytes. Two approaches can be considered: - Split up the leads into several entries/segments. This might obscure the hierarchical organization. Besides, some minor modifications should be done in the x73-PHD standard in order to keep track of the fragmented ECG. - Entries can be fragmented. The idea is to modify the x73PHD, so that one Entry can be divided into sequential SegmentDataEvents. In our implementation, this approach has been followed. When holding a fragmented Entry, the field segm-evt-entry-count is set to zero. Besides, two new fields have been added to the SegmDataEventDescr struct to keep count of the Entry fragment being transmitted: segm-evt-entry-fragmnt-index (index of the fragment) and segm-evt-entry-fragmnt-total (total number of fragments). Regarding the internal physical storage, in our application the data are stored in a file exactly in the order that the Manager would ask for them, so that it is quicker to create response messages or SegmentDataEvents. Therefore, in a totally transparent way for the final user, the x73-PHD standard is followed by an Agent to configure a simulated ECG device, record and store an ECG signal and finally send it to the Manager using the PM-Store concept, classes and procedure (including a modification to deal with large ECGs). After that, the Manager generates a SCP-ECG file that can be sent to an EHR Server and included in the patient history. The SCP-ECG files generated with our application have been successfully tested using the certification service provided by the OpenECG portal [13]. This tool includes a content checker and a format checker.
The S&F feature by means of the PM-Store class has been implemented in a pre-existing x73-PHD platform that included a simulated and custom-defined ECG device. An enhancement to cover the transmission of large ECGs has been proposed and discussed. The ability of the SCP-ECG messaging part within the framework of x73-PHD has been investigated. The relationships between the different fields and messages of both standards have been described. This process has proved that the x73-PHD PM-Store concept is a well-defined idea to manage metric stored data, including ECGs. The open approach used in x73-PHD to define the messages and fields covers practically the whole SCP-ECG messaging part. Some SCP-ECG ideas, that lose their sense in an x73-PHD interface, can be profitably transferred to the Manager/Management Server interface. The main further research trend is the implementation of the Management Server. It could cover not only the medical management (medication reminder alarms or modification of parameters, such as resolution, sample interval, amplitude…) but also the technical management of the device, including this way Managers and Agents in the management network. REFERENCES [1]
[2] [3]
[4] [5] [6]
[7]
[8] [9] [10] [11] [12]
[13]
L. Reimer, L. Liu, and I. Henderson, “Beyond videoconference: A literature review of store-and-forward applications in telehealth” in Proceedings of the Second IASTED International Conference on Telehealth, pp. 125-130, Banff, AB: ACTA Press., 2006. R. Wootton, J, Craig and V. Patterson (Editors), “Introduction to telemedicine”, Rittenhouse Book Distributors, 2 nd Ed, pp. 44, 2006. V. Sakkalis, F. Chiarugi, S. Kostomanolakis, C.E. Chronaki, M. Tsiknakis, S.C. Orphanoudakis, “A gateway between the SCP-ECG and the DICOM supplement 30 waveform standard”, in Computers in Cardiology, pp. 25- 28, 2003. W. Ling-ling, R. Ni-ni, P. Li-xi, W. Gang, “Developing a DICOM Middleware to Implement ECG Conversion and Viewing”, in Int Conf IEEE Eng in Medicine and Biology Society, pp. 6953-6956, 2005. M.J.B. van Ettinger, J.A. Lipton, M.C.J. de Wijs, N. van der Putten, S.P. Nelwan, “An open source ECG toolkit with DICOM”, in Computers in Cardiology, pp. 441-444, 2008. A. Schloegl, F. Chiarugi, E. Cervesato, E. Apostolopoulos, C.E. Chronaki, “Two-way converter between the HL7 aECG and SCPECG data formats using BioSig”, in Computers in Cardiology, pp. 253-256, 2007. J.D. Trigo, F. Chiarugi, Á. Alesanco, M. Martínez-Espronceda, C. E. Chronaki, J. Escayola, Ignacio M. and J. García, “Standard-Compliant Real-Time Transmission of ECGs: Harmonization of ISO/IEEE 11073-PHD and SCP-ECG”, in Int Conf IEEE Eng in Medicine and Biology Society, 2009. SCP-ECG, Standard Communication Protocol for Computer-Assisted electrocardiography, EN1064:2005+A1:2007. ISO/IEEE11073. Health informatics Medical Devices communication [P11073-20601.Application profile-Optimized exchange protocol]. http://standards.ieee.org/. First edition: 2006. ISO/FDIS 11073-91064 Health informatics. Standard communication protocol – Part 91064: Computer-assisted electrocardiography. ISO/IEEE11073-10406 Health informatics. Personal Health Devices communication. Device Specialization - Basic ECG (1-3 lead). I. Martínez J. Escayola, I. Fernández de Bobadilla, M. MartínezEspronceda, L. Serrano, J.D.Trigo, S. Led and J. García, “Optimization Proposal of a Standard-based Patient Monitoring Platform for Ubiquitous Environments”, in Int Conf IEEE Eng in Medicine and Biology Society, pp. 1813-1816, 2008. OpenECG Project, http://www.openecg.net. Accessed June 2009.
