The Conceptual Modeling of Interoperability Framework of Heart Sound Monitor in the Context of an Interoperable End-to-End Architecture

Abstract

Background: Heart sound monitor (HSM), a device suitable for home-use, can be used to acquire heart sounds. It enables the telemonitoring of cardiac function, which has been largely evolved and widely used in recent years. Nevertheless, the designers paid little attention to the consistency of information model and data interaction of HSM, thus the data could not be shared and aggregated among healthcare systems. Consequently, the device's development and its application in person-centered telehealth are hindered.

Objective: To solve this problem and to build interoperability for HSM, this article proposes a HSM interoperability framework that is constructed by using standardized modeling methods.

Methods: The authors collected the common device-output information of HSM involved in telemonitoring, leveraged the standardized interoperability framework defined in ISO/IEEE 11073 Personal Health Device (11073-PHD) standards to model the static data structure and dynamic interaction behaviors of HSM.

Results: Via a meta-analysis, the HSM device-output information includes collected data (heart sound measurement), and derived data (e.g., device status). Based on such information, an 11073-PHD-compliant domain information model has been successfully created. This enables the interoperability between HSM and aggregation device, allowing inter-device plug-and-play using the service model and communication model. A prototype of this design has been implemented and validated via Continua Enabling Software Library.

Conclusions: The ISO/IEEE 11073-PHD standard framework has the potential to accommodate the HSM, which implicate HSM can be integrated into the interoperable ecosystem to achieve holistic health solution. Findings in this article may be taken as a reference for standard developing organizations to establish a standardized interoperability framework for HSM.

Introduction

Cardiovascular disease (CVD), a class of chronic noninfectious diseases, has been the leading cause of death in the world.¹ The heart sound, as a direct manifestation of cardiac mechanical activity, provides a set of valuable information about one's cardiovascular physiological and pathological status. Through an electronic stethoscope, heart sounds can be detected by heart sound monitor (HSM) and be recorded after being converted into digital signals so that a phonocardiogram (PCG) can be formed. The feature parameters (e.g., time-domain and frequency-domain parameters, the abbreviations of these parameters are shown in Table 1) can be derived from PCG via the signals processing and features extraction, such signal analysis process can be done locally in HSM or done remotely in computing device (e.g., computer, cellphone, and server).

Table 1.

Abbreviations of Heart Sound Parameters

ABBREVIATION	THE FEATURE PARAMETER OF HEART SOUND
S1	The amplitude of first heart sound
S2	The amplitude of second heart sound
D	Diastolic duration
S	Systolic duration
S1/S2	The amplitude ratio of the first heart sound to the second heart sound
D/S	The ratio of diastolic to systolic duration
HR	Heart rate
CCCT	Cardiac contractility change trend (the increase of the amplitude of S1 after completing whole exercise workload, with respect to S1 recorded at rest)
T1/M1	The amplitude ratio of the first heart sound at the tricuspid auscultation area to the first heart sound at the mitral auscultation area

A number of studies already proved that those parameters can reflect the abnormalities and pathologic characteristics of the heart. For instance, diastolic/systolic (D/S) and heart rate (HR) going beyond the normal ranges during the stage of pregnancy or labor indicate a phenomenon of cardiac overload that might lead to pathologic changes.² The D/S and the amplitude ratio of the first heart sound to the second heart sound (S1/S2) of preterm infants whose cardiovascular system is not yet mature are significantly lower than full-term infants.³ And the decrease of S1/S2 has been observed in patients with left ventricular systolic dysfunction.⁴ Also, some studies have developed neural network-based or experience-based recognition models base on the frequency spectrum features of PCG, which can effectively discriminate abnormal sounds, detect and discern heart murmurs, and be used as a significant auxiliary tool for heart auscultating.⁵ In addition, the D/S and S1/S2 of athletes are both higher the average person, which indicates that heart sound signals can also be applied to assess cardiac reserve so as to select physically fitter athletes and train them more scientifically.⁶ The HSM is generally perceived as a useful tool to monitor the cardiac reserve and cardiac function, and it can aid in the early diagnosis of CVD.

During the development of HSM, the portable personal health device (PHD) gains its momentum, which can be used for continuous monitoring of personal health status in the context of home, outside, emergency, and even during extra-vehicle activities.⁷ This enables the use of HSM in either home or outdoor environment.⁸ Also, with the advancement of Internet of Things technology and medical information technology, wireless communication and database technologies are introduced to the development of HSM healthcare system, which enables the real-time telemonitoring of cardiac function.^9
–11 The heart sound data can be recorded by HSM wherever, and it can be locally analyzed and managed after the data have been transmitted to gateway devices (e.g., cellphone or personal computer) through communication interface integrated on HSM. The obtained data can be further transferred to healthcare information systems through those gateway devices, so that the information can be accessed and analyzed by professional caregivers in distance. During the telemonitoring process, the alert function of HSM allows both the users and the caregivers be informed when the heart sound parameters exceed the limit, which enables the caregivers to intervene in or dispatch emergency service timely. Besides, HSM can also send out its running status through communication interface, thus medical malpractice caused by device fault would be avoided, and device troubleshooting information could be provided for the vendor. Multiple studies have found that there were reduction in medical costs, hospital admissions/readmissions, length of hospital stay, and emergency department visit on the application of telemonitoring for heart failure patient.^12,13

