A Proposal to Incorporate Digital Auscultation and Its Processing into an

Existing Electronic Health Record

P. Gomes

, S. Frade

2,4

A. Castro

, R. Cruz-Correia

2,4

and M. Coimbra

Instituto de Telecomunicac¸

oes, Faculdade de Ci

encias, Universidade do Porto, Porto, Portugal

Faculdade de Medicina, Universidade do Porto, Porto, Portugal

Faculdade de Engenharia, Universidade do Porto, Porto, Portugal

CINTESIS - Center for Research in Health Technologies and Information Systems, Porto, Portugal

Keywords:

Auscultation, Digital Stethoscope, HL7, OpenEHR, e-Health.

Abstract:

This paper aims to describe and discuss a proposal to incorporate digital auscultation and its processing into

an existing EHR. The architecture was planned to be used in both primary and hospital care, and includes a

digital stethoscope; an exam collection module; an integration module; an EHR web service; and an EHR.

Special attention was given to standardize communications using HL7 and openEHR. The proposed imple-

mentation uses a commercial stethoscope, an android app to collect the data, a mirth integration engine that

communicates using HL7 or openEHR through REST or SOAP calls. The signal processing of the sounds

is also included. The auscultation sound ﬁles are made available to the EHR users. This solution will open

the possibility to have richer patient records than can be very important for patient care, research and medical

teaching. It also raises issues regarding ethical and legal concerns that must be considered in future research.

1 INTRODUCTION

The ageing population has increased steadily over the

past few years. According to the World Health Or-

ganization, in almost all countries, the proportion of

people aged over 60 years, is growing rapidly as a re-

sult of increased life expectancy and reduced fertility

rates (WHO, 2014; WHO, 2011). This raises the con-

cern to focused not only on the treatment of disease

and monitoring, but also in its prevention and active

ageing (Rechel et al., 2013; SCPSDC, 2013).

Health problems in the elderly are usually linked

to accidents, development of non-communicable dis-

eases, poverty, social isolation and exclusion, abuse,

and mental health disorders. It is also recognized that

the limitations characteristic of this population, may

often prevent their access to health care, which makes

it imperative to identify these patients for closer mon-

itoring. Remote monitoring of this population earns

great interest not only in preventing the disease, but

also in promoting an active lifestyle, and the detec-

tion of possible complications (WHO, 2012; Euro-

peanCommission, 2013). An integrated health sys-

tem brings many beneﬁts from the point of view of

patients and health professionals. From the side of

the patient, these systems allow a myriad of oppor-

tunities, from monitoring of chronically ill patients,

health promotion and self-care, improving their over-

all condition. From the perspective of health profes-

sionals, this new paradigm allows a direct costs de-

crease by reducing the number of hospitalizations, the

risks associated with nosocomial infections, and over-

crowding. These technologies allow the extension of

health care to patients away from urban centers, en-

suring greater equity in health care, and providing fur-

ther support to the health professional through med-

ical decision support systems and alarms (Ferreira

et al., 2013; Pereira et al., 2013).

The ICT for Future Health project, led by the

University of Porto, aims to address this emerging

reality by incorporating three health data gathering

modalities into a uniﬁed Electronic Health Record

(EHR), deployed in the zone of inﬂuence of a pri-

mary care center in the northern region of Portugal

(USF Nova Via) that covers a population of around

7000 isolated elderly inhabitants. These three modal-

ities are: continuous self assessment of patients using

wearable sensing, self assessment of patients within a

health kiosk environment, and assessment of patients

by clinicians either at home or in a primary care envi-

ronment. In this paper we will address the integration

of the later into the uniﬁed EHR of the ICT for Future

143

Gomes P., Frade S., Castro A., Cruz-Correia R. and Coimbra M..

A Proposal to Incorporate Digital Auscultation and Its Processing into an Existing Electronic Health Record.

DOI: 10.5220/0005222901430150

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2015), pages 143-150

ISBN: 978-989-758-068-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

Health project.

1.1 Heart Auscultation

