**4. Maturity capability statements for the micro-level processes of each domain**

If the three-dimensional concept model (Figure 2) is sliced up along the domain dimension, fifteen sets of maturity capability statements (green) are created, three for each domain. The three sets per domain are with respect to the micro-level, meso-level and macro-level proc‐ esses. This section presents the complete sets of maturity capability statements with respect to micro-level processes. Each of the five rows of Figure 4 represents the heading for each of the five respective sets of maturity capability statements presented in this section.

#### **4.1. Users (***Man-***domain)**

The capability statements for the micro-level services within context of the *man-*domain is shown in Figure 6.

others. On the the left hand side of examples are given of users (orange) for each of the steps within the micro-level telemedicine service. These examples are derived from a meta-analysis of telemedicine projects on which reports were published between 2007 and 2010 in the

Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 *no ad hoc managed standard measured optimising* 

> standard and (technically) interoperable

> > quality standards

> > work standards

consitent and

standard and (semantically) interoperable

tionalized

Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 *no ad hoc managed standard measured optimising* 

> standard and (technically) interoperable

> > quality standards

> > work standards

consitent and permanent

users no-one entrepeneur champion everyone workforce professional

consitent quality

execution

consitent, but temporary

Level 1 Level 1 Level 2 Level 3 Level 4 Level 5 *ad hoc ad hoc managed standard measured optimising* 

monitored

The Telemedicine Service Maturity Model: A Framework for the…

quality control

performance control

permanent accountability cost

evidence based medicine

scalable monitored continuous

business intelligence

monitoring and evaluation

sustainable cost metrics value

monitored

quality control

performance control

accountability cost

maintenance and upgrades

http://dx.doi.org/10.5772/56116

225

quality improvement

continuous improvement

optimisation

change to community

improvement

business analytics

optimising

optimisation

maintenance and upgrades

quality improvement

continuous improvement

optimisation

users no-one entrepeneur champion everyone workforce professional

consitent quality

execution

consitent, but temporary

nothing prototype pilot

entrepeneur

no EHR mgmt system

research and development

nothing prototype pilot

process ad hoc consistent

entrepeneur

no EHR uncertain quality

no

costs no funds R and D /

community resistance acceptable norm

not existing not existing defined institu-

none insufficient managed standard and

consistent EHR mgmt

dependent on seed funding

no EHR uncertain quality

procedures no process ad hoc consistent

costs no funds R and D /

no

research and development

International Journal for Telemedicine and Telecare [24].

Micro-level Telemedicine Service

> devices / applications

electroni c health records

work

Meso- and Macro Level Telemedicine Processes

> user community

ICT infrastructure

EHR mgmt no EHRs

change management

financial sustainability

**Figure 4.** Micro-level domain-specific maturity indicators

Micro-level Telemedicine Service

> devices / applications

electronic health records

work procedures

**Figure 5.** Macro-level domain-specific maturity indicators

man

machine

material

method

money

man

machine

material

method

money

man

machine

material

method

money

Telemedicine services have a wide range of users. Depending on how the service is set up, the telemedicine process can include patients as well as healthcare workers, such as medical specialists, nurses, radiologists, midwifes, primary care practitioners and counsellors, amongst


**Figure 4.** Micro-level domain-specific maturity indicators

**3.5. The maturity scale**

224 Telemedicine

project management and innovation management.

The generic levels are described below:

**3.6. Domain-specific maturity indicators**

next section.

**domain**

**4.1. Users (***Man-***domain)**

shown in Figure 6.

The maturity scale of the TMSMM is based on the generic level indicators of the capability maturity model (CMM). This is done for two reasons: Firstly, most of the existing maturity models use a maturity scale, which is either identical to, or strongly resembles the CMM-scale. This is indicative of the usefulness and validity of this scale. Secondly, it opens up the possibility that the TMSMM, which is categorized as a descriptive maturity grid, is used in conjunction with comparative CMM-like maturity models, for example those developed for

**• Level 1**:Ad hoc - The service is unpredictable, experimental, and poorly controlled

**• Level 3**:Standard - The service is defined/confirmed as a standard business process

**• Level 4**:Quantitatively managed - The service is quantitatively measured and controlled