With HSMs healthcare system, the heart sound data of users under each period of disease prevention, treatment, and rehabilitation can be collected and the medical value of these data can be maximized; furthermore, the heart sounds libraries of these systems can be used for research opportunities and education, for example, applied in the field of medical research, identity verification, and digital signatures. Currently, many research teams or vendors are already capable to integrate the HSM device into an end-to-end healthcare system through common transmitting technologies. Nevertheless, such solutions are all based on proprietary protocols: the digital signals of PCG in different auscultation areas with different sampling frequency and bit resolution is transmitted by HSM to gateways through USB or Bluetooth in a proprietary encoding format, besides, some systems also transmit the feature parameters of PCG or the alert information.^11,14
–16 However, little attention has been paid to the semantic interoperability in the aspect of data format, interaction mechanism, and system compatibility. This caused vast discrepancy among the data components, semantic representation, and expression structure of HSM information model between systems. The heart sounds data and context information can only be accessed by the users of vendor-specific healthcare system, which makes person-centered information sharing and collaborative care in the field of cardiac function telemonitoring a major problem, and has put stakeholders into many silos and hindered the commercialization and industrialization of HSM. This can only be solved by building a consistent information model and interaction mechanism to ensure the standardization and validation of heart sound data from disparate source.

By far, the personal connected health industry has already taken some actions to interconnect and aggregate the health information from home-use devices.¹⁷ Interoperability architecture was built up by them to achieve an interoperable personal connected health ecosystem, as shown in Figure 1, where the standards of each interface are integrated and harmonized and thus the end-to-end interoperability and semantic consistency have been established. This enables data recorded by various PHDs to be shared seamlessly in each interface and integrated efficiently into healthcare information systems, for example, electronic health records; in addition, new components such as new PHDs can be easily incorporated into this architecture to achieve a holistic and ubiquitous solution. With regard to the PHDs interface in this architecture, it has both a lower-layers component (Open-Systems-Interconnection [OSI] layers 1–4) and an upper-layers component (OSI layers 5–7). The lower layers adopt base transport standards (e.g., USB and Bluetooth) and the upper layers are the ISO/IEEE 11073-PHD standards that define the transport-independent interoperability frameworks for multiple types of connected PHD, specifying their information model, data structure, and interactive behaviors.¹⁸ The importance of this interface is reflected in two aspects: (1) the interoperability of devices interface ensures the seamless sharing and efficient aggregation of data in follow-up interfaces of the architecture; (2) the interoperability of application layer provides uniform information models that defines unambiguous semantics and consistent syntax for data. However, as a widely used device in the personal connected health domain, HSM has not yet been covered by this interface, that is, no application-level framework has been established for it. To fill this gap, this article aims to establish an interoperability framework for HSM by modeling its device-output information within the aforementioned standard frameworks.

Fig. 1.

PHD interoperability architecture. PHD, personal health device.

The following content of this article is organized as three sections: the Methods section presents the method of establishing the HSM interoperability framework; the Results section presents the designing and implementation results of this framework; and finally the Discussion section draws conclusion upon this article.

Methods

The Overview Of Modeling Process

To create compliance toward the 11073-PHD standards, one has to build the information model and define the corresponding access methods. For our purpose, the first step is to collect, analyze, and group the HSM device-output information based on the common needs of HSMs; second, the common tools provided by ISO/IEEE 11037-PHD standards are customized and tailored for HSM; the third step is to leverage these tools to create a domain information model (DIM) of HSM, and to define parameters for this model. The whole process is shown in Figure 2 and each step will be elaborated hereinafter.

Fig. 2.

The modeling process of HSM interoperability framework. HSM, heart sound monitor.

Hsm Device-Output Information

Thanks to profound analysis and experimental modeling done by scholars from this domain, there has been a number of HSM-related metrics defined and used for assessing cardiac health status, although different vendors might define their metrics in different ways. To create a common understanding of these metrics, the authors did a literature review to extract those HSM-related metrics with higher occurrence frequency and suitable for telemonitoring. This data set will serve as the basis to further information modeling, and it might help to improve the applicability of the resulted model.

Iso/Ieee 11073-Phd Interoperability Framework

The 11073-PHD standards family defines a generic interoperability framework, specifying how PHDs exchange information with aggregation devices in aspects of model classification, abstraction, and construction. Among these standards, the ISO/IEEE 11073-20601 Optimized Exchange Protocol serves as the baseline standard. It defines a reference model based on an object-oriented paradigm that guarantees extensibility and reusability by defining three different models: DIM, service model, and communication model.¹⁹ The ISO/IEEE 11073-104xx Device Specializations are a set of standards established on top of the 11073-20601, providing specific constraints and configurations designed for certain type of PHD.

For the purpose of this research, a HSM-specific DIM is created by mapping and representing above HSM-specific metrics into 11073-20601 generic models. With regard to the service model and communication model defined in 11073-20601, there is not much difference between HSM and other PHDs.

Designing The Parameters Of Dim

A DIM of PHD contains a set of “objects” representing device-output information via the objects' attributes.²⁰ The design procedure of HSM DIM mainly includes two parts: (1) class model instantiation and (2) attributes design.

The instantiation of class model