Auscultation is a standard medical exam for heart

pathology screening, and although it is the gold stan-

dard for heart condition monitoring, it is a difﬁcult

skill to master (Carapetis et al., 2008). Besides, there

is not still a way of storing this important data for

patient follow-up; the current practice does not take

this into consideration, losing important information

in case of disease detection/evolution. There is not

yet a standard for heart sound collection and trans-

mission that may allow different professionals to eval-

uate the same signal (general practitioner and cardi-

ologist e.g.). The DigiScope data collection system

presented in Figure 1 was designed to ﬁll this gap,

collecting an auscultation using an electronic stetho-

scope, along with patient clinical data and annotations

(Pereira et al., 2013).

Figure 1: DigiScope collector (DSCollector), used for elec-

tronic auscultation, with an electronic stethoscope and a

tablet.

1.2 Electronic Health Records & HL7

OpenEHR (openEHR, 2013) is a non-proprietary

standard architecture for electronic health records.

OpenEHR lets you capture and store clinical knowl-

edge in a structured manner, independent of software,

providing interoperability of health information sys-

tems, avoiding trapping data in proprietary systems

and increasing support for distributed clinical work

ﬂows. OpenEHR allows the standardization of the

Electronic Health Record (EHR) architecture follow-

ing a multi-level modelling approach, which sepa-

rates information from knowledge (Beale and Heard,

2008). The ﬁrst level (the reference model - RM)

speciﬁes a generic model according to which data will

be stored and communicated. The second level (the

archetype model) deﬁnes constraints in the reference

model that represent concepts in a speciﬁc domain.

Trough the use of archetypes (structured concepts of

clinical knowledge) and templates (combination of

archetypes related to a particular clinical task), the

semantic meaning and functionality is kept indepen-

dent of the systems collecting or holding the data (e.g.

clinical records, mobile systems). The archetypes

can be developed in any language and later be trans-

lated to other languages (e.g., Portuguese, English,

Chinese, Swedish) keeping their original meaning.

In addition, terminologies can be associated within

archetypes elements supporting their deﬁnition.

Health Level 7 (HL7) is a well established

message-based standard developed by the American

National Standards Institute (ANSI) accredited stan-

dards developing organization Health Level 7 Inc. It

aims to develop coherent and extensible standards for

the exchange, management and integration of elec-

tronic information in the clinical and administrative

domain (Health Level Seven International, 2007).

HL7 refers to the Application Level of the OSI seven

layers model. This level describes how data are ex-

changed and the timing of the interchange as well

as the handling of communication errors. According

to Health Level Seven, HL7 version 2.5 is the most

widely implemented standard for health care informa-

tion worldwide.

HL7 contains many optional data segments which

makes it very ﬂexible but at the same time impossible

to guarantee standard conformance of any vendors’

implementation. This has the regrettable consequence

that vendors might need more time to analyse and

plan their interface to assure that the same optional

features are used by both parties (Health Level Seven

International, 2007). The vagueness in the standard,

the lack of a consistent application data model, a for-

mal methodology to model data artefacts and the lack

of well deﬁned application user roles were issues ad-

dressed in HL7 version 3.0. It uses an object-oriented

development methodology based on a data model, the

Reference Information Model (RIM), to create mes-

sages. RIM provides an explicit representation of

semantic and lexical connection that exists between

the information transferred in HL7 version 3.0 mes-

sages (Health Level Seven International, 2007).

1.3 Aim

Since auscultation is the ﬁrst line of screening of car-

diovascular pathologies, but it is still not part of the

electronic health record, this paper aims to describe

and discuss a proposal to incorporate digital auscul-

tation and its processing into an existing electronic

health record.

HEALTHINF2015-InternationalConferenceonHealthInformatics

144

2 STORYBOARD

The new paradigms of societal change imposed to

healthcare have taken monitoring and data storage to a

new level of systems interoperability. To better illus-

trate this new scenario, we will describe a storyboard

to facilitate understanding of our service application.

2.1 At Primary Care Unit