Domain specific maturity indicators for the micro-level as well as meso- and macro-level telemedicine service processes are shown in Figure 4 and Figure 5 respectively. Each of these rows serves as heading for each of the respective maturity grids, which are presented in the

**4. Maturity capability statements for the micro-level processes of each**

five respective sets of maturity capability statements presented in this section.

If the three-dimensional concept model (Figure 2) is sliced up along the domain dimension, fifteen sets of maturity capability statements (green) are created, three for each domain. The three sets per domain are with respect to the micro-level, meso-level and macro-level proc‐ esses. This section presents the complete sets of maturity capability statements with respect to micro-level processes. Each of the five rows of Figure 4 represents the heading for each of the

The capability statements for the micro-level services within context of the *man-*domain is

Telemedicine services have a wide range of users. Depending on how the service is set up, the telemedicine process can include patients as well as healthcare workers, such as medical specialists, nurses, radiologists, midwifes, primary care practitioners and counsellors, amongst

**• Level 2**:Managed - The service is characterised by projects and is manageable

**• Level 5**:Optimising - Deliberate focus on continuous improvement


**Figure 5.** Macro-level domain-specific maturity indicators

others. On the the left hand side of examples are given of users (orange) for each of the steps within the micro-level telemedicine service. These examples are derived from a meta-analysis of telemedicine projects on which reports were published between 2007 and 2010 in the International Journal for Telemedicine and Telecare [24].


For example, when the users are human resources of the hospital or health system, integration with the human resource business process is expected. The maturity level for the user-domain is scored at level 4 (quantitatively managed) if worker performance metrics exist for each of the steps of the telemedicine process and if data is effectively included in performance management and in the work appraisal process. A maturity level of 5 indicates a deliberate attempt towards continuous professional development with respect to the use of the micro-

The maturity capability statements for the micro-level *machine* domain is shown in Figure 7.

Data Transmission processes

The Telemedicine Service Maturity Model: A Framework for the…

http://dx.doi.org/10.5772/56116

227

internet service, mobile phone network etc.

… is non-existing (not the same as not available)

… was considered in the design of the service.

… 's interoperability is considered in the system's standards design.

...'s reliability and availability can be measured.

...'s reliability and availability are monitored.

: Deviations from acceptable levels of availability and reliability is continuously addressed.

… 's capability, reliability and availability is continuously improved.

basis … is assumed to be available.

… meets design requirements … is confirmed to be available.

… is reliable and available … transmits data repeatably.

… is effective … transmits data effectively.

Capture, Diagnose/ Analyse, React processes

telemedicine device/ mobile phone ect.

… is non-existing (not the same as not available)

… is used on ad hoc/ experimental

… was procured/ developed/ considered according to system design standards.

… 's interoperability is considered in the system's standards design.

… is developed and operated according to specifications of regulatory bodies.

… is continuously monitored to determine adherance to specifications of regulatory bodies.

… is continuously upgraded to specifications of regulatory bodies and standards organizations.

… is continuously upgraded to specifications of regulatory bodies and standards organizations.

Examples of devices and applications (orange) for each of the steps of the micro-level teleme‐ dicine service (yellow) are given. These examples are derived from a meta-analysis of teleme‐

**Figure 7.** Maturity capability statements for the micro-level processes of the "Machine" domain

level telemedicine service.

**4.2. Devices and software applications (***Machine***-domain)**

devices / applications

no

ad hoc

managed

standard

measured

optimising

maintenance and

upgrades

standard and

(technically)

monitored

interoperable

nothing

prototype

pilot

Level 0

Level 1

Level 2

Level 3

Level 4

Level 5

**Figure 6.** Maturity capability statements for the micro-level processes of the "Man" domain

Patients are always the beneficiaries of telemedicine services and are often categorised as users. In home-based telemedicine services, it is common that patients are equipped with appropriate technology enabling them to collect and transmit their healthcare data themselves. On the other hand, patients are not necessarily a user of the system. For example, a nurse can use a teleme‐ dicine service to deliver appropriate care to a patient. In this case the nurse would be catagor‐ ised as the user of the telemedicine service and not the patient. By the same token, the role of ICT technologists is imperative for the operation of a telemedicine service, but the ICT technologist is not necessarily a user of the system.