The DIM defined in 11073-20601 provides a set of generic classes for device modeling. The first step of the design procedure of HSM DIM is to map the HSM-specific metrics with appropriate class models, and then instantiate each object to represent these metrics.

Designing the attributes

After instantiation, the objects in DIM need to be refined by designing the details of their attributes. This includes the description of the metric value, data types, data status, and other semantic contents of those objects. During such process, the nomenclature codes are developed to ensure semantic consistency of data elements, and the Abstract Syntax Notation Number One (ASN.1) structures are developed to ensure the syntactic consistency.

Nomenclature code

A nomenclature code is used to identify a commonly agreed concept involved in PHD interoperability. It helps to avoid different semantic understanding caused by different stakeholders or by different languages.²¹ In addition, it makes the message payload of communication protocols compact. The nomenclature code in 11073-PHD standard family consists of a high 16-bit partition code and a low 16-bit term code. For the need of vendors, researchers, and testers, a code space is reserved for proprietary extensions.

ASN.1

The ASN.1 is a standardized syntax notation that is used for the definition of data types, values, and constrains on values, which can be combined with standardized encoding rules (e.g., Medical Device Encoding Rules [MDER], Binary Encoding Rules [BER]) to achieve efficient data encoding and decoding with the strong capacity for semantic expression. This syntax notation method is neutral to programming language or lower layer transport. When creating the DIM for HSM, the abstract data types defined by ANS.1 are used to describe the semantic information of attributes.

Results

Hsm Device-Output Information

Searching by the keywords “heart sound/PCG,” “digital/electronic stethoscope,” and “cardiac contractility” in the databases: Web of Science, Engineering Village and PubMed, 395 articles are retrieved. Among them, 349 articles are found irrelevant to HSM, or are only focused on front-end sensing technology or postprocessing algorithm of denoise and diagnosis, thus are excluded. By studying the remaining 46 works, and meanwhile by referring to several DIMs defined in existing 11073-104xx standards, the authors identified a set of metrics that HSM devices often exchange with other devices. This metrics can be divided into two categories: collected data and derived data. The collected data, namely heart sound data, includes PCG gathered from one or more auscultation areas and feature parameters extracted from PCG; the derived data include threshold information, device status, and sensor location. The frequencies of occurrence of these metrics are summarized in Table 2.

Table 2.

The Heart Sound Metrics and Their Frequency from Those Studied Works

TYPE OF DATA	HEART SOUND METRICS	COUNT OF OCCURRENCE
Collected data	PCG	46
	S1/S2	4
	D/S	5
	HR	5
	CCCT	3
	T1/M1	1
Derived data	S1/S2 threshold	2
	D/S threshold	5
	HR threshold	1
	HSM threshold status	1
	Sensor location
	Aortic	8
	Mitral	7
	Tricuspid	8
	Pulmonary	7
	General device status	3

HSM, heart sound monitor; PCG, phonocardiogram.

As for the collected data, PCG is the one that appears most frequently in the studied articles. It is the core data for both experimental study and commercial products. With regard to the metrics extracted from PCG, the S1/S2, D/S, HR, and CCCT are with the higher frequency. Since CCCT can only be obtained from specific exercise tests conducted by professionals, it is hardly applicable to personal telemonitoring.²² In addition, there are few works studying on T1/M1, however, further studies may need to verify its accuracy and validity.²³

As for the derived data, those listed metrics are either directly used by personal telemonitoring or are used to provide further details of certain collected data. As a result, the PCG, S1/S2, D/S, and HR in collected data and the S1/S2 threshold, D/S threshold, HR threshold, HSM threshold status, sensor location, and general device status in derived data are chosen as HSM device-output information. They are the targets for the following information modeling.

The Instantiation Of Class Model

The mapping between the HSM device-output information and the class model, and the result of object instances are shown in Table 3. The Medical Device System (MDS) object represents the abstract concept of HSM, which mainly describes device general information, such as device identity, vender information, and device configuration. The numeric objects represent episodic measurements, such as D/S, S1/S2, HR, and threshold data. The Real-Time Sample Array (RT-SA) objects represent continuous samples or waveform data, for instance, PCG. The enumeration objects represent event annotation data, such as threshold status and device status. Considering that the HSM may collect PCGs from multiple auscultation areas simultaneously, the sensor location information is embedded as an attribute in each PCG object.

Table 3.

Mapping Between Heart Sound Monitor Device-Output Information and Class Model, and the Object Instances

INFORMATION TYPE	HSM DEVICE INFORMATION	CLASS MAPPING	OBJECT NAME
System information	\	MDS	HSM
Collected data	PCG	RT-SA	PCG Waveform
	D/S	Numeric	Ratio of Diastolic to Systolic Duration
	S1/S2	Numeric	Ratio of S1 to S2 Amplitude
	HR	Numeric	Heart Rate
Derived data	S1/S2 threshold	Numeric	S1/S2 Low/High Threshold
	D/S threshold	Numeric	D/S Low/High Threshold
	Heart rate threshold	Numeric	Heart Rate Low/High Threshold
	HSM threshold status	Enumeration	HSM Threshold Status
	General device status	Enumeration	General Device Status
	Sensor location	—	—

MDS, medical device system; RT-SA, real-time sample array.

As shown in Figure 3, the object instance diagram of the HSM DIM structurally demonstrates each object instance of HSM and their relationships.

Fig. 3.