Mrs. Amelia is a 72 years old woman, living alone in

a rural house far from the city centre. Mrs. Amelia

is autonomous, although she presents a few chronic

health conditions: type II diabetes, hypertension and

dyslipidemia. Mrs. Amelia has regular appointments

with her general practitioner (GP) in her primary care

unit, to analyze and manage her health condition, and

when necessary, adjust the medication. Her consul-

tation includes several physical observations, as stan-

dard clinical practice routine, including a heart aus-

cultation. Her GP auscultates her with an electronic

stethoscope, connected to a tablet (DSCollector), that

links this information to her electronic health record

(EHR), storing each auscultation as an observation of

the consultation, identiﬁed with her national health

identiﬁcation number.

The heart sound, or phonocardiogram (PCG)

record, is stored with her clinical data and with the de-

scription of the ﬁndings of the auscultation redeemed

by the GP. When the collected PCG is sent to the EHR

in the server, it passes through a signal processing unit

that automatically extracts several features from the

auscultation useful for clinical evaluation (heart rate,

S12 and S21 time intervals, presence of murmurs and

its shape and intensity, extra heart sounds, or hyper-

phonesis e.g.). This information is then fed to a ma-

chine learning algorithm that incorporates PCG fea-

tures with the patient clinical data, providing an ad-

visory system for the GP in case of warning signs,

that may lead to further evaluation from a Cardiology

specialist. This way, there is a register of the evolu-

tion of the heart sound and a possible alarm in case of

missed events by the GP. In her last appointment Mrs.

Amelia condition was stable, and she returned to her

home until the next appointment.

2.2 At Home to a Central Hospital

Last week, Mrs. Amelia had a small accident and

fractured her left foot, leaving her with limited mo-

bility. Since Mrs. Amelia lives in a small village, far

from the city centre, she was unable to continue her

regular appointments, and the health care was deliv-

ered to her directly at home by a nurse. Every time

the nurse leaves the primary care unit, the tablet con-

nects to the central server, and receives the data from

the scheduled patients for home visit that day. Ev-

ery patient scheduled for visit has his/her information

on the tablet, and after observation, the collected data

will be synchronized with the server to update in case

of change, and save the auscultation as an observa-

tion on the EHR. If for some reason, the health care

professional needs to visit a patient that is not consid-

ered in the schedule of that day, he/she may add a new

patient, using the national health identiﬁcation num-

ber; after collection, and when synchronizing with the

central server, this may be introduced as a new pa-

tient, with the correspondent exam, or as an observa-

tion for an existing patient in the database, identiﬁed

through the national health identiﬁcation number.

Since Mrs. Amelia has a combination of chronic

conditions, on each visit the health professional col-

lects several physiological variables in a tablet, in-

cluding her auscultation according to the clinical stan-

dards. The visiting nurse was trained to perform an

auscultation, directly sent to Mrs. Amelias EHR at the

central server, and later analyzed by her GP. The PCG

collected during the last visit was processed at the

server, detecting a systolic murmur in her PCG. This

event generated an alarm to her GP, that listened to

her auscultation, conﬁrming the clinical ﬁnding. Mrs.

Amelia GP shared the auscultation with the Cardiolo-

gist from the regional hospital, for a second opinion,

who considered that Mrs. Amelia was indicated for

further evaluation. Mrs. Amelia was immediately re-

ferred to a Cardiology consultation, where she contin-

ued to be accompanied.

Data collected in both scenarios includes the per-

sonal information (age, weight, height and gender),

clinical data resulting from the examination (systolic

and diastolic blood pressure, oximetry, and a text ﬁeld

for comments), and the auscultation ﬁle (audio ﬁles,

one for each auscultation spot).

3 ARCHITECTURE

The proposed architecture (ﬁgure 2) is composed by 5

modules that are independent of each other. We have

the digital stethoscope; the collection module; the in-

tegration module; the EHR web service; and ﬁnally

the EHR.

In the digital stethoscope we use is the Littmann