Many authors, for example, [25] and [26], agree that the involvement of a so-called champion is one of the contributing factors to the successful implementation of telemedicine services. A champion is a user from the community who takes the role of innovator and advocate. Both level 2 and level 3 imply that the user is appropriately trained and motivated to execute the task consistently and on an ongoing basis. A maturity level of 2 is assigned when this process is driven by a champion. A maturity level of 3 is allocated if every user is trained and motivated to execute the task consistently and on an ongoing basis.

Another determinant for the successful implementation of telemedicine, is the integration of the telemedicine service with other business processes of the hospital or health system [1, 27]. For example, when the users are human resources of the hospital or health system, integration with the human resource business process is expected. The maturity level for the user-domain is scored at level 4 (quantitatively managed) if worker performance metrics exist for each of the steps of the telemedicine process and if data is effectively included in performance management and in the work appraisal process. A maturity level of 5 indicates a deliberate attempt towards continuous professional development with respect to the use of the microlevel telemedicine service.

#### **4.2. Devices and software applications (***Machine***-domain)**

Patients are always the beneficiaries of telemedicine services and are often categorised as users. In home-based telemedicine services, it is common that patients are equipped with appropriate technology enabling them to collect and transmit their healthcare data themselves. On the other hand, patients are not necessarily a user of the system. For example, a nurse can use a teleme‐ dicine service to deliver appropriate care to a patient. In this case the nurse would be catagor‐ ised as the user of the telemedicine service and not the patient. By the same token, the role of ICT technologists is imperative for the operation of a telemedicine service, but the ICT

Many authors, for example, [25] and [26], agree that the involvement of a so-called champion is one of the contributing factors to the successful implementation of telemedicine services. A champion is a user from the community who takes the role of innovator and advocate. Both level 2 and level 3 imply that the user is appropriately trained and motivated to execute the task consistently and on an ongoing basis. A maturity level of 2 is assigned when this process is driven by a champion. A maturity level of 3 is allocated if every user is trained and motivated

Another determinant for the successful implementation of telemedicine, is the integration of the telemedicine service with other business processes of the hospital or health system [1, 27].

technologist is not necessarily a user of the system.

users

no

ad hoc

managed

standard

measured

optimising

no-one

entrepeneur

champion

everyone

workforce

professional

Level 0

226 Telemedicine

Level 1

Level 2

Level 3

Level 4

Level 5

Capture, Diagnose/ Analyse, React processes

… is non-existing / not part of the system anymore.

… should possibly be able to do this.

… has done it before and is willing to do this as default action.

… is willing and mandated to do this as default action.

… is mandated and expected to do this as default action.

… is mandated and compelled to do this as default action.

… is monitored if/ how he does this.

… is monitored and appraised on if/how he does this.

… has the support to improve his performance in doing this.

… contributesthe training and development of peers towards doing this.

**Figure 6.** Maturity capability statements for the micro-level processes of the "Man" domain

patient/ doctor/ nurse etc. patient/ doctor/ nurse etc.

… has done it before. … has done it before.

Data Transmission processes

… is non-existing / not part of the system anymore.

… should possibly be able to do this.

… has done it before and is willing to do this as default action.

… is willing and mandated to do this as default action.

… is mandated and expected to do this as default action.

… is mandated and compelled to do this as default action.

… is monitored if/ how he does this.

… is monitored and appraised on if/how he does this.

… has the support to improve his performance in doing this.

… contributesthe training and development of peers towards doing this.

to execute the task consistently and on an ongoing basis.

The maturity capability statements for the micro-level *machine* domain is shown in Figure 7.


**Figure 7.** Maturity capability statements for the micro-level processes of the "Machine" domain

Examples of devices and applications (orange) for each of the steps of the micro-level teleme‐ dicine service (yellow) are given. These examples are derived from a meta-analysis of teleme‐ dicine projects on which reports were published between 2007 and 2010 in the International Journal for Telemedicine and Telecare [24].

