healthcare it our mission

4
HEALTHCARE IT MANAGEMENT ISSN: 1782-8406 THE OFFICIAL JOURNAL OF THE EUROPEAN ASSOCIATION OF HEALTHCARE IT MANAGERS REMOTE PATIENT CARE SMART CARDS AND HEALTHCARE HOSPITAL ASSET MANAGEMENT PATIENT CLASSIFICATION SYSTEMS PCC: RADIOLOGY INFORMATION SYSTEMS COUNTRY FOCUS: BELGIUM Volume 4 / Issue 1 / 2009

Upload: others

Post on 03-May-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: HEALTHCARE IT OUR MISSION

The European Association of Healthcare IT Managers is a non-profit pan-European umbrella organisation for all relevant national healthcare IT associations in Europe.

OUR MISSION:• The European Association of Healthcare IT Managers supports and encourages the emergence of common healthcare IT standards at both EU and international levels.

• The European Association of Healthcare IT Managers believes that the European Healthcare IT sector needs a common voice - especially in the face of rapid technological change and growing socioeconomic pressures.

• The European Association of Healthcare IT Managers invites you to be involved in a community to exchange opinions and experiences with like-minded colleagues. We defend your interests and make your voice heard, effectively.

If you are a CIO, CMIO or IT Manager in the healthcare area

JOIN US !

Visit our website at www.hitm.eu to apply for membership today!

European Association ofHEALTHCARE IT MANAGERS28, Rue de la LoiB-1040 Brussel, Belgium

Tel.: +32/2/286 85 01Fax: +32/2/286 85 08Email: [email protected]: www.hitm.eu

HEALTHCARE ITM A N A G E M E N T

ISSN: 1782-8406

THE OFFICIAL JOURNAL OF THE EUROPEAN ASSOCIATION OF HEALTHCARE IT MANAGERS

REMOTE PATIENT CARE

SMART CARDS AND HEALTHCARE

HOSPITAL ASSET MANAGEMENT

PATIENT CLASSIFICATION SYSTEMS

PCC: RADIOLOGY INFORMATION SYSTEMS

COUNTRY FOCUS: BELGIUM

Volume 4 / Issue 1 / 2009

cover_Hitm_Final:Layout 1 11/02/09 15:01 Page 1

Page 2: HEALTHCARE IT OUR MISSION

Interoperability and Standards

It has become essential for systems tointeroperate and this has created a needfor health devices to have a commonstandard. The healthcare industry hasrecognised such a need, and the Contin-ua Alliance (www.continuaalliance.org)has been formed to develop industrystandards for interoperability betweensensors, home networks, telehealth net-works and health and wellness services.The first set of standards due for releasehas been developed for the sensors bythe IEEE 11073 standards group.

The IEEE 11073 Family of Standards

The ISO/IEEE 11073 family of standardsfor medical devices has existed for manyyears and was originally developed forhospital based equipment and specifical-ly for the intensive care environment. Theoriginal protocol, based on the full OSI 7layer model, was often criticised as be-ing heavyweight and complex. In its cur-rent form, it was not considered appro-priate as the basis of a new standard forpersonal health data (PHD) devices. How-ever, with the expected rapid increase inthe demand for health devices in thehome with capability to communicate re-sults, a standard capable of operating inthis environment is essential.

The 11073 family of standards is parti-tioned into a set of standards coveringthe many aspects of communicating thesemantics of medical data from deviceto manager. This includes a Domain In-formation Model (DIM), nomenclature,

device specialisations, device behaviour,communication transports, and commu-nication protocol. The 11073 family ofstandards has also acted as an umbrellafor medical device standards.

The IEEE 11073 PHD Working GroupThe IEEE 11073 PHD Working Group(WG) was established to develop a newmedical standard that would be used forthe typical PHD device. It was acceptedthat any new standard would need to beimplemented within the limited resourcesof such devices, and also align with cur-rent developments in the Bluetooth SIGand USB SIG to develop health profiles.The work group set itself the task to de-velop a common base protocol thatwould work with an initial set of six de-vice specialisations (pulse oximeter,pulse/heart rate, blood pressure, ther-mometer, weighing scale and glucose).The group currently consists of 205 mem-bers from 112 organisations, with 57%

from USA, 19% from Far East and 24%from Europe. It has weekly telephoneconference calls and meets every 2-3months in face to face meetings.

The Standards ProcessInitially four proposals were submitted tothe group for consideration as a basis forthe standard. However no one proposalsatisfied all the requirements and aprocess to develop a combined proposalwas adopted. This included identifying atemplate of a set of minimum require-ments, a set of preferred requirements,and a set of mandatory behaviour. Propos-als were compared and strengths of eachidentified to inform the final proposal.

