Integrating Physical Activity Data with Electronic Health Record

Rishi Saripalle

School of Information Technology, Illinois State University, Normal, Illinois, 61790, U.S.A.

Keywords: HL7 Fast Health Interoperability Resources (FHIR), Physical Activity Resource, EHR Physical Activity,

OpenEMR, Exercise, Wearables.

Abstract: Wearables allow individuals to track, analyze, and visualize their physical activities and associated data

such as vitals, activity information, etc. across time. But, none of this activity data is anywhere to be found

in an electronic health record - the primary source of patient medical data for the healthcare providers. This

inability doesn’t allow experts to view the complete health summary of an individual and also, activity data

can play a key role in healthcare decisions. This problem is due to the lack of standards that can capture

activity data from disparate sources (e.g., wearables, smart watches, trackers, etc.) and integrate it with an

EHR. This research article identifies and provides a detailed analysis of the key factors contributing to the

problem. Based on the detailed analysis, we design an interoperable model by leveraging HL7 FHIR

standard to capture activity data from wearables and develop it using FHIR HAPI - an implementation of

HL7 FHIR. This initial prototype is tested by capturing Fitbit data and integrating it with OpenEMR - an

open source EHR.

1 INTRODUCTION

Digitalization of healthcare data in the form of

Electronic Health Record (EHR) eliminated many

healthcare issues and is leveraged by the industry to

capture, aggregate, and analyse the patient data.

Currently, many EHR systems, both proprietary and

open-source, allow providers to capture a variety of

patient data such as diagnosis, encounters,

observations, procedures, medications, family

medical history, etc. The patient data can be shared

across healthcare systems using different healthcare

standards such as ASTM CCR, Health Level 7

(HL7) CCD (D’Amore et al., 2011), HL7 V2 and V3

(Boone, 2011, Dolin et al., 2001) messaging format,

and HL7 FHIR (Saripalle, in press). However, the

physical activity data of a patient is not captured in

an EHR and is not shared across diverse healthcare

systems. Physical activity is defined as “any bodily

movement produced by skeletal muscles that result

in energy expenditure” (Caspersen, Powell &

Christenson, 1985). Exercise is a subset of physical

activity which is defined as “a planned, structured,

and repetitive and has as a final or an intermediate

objective the improvement or maintenance of

physical fitness” (Caspersen et al., 1985). Both

physical activity and exercise will be referred as to

“activity” for the rest of the article unless stated

explicitly.

Before wearables, tracking activities and

quantifying their output was practically impossible

or expensive for an individual/patient. Hence, there

is none or minimal activity data recorded in the

health records. However, the introduction of

wearables and smartwatches (e.g., Fitbit, Apple

Watch, LG Watch, etc.) have revolutionized the

personal health space and the behavior/attitude of

the consumers towards activities. Using these

affordable digital instruments, an individual can

track their physical activity (e.g., walking, running,

etc.) and any associated data (e.g., heart rate,

calories, distance, elevation, route, time, etc.).

According to market analysts (Hunn, 2015, Kaul,

Wheelock, 2015), there is an accelerating market for

wearables where the valuations are expected to reach

~30 billion by 2020 from ~$600 million in 2013.

Researchers (Shin, Jarrahi, Nov 15 2014, Hillsdon,

2015, Fanning et al., 2012, Lim et al., 2011) also

found evidence that the wearables served as a

valuable tool for quantifying and visualization an

individual’s physical activities and provided them

motivational affordances to do more.

Even as individuals can track their activities and

quantify its output, healthcare providers cannot see

Saripalle, R.

Integrating Physical Activity Data with Electronic Health Record.

DOI: 10.5220/0007310100210029

In Proceedings of the 12th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2019), pages 21-29

ISBN: 978-989-758-353-7

this data in an EHR. The primary reason is due to

the lack of an interoperable model/structure within

the existing healthcare standards that can capture

activity data. These are the same healthcare