Admittedly, technology is developing at a rapid pace and it is likely that the current list of most used telemedicine devices and software looks somewhat different to those identified in this study. This does not influence the relevance of the TMSMM, since it is technologyindependent. The purpose of the TMSMM is not to measure the complexity of technological advancement of the devices and software. Telemedicine is a service innovation [28] and not a technological innovation. The technology most commonly used for telemedicine services is relatively simple. Hence, the TMSMM measures the maturity of the telemedicine service and as such considers the appropriateness, maintainability, availability and interoperability of the device and software.

According to the layered telemedicine implementation model [27] during the prototype phase, the focus is on the technological feasibility. Technological feasibility includes aspects such as the availability, reliability, and maintainability (RAM) of the used technology. Until this is achieved, the maturity of the telemedicine service, in terms of devices and software, is pitched at level 1 (ad hoc).

For a managed telemedicine service (level 2) the telemedicine device and/or software must be regularly available and maintained and user support must be available within the context in which it is to be used. This is typical in the pilot phase. In South Africa [21] and throughout the world [27] it seems that the initial enthusiasm of the 1990s has given way to.more reflective views of the place of telemedicine in healthcare delivery. This is mostly due to the fact that the majority of pilot projects have failed to be sustained. Yunkap Kwankam, eHealth coordinator of the World Health Organisation, ironically described this situation as "suffering from pilotitis" [29].

A telemedicine device or software application is only considered to be standard (level 3) if it is standardised, interoperable and integrated with other systems in the healthcare system. Keeping track of standard software upgrades entails technology maintenance (level 3).

level of 2 indicates a consistent and repeatable record keeping process, but without considering

Itis importantthatpersonaldata aboutpatients are transmittedsecurely andtheprivacy ofdata be ensured. This includes the raw data which is used for diagnosis, as well as the prognosis and informationwhichis sentbacktothepersonwhoneeds toreact.Ifthis isaccomplishedaccording to encryption and decryption standards of the governing institution, the "transmit data" and "transmitfeedback"processes areplacedonmaturitylevel 3.Amaturitylevel of 1 indicates that datasecurityprotocolsarenotconsidered,whatsoever.Amaturitylevelof2isawardedifsecurity

Level 4 pertains to the tracking of electronic health records, whilst level 5 indicates deliberate

Refer to Figure 9 for the maturity capability statements for the micro-level processes of the

protocols are considered, but not necessarily managed by the governing institution.

attempts to increase the quality of electronic health records.

electronic health records

no

ad hoc

managed

standard

measured

optimising

quality

improvement

no EHR

uncertain quality

consitent quality

quality standards

quality control

Level 0

Level 1

Level 2

Level 3

Level 4

Level 5

Capture, Diagnose/ Analyse, React processes

is of varying and most often unacceptable quality.

 is of varying but most often acceptable quality.

 are created repeatably with consistently acceptable quality.

 are created repeatably. Consistent and acceptable (fitfor-purpose) quality of EHR record.

's quality standards are clearly defined within context of this service.

's quality standards are clearly defined within a larger context.

's quality are measured as part of the standard process.

> 's quality measures are effectively reported.

: Causes for unacceptable quality are continuously identified.

: Causes for unacceptable are continuously and effectively addressed.

**Figure 8.** Maturity capability statements for the micro-level processes of the "Material" domain

Data Transmission processes

The Telemedicine Service Maturity Model: A Framework for the…

http://dx.doi.org/10.5772/56116

229

data

is sometimes unrightfully intercepted as part of transmission process.

sometime get list during transmission, but it is not unrightfully intercepted.

is secured in terms of user control.

is secured in terms of encription and decription.

is secured according to standards within context of the service.

is interoperating syntactically with other EHRs within context of this service.

can be tracked throughout the telemedicine service.

and identities of persons who viewed and edited it, can be tracked.

: Causes for delays and incorrectly transmitted EHRs are identified.

: Causes for delays and incorrectly transmitted EHRs are continuously addressed.

EHR data/ images/ video ect. EHR-type data/ images/ video

No record keeping whatsoever No electronic transmission of

**4.4. Work protocols (***Methods***-domain)**

"methods" domain, namely work protocols.

standard data formats.