3200 stethoscope without any modiﬁcation, this

choice was made taking in consideration the accep-

tance from the medical staff and usability purposes.

The collection module is assured with the DSCol-

lector application. An android application that will

AProposaltoIncorporateDigitalAuscultationandItsProcessingintoanExistingElectronicHealthRecord

145

Figure 2: Architecture proposed with all the modules and information ﬂows. The Littmann stethoscope sends the auscultation

to the Digiscope Collector (collection module) via bluetooth. Then, this module communicates using HL7 messages with the

Mirth Connect (integration module). Which in turn parses the messages, transforming them in the structure expected by the

EHR web service. This ﬂow allows that a patient record can be sent from the mobile application to the EHR repository.

assure the communication with the stethoscope (via

bluetooth) and the storage of all the data collected

during the appointment between the healthcare pro-

fessional and the patient. This data is then compiled

in standard HL7 messages that can be sent to the EHR

modules (via HTTPS).

The integration module is our Mirth Connect that

can receive any standard HL7 message, process it and

translate it to the structure known by the EHR web

service module. This module is also capable of do-

ing the reverse communication ﬂow, in our scenario

the collection module can also request information

about patients which requires being capable to receive

HL7 queries and sent responses in accordance with

the standard. The EHR web service module allows

an external application or service to send EHR with

a structure known to the EHR. This module can be

seen as the door to the VCIntegrator module and that

is why we need the integration module to transform

the HL7 structure to this one operated in the VCIn-

tegrator, this communication can be done with SOAP

or REST.

Finally we have the EHR itself, which has its own

structure based in OpenEHR and all the functional-

ities that are required in a systems like this. In this

architecture, our EHR is handled by the VCIntegra-

tor that is feed with patient records by our EHR web

service, this communication can be done by SOAP or

REST as well.

An important aspect to understand in the architec-

ture is the main information ﬂows between the mod-

ules. We have two information ﬂows that we need to

address: the retrieve of the patient list that the health-

care professional needs to visit; and the upload of the

patients records to the EHR repository. As seen in the

ﬁgure 2, the request of a patient list is made by an

HL7 request from the DSCollector to the Mirth Con-

nect, this one will parse the message and will do the

same request to the EHR web service, that will re-

trieve the list from the VCIntegrator and send it back

using the same route.

The other information ﬂow is simpler, because

there is no need to answer. The DSCollector will up-

load the patients records to the Mirth Connect, using

HL7 messages, and this module will parse them and

send them to the EHR web service in the expected

structure.

4 IMPLEMENTATION

In this section we will address the HL7 messages that

are required to communicate between the collection

and integration modules and we will also explain how

each module was implemented.

4.1 HL7 Communication Between

Modules

The communication between the DSCollector and the

VCIntegrator will be made by HL7 standard mes-

sages, and using the already approved IHE models.

The IHE has already deﬁned and validated two frame-

works from where we can adapt. The Patient De-

mographics Query (PDQ) and the Patient Identiﬁer

Cross-Referencing (PIX), are two frameworks that

handle patients list exchange between any systems

(IHE, 2013). In ﬁgure 3) it is possible to see all the

message handling between the collection and the in-

tegration modules.

Each interaction between the two modules re-

quires an authentication of the user, and all the mes-

sages are exchanged under the security of this authen-

tication. The ﬁrst step of the protocol is to send a

HEALTHINF2015-InternationalConferenceonHealthInformatics

146

Figure 3: Communication protocol to exchange HL7 mes-

sages between the DSCollector and the VCIntegrator.

QBPˆQ22 to request all the demographics of the pa-

tients that the physician needs to see that day. In that

message it is important to notice the speciﬁc method

to request this list. Usually this message is used

to request a list of patients based on a demographic

ﬁeld, but in this case, we send the identiﬁcation of the

physician that is requesting his schedule. This way

we respect the standard, and the receiving application

knows what to do (see ﬁeld QPD.3.1 in the Message

1) and which physician list should he send (identiﬁ-

cation on the ﬁeld QPD.3.2 in the Message 1).