The object instance diagram of the HSM DIM. DIM, domain information model.

Designing The Attributes

Once instantiated, the attributes of above objects need to be designed, they may be dropped, restricted, extended, or reused. This is because the objects defined in ISO/IEEE 11073-20601 serve for a wide range of PHDs, rather than a particular type of device. We have to refine these objects to cover the specific needs of HSM, and this may help to optimize the massage payload during data transmission. Such design process includes following steps: (1) selecting attributes, (2) defining nomenclature and specifying the semantic of abstract data structures. As a result of the design, the summary of the designed attributes of each instantiated object in HSM DIM are shown in Table 4, and detailed descriptions on the design process are provided as follows.

Table 4.

The Summary of the Designed Attributes in Heart Sound Monitor Domain Information Model

OBJECT	ATTRIBUTE	THE VALUE OF ATTRIBUTE^a
HSM	System-Type-Spec-List	{MDC_DEV_SPEC_PROFILE_HSM(4125), 1}
HSM	Dev-Configuration-Id	32768
Ratio of Diastolic and Systolic Duration, Ratio of S1 and S2 Amplitude, Heart Rate	Type	MDC_HSM_RATIO_DIS_SYS_TIME (61440), MDC_HSM_RATIO_S1_S2_AMP (61441), MDC_HSM_HEART_RATE(61442)
	Unit-Code	MDC_DIM_DIMLESS(512), MDC_DIM_DIMLESS, MDC_DIM_BEAT_PER_MIN(2710)
	Metric-Structure-Small, Metric-Spec-Small, Basic-Nu-Observed-Value, Absolute-Time-Stamp	See the section [RATIO OF DIASTOLIC AND SYSTOLIC DURATION OBJECT].
PCG Waveform	Type	MDC_HSM_WAV_PCG(61443)
	Unit-Code	MDC_DIM_DIMLESS
	Supplemental-Types	See the section [RT-SA object]
D/S Low/High Threshold, S1/S2 Low/High Threshold, Heart Rate Low/High Threshold	Type	MDC_HSM_THRESHOLD_ DIS_SYS_TIME (61450), MDC_HSM_THRESHOLD_S1_S2_ AMP (61453), MDC_HSM_THRESHOLD_HR (61456)
	Unit-Code	MDC_DIM_DIMLESS, MDC_DIM_DIMLESS, MDC_ DIM_ BEAT_PER_MIN
	Metric-Id-List	{MDC_HSM_D_S_HIGH(61451) or MDC_HSM_D_S_LOW(61452)}, {MDC_HSM_S1_S2_HIGH(61454) or MDC_HSM_S1_S2_ LOW(63455)}, {MDC_HSM_ HR_HIGH (61457) or MDC_HSM_HR_LOW(61458)}
	Metric-Structure-Small, Metric-Spec-Small, Compound-Basic-Nu-Observed-Value, Absolute-Time-Stamp	See the section [D/S LOW/HIGH THRESHOLD OBJECT]
HSM Threshold Status, General Device Status	Type	MDC_HSM_THRESHOLD_ STAT(61459), MDC_HSM_ DEV_STAT(61460)
HSM Threshold Status, General Device Status	Metric-Spec-Small, Enum-Observed-Value- Basic-Bit-Str	See the section [Enumeration objects] and Table 6.

The value of attribute: the nomenclature codes in italic format are located in the MDC_PART_DIM partition, and the remaining nomenclature codes are newly designed in this article and located in the MDC_PART_PVT partition.

DIM, domain information model.

MDS object

The System-Type attribute uniquely identifies the main function of certain PHD, and we propose a new nomenclature code MDC_DEV_SPEC_PROFILE_HSM with code value 4125 for our targeting HSM. The nomenclature code of all the newly designed HSM-related objects are placed within the private partition—MDC_PART_PVT (1024), which is a code space dedicatedly reserved for private extension. This proposal has been submitted to the accountable standard development organization—ISO/IEEE 11073-PHD WG. Once accepted, a formal code assignment will be made from the MDC_PART_INFRA partition. The value of System-Type-Spec-List attribute is thus designed to be “{MDC_DEV_SPEC_PROFILE_HSM, 1},” which indicates the first version of HSM DIM.

The Dev-Configuration-Id attribute is used to uniquely identify the device configuration of the PHD, that is, the configuration of HSM DIM in our case. This Dev-Configuration-Id is static during the lifetime of an association between PHD and aggregation device. The latter may leverage this information to quickly establish the image of HSM DIM and to shorten the connection and reconnection time. As the 11073-20601 reserves the range (32786-65535) for private configuration, we use 32768 as the value of our HSMs Dev-Configuration-Id.

Numeric object

The 11073-20601 provides several options of timestamp with different resolutions and formats, which are used to indicate the timestamp of metric data of metric-derived objects. For the HSM-generated numerical data discussed here, the Absolute-Time-Stamp is selected to represent the date and time of each data sample. Such selection of timestamp attribute meets the requirements of time accuracy for numerical metric data with minimum consumption of bytes.

Having in mind the similarity of the data represented by numeric objects, the Ratio of Diastolic and Systolic Duration object and the D/S Low/High Threshold object are taken for examples, and describe the design process of the remaining attributes in detail as follows.

Ratio of diastolic and systolic duration object