standards that are used to share EHRs. Figure 1

renders the current wearable infrastructure and it’s

working. In most cases, logs are used to record the

exercise routine/plan, a non-digital format facing the

same issues as paper-based medical records. Activity

data captured using the wearables (e.g., Fitbit, most

popular among wearables) is synchronized to the

organization data repositories through a mobile app

(e.g., Fitbit, LG Sport, etc.) and is accessible via an

API (e.g., Fitbit or Google Fit API) but is formatted

in the organization own data format. In the case of

Apple Watch, data is only accessible within iOS

ecosystem using Apple HealthKit or download

through its Health App, making it difficult to access

the data outside the iOS environment. In Android,

the devices use Google Fit to record and access the

activity data. Most of the other fitness wearables

(e.g., Garmin, etc.) fall under the same pattern –

record, report, and access the data via an API if

provided or download the data. From Figure 1, it is

evident that the activity instruments, digital or non-

digital, collect (and report) data in a non-standard

format and report the data to a proprietary data store,

creating data silos. These data repositories or the

devices cannot communicate the captured data with

a healthcare information entity such as an EHR due

to the lack of an agreed “standard” to capture and

share the activity and any associated data. Focusing

on integrating individual devices with an EHR out of

the box is unfeasible, aunting, and practically not

scalable.

Another issue due to the inability to integrate

activity data with an EHR is that the experts cannot

provide evidence-based physical activity plans,

exercise routines, etc. For example, an individual,

say, John Doe, age 25 with no serious medical

condition approaches a trainer to improve his fitness.

Most of the trainers use their knowledge and

experience to design a exercise routine to help John

Doe reach his/her goal. How will the trainer prove

the provenance of the routine? What kind of

evidence can the trainer provide to John Doe that

supports the plan or at least in majority cases? John

Doe might have a positive attitude towards the

exercise routine if the trainer shows evidence that

the exercise routine worked previously with other

individuals. In biomedical and health informatics,

questions related to the patient's treatments or care

can be answered with clinical evidence. This

evidence is obtained by analyzing copious amounts

of de-identified aggregated patient data using

various computational algorithms and techniques.

The same cannot be said about physical activity and

exercise routine/plan(s).

The aim of this research is to design and develop

an interoperable model/structure using existing

healthcare standard to capture activity data and share

it across healthcare information systems. The rest of

the paper is organized as follows. Section 2 provides

the background knowledge and analysis of the

current situation. Section 3 presents the solution

using the HL7 FHIR and OpenMRS – an open

source EHR. Section 4 summarizes the research.

Figure 1: Interoperability issues with current physical activity and exercise digital and non-digital instruments.

HEALTHINF 2019 - 12th International Conference on Health Informatics

2 BACKGROUND AND

ANALYSIS

Experts unanimously agree that physical activity has

many health benefits and numerous research studies

spanning across multiple decades has proven to

show its impact the overall health of an individual

and nation’s economy. With the goal to improve the

activity level of individuals across the United States,

in 2007, the American Medical Association and the

American College of Sports Medicine (ACSM)

collaborated to launch the program - Exercise is

Medicine (EIM) (Lobelo et al., 2014). The goal of

the program is to make physical activity a standard

and adapt scientifically proven benefits of physical

activity into the mainstream healthcare. The idea is

for the physicians to access the activity level of the