Message 1: An example of a QBPˆQ22 message. This

message is requesting the list of patients that the physician,

identiﬁed in the ﬁled QPD.3.2, needs to see during is work

day.

|201408310830||QBPˆQ22|201408310830_5498465678|P|2.5

QPD|Q22ˆGetScheduleˆHL7|201408310830_7489764|@PV1

.7.1ˆ516886416

RCP|I|10ˆRD

With this message the VC Integrator should return

a RSPˆK22, which is the standard response to the pre-

vious message. This message is fully compliant with

the standard and should only return the demographics

of the patients to visit in that day by the requesting

physician (see Message 2). After this procedure the

physician has all the information needed to go to the

patients houses and proceed with the appointments.

Message 2: An example of a RSPˆK22 message with the

demographics of the patients.

|201408310832||RSPˆK22|201408310832_6546871463|P|2.5

MSA|AA|201408310830_5498465678

QAK|201408310830_7489764|OK||2|2|0

QPD|Q22ˆGetScheduleˆHL7|201408310830_7489764|@PV1

.7.1ˆ516886416

PID|1||16546846||GomesˆPedro||19900101|M|||Rua do Campo

Alegreˆ1021/1055ˆPortoˆPortoˆ4169-007ˆPortugal

||+351123456789

PID|3||55587236||FradeˆSamuel||19900101|M|||Rua Dr. Plcido

da Costaˆs/nˆPortoˆPortoˆ4200-450ˆPortugal||+351123456789

In the end of the day, he needs to upload all the

data collected from the appointments to the VC In-

tegrator. In this procedure, the physician needs to

authenticate himself in the VC Integrator and send

all the patients observed as new admissions. If the

patient demographics were retrieved earlier and no

changes were made in the demographics, the DSCol-

lector needs to send a simple admission (ADTˆA01

message in Message 3) with the clinical data gath-

ered during the appointment. However, if any of the

demographics has changed, the admission should im-

ply that a change has been made (ADTˆA08 message,

similar to Message 3). And the last scenario hap-

pens when, for any reason, the physician has an ap-

pointment with an unscheduled patient that was not

retrieved earlier. In this case, we need to inform the

receiving application that the patient that we are send-

ing, does not have an identiﬁcation known in the re-

ceiving database (ADTˆA04 message, similar to Mes-

sage 3) and should be added as a new patient if not

founded, or added as a normal admission if founded.

Message 3: An example of an ADTˆA01 message. This

message is used to inform of an admission. The messages

ADTˆA04 and ADTˆA08, also used in our protocol, are

very similar to this one, they use the same tags and ﬁelds

and only in the MSH header is possible to understand which

kind of message is being sent.

|201408311800||ADTˆA01|201408311800_515674657|P|2.5

EVN|A01|201408311048

PID|16546846||16546846||GomesˆPedro||19900101|M|||Rua do

Campo Alegreˆ1021/1055ˆPortoˆPortoˆ4169-007ˆPortugal

||+351123456789

PV1||I|||||ID

ˆ516886416|||||||||||||||||||||||||||||||||||||201408311048

OBX|1|ST|8302-2ˆBody heightˆLN||180|CM

OBX|2|ST|29463-7ˆBody weightˆLN||80|KG

OBX|3|ST|8480-6ˆSystolic blood pressureˆLN||120|MMHG

OBX|4|ST|8462-4ˆDiastolic blood pressureˆLN||80|MMHG

OBX|5|ST|20564-1ˆOxygen saturationˆLN||98|%

AProposaltoIncorporateDigitalAuscultationandItsProcessingintoanExistingElectronicHealthRecord

147

OBX|6|ST|DS-OPENFIELDˆOBSˆDS||medicalObservation|txt

OBX|7|ST|DS-PCGAVˆPCG_AORTICˆDS||file encoded in Base64|wav

OBX|8|ST|DS-PCGPVˆPCG_PULMONARYˆDS||file encoded in Base64|

wav