A maturity level of 4 is reached if systems are in place to monitor the reliability, availability and maintainability of the technology, whilst a maturity level of 5 indicates that hardware and software are continuously upgraded, where appropriated.

#### **4.3. Electronic health records (***Material***-domain)**

The telemedicine service converts raw data into useful information, similar to any manufac‐ turing process, in which raw material is converted into a useful product. Hence, "material" is included as a domain in the final TMSMM, referring to electronic health records (micro-level) and local EHR systems (meso-level) and national EHR systems (macro-level). The maturity capability statements of individual EHRs (micro-level) appear in Figure 8.

A maturity level of 3 is awarded to the "capture data", "perform diagnosis" and "react" processes if the EHRs are compiled according to a standard data format. If no intentional record keeping protocol is in place, the maturity of these three processes is gauged at 1. A maturity


**Figure 8.** Maturity capability statements for the micro-level processes of the "Material" domain

level of 2 indicates a consistent and repeatable record keeping process, but without considering standard data formats.

Itis importantthatpersonaldata aboutpatients are transmittedsecurely andtheprivacy ofdata be ensured. This includes the raw data which is used for diagnosis, as well as the prognosis and informationwhichis sentbacktothepersonwhoneeds toreact.Ifthis isaccomplishedaccording to encryption and decryption standards of the governing institution, the "transmit data" and "transmitfeedback"processes areplacedonmaturitylevel 3.Amaturitylevel of 1 indicates that datasecurityprotocolsarenotconsidered,whatsoever.Amaturitylevelof2isawardedifsecurity protocols are considered, but not necessarily managed by the governing institution.

Level 4 pertains to the tracking of electronic health records, whilst level 5 indicates deliberate attempts to increase the quality of electronic health records.

#### **4.4. Work protocols (***Methods***-domain)**

dicine projects on which reports were published between 2007 and 2010 in the International

Admittedly, technology is developing at a rapid pace and it is likely that the current list of most used telemedicine devices and software looks somewhat different to those identified in this study. This does not influence the relevance of the TMSMM, since it is technologyindependent. The purpose of the TMSMM is not to measure the complexity of technological advancement of the devices and software. Telemedicine is a service innovation [28] and not a technological innovation. The technology most commonly used for telemedicine services is relatively simple. Hence, the TMSMM measures the maturity of the telemedicine service and as such considers the appropriateness, maintainability, availability and interoperability of the

According to the layered telemedicine implementation model [27] during the prototype phase, the focus is on the technological feasibility. Technological feasibility includes aspects such as the availability, reliability, and maintainability (RAM) of the used technology. Until this is achieved, the maturity of the telemedicine service, in terms of devices and software, is pitched

For a managed telemedicine service (level 2) the telemedicine device and/or software must be regularly available and maintained and user support must be available within the context in which it is to be used. This is typical in the pilot phase. In South Africa [21] and throughout the world [27] it seems that the initial enthusiasm of the 1990s has given way to.more reflective views of the place of telemedicine in healthcare delivery. This is mostly due to the fact that the majority of pilot projects have failed to be sustained. Yunkap Kwankam, eHealth coordinator of the World Health Organisation, ironically described this situation as "suffering from

A telemedicine device or software application is only considered to be standard (level 3) if it is standardised, interoperable and integrated with other systems in the healthcare system. Keeping track of standard software upgrades entails technology maintenance (level 3).

A maturity level of 4 is reached if systems are in place to monitor the reliability, availability and maintainability of the technology, whilst a maturity level of 5 indicates that hardware and

The telemedicine service converts raw data into useful information, similar to any manufac‐ turing process, in which raw material is converted into a useful product. Hence, "material" is included as a domain in the final TMSMM, referring to electronic health records (micro-level) and local EHR systems (meso-level) and national EHR systems (macro-level). The maturity

A maturity level of 3 is awarded to the "capture data", "perform diagnosis" and "react" processes if the EHRs are compiled according to a standard data format. If no intentional record keeping protocol is in place, the maturity of these three processes is gauged at 1. A maturity

capability statements of individual EHRs (micro-level) appear in Figure 8.

software are continuously upgraded, where appropriated.

**4.3. Electronic health records (***Material***-domain)**