The final proposal was mainly based onthe 11073 standard but included impor-tant changes to accommodate the re-source requirements of PHD devices andto incorporate advantageous character-istics of the other protocols.

REMOTE CARE OF PATIENTSThe Personal Health Devices Standard - ISO/IEEE 11073-20601

Malcolm Clarke is Senior Lecturerin telemedicine and eHealth Systems atBrunel University. He is former chairman of the AmericanTelemedicine Association Special Inte r -est Group in Technology and is on CEN,HL7, IEEE and ISO committees workingon standards for medical devices.

AUTHOR

With an ever-increasing elderly population and the growing prevalence of chronic disease, current healtcaresystems are struggling to cope. Home based monitoring, with a patient taking data measurements at homeand relaying the data automatically to remote data servers, is seen as an important solution to reduce relianceand demand on care services.

The Official Voice of HITM 33

10400 Common Framework

20601 Optimized Exchange Protocol

00103 Technical Report - Overview

OSI10404Pulse

Oximeter

10406Pulse

10407Blood Pres-

sure

10408Thermo-

meter

10415Weighing

Scale

Device Specializations

10417Glucose

Serial IrDA Bluetooth USB Zigbee Other

Phase II...

Fig. 1. Overview of the IEEE PHD 11073 Framework

HITM_V4_I1_Tosh_inside:Layout 1 12/02/09 14:40 Page 33

Page 3: HEALTHCARE IT OUR MISSION

The ProtocolOverview

A typical IEEE PHD 11073 system is de-fined by the framework as shown in Fig-ure 1. The overall task is concerned withdefining the protocol at layer 7. The trans-ports which provide layers 1-6 are definedelsewhere and outside the scope of thework of the group, although there has beenclose liaison with groups such as BluetoothSIG to ensure compatibility. However notethat the group set an objective to make theprotocol transport agnostic in order to al-low use with future transport technology.

The existing 11073 standard uses OSI lay-er 7 and utilizes existing functionality ofCMISE and ROSE. It was quickly appar-ent that an optimised exchange protocolwas required. This would provide thesame functionality as OSI layer 7, but im-plement it in a lightweight fashion, elim-inating any redundant features, and befully defined in the new standard 20601,which would simplify implementation.

Domain Information Model (DIM)

The existing DIM of 11073 was used, butit was simplified for PHD devices by con-straining the scope of the model and re-stricting and flattening the hierarchy. Ab-stract Syntax Notation (ASN.1) is used todescribe the model, and this may alsoform the basis of definitions of data struc-tures for other languages.

The current optimised DIM for the PHDhas three objects to model the data ofthe device; the Medical Device System(MDS), the Numeric and the Real TimeSampled Array (RT-SA). The MDS has asattributes all the information pertaining to

the device and its operational status, suchas unique device ID, device configuration,and time functions. Attributes also con-tain product specification in text form. At-tributes may be determined by using theGET method defined in 20601.

Numeric objects relate to the physiolog-ical parameters and have as attributesthe mechanism to obtain an observedvalue and its status such as units and thetimestamp. The numeric object is definedto permit intermittent observations to bereported. Observations may be reportedusing four methods: the manager maymake a specific request for currentlyavailable data; the manager may requestdata to be reported as they become avail-able for a specified time; the managermay request data to be reported as theybecome available for an unbounded pe-riod of time; the agent may send an un-solicited observation. The RT-SA is opti-mised to report an array of observedvalues as a single data transmission,which reduces protocol overhead andwould be used for real time streams withhigh data rate and requiring low latency,such as the plesythmogram.

The protocol is further optimised by al-lowing for fixed and variable format ofdata transmission (Figure 2). In variableformat, each observation carries its attrib-ute ID, the length of the entry and the nu-meric value. If a stream of observationsis established, each having the same at-tributes, then the common attributes canbe defined in advance of the transmissionso that only the values need to be report-ed each time. This common attribute listis defined as the Observed-Value-Mapand is applied to each set of values re-ported and will reduce the transmission

burden. The idea is further extended tothe concept of defining standard deviceswith standard configuration. In this casethere may be no need to define the Ob-served-Value-Map in advance, so reduc-ing transmission burden during associa-tion further. A device may define itself assupporting extended functionality and usethe variable format to allow flexibility.

The Medical Device Encoding Rules(MDER) are used to convert ASN.1 struc-tures to binary transmissions. Althoughessentially the same as DER, they applysome optimisations to the protocol byhaving fixed size coding and removingsome of the features, and so align withthe needs of PHD devices.

Communication Model

The transport layer has been assumed toappear as a point to point link and be con-nection-oriented. It is further assumed thatwhenever the transport indicates a con-nection, the state machine moves to theconnected state and the agent is placedin the unassociated state. The agent willinitiate the association between itself andthe manager by issuing an association re-quest and will enter the associating state.