OBX|9|ST|DS-PCGTVˆPCG_TRICUSPIDˆDS||file encoded in Base64|

wav

OBX|10|ST|DS-PCGMVˆPCG_MITRALˆDS||file encoded in Base64|

wav

In this messages, the most important segment for

our proposal is the OBX segment, because this is the

segment that carries the clinical information collected

during the appointment. In the Message 3, as exam-

ple, we can see that the DSCollector sends ten obser-

vations collected during the appointment. Some of

the ﬁelds are already common in this kind of proce-

dure, such as height, weight or oxygen saturation and

are sent using the LOINC coding system. We also

have an open ﬁeld where the physician can add infor-

mation not accounted for, but the most relevant ﬁelds

are the last four. In this OBX segments we are send-

ing the phonocardiogram of the patient divided in the

four major focal points, the aortic, pulmonary, tricus-

pid and mitral valve. This sounds are collected using

the DSCollector (see section 4.3) and then encoded in

Base64 to be sent inside this message, as commonly

used in the email attachments.

4.2 Mirth/VCIntegrator

VCIntegrator (VirtualCare, 2014) is an online elec-

tronic health record which implemented the openEHR

standard, on which the health record forms are auto-

matically generated based on openEHR templates and

the data saved, following the openEHR speciﬁcation.

As long as the data is stored in this speciﬁed format

it can be loaded into the associated form. The HL7

messages are received by a Mirth Connect citemirth

server interface which has three channels conﬁgured:

one channel to receive the collected raw data, another

channel for signal processing and a channel intended

for internal use that sends the data to VCIntegrator

java backend webservices for storage. This way the

channels can be easily arranged to several possible

scenarios: either to ignore the signal processing and

just store raw data, store both incoming data in paral-

lel, or just forward the raw data to signal processing

servers. The data sent via webservices can be visu-

alized in VCIntegrator user inteface in the respective

form and visual components. The extraction of the

data from the HL7 messages into openEHR speciﬁ-

cation is done, at the moment, by mapping each of

the HL7 data ﬁelds with the corresponding openEHR

archetype data elements, each with a unique identi-

ﬁable openEHR path. This is currently being done

inside Mirth Connect using java, but further work

should be put into a more automated solution. The

webservice layer provides a solution for both SOAP

and REST speciﬁcations. In order to be able to store

the data, in either speciﬁcations, using the accord-

ing client implementation, the client must ﬁrst iden-

tify itself, then proceed with the patient EHR identi-

ﬁcation and set it as the current working EHR, iden-

tify the working openEHR Template and set the data

to record (create Composition) and ﬁnally submit the

Composition to the EHR. During these procedures the

audit details are being generated and then saved to-

gether with the data. Creating the openEHR template

for this work consisted in (1) identifying the clinical

statements recorded by the DSCollector, (2) develop

a structured representation of these statements, (3)

search for existing archetypes in the openEHR Clini-

cal Knowledge Manager (CKM) (openEHR commu-

nity, ) to represent the clinical statements, (4) create

the template. Since the structured representation of

the clinical statements and the archetypes were avail-

able, it was possible to create the template. The struc-

tured representation helped to create the framework

of the template, where the archetypes were arranged.

The development of the template was made on the

Ocean Template Designer software that allows com-

posing a set of archetypes into a template which is

also available for free download on the Ocean Infor-

matics website. The following openEHR arquetypes

were obtained from the openEHR Clinical Knowl-

edge Manager (CKM) and are used to represent the

clinical data, as a template, collected by the DSCol-

lector:

• openEHR-EHR-COMPOSITION.encounter.v1

• openEHR-EHR-CLUSTER.individual personal.v1

• openEHR-EHR-CLUSTER.person name.v1

• openEHR-EHR-OBSERVATION.blood pressure.v1

• openEHR-EHR-OBSERVATION.body weight.v1

• openEHR-EHR-OBSERVATION.height.v1

• openEHR-EHR-OBSERVATION.indirect oximetry.v1

• openEHR-EHR-EVALUATION.clinical synopsis.v1