The Type and Unit-Code attribute defines the type and unit of the metric data represented by the object, respectively. For the Type attribute of Ratio of Diastolic and Systolic Duration object, we propose a new nomenclature MDC_HSM_RATIO_DIS_SYS_TIME with code value 61440. This metric is a calculated ratio that is dimensionless, thus the value of its Unit-Code attribute is set to be MDC_DIM_DIMLESS (512).

The 11073-20601 has defined several attributes to describe the context information of metric data: the Metric-Spec-Small attribute represents data characteristics and transmission mechanism, and the Metric-Structure-Small attribute conveys the composition of metric data. The data structure of these attributes value are either bit string or integer, which contain multiple options that are prepared for different use cases. The semantic meaning of such value options that relate to HSM are shown in Table 5. Subsequently, these attribute are designed by setting appropriate bits or integers to reflect the specific context information of HSM metric data, and the design results are shown in Table 6.

Table 5.

The Semantic Meaning of the Value of Metric-Spec-Small and Metric-Structure-Small Attribute (Heart Sound Monitor-related only)

ATTRIBUTE	ATTRIBUTE TYPE	THE VALUE OF ATTRIBUTE
ATTRIBUTE	ATTRIBUTE TYPE	BIT/STRUCTURE	SEMANTIC MEANING
Metric-Spec-Small	BITS-16	mss-avail-stored-data(bit1)	The HSM is capable to store multiple historical values and send them later.
		mss-upd-aperiodic(bit2)	The new value of this metric is sent aperiodically.
		mss-acc-agentinitiated(bit9)	The transmission of the update of this object initiated by the HSM device.
		mss-cat-manual(bit12)	The value of this metric is acquired manually.
		mss-cat-calculation(bit14)	The value of this metric is a calculated value, rather than a direct measurement.
Metric-Structure-Small	INT-U8	{ms-struct-simple, 0}	Each update of this metric contains a single value.
Metric-Structure-Small	INT-U8	{ms-struct-compoundfix, 2}	Each update of this metric may contain two values (low and high threshold in HSM case) and size shall not be dynamic.

Table 6.

The Design of Metric-Spec-Small and Metric-Structure-Small Attribute of Each Object in Heart Sound Monitor Domain Information Model

ATTRIBUTE	OBJECT	DESIGN RESULTS
Metric-Spec-Small	Ratio of S1 and S2 Normalized Amplitude, Ratio of Diastolic and Systolic Duration, Heart Rate	mss-avail-stored-data(bit1) \| mss-acc-agent-initiated(bit9) \| mss-cat-calculation(bit11)
	S1/S2 Low/High Threshold, D/S Low/High Threshold, Heart Rate Low/High Threshold	mss-acc-agent-initiated(bit9) \| mss-cat-manual(bit12)
	HSM Threshold Status, Device Status	mss-avail-stored-data(bit1) \| mss-upd-aperiodic(bit2) \| mss-acc-agent-initiated(bit9)
Metric-Structure-Small	Ratio of S1 and S2 Normalized Amplitude, Ratio of Diastolic and Systolic Duration, Heart Rate	{ms-struct-simple, 0}
Metric-Structure-Small	S1/S2 Low/High Threshold, D/S Low/High Threshold, Heart Rate Low/High Threshold	{ms-struct-compoundfix, 2}

To represent a numeric metric value, the 11073-20601 standard offers two attributes: Simple-Nu-Observed-Value and Basic-Nu-Observed-Value, which respectively correspond to the data types FLOAT-Type (32-bit with 24-bit mantissa and 8-bit exponent) and SFLOAT-Type (16-bit with 12-bit mantissa and 4-bit exponent). The trade-off of the decision on which attribute is instantiated is among overhead efficiency, minimum data resolution, and required value range. As an example, the metric value of Ratio of Diastolic and Systolic Duration object normally contain one digit for its integer part and two digits for its decimal part,³ thus the SFLOAT-Type is favorable and the Basic-Nu-Observed-Value attribute is instantiated in this object.

D/S low/high threshold object

The Metric-Id-List attribute is used to further subdivide the Type of the object. For threshold data represented by the D/S Low/High Threshold object, it can be subdivided into high and low threshold of D/S, so we propose two nomenclatures for this sub-types, that is MDC_HSM_D_S_HIGH and MDC_HSM_D_S_LOW with code value 61451 and 61452 respectively.

The value of D/S Low/High Threshold object is manually set by user, and it is compound data structure containing both low and high threshold values, thus the corresponding value is set in Metric-Spec-Small and Metric-Structure-Small (Table 6). The 11073-20601 offers two attributes to represent compound numeric value: Compound-Simple-Nu-Observed-Value and Compound-Basic-Nu-Observed-Value, which represent an array of numeric data. Similarly, the Compound-Basic-Nu-Observed-Value attribute is instantiated in this object.

RT-SA object

The Supplemental-Types attribute is used to provide supplemental information of the metric data. Within HSM DIM, this attribute is used to indicate the sensor locations that uniquely identify the auscultation areas of PCG Waveform object. It can be known that the auscultation areas principally include Aorta, Pulmonary, Tricuspid, and Mitral areas,²⁴ as shown in Figure 4. Therefore, a set of nomenclature codes are proposed to indicate these areas, as shown in Table 7.

Fig. 4.

Auscultation areas of heart valves.

Table 7.

The Design of Supplemental-Types Attribute