Configuration of a Device

IEEE 10073-20601 includes the conceptthat agents self describe in order to sup-port plug and play. This is supported ini-tially by the association request, whichwill contain the configuration ID of theagent and allow the manager to determineif it should accept the request and if it al-ready has configuration information froman earlier association. If the manager doesnot have the configuration information itmust request that configuration informa-tion is sent by the agent prior to enteringthe operating state. The configuration in-formation sent by the agent will includeinformation on the objects in the deviceand a handle number by which they maybe accessed. This step is bypassed if theconfiguration is already known and as-sumed unchanged. Manager and agentwill then enter the operating state. An as-sociation release and its response will takemanager and agent back to the unassoci-ated state, and this is the preferredmethod to disconnect devices.

34

features

Attribute 1 ID, Lenght

Observed-Value-Mapattribute in “ConfigurationMessage”

Attribute 1 Value

Fixed FormatValue Update

Attribute 2 Value

Attribute 3 Value

Attribute N Value

Attribute 2 ID, Lenght

Attribute 3 ID, Lenght

Attribute N ID, Lenght

Attrubute 1 IDLengthValue

Attrubute 2 IDLengthValue

Attrubute 3 IDLengthValue

Attrubute N IDLengthValue

Fig. 2. Fixed and Variable Data Formats.

HITM_V4_I1_Tosh_inside:Layout 1 12/02/09 14:40 Page 34

Page 4: HEALTHCARE IT OUR MISSION

Current and Future PlansCurrently the base protocol ISO/IEEE 11073-20601 and the specialisations listed belowhave been announced as phase I standardsthat will appear in early 2009, with commer-cial devices being announced for releaseshortly thereafter. The Continua Alliancehold regular interoperability events and pre-standard devices have been demonstrated.

Ó ISO/IEEE 11073-10404Pulse oximeter

Ó ISO/IEEE 11073-10407Blood pressure

Ó ISO/IEEE 11073-10408Thermometer

Ó ISO/IEEE 11073-10415Weighing scale

Ó ISO/IEEE 11073-10441Cardiovascular

Ó ISO/IEEE 11073-10442Strength fitness

Ó ISO/IEEE 11073-10471Independent living hub

The devices announced for phase II areshown below.

Ó ISO/IEEE 11073-10406Basic E.C.G. (1 to 3 lead)

Ó ISO/IEEE 11073-10417Glucose meter

Ó ISO/IEEE 11073-10418INR (blood coagulation)

Ó ISO/IEEE 11073-10419Insulin pump

Ó ISO/IEEE 11073-10443Physical activity

Ó ISO/IEEE 11073-10472Medication monitor

Conclusions

The IEEE 11073-20601 protocol has beendeveloped as a protocol for medical de-vices that is optimised for low capabilityagents that have limited resources of pro-cessing power, memory and power forcommunication.

It has reduced the complexity of the exist-ing 11073 standard by reducing data trans-mission sizes through defining a lightweightapplication layer, removing the session andpresentation layers of OSI, and making as-sumptions of the transport layer.

The DIM has been constrained and its hier-archy flattened to create simplified modelsmore appropriate to PHD devices. An opti-mised reconnection protocol can removethe need to transmit the configuration of anagent already known to a manager or forstandard devices. The protocol aligns withthe existing DIM and utilizes the existingnomenclature to leverage the 11073 stan-dards and to provide a framework for exten-sibility.

Acknowledgment

The author acknowledges the work andcontribution of the members of the IEEEPHD WG to this work.

The Official Voice of HITM 35

Disassociating+entry / TxAssocRelReq

Associating+entry / TxAssocReq

Unassociated

Operating

Associated

Configuring

Connected

Sending Config

Waiting Approval

TxAs

socA

bort

RxAs

socA

bort

RxAs

socR

elRs

p

RxAs

socR

elRe

q/Tx

Asso

cRel

Rsp

RxCo

nfig

Even

tRep

ortR

sp(a

ccep

ted-

conf

ig)

RxCo

nfig

Even

tRep

ortR

sp(U

nsup

porte

d-co

nfig

)

TxCo

nfig

Even

tRep

ortR

eq

asso

cReq

TxAssocAbort

RxAssocAbort

RxAssocRelReq/TXAssocRelRsp

RxAssocRsp(accepted-unknown-config)

RxAssocRsp (accepted)

RxAs

socA

bort

orTx

Asso

cAbo

rt

TxAs

socR

sp(re

ject

ed)

assocRelReq

Transport connectindication

Transport disconnectindication

Disconnected

Fig. 3. Association State Machine

HITM_V4_I1_Tosh_inside:Layout 1 12/02/09 14:40 Page 35