4.3 DSCollector

The DSColector is an Android based application

that allows healthcare professionals to collect clinical

data, such as weight, height, blood pressure, etc; and

the phonocardiogram from any patient anywhere. The

most relevant feature of this application is the acquisi-

tion of the phonocardiogram in order to store it in the

electronic health record of the patient. In order to do

that, the DSCollector handles a bluetooth communi-

cation with an electronic stethoscope (in our case, the

Littmann 3200), and using a simple protocol, stores

HEALTHINF2015-InternationalConferenceonHealthInformatics

148

(a) (b) (c)

Figure 4: DSCollector screenshots of some of the acquisition stages during an appointment. 4(a) Patient creation layout. 4(b)

Clinical information gathered from the patient. 4(c) Acquisition of the pulmonary valve sound.

4 different sounds from the patient, being them the

4 most common heart focal points (pulmonary valve,

aortic valve, mitral valve and tricuspid valve).

As seen in ﬁgure 4 we can see the usual workﬂow

of this application. The healthcare professional needs

to ﬁrst chose one electronic stethoscope to connect to,

and he can then proceed with the appointment, this

step is only required to do in the beginning of the ap-

plication and not for every patient. After that he can

chose to add a new patient or to create a new one, if

he chose to create one, he is requested to enter the pa-

tient identiﬁcation number (that should be unique un-

der the national or private healthcare information sys-

tem), name, age and gender. After the patient creation

or after choosing an existence patient, the healthcare

professional is requested to enter all the clinical data

as he would retrieve in a standard appointment plus

the auscultation.

In the ﬁgure 4(c) it possible to see how this proce-

dure is done, the healthcare professional is requested

to collect 4 individual sounds from the patient, being

allowed to record more if required, from the same fo-

cal point.

All this data is then stored in the device and it will

be ready to be sent to any system that can receive HL7

messages (see section 4.1). From all the data gathered

with this device, only the sound ﬁles are not common

data to be sent in an electronic health record, but as

you can see in message 3 in the section 4.1, what we

do is to encode the sound to Base64, as it is done with

email messages, and send them inside the HL7 mes-

sage. All the HL7 handling is made with the help of

the HAPI parser an library for Java.

5 HEART SOUND SIGNAL

PROCESSING

As described earlier, after data collection, clinical

data are sent to the server for storage, and in parallel,

several signal processing tasks will be performed over

the collected PCG. The objective is to automatically

extract relevant signal features, as soon as the PCG

reaches the server, and produce a report with this in-

formation. This report will be later attached to the ob-

servation; if any alarming feature is detected, a warn-

ing may be sent to the clinician for earlier further eval-

uation of the patient. Several algorithms are already

implemented for PCG analysis, and features extrac-

tion (Ferreira et al., 2013; Castro et al., 2013; Pedrosa

et al., 2014; Oliveira et al., 2014; Castro et al., 2014):

auscultation spot segmentation; heart sound envelope;

heart cycle segmentation; signal quality; heart sounds

amplitude and duration; murmur detection; S2 com-

ponents’ analysis.

Figure 5: Example of a phonocardiogram collected in a real

clinical environment with heart sounds detection and classi-

ﬁcation (heart rate, S12 and S21 time intervals estimation).

Figure 5 presents an example of an auscultation

collected in a clinical scenario, with heart sounds de-

tection, and features extraction.

Figure 6 shows a proposal for data presentation to

the healthcare professional, with the results of the sig-

nal processing integrated in the EHR. A report with

these features may be generated, as well as a graph-

ical representation of the PCG, which may be very

helpful for clinical assessment and is not available for

standard acoustic auscultation.

6 DISCUSSION

In this paper we have proposed a framework for in-

tegrating the health data gathered by a clinician dur-

ing a patient evaluation either at home or in a primary

AProposaltoIncorporateDigitalAuscultationandItsProcessingintoanExistingElectronicHealthRecord

149

Figure 6: Proposal of data presentation to the healthcare