THE VALUES OF SUPPLEMENTAL-TYPES	SEMANTIC MEANING
MDC_HSM_SAMPLELOCATION_AUSCULT_AORTIC(61444)	Auscultation area of aortic valve
MDC_HSM_SAMPLELOCATION_AUSCULT_ TRICUSPID(61445)	Auscultation area of tricuspid valve
MDC_HSM_SAMPLELOCATION_AUSCULT_MITRAL(61446)	Auscultation area of mitral valve
MDC_HSM_SAMPLELOCATION_AUSCULT_PULMONARY_ ARTERY(61447)	Auscultation area of pulmonary valve
MDC_HSM_SAMPLELOCATION_OTHER(61448)	Other auscultation area
MDC_HSM_SAMPLELOCATION_UNDETERMINED(61449)	Undefined auscultation area

For RT-SA objects, 11073-20601 defines several attributes that provide an optimized and unambiguous way for transmitting the various types of waveform data. For example, the Sample-Period attribute represents the sampling interval with time precision of 1/8 ms, the Scale-and-Range-Specification attribute defines the conversion algorithm that allows actual metric data with offset range and limited resolution to be converted to an integer value that can reduce the amount of transmitted data, and the Sa-Specification attribute further describes the characteristics of waveform data, such as whether performed smoothing processing or whether the curve is delayed. Thus, these attributes are sufficient for transmitting PCG with different formats and sampling frequencies as defined by different vendors, and the aggregation devices can decode the PCG data unambiguously and efficiently by these attributes.

Enumeration objects

The 11073-PHD standards provide the data types OID (nomenclature) and Bit-Str (bit string), which is respectively used to represent the exclusive event and concurrent events of enumeration metric data.