patient (use of the Physical Activity Vital Sign

(PAVS) questionnaire (Lobelo et al., 2014, Sallis,

2011) during the patient’s encounter and prescribe

physical activity based on the identified health risks

and ACSM evidence-based guidelines. The physical

activity prescription, similar to medication

prescription, must be saved and tracked along with

other data. The most effective way to achieve this

goal is to integrate activity data with an EHR. The

intention of the EIM is congruent with the research

statement and supports the need for healthcare

standard(s) to integrate the activity data with an

EHR.

Beyond EIM framework, there are only a few

research studies that have identified and reported the

need to save physical activity data for longitudinal

healthcare analysis and benefits. Sallis (2011)

pushed to treat physical activity as a vital sign.

Physicians must record and observer the patient’s

physical activity levels during their medical visits

once recognized as a vital sign by the healthcare

community. Coleman et al., (2012) presented facts

and validity of Exercise Vital Sign (EVS), similar to

PAVS, for its use in an outpatient electronic medical

record. After analysing the current research and

healthcare standards, the primary reason for the

interoperability issues is due to the lack of agreed

healthcare standards, both structural and semantic,

for representing and sharing activity data. As the

standards are a foundation for interoperability, it’s

surprising that the experts have not yet designed an

interoperable standard to capture physical activities

and exercises. Without an agreed standard, it’s not

feasible to capture, share and integrate the activity

data into the healthcare systems. Few standards are

scalable and can be extended to meet various

healthcare requirements, in our case capture activity

data. For instance, HL7 V2 (Boone, 2011)

messaging format is a pipe (|) and hat (^) encoding

format that allows clinicians to exchange data.

However, this standard is not supported by a

software model with a well-defined structure and

semantics. Due to this drawback, experts developed

the HL7 V3 (Boone, 2011) messaging format. Thus,

it doesn’t add any value to extend the HL7 V2

format to achieve our goal. The HL7 V3 is built

using HL7 Reference Information Model (RIM)

(Boone, 2011) – a sound object-oriented model with

a well-defined structure, semantics, and constraints

that can be extended. The current HL7 RIM model

can be repurposed to capture and communicate a

limited set of activity data. For example, activities

such as jogging, swimming, etc. and the vitals

generated during the activities can be represented

and communicated using HL7 V3 messages. Figure

2a shows the activity jogging (the subject of the

message) and heartbeat (outcome (OUTC)

relationship), an outcome of the subject in HL7 V3

format.

Saripalle (2017) extended the HL 7 RIM model

with required classes to capture the activity data.

Later, HL7 V3 messages were constructed based on

the extended model to share the activity data across

healthcare systems that accept HL7 V3 messaging

format. Figure 2b shows the extended model. The

classes, PhysicalActivity and ExercisePlan, that

capture the required data. authors to use this

document for the preparation of the camera-ready.

There are two key lessons learned from this

research. First, the HL7 RIM is a complex model

that can be difficult to comprehend. Further,

understanding HL7 V3 messaging format has a steep

learning curve that requires expertise in computing.

Second, there are only a few open-source healthcare

systems and tools, specifically EHR's, which can be

extended and are designed to accept HL7 V3

messages. This makes implementation of the

research very difficult.

The knowledge required to design the new

classes (Figure 2b) to extend the RIM is adapted

from PhysicalActivity and ExercisePlan schemas

defined by Schema.org. Schema.org (2012) is an

open source effort to define schemas/data structures

to describe any data, especially the data published on

the web. Schema.org describes, i.e., provide

schema/structure for numerous concepts (e.g.,

Person, ScholaryArticle, Book, Organization, etc.)

across various domains (e.g., Auto, Health, Books,

Biology, etc.). Currently, most of the data published

on the web is unstructured. The developers use the

Schema.org schemas to annotate (using Microdata or

Integrating Physical Activity Data with Electronic Health Record

(b) HL7 V3 message representing the activity jogging and

resultant vital data using the RIM model Act and Observation

class.

(a) Extended HL7 RIM model to capture activity data.

Figure 2: HL7 V3 message format and extended HL7 RIM model.

RDFa or JSON-LD formats) their data before

publishing. This also allows machines to understand

and link data efficiently. Many modern websites use

Schema.org to annotate their webpages to provide

meaning to their data and also make the website

search engine friendly. The PhysicalActivity and

ExercisePlan schemas from the Schema.org that are

adapted by Saripalle (Saripalle, 2017) to design the

new RIM classes (Figure 2b) and are also used for

this research. Similar to the Schema.org, Open

mHealth (Open mHealth, 2015) is a data-driven

approach to provide schemas specifically for

describing, collecting, and sharing healthcare data

such as blood pressure, body weight, body height,

heart rate, etc.

Further, apart from developing the structural

standard(s) for activity data, the idea of this

research, experts must also define semantic

standard(s) to standardize the physical activity and

exercise vocabulary. Few existing terminologies

capture concepts related to the physical activity and

exercise. For example, SNOMED (2007) is an

internationally recognized biomedical semantic

terminology that captures concepts spanning across

multiple clinical disciplines. For example, jogging

(code 1968006), running (418060005), walking

(129006008), chest press exerciser (46778600), etc.

However, currently, there is no dedicated standard

semantic terminology that comprehensively captures

the concepts of physical activities and exercises.

Designing and developing standards itself

doesn’t solve the problem. The standards also need

support from the healthcare community, information

technology, healthcare experts, public and private

organizations. Most importantly, the healthcare

community must adopt the new/extended standard to

existing systems and applications. The healthcare

experts might have to tweak their protocols, best

practices, and include physical activity check during

a regular patient’s visit.

3 INTEGRATING ACTIVITY

DATA WITH EHR USING HL7

FHIR

To capture the activity data and seamlessly integrate

it with a healthcare system such as an EHR, this

research will leverage HL7 Fast Health

Interoperability Resource (FHIR) (HL7, 2015) – the

new HL7 member, OpenEMR – an open source

electronic health record system (OpenEMR, 2001)

and schemas defined by Schema.org and Open

mHealth. The research design has two phases. First,

extend FHIR to design a new model to capture the

activity data. Second, implement the new FHIR

model and interface it with the OpenEMR. This

research doesn't handle semantic standard(s)

required for the physical activity and exercise.

HEALTHINF 2019 - 12th International Conference on Health Informatics

Briefly, the HL7 FHIR standard is designed by

combining the HL7 RIM model, lightweight HTTP-

based RESTful web services and the lessons learned

from using HL7 V3 format. HL7 FHIR is a mashup

of HL7 RIM and REST protocol with backward

compatibility with the HL7 V3. The atomic unit of

FHIR is a Resource. The health data in the FHIR

environment is captured and shared as an FHIR

resource. The FHIR standard defines multiple

resources to represent different types of healthcare

data. For example, MedicationStatement resource

captures a patient’s prescription, Encounter resource

captures patient-provider visit information,

Observation resource captures vital data (e.g., heart

rate, blood pressure, pulse, BMI, weight, etc.) or

symptom data, DiagnosticReport captures test

results information including images, and Vision

resource captures patient’s optical data. HL7 FHIR

also has resources to capture administrative and

health insurance aspects such as Claim, Coverage,

PaymentNotice, etc. For comparison, FHIR

resources are equivalent to various sandwich

ingredients such as bread, spreads, vegetables, meat,

sauces, etc. As the different ingredients are

combined to make a user’s sandwich, multiple FHIR

resources are aggregated to build a patient record or

an EHR. Figure 3 exemplifies the usage of

individual FHIR resources to build a patient’s

record. Currently, FHIR defines 117 resources that

can be categorized into clinical (e.g., Condition,

Observation, NutiritionOrder, etc.), foundation (e.g.,

CapabilityStatement, Provenance, etc.), base (e.g.,

Patient, Person, Organization, etc.), financial (e.g.,

Claim, Coverage, etc.), and specialized (e.g.,

ResearchStudy, Questionnaire, etc.). It’s beyond the

scope of this paper to further deluge into the

fundamentals of FHIR standard and its inner

workings. For further documentation and a complete

list of the FHIR resources can be accessed at the

FHIR specification website (HL7, 2017).

The HL7 FHIR standard designers are aware that

the current set of resources might not meet all the

current and future healthcare and policy

requirements. Thus, the FHIR design team ensured

that the standard is extendable, i.e., experts can

define new FHIR resources or existing resources can

be modified to meet any requirement. In software

engineering terms, FHIR embraced the classic open-

closed principle. This research will leverage this

feature to design a new FHIR resource to capture the

patient’s physical activity and exercise data and

share it across healthcare information systems. The

context and knowledge required to define the new

FHIR resource, named PhysicalActivity, that

captures the activity data is obtained from the

PhysicalActivity and ExercisePlan schemas defined

in Schema.org, PhysicalActivity and related schemas

from Open mHealth, PAVS questionnaire, and

knowledge from the experts in the field of exercise

science. Table 1 shows the primary attributes of

PhysicalActivity and ExercisePlan (some attributes

are ignored as they are unrelated to the research

goal) defined by Schema.org.

Table 1: Attributes associated with PhysicalActivity and

ExercisePlan schema defined in Schema.org.

Physical Activity

Attribute Name Explanation

associatedAnatomy

The anatomy of the underlying

organ system or structures

associated with this entity.

category A category this activity belongs to

epidemiology

The characteristics of associated

patients, such as age, gender, race

etc.

code

The code from a controlled

vocabulary or ontology such as

ICD, MeSH, SNOMED-CT, etc.

recognizingAuthority

The organization that officially

recognizes this activity

pathophysiology

Changes in functions associated

with this activity.

Exercise Plan

Attribute Name Explanation

activityDuration

Length of time to engage in the

exercise.

activityFrequency

How often one should engage in the

exercise.

exerciseType

Type(s) of exercise, such as strength

training, aerobics, etc.

intensity

Degree of force involved in the

exercise. E.g., heartbeats

Repetitions

Number of times one should repeat the

activity.

Workload

Measure of the exercise output or

energy expenditure

On further analysis, the attributes of the

PhysicalActivty schema defined by Open mHealth

are a subset of PhysicalActivity schema attributes of

Schema.org. The Open mHealth doesn’t provide a

standard data structure to capture exercises. Apart

from the ExercisePlan schema from Schema.org, the

research also considered the paper-based (exercise

Integrating Physical Activity Data with Electronic Health Record

Figure 3: FHIR resources are aggregated to define a patient profile.

logs) structure followed by various organizations

(e.g., LA Fitness, Gold gym, etc.), and expert’s

knowledge into the new FHIR resource design

consideration.

Figure 4 shows the PhysicalActivity FHIR

resource. The exercise entity is modeled as an inner

element of the PhysicalActivity resource as an

exercise is a structured and repetitive physical

activity in the exercise science (Caspersen et al.,

1985). In an object-oriented language, the exercise

element has a composition relationship with

PhysicalActivity resource. Figure 4 provides a

detailed description of each attribute in the

PhysicalActivity resource and the data it captures.

The attributes vital and patient are of type

Observation and Patient FHIR resources

respectively. The types of other attributes are FHIR

defined datatypes such as Identifier, Quantity,

CodeableConcept, string, etc. As previously stated,

some attributes (Table 1) from PhysicalActivity and

ExercisePlan schemas from Schema.org are in the

PhysicalActivity resource. The designed resource

also captures the crucial data requested in the PAVS

questionnaire through the attributes activeTime and

Workload (e.g., calories burned). The

PhysicalActivity resource can also be extended, like

any other FHIR resource to meet any future

requirements.

The second phase is the implementation of the

designed research and integrating the captured data

with an EHR – OpenEMR. The HL7 FHIR is only a

standard specification, but not an executable

software. The research used the FHIR specification

to design the new PhyscialActivity FHIR resource,

but to prototype the solution this research will use

HAPI FHIR (Velykis, 2014). The HAPI FHIR is an

open-source Java implementation of HL7 FHIR

specification that has both server and client. The

Open Medical Record System (OpenEMR) is used

to integrate the activity data captured as an FHIR

resource. The OpenEMR is chosen for this research

due to an active community, has a larger audience,

and focused on natively supporting the FHIR

standard. The OpenEMR is modified to accept the

new FHIR resource, persist the data and display the

data on the system.

Figure 5 shows the architecture of the

implementation. The HAPI server is the main

module of the architecture interfacing with the

Translator and the OpenEMR database. The

Synchronizer extracts the activity data using the

wearable API (e.g., Fitbit API) and authenticating

using the provided OAuth credentials from the

respective wearable datastores and pass the data to

the Translator.The Translator translates the activity

data into an instance of PhysicalActivity FHIR

resource and passes it to the HAPI server. Currently,

the implementation can handle Fitbit, Jawbone data

and Google Fit data. The FHIR server saves the data

in the OpenEMR database using its OpenEMR API

and physician can access the same data using

OpenEMR user interface. The wearable, with an

API, has to be configured only once and the data is

extracted periodically. Currently, the wearable

configuration, primarily authentication, needs be

done at the programming level, but not through

OpenEMR UI. As the diverse activity data formats

are translated into an FHIR resource, any healthcare

application that supports the extended FHIR

standard can replace the OpenEMR. Also, the

designed research solution is in line with the EIM

solution the experts are seeking. The implemented

solution is accessible at

http://umls.it.ilstu.edu:8100/openemr/index.php and

further details are available on request. Figure 6

(top) shows a screenshot of the OpenEMR physician

interface displaying “Physical Activity” (bottom

right) as a member of any other medical entity such

as medication, allergy, prescription, etc. Figure 6

(below) shows the physician a quick snapshot of the

weekly summary (calories burned and time in

minutes) which is equivalent to PAVS.

4 CONCLUSIONS

This research has identified and reasoned the need to

HEALTHINF 2019 - 12th International Conference on Health Informatics

Figure 4: Physical Activity FHIR resource.

Figure 5: Software architecture of the modified OpenEMR system with HAPI FHIR to integrate physical activity and

exercise data.

standardize activity data format and integrate the data

with a healthcare information systems, such as an

EHR, to provide a patient’s complete health

summary to the healthcare provider to make an

informed decision. To this end, the research

identified that the inability to integrate activity data

captured by various instruments (e.g., wearable,

smart watched, logbooks, mobile apps, etc.) with an

EHR or any other healthcare information system is

due to lacks of agreed interoperable structural

standards to represent activity data. Based on the

analysis, background knowledge and previous

research, lessons from EHR development, and

feedback from multiple experts (exercise and health

sciences), this research designed an interoperable

model, PhysicalActivity resource (Figure 4), by

leveraging HL7 FHIR and schemes from Schema.org

and Open mHealth to capture activity data. The

PhysicalActivity resource is implemented using

HAPI FHIR, a client-server implementation of the

Integrating Physical Activity Data with Electronic Health Record

HL7 FHIR specification. The research is

demonstrated (Figure 5) by extracting the Fitbit data

via Fitbit API, translating the data into

PhysicalActivity resource and integrating it with

OpenEMR - an EHR. Once in the digital format

within an EHR, the activity data can be de-identified

and aggregated to build large activity datasets

allowing researchers to apply data-driven techniques

to derive actionable knowledge in the field of health

sciences and beyond.

The work presented is an initial step on a long

path. Currently, we are evaluating wearables and

trackers working on Google Fit and will work our

way towards other wearables such as Samsung,

Garmin, etc. The next step worthy of pursuing would

Figure 6: Modified OpenEMR to include physical activity

and exercise data.

be to propose the PhysicalActivity FHIR resource to

the FHIR committee for considering it in the standard

after conducting feasibility and acceptability

analysis. In the prototyped architecture (Figure 6),

the Synchronizer extracts the data and Translator

translates it to the FHIR resource. Research is

required to understand how this process can be

integrated with an EHR and address any security,

privacy and legal concerns.

REFERENCES

D’Amore, J.D., Sittig, D.F., Wright, A., Iyengar, M.S. &

Ness, R.B. 2011, "The Promise of the CCD:

Challenges and Opportunity for Quality Improvement

and Population Health", AMIA Annual Symposium

Proceedings, vol. 2011, pp. 285-294.

Boone, K.W. 2011, The CDA

book, 2011th edn,

Springer.

Dolin, R.H., Alschuler, L., Beebe, C., Biron, P.V., Boyer,

S.L., Essin, D., Kimber, E., Lincoln, T. & Mattison,

J.E. 2001, The HL7 Clinical Document Architecture.

Saripalle, R. in press, "Fast Health Interoperability

Resources (FHIR): Current Status in the Healthcare",

International Journal of E-Health and Medical

Communications (IJEHMC), vol. 10, no. 1.

Caspersen, C.J., Powell, K.E. & Christenson, G.M. 1985,

Physical activity, exercise, and physical fitness:

definitions and distinctions for health-related

research.

Hunn, N. 2015, The Market for Wearable Technology: A

Consumer Centric Approach.

Kaul, A. & Wheelock, C. 2015, Wearable Device Market

Forecasts.

Shin, G. & Jarrahi, M. Nov 15 2014, "Studying the Role

of Wearable Health-Tracking Devices in Raising

Users’ Self-Awareness and Motivating Physical

Activities", International Workshop on Interactive

Systems in Healthcare.

Hillsdon, M. 2015, What Influence Does Personal

Physical Activity Tracking Have On Membership

Retention?, http://theretentionpeople.com/what-

influence-does-personal-physical-activity-tracking-

have-on-membership-retention/ edn.

Fanning, J., Mullen, P.S. & McAuley, E. 2012,

"Increasing Physical Activity With Mobile Devices: A

Meta-Analysis", J Med Internet Res, vol. 14, no. 6, pp.

e161.

Lim, B.Y., Shick, A., Harrison, C. & Hudson, S.E. 2011,

"Pediluma: Motivating Physical Activity Through

Contextual Information and Social Influence",

Proceedings of the Fifth International Conference on

Tangible, Embedded, and Embodied InteractionACM,

New York, NY, USA, pp. 173.

Lobelo, F., Stoutenberg, M. & Hutber, A. 2014, The

Exercise is Medicine Global Health Initiative: a 2014

update.

Sallis, R. 2011, Developing healthcare systems to support

exercise: exercise as the fifth vital sign.

Coleman, K.J., Ngor, E., Reynolds, K., Quinn, V.P.,

Koebnick, C., Young, D.R., Sternfeld, B. & Sallis,

R.E. 2012, Initial validation of an exercise "vital sign"

in electronic medical records.

Saripalle, R. 2017, Extending HL7 RIM Model to Capture

Physical Activity Data, Pittsburg.

(b) OpenEMR with physical activity.

(a) Physical activity weekly summary.

HEALTHINF 2019 - 12th International Conference on Health Informatics

Schema.org 2012, Schema.org, http://schema.org/ edn.

Open mHealth 2015, Open mHealth Schema library,

http://www.openmhealth.org/documentation/#/schema

-docs/schema-library edn.

SNOMED 2007, Systematized Nomenclature of Medicine.

Available: http://www.ihtsdo.org/snomed-ct [2016,

October].

HL7 2015, Fast Healthcare Interoperability Resources

Documentation. Available:

https://www.hl7.org/fhir/documentation.html.

OpenEMR 2001, June-last update, OpemEMR. Available:

https://www.open-emr.org/ [2018, May 2].

HL7 2017, FHIR Resources,

https://www.hl7.org/fhir/resourcelist.html edn.

Velykis, A. 2014, HAPI FHIR, http://hapifhir.io.

Integrating Physical Activity Data with Electronic Health Record