Journal for Telemedicine and Telecare [24].

device and software.

228 Telemedicine

at level 1 (ad hoc).

pilotitis" [29].

Refer to Figure 9 for the maturity capability statements for the micro-level processes of the "methods" domain, namely work protocols.


**Figure 9.** Maturity capability statements for the micro-level processes of the "Methods" domain.

Any healthcare service needs to be executed according to a certain set of well defined protocols in order to ensure consistency, integrity and ethical conduct. In most cases these protocols was defined, before ICT made telemedicine possible. In many cases the telemedicine service deviates significantly from the original way of doing and a new protocol for the telemedicine service does not exists. In this case, a maturity level of 1 is allocated. A maturity level of 2 indicates that the telemedicine process is executed consistently and repeatably, but the protocol

6

is not formally defined. Once it is formally defined the maturity is guaged at 3. Performance control metrics enables the consistent measurement of the effectiveness of the protocol (maturity level 4). A maturity level of 5 is reached as soon as the causes of performance

The *money*-domain (considers maturity in terms of operational cost (micro-level), business model (meso-level) and health economics (macro-level). Figure 10 shows the maturity

Data Transmission processes

The Telemedicine Service Maturity Model: A Framework for the…

http://dx.doi.org/10.5772/56116

231

cost of transmission service

: The service is still only in conceptual phase.

are not considered by developers/ entrepeneur.

are considered and covered by seed funds whilst service is in development phase.

will be covered on short term by seed funds.

will be covered on long term by seed funds.

are included partially as a standard budget item.

are included fully as a standard budget item.

are a reporting item of the accounting system.

s reports are routinely scrutinized to ensure optimal use of funds.

: Continuous efforts by service provider to bring down costs.

: Continuous efforts by service provider to bring down costs filtered through to service context.

Capture, Diagnose/ Analyse, React processes

operational and maintenance costs

: The service is still only in conceptual phase.

are not considered by developers/ entrepeneur.

are considered and covered by seed funds whilst service is in development phase.

will be covered on short term by seed funds.

will be covered on long term by seed funds.

are included partially as a standard budget item.

are included fully as a standard budget item.

are a reporting item of the accounting system.

s reports are routinely scrutinized to ensure optimal use of funds.

: Non-value adding activities are continuously identified.

: Non-value adding activities are continuously eliminated.

Maturity level 1 and 2 applies when the operational costs are provided by external entities, either for purposes of research and development (level 1) or for philantropic reasons by external donors. These funding modes are not sustainable. For financial sustainability, is it compulsory the operational expenses are covered as part of the standard budgeting process of the governing organization (maturity level 3). Maturity level 4 concerns accountability. It

**Figure 10.** Maturity capability statements for the micro-level processes of the "Money" domain.

capability statements for the micro-level processes of the "money" domain.

deviations are continuously identified and rectified.

costs

no

ad hoc

managed

standard

measured

optimising

no

R and D /

consitent, but

consitent and

permanent

accountability

cost optimisation

temporary

entrepeneur

Level 0

Level 1

Level 2

Level 3

Level 4

Level 5

**4.5. Costs (***Money***-domain)**

is not formally defined. Once it is formally defined the maturity is guaged at 3. Performance control metrics enables the consistent measurement of the effectiveness of the protocol (maturity level 4). A maturity level of 5 is reached as soon as the causes of performance deviations are continuously identified and rectified.

#### **4.5. Costs (***Money***-domain)**

6

work procedures

Level 0

230 Telemedicine

Level 1

Level 2

Level 3

Level 4

Level 5

optimising

measured

standard

managed

ad hoc

no innovation

no innovation

ad hoc

consistent execution

work standards

performance control

continuous improvement

Capture, Diagnose/ Analyse, React processes

is exactly the same as without

is executed on and a trial and error basis.

differs from person to person and case to case.

is executed consitently.

is executed consitently and this process is documented.

is defined as a work standard for this service.

is acceptable within context of relevant ethical guidelines and legal frameworks.

's effectiveness is continously

's efficiency is continuously monitored.

: causes for ineffectiveness are continuously addressed.

: continuous improvement in terms of process efficiency.

Any healthcare service needs to be executed according to a certain set of well defined protocols in order to ensure consistency, integrity and ethical conduct. In most cases these protocols was defined, before ICT made telemedicine possible. In many cases the telemedicine service deviates significantly from the original way of doing and a new protocol for the telemedicine service does not exists. In this case, a maturity level of 1 is allocated. A maturity level of 2 indicates that the telemedicine process is executed consistently and repeatably, but the protocol

**Figure 9.** Maturity capability statements for the micro-level processes of the "Methods" domain.

work procedure network service

ICT. does not exist.

Data Transmission processes

is sometimes available. Not a specific service provider.

is mostly available. Not a specific service provider.

is delivered by a specific (set of) service provider(s) with varying service levels.

is delivered by a specific (set of) service provider(s) with consistent service levels.

level agreements (SLAs) are defined.

level agreements (SLAs) are contractually agreed upon.



levels are continuously improved.

monitored. -levels are measured.

The *money*-domain (considers maturity in terms of operational cost (micro-level), business model (meso-level) and health economics (macro-level). Figure 10 shows the maturity capability statements for the micro-level processes of the "money" domain.


**Figure 10.** Maturity capability statements for the micro-level processes of the "Money" domain.

Maturity level 1 and 2 applies when the operational costs are provided by external entities, either for purposes of research and development (level 1) or for philantropic reasons by external donors. These funding modes are not sustainable. For financial sustainability, is it compulsory the operational expenses are covered as part of the standard budgeting process of the governing organization (maturity level 3). Maturity level 4 concerns accountability. It must be possible to measure and report on the costs related to this process. On maturity level 5 the cost effectiveness of the process are continuously improved.

The maturity of the ICT infrastructure depends on its availability, reliability and maintaina‐ bility (maturity level 3) as well as the measurement thereof (maturity level 4). Continuous improvement (maturity level 5) within this context relates to technology upgrades and

The Telemedicine Service Maturity Model: A Framework for the…

http://dx.doi.org/10.5772/56116

233

The maturity scale described below applies equally to meso-level, local EHR systems and the

Syntactic interoperability involves a common data format and common protocol to struc‐ ture any data so that the manner of processing the information will be interpretable. When the different systems involved in a telemedicine service are capable of communicating and exchaning data, they are syntactically interoperable [35] and a maturity level of 2 is indicated. "Beyond the ability of two or more computer systems to exchange information, semantic interoperability is the ability to automatically interpret the exchanged information meaning‐ fully and accurately in order to produce useful results as defined by the end users of both systems" [35]. A maturity level of 3 is awarded if semantic interoperability is achieved. If no intentional record keeping protocol is in place, the maturity of these three processes is

Business intelligence (BI) is a broad category of applications and technologies for gather‐ ing, storing, analyzing, and providing access to data to help enterprise users make better business decisions. A maturity level of 4 indicates that such applications and technologies existsBusiness analytics (BA) is often used as synonymn for BI. However, for purposes of the chapter, it is recognized that for BA statistical methods are used to develop an understand‐ ing of business performance and to provide a feedback loop towards continuous business

The need for deliberate and effective change management is echoed throughout studies on the implementation of telemedicine services [1-4, 23, 26, 37]. Change management is the process of changing processes. Within context of the TMSMM, change management is posi‐

The majority of telemedicine services do not sustain after pilot phase [22, 27, 26] even though the concept was technologically proved during prototype and pilot phase. In those

A champion is a user from the community who takes the role of innovator and advocate. Many authors [1, 25, 26] mention the involvement of a so-called champion as a critical suc‐ cess factor to the successful implementation of telemedicine services. Maturity level 2 ap‐

A maturity level of 3 indicates sustainable institutional commitment to accomplish change. This commitment is firstly demonstrated by the formal and permanent appoint of a change

plies when such a champion is either self-appointed or appointed by the institution.

scalability.

gauged at 1.

improvement.

**5.4. Change management (***Methods-***domain)**

tioned as meso-level process of the Methods-domain (Figure 9).

cases, the change management process was ineffective (maturity level 1).

**5.3. EHR systems (***Material***-domain)**

macro-level, national EHR systems.