The General Device Status object is used to notify the aggregation device of some key events of device status, such as fault status (sensor, software, battery) or demand status (require user's intervention), and the HSM Threshold Status object notify of the over-limit status of metric value. Considering that multiple device events or multiple over-limit events may occur concurrently, the Enum-Observed-Value-Basic-Bit-Str attribute is instantiated in these objects and the semantic meaning of each single bit is defined, as shown in Table 8.

Table 8.

The Design of Enum-Observed-Value-Basic-Bit-Str Attribute of General Device Status and Heart Sound Monitor Threshold Status Object in Heart Sound Monitor Domain Information Model

OBJECT	ATTRIBUTE	ATTRIBUTE TYPE	THE VALUE OF ATTRIBUTE
OBJECT	ATTRIBUTE	ATTRIBUTE TYPE	BIT	SEMANTIC MEANING
General Device Status	Enum-Observed-Value-Basic-Bit-Str	BITS-16	device-status-undetermined (bit0)	An undetermined condition occurred.
			device-status-error-mechanic (bit1)	A mechanical fault occurred.
			device-status-error-software (bit2)	A software error occurred.
			device-status-error-battery (bit3)	A battery fault occurred.
			device-status-service-time-sync- required (bit4)	A time synchronization is required.
			device-status-service-calibration- required (bit5)	A calibration is required.
			device-status-loss-of-sensor- connection (bit6)	Loss of sensor connection
			device-status-loss-of-sensor-signal (bit7)	Loss of sensor signal
HSM Threshold Status	Enum-Observed-Value-Basic-Bit-Str	BITS-16	D-S-threshold-high (bit0)	D/S higher than threshold limit.
			D-S-threshold-low (bit1)	D/S lower than threshold limit.
			s1-s2-threshold-high (bit2)	S1/S2 higher than threshold limit.
			s1-s2-threshold-low (bit3)	S1/S2 lower than threshold limit.
			heart-rate-threshold-high (bit4)	Heat rate higher than threshold limit.
			heart-rate-threshold-low (bit5)	Heat rate lower than threshold limit.

Message Transmission Mechanism

The HSM and the aggregation device interact with each other in the form of Application Protocol Data Units (APDUs), which is in binary format, and is generated by encoding the abstract data type through the MDER. Based on the service model and communication model defined in 11073-20601, the dynamic interaction between HSM and aggregation device can be achieved, which realizes the access to HSM DIM and the semantic interoperation.

When HSM and the aggregation device are connected for the first time, the configuration of HSM is unknown to the aggregation device. Thus, the HSM has to send its configuration information of all objects that it supports and all static attributes to the aggregation device. Once connected, the configuration of this HSM is stored by this aggregation device and reused in reconnected process, which helps to simplify the reconnection process and to reduce the message overhead.

Since HSM and aggregation device follow a consistent information model and are based on common configuration information, the aggregation device can decode the semantic information of the binary data through the MDER. The static attributes of HSM DIM, such as Unit-Code and Metric-Id-List, are stored by aggregation device during the configuration process; thus there is no need to repeatedly send them along with the reported metric data; furthermore, each time when reporting new metric value, HSM only needs to update the metric data in the APDU, while keep the rest of the APDU unchanged. This helps to reduce the message overhead and optimize formatting and parsing performance.

The Implementation Of Hsm Interoperability Framework

To validate the above design, a HSM device is simulated based on software only. This simulated HSM device is capable to transmit the PCG and some derived metric data, such as D/S, S1/S2, and HR to aggregation device. The Continua Enabling Software Library (CESL)²⁵ acts as the aggregation device, which follows the ISO/IEEE 11073-PHD standards. The prestored PCG waveform with two cardiac cycles is repeated to simulate the PCG metric data, and the data are exchanged leveraging the above designed HSM interoperability framework after the Transmission Control Protocol (TCP) connection being established. The simulation result is shown in Figure 5, where the upper part is the transmitted metric data displayed on the HSM simulation device and the lower part is the received metric data displayed on the aggregation device.

Fig. 5.

The metric data that are transmitted from HSM to aggregation device.

As it can be seen from the interaction between the simulated HSM device and the aggregation device, the standardized aggregation device can access metric data within HSM DIM and can correctly understand the semantic information of the data in transmission, which indicates the semantic interoperability between HSM and aggregation device is achieved.

Discussion

Summary Of This Research Work

Due to the lack of semantic interoperability between the HSM and aggregation devices, the heart sound data generated by HSM cannot be widely shared and aggregated in different kind of telehealth systems. To address this issue, an interoperability framework is constructed by modeling the static data structures and dynamic interactive behaviors of HSM based on the general models offers by ISO/IEEE 11073-20601 standard. The HSM device-output information is organized and represented as a DIM, which acts as a standardized and structured access interface, so that the aggregation device can leverage the service model and communication model defined in 11073-20601 to access the HSM in a plug-and-play manner. The HSM DIM is a general object-oriented model that is independent of the implementation tools. A software-only simulation of HSM is implemented using C++, and it is used to validate the designed interoperability framework against standardized test tool.

Lessons Learned

Constructing the information model

It is important to correctly understand the relationship between different kinds of device-output information, especially the dependency between the key metric data and its associated supplemental information. When designing the DIM, consider to model the key metric data as an object and to model the supplemental information as an attribute. For example, the device status information of HSM is a key metric that is applicable to all kinds of HSM device and can be associated with other metric-derived objects to convey the context information of metric data, thus is modeled as an object. In contrast, the sensor location data of PCG is secondary context information of the key metric—PCG waveform, thus is modeled as an attribute of the PCG object.

Designing the nomenclatures

The nomenclature helps to ensure the semantic consistency among different manufactures and different interfaces. For such purpose, the authors obey the following rules when defining nomenclatures. First, always try to reuse the existing 11073-PHD nomenclatures whenever possible. One semantic meaning shall only be associated to one nomenclature. Second, when dealing with the new semantic meaning that does not have a nomenclature yet the inference process defined in ISO/IEEE 11073-10101 standard should be followed to define a new nomenclature representing the unique semantic of the target. The new code should also be assigned, from the proper partition and code space. Since this research work is not a formal standard development activity the authors only used the code space that is dedicatedly reserved for private extension. But this does not affect the result of this research, and it can serve as a reference for future formal standard development.

Designing the abstract data types

For some attributes with similar functionality, the 11073-20601 standard offers multiple options with different data type or data structure. When converting device-output information into attributes of DIM, it is important to select suitable abstract data type that fits the need. The trade-off is between optimizing the overhead of protocol message and providing sufficient coverage for the value range of metric data. Both of them are important for PHDs.

Medical device cybersecurity

Information security and risk management of medical devices are important aspects that need to be considered when dealing with device interoperability. The 11073-PHD, as an application layer protocol, takes into account the security mechanisms of the interoperability framework in two aspects: (1) 11073-20601 presumes that the lower layer transport provides a reliable and secure transmission mechanism, which protects the unidirectional data uploading from malicious attacks or leaks. (2) From the perspective of risk management, the ISO/IEEE 11073-00103 standard refers to two international standards of EN/ISO 14971: 2007 and ISO/IEC 27002: 2005 in describing the potential risk factors (human factors, operational errors, etc.) when implementing 11073-PHD standards, in addition to confidentiality, integrity, availability, and nonrepudiation of the information that should be guaranteed in the context of medical device cybersecurity.

Limitations

However, there are still some limitations in this research. The device-output information used to construct the HSM interoperability framework does not cover all the possible metrics that could be derived from the heart sound data generated by the HSM. Only those metrics that have been intensively studied and are suitable for telehealth services are selected through literature review. The result of this research has been submitted to ISO/IEEE 11073-PHD Workgroup to facilitate the corresponding standard development activity there. Later, the Workgroup might come up with modification or extension on the proposed HSM DIM based on manufacture consensus.

In addition, the implementation and verification of the HSM interoperability framework is currently done only through software simulation. An implementation over physical device might better illustrate the interaction and may help to expose any potential gaps of the design.

Conclusions

The lack of semantic interoperability between the HSM and aggregation devices makes it difficult to integrate HSM with different kind of telehealth systems. To address this issue, this article presents a design of application-level interoperability framework to enable plug-and-play between HSM and aggregation devices. This framework is compliant with the ISO/IEEE 11073 standard family and thus has the potential to be integrated into the 11073-PHD stack.

Footnotes

Acknowledgments

The authors would like to thank the Personal Connected Health Alliance for providing the CESL tool.

Disclosure Statement

No competing financial interests exist.

References

Amiri

, Abtahi

, Constant

, Mankodiya

. Mobile phonocardiogram diagnosis in newborns using support vector machine. Healthcare, 2017; 5:e16.

Guo

, Ding

, Lei

, Xie

, Zhong

, Xiao

. Non-invasive monitoring and evaluating cardiac function of pregnant women based on a relative value method. Acta Physiol Hung, 2012; 99:382–391.

Yang

, Zeng

. A relative value method for measuring and evaluating neonatal cardiac reserve. Indian J Pediatr, 2010; 77:661–664.

Hsieh

, Unver

, Mcnulty

, Schiller

. The amplitude ratio of the first to second heart sound is reduced in left ventricular systolic dysfunction. Int J Cardiol, 2010; 145:133–135.

Eslamizadeh

, Barati

. Heart murmur detection based on wavelet transformation and a synergy between artificial neural network and modified neighbor annealing methods. Artif Intell Med, 2017; 78:23–40.

Xie

, Xiao

, Liu

, Yi

, You

, Guo

, Shao

, Huo

, Du

, Xu

, Wu

, Xiao

, Yang

, Guo

. Multi-center, multi-topic heart sound databases and their applications. J Med Syst, 2012; 36:33–40.

Fei

, Zhao

, Boanca

, Hughes

, Bai

, Merrell

, Rafiq

. A biomedical sensor system for real-time monitoring of astronauts' physiological parameters during extra-vehicular activities. Comput Biol Med, 2010; 40:635–642.

Johnson

, Hermann

, Witter

, Cornu

, Brennan

, Dufaux

. An ultra-low power subband-based electronic stethoscope. Conference Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing. New York: IEEE,, 2006; 1156–1159.

Luo

. Portable bluetooth visual electrical stethoscope research. Conference Proceedings of the 11th IEEE International Conference on Communication Technology. New York: IEEE,, 2008; 634–636.

10.

Khan

, Jawed

, Khan

, Mazhar

. An innovative approach towards E-health in development of tele auscultation system for heart using GSM mobile communication technology. Conference Proceedings of the 19th IEEE International Symposium for Design and Technology in Electronic Packaging. New York: IEEE,, 2014; 201–204.

11.

Jusak

, Pratikno

, Putra

. Internet of Medical Things for cardiac monitoring: Paving the way to 5G mobile networks. Conference Proceedings of the IEEE International Conference on Communication, Networks and Satellite. Surabaya, Indonesia, 2017; 75–79.

12.

Bashshur

, Shannon

, Smith

, et al. The empirical foundations of telemedicine interventions for chronic disease management. Telemed J E Health, 2014; 20:769–800.

13.

Giordano

, Scalvini

, Zanelli

, et al. Multicenter randomised trial on home-based telemanagement to prevent hospital readmission of patients with chronic heart failure. Int J Cardiol, 2008; 131:192–199.

14.

Shi

, Mays

, Chiao

. Wireless stethoscope for recording heart and lung sound. Biomed Wireless Technol Netw Sens Syst, 2016; 1–4.

15.

Lakhe

, Sodhi

, Warrier

, Sinha

. Development of digital stethoscope for telemedicine. J Med Eng Technol, 2016; 40:20–24.

16.

Huang

, Liu

, Pi

, Ao

, Wang

. Computer-aided diagnosis and new electronic stethoscope. Zhongguo Yi Liao Qi Xie Za Zhi, 2017; 41:161–165.

17.

Carroll

, Cnossen

, Schnell

, Simons

. Continua: An interoperable personal healthcare ecosystem. IEEE Pervasive Comput, 2007; 6:90–94.

18.

Barrón-González

, Martínez-Espronceda

, Trigo

, Led

, Serrano

. Overview of the ISO/IEEE 11073 family of standards and their applications to health monitoring. In: Chen

, Oetomo

, Feijs

, eds. Neonatal Monitoring Technologies: Design for Integrated Solutions. Hershey, PA: IGI Global, 2012:26.

19.

Rubio

ÓJ

, Trigo

, Alesanco

, Serrano

, García

. Analysis of ISO/IEEE 11073 built-in security and its potential IHE-based extensibility. J Biomed Inform, 2016; 60:270–285.

20.

Barrón-González

, Martínez-Espronceda

, Trigo

, Led

, Serrano

. Lessons learned from the implementation of remote control for the interoperability standard ISO/IEEE 11073-20601 in a standard weighing scale. Comput Methods Programs Biomed, 2016; 123:81–93.

21.

Clarke

, De

, Verma

, Gokalp

. Interoperable End-to-End Remote Patient Monitoring Platform based on IEEE 11073 PHD and ZigBee Health Care Profile. IEEE Trans Biomed Eng, 2018; 65:1014–1025.

22.

Xiao

, Wang

, Hu

. Studying cardiac contractility change trend to evaluate cardiac reserve. IEEE Eng Med Biol Mag, 2002; 21:74–76.

23.

Xiao

, Guo

, Sun

, Xiao

. A relative value method for measuring and evaluating cardiac reserve. Biomed Eng Online, 2002; 1:6.

24.

Kocharian

, Sepehri

, Janani

, Malakan-Rad

. Efficiency, sensitivity and specificity of Automated Auscultation Diagnosis Device for detection and discrimination of cardiac murmurs in children. Iran J Pediatr, 2013; 23:445–450.

25.

Benner

, Schöpe

. Using Continua Health Alliance Standards - Implementation and Experiences of IEEE 11073. Conference Proceedings of the 12th IEEE International Conference on Mobile Data Management. New York: IEEE,, 2011; 40–45.