professional including the signal processing results.

care environment. We have focused on the ausculta-

tion signal since it is by far the less explored in both

literature and similar projects, given its challenging

hardware and gathering protocol requirements.

A full solution is proposed that includes not only

communication and storage protocols but also pro-

vides the framework with fundamental signal process-

ing and data visualization capabilities.

As part of the workplan of the ICT for Future

Health project, this framework will be implemented,

deployed and evaluated at the USF Nova Via primary

care center in Vila Nova de Gaia, Portugal, in early

2015.

ACKNOWLEDGEMENTS

This work was partially funded by the Fundac¸

para a Ci

encia e Tecnologia (FCT, Portuguese Foun-

dation for Science and Technology) under the ref-

erence Heart Safe PTDC/EEI-PRO/2857/2012; and

Project I-CITY - ICT for Future Health/Faculdade de

Engenharia da Universidade do Porto, NORTE-07-

0124-FEDER-000068, funded by the Fundo Europeu

de Desenvolvimento Regional (FEDER) through the

Programa Operacional do Norte (ON2) and by na-

tional funds through FCT/MEC (PIDDAC).

REFERENCES

(2013). IHE - IT Infrastructure Tecnhical Framework. IHE,

volume 2a edition.

Beale, T. and Heard, S. (2008). OpenEHR architecture

overview.

Carapetis, J. R. et al. (2008). Evaluation of a screening pro-

tocol using auscultation and portable echocardiogra-

phy to detect asymptomatic rheumatic heart disease in

Tongan schoolchildren. Nature Clinical Practice Car-

diovascular Medicine, 5(7):411–417.

Castro, A., Mattos, S. S., and Coimbra, M. T. (2014). Non-

invasive blood pressure and the second heart sound

analysis. In Engineering in Medicine and Biology So-

ciety (EMBC).

Castro, A., Vinhoza, T., Mattos, S., and Coimbra, M.

(2013). Heart sound segmentation of pediatric aus-

cultations using wavelet analysis. In Engineering in

Medicine and Biology Society (EMBC).

EuropeanCommission (2013). Active and healthy ageing

for you & with you.

Ferreira, P., Vinhoza, T., Castro, A., Mourato, F., Tavares,

T., Mattos, S., Dutra, I., and Coimbra, M. (2013).

Knowledge on heart condition of children based

on demographic and physiological features. In

Computer-Based Medical Systems (CBMS), pages

314–319.

Health Level Seven International (2007). What is HL7?

Oliveira, J., Castro, A., and Coimbra, M. T. (2014). Ex-

ploring embedding matrices and the entropy gradient

for the segmentation of heart sounds in real noisy en-

vironments. In Engineering in Medicine and Biology

Society (EMBC).

openEHR (2013). What is openEHR.

openEHR community. Clinical knowledge manager.

Pedrosa, J., Castro, A., and Vinhoza, T. (2014). Auto-

matic heart sound segmentation and murmur detec-

tion inpediatric phonocardiograms. In Engineering in

Medicine and Biology Society (EMBC).

Pereira, D., Gomes, P., Mota, l., Costa, E., Cruz-Correia,

R., and Coimbra, M. (2013). Combining a tablet and

an electronic stethoscope to create a new interaction

paradigm for teaching cardiac auscultation. In HCI In-

ternational 2013, volume 374 of Communications in

Computer and Information Science, pages 206–209.

Rechel, B., Grundy, E., Robine, J.-M., Cylus, J., Macken-

bach, J. P., Knai, C., and McKee, M. (2013). Ageing

in the european union. The Lancet, 381(9874):1312–

1322.

SCPSDC (2013). Ready for ageing? (Report of Ses-

sion 201213 Select Committee on Public Service and

Demographic Change, e Authority of the House of

Lords).

VirtualCare (2014). Vcintegrator.

WHO (2011). Global health and aging.

WHO (2012). Good health adds life to years.

WHO (2014). Health topics, ageing.

HEALTHINF2015-InternationalConferenceonHealthInformatics

150