GATEWAY BEST PRACTICES · 2011. 9. 19. · Patient Summary Record HL7 CDA Release 2 CCD or ASTM CCR Electronic Prescribing NCPDP SCRIPT Version 8.1 or 10.6 Electronic Submission of

GATEWAY BEST PRACTICES

15 www.netspective.com

What a Gateway must support

Provisioning, securely enabling

and disabling features

Device settings and parameters

configuration

Software installs and upgrades

Fault management,

diagnostics, and remote support

Hospital IT connectivity to EHRs, financial systems, etc.


Gateway specific functionalities

Management

•Profiles (users, devices, organizational)

•Usage analytics, logging, and reporting

•Asset tracking

•Policy application

•Clinical data discovery

•Event and rules engine

Remote Service

•Diagnostics and troubleshooting

•Software installs, upgrades

•Monitoring

•Security

•Backup/Restore/Remote Wipe

Connectivity

•Electronic Health Record (EHR) integration

•Hospital Information System (HIS) integration

•HL7, X.12, MU integration

Provisioning and Configuration

•Authentication & authorization

•Device provisioning

•Single sign on between devices and apps

•Directory integration and federation

•Location tracking


Gateway deployment strategies

Single server in a single data center

• Assumes option 1 is chosen

• All devices connect to a single server

• Works well for fewer than 100 or so devices

Multiple homogenous servers in one or more data centers (Cluster)


• All devices connect to a group of clustered servers

• Works well for over a 100 devices

Multiple heterogeneous servers in one or more

data centers


• Each device group connects to their own gateways

• Works well for any number of devices


Common Gateway Elements

Application Server

Cloud Message Router

Data Integration

Server

Activity Tracking & Auditing

Service Container

Identity Federation


Required quality properties

• Safety critical attributes need to be supported based on which devices may connect

• Risk management approach that meets or exceeds FDA requirements must be used

• Scalability and performance based on expected vendor devices that need to be connected

• Security threats and threat matrix based on both closed (your own company) and open access (across vendors)

• Reliability that meets or exceeds medical device standards • Fault Tolerance that meets or exceeds medical device standards • Reusability of design (not necessarily code) across business units • Supportability across sectors and business units • Maintainability across sectors and business units • Testability across sectors and business units


PHI, PII and HIPAA properties

• Mechanisms of ensuring compliance with Healthcare, HIPAA PHI, and PII security requirements

• Security policy and procedure creation for cross-device data collection and dissemination

• Awareness, training, and education materials for both safety and privacy concerns

• De-Identifying information must be allowed for research and data sharing

• Workstation and server IT related security controls that meet or exceed hospital IT environments need to be incorporated


SRS (Requirements) Subject Areas

• Intended use

• Product structure (device vs. server)

• Use models (connected vs. disconnected)

• Data

• Events

• Logging

• Alarms

• Connectivity

• Radio (devices only)

• Controller (devices only)

• Server (gateway only)

• Usability

• User interface and User experience

• Regulatory

• Documentation

• Servicability


Examples of Serviceability Subjects

• New device purchase • New device purchase with pre-existing service • Remote service management • Help desk problem determination • Back up and restoration • High volume configuration • Automatic status reporting • Software download • Change of service (e.g. adding a new service) • Service discovery and provisioning

GATEWAY ARCHITECTURE What modern gateways should look like


Gateway Protocols Suggestion

Corporate Gateway

Service DB

Man

ageme

nt Se

rvices

Security

Firew

all

HTTPS, REST, SOAP SFTP, SCP, HL7, X.12 SMTP, XMPP, DDS

HTTPS, SOAP, REST, HTTP SFTP, SCP, HL7, X.12

SMTP, XMPP, DDS

Customers & Partners

Apps MQs Services Apps Services

Corporate Cloud (Data Center)

Development

App DB

Central DB

Registry

Rem

ote

Facilities

VP

N

NOTE: Initial design is for a non-federated backbone. If performance or security demands require it, a federated solution will be deployed.


Next Gen Gateway Architecture

Web Application Stack

On-Premise Appliance or Cloud Deployment

Data Integration Stack

Content Management System

Data Services and Persistence Stack

Relational Database Taxonomy Full Text Search

Biz Intel

Secure, HIPAA-Compliant, Web Server

Reporting

Dashboards

Alerting

Enterprise Service Bus

Analytics

Data Mining

OLAP

Notifications

Process Mgmt

Integration

ETL

Gateway

EII Metadata Rules Engine

Secure, MU- and HIPAA-Compliant, Clinical Data Repository (CDR) and Master Patient Index (MPI)

HL7 X.12

IM / E-mail

Themes

App Store

Forms

Documents

EHR Modules

Secu

rity &

Au

ditin

g

CCR

Patient Manager

Secure Messaging

Social Networks

HCP Directories

Target multiple devices like PC, SmartPhone, Tablet, Voice

HIE/NHIN Integration

EHR Integration

NLP & Patterns

Med Device Integration

Single sign on (LDAP, SAML)

Mobility Stack

Med Device Tethering

HIPAA Encryption & RBAC

Provisioning & Auditing

Legacy App Connectivity

Graph DB (RDF) Content Repository LDAP

As defined by Netspective Medigy Platform

DDS


Structured Data Format Suggestions

Item Standard

In general Follow requirements stipulated by NIST in MU guidance

Patient Summary Record HL7 CDA Release 2 CCD or ASTM CCR

Electronic Prescribing NCPDP SCRIPT Version 8.1 or 10.6

Electronic Submission of Lab Results to Public Agencies

HL7 2.3.1 or HL7 2.5.1

Electronic submission to immunization registries

HL7 2.3.1 or HL7 2.5.1

Quality Reporting The CMS Physician Quality Reporting Initiative (PQRI) 2009 Registry XML Specification


Coded Vocabulary Suggestions

Item Standard

In general Follow requirements stipulated by NIST in MU guidance

Problem List ICD9-CM / ICD10 or SNOMED CT 2009

Procedures CPT-4 / CPT-5

Laboratory test results LOINC 2.27+

Medications Any source vocabulary that is included in RxNorm

Immunizations HL7 Standard Code Set CVX - Vaccines Administered, July 30, 2009 version

Race and Ethnicity OMB Statistical Policy Directive No. 15


Privacy and Security Standards

Item Standard

In general Follow NIST 800-53 and related standards

Encryption and decryption of electronic health information

SSL/TLS Certificates, NIST FIPS 140-2

Record actions related to electronic health information

The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded

Verification that electronic health information has not been altered in transit

SHA-1 or higher (NIST FIPS PUB 180-3)

Record treatment, payment, and health care operations disclosures

The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501

CONNECTIVITY BEST PRACTICES The most important aspect of a Gateway is its connectivity


Connectivity Decisions Required

Physical

•Wired, wireless (WiFi, cellular, etc.)

Logical

•Device Concentrator Gateway Enterprise IT Cloud

Structural

•Security, Numbers, Units of Measure, etc.

Semantic

•Presence, Vitals, Glucose, Heartbeats, etc.


Legacy Physical Connectivity

Device

USB Converter Data

Concentrator (IEEE 11073?)

Hospital Network

Gateway (Data Mediator)

Corporate Cloud

Hospital Systems

Serial Converter

11073 assumes desire for multi-vendor connectivity


Next Gen Physical Connectors

Minimal

• Serial

• USB 2.0

• RJ-45

• 802.11a/b/g

Recommended

• Serial

• USB 3.0

• RJ-45

• Power over Ethernet (PoE)

• 802.11n

• Bluetooth

Advanced

• Thunderbolt

• USB 3.0 + eSata

• RJ-45

• Power over Ethernet (PoE)

• 802.11n/I

• Bluetooth

• Ant+

• Zigbee

• Cellular

• Zwave


Next Gen Physical Connectivity

Device Hospital Network

Gateway

Corporate Cloud

Hospital Systems

Option 1 (hospital IT integration required or no cellular access)

Device Corporate

Cloud

Option 2 (cellular access and no hospital IT integration required)

Could be a Home Network, too

Wired

Wireless Bluetooth, WiFi, Zibee, etc.

Wireless, Cellular


Legacy Protocols Best Practices

Device

Serial Converter

USB Converter

Data Concentrator

Hospital Network

Corporate Gateway

Corporate Cloud

Hospital Systems

DDS

REST

DDS Ethernet

Serial

HL7

X.12

If multi-vendor connectivity is required, add data translator and homogenization capability

MPEG-21


Next Gen Protocols Best Practices

Device Hospital Network

Corporate Gateway

External Cloud

Hospital Systems

Option 1 (no cellular access or hospital IT integration required)

Device External

Cloud

Option 2 (cellular access and no hospital IT integration required)

DDS

REST

HL7

X.12

DDS REST

MPEG-21

MPEG-21

Could be a Home Network, too

Wired

Wireless Bluetooth, WiFi, Zibee, etc.

Wireless, Cellular

HOW TO DESIGN NEW DEVICES FOR CONNECTIVITY AND INTEGRATION

Going beyond legacy devices and minor upgrades


New Device Design Approach

• Use existing industrial design boards based on safety-critical mobile phone-like battery powered design that will cut development time

• Use Windows CE as the operating system if the unit cost of $20 per unit is acceptable

• Build in web server for remote administration • Build in SQL Server Compact for data storage • Build in RTI DDS client and server for real-time

messaging • Use HTML 5 + JavaScript (Windows 8 technologies) or

QT Quick for UI development


New Device Architecture Suggestion

Device Components

Security and Management Layer Device OS (QNX, Android, Windows)

Connectivity Layer (DDS, HTTP, XMPP, SIP)

Plugin Container

Don’t create your own OS!

Security isn’t added later

Think about Plugins from day 1

Connectivity is built-in, not added

Build on Open Source

Create code as a last resort


New Device Plugin Architecture

Device Components 3rd Party Plugins

App #1

App #2


Plugins


Plugin Container

Event Architecture

Your device functionality should be a “plugin” too

Location Aware


New Device Connectivity Components

Device Components


Web Server, IM Client


• Presence • Messaging • Registration • JDBC, Query

Plugin Container

Surveillance & “remote display”

Remote Access

Alarms Event Viewer

Design all functions as plugins


New Device Functionality Components



Sensors Storage Display Plugins



Plugin Container

Event Architecture

Location Aware

Virtualize!

“On Device” Workflow

Patient Context, too



App #1

App #2


Sensors Storage Display Plugins


Connectivity Layer (HTTP, XMPP)

• Presence • Messaging • Registration • JDBC, Query

Cloud Services

Management Dashboards

Data Transformation (ESB, HL7)

Device Gateway (XMPP, ESB)

Healthcare Enterprise

Enterprise Data

Modern Connectivity Architecture

Plugin Container

Event Architecture

Inventory

Workflow

Notifications

Patient Context

Location Aware


Logical Connectivity Options

Wireless Communication

Transfer Protocol (WCTP)

IEEE 11073 (x73)

OMG Data Distribution Service

for Real-Time Systems (DDS)

Custom REST or SOAP Web Services

Advanced Message Queuing Protocol

(AMQP)

Extensible Messaging and

Presence Protocol (XMPP)

Simple Network Management

Protocol (SNMP)

Minimal Lower Layer Protocol

(MLLP) with HL7 X.12 over TCP/IP

WHY DDS? Elaboration of why Data Distribution Service (DDS) is recommended


Sophisticated communication interface

Object Management Group (OMG) standard

• Good industry support

• Multiple competing implementations provide choice

Supports real-time, deterministic data distribution

• Quality of Service (QoS) is built-in

• Dynamically scalable

• Static typing and low overhead

Used in safety-critical and performance-sensitive industries already

• Defense

• Avionics

• Nuclear

If we don’t use DDS we end up re-creating most of its features

• The functionality it provides is not optional in safety-critical systems

Why DDS?


Real-time protocol

Non-realtime (millisecond

resolution with best-effort delivery)

Realtime (microsecond

resolution with guarantees)

Why DDS?


Data centric with Quality of Service

Message centric

Data centric

Why DDS?

DDS QoS options: • Deadline • Destination Order • Durability • Group Data • History • Latency Budget • Lifespan • Liveliness • Ownership • Partition • Presentation • Reader Data Lifecycle • Reliability • Resource Limits • Time-Based Filter


Peer to Peer Publish / Subscribe

Hub/Spoke – high coupling Publish/Subscribe – low coupling

Why DDS?

Supports one-to-one, one-to-many, many-to-one, and many-to-many communications

iOS Android

PC App Mobile App Any others

Independent DB

Server or Phone


Member discovery protocol built-in (with stale endpoint detection)

Manual Discovery – gateway must be aware of all participants a priori

Auto Discovery – all devices can “discover” each other as required

Why DDS?

Gateway does not have to be modified when new members are installed.


Publish / Subscribe for Extensibility Why DDS?

iOS Android

PC App Mobile App Any others

Independent DB

Server or Phone

Independent DB


Easier Testing and Validation

• Encourage reusable testing and validation – Create system abstractions

– Create component abstractions

• Focus on data-oriented test scenarios

• Create data generators, loggers, and initiators for test scenarios

• Encourage automated testing from day 1

• Start using and building simulators for ecosystem validation

Why DDS?


Enable devices without gateway

• DDS, as a publish/subscribe data-oriented standard, does not require that all devices and gateways be defined and designed together.

• Roadmaps for different business units, products, and projects can remain aligned or diverge based on business requirements or schedules.

• Start DDS enabling devices now, even without finalizing the gateway strategy.

Why DDS?


Why not just IEEE 1073 / HL7 / …?

11073 DDS

Why DDS?

NEXT STEPS Getting started with the terminology


Do the hard stuff first

• Focus all attention on data interoperability, test beds, simulators, risk assessment, and physiologic evaluation tools first – Look at tools like ECGSyn (at physionet.org)

• Focus attention on general software architecture, languages, tools, etc. second

• Specify a “zero tolerance” policy to prevent creation of new software when open source software exists (or commercial software to some extent if it doesn’t create a success tax)

http://physionet.org/


Review ISO/IEEE 11073 Concepts

• Comprehend ISO/IEEE 11073:2004(E) Health Informatics - Point-of-care medical device communication, especially 10101 and 10201

– Part 10101: Nomenclature

– Part 10201: Domain Information Model (DIM)

– Part 20101: Application Profile - Base Standard

– Part 30200: Transport Profile - Cable Connected

– Part 30300: Transport Profile - Infrared Wireless


Primary IEEE 11073 Nomenclature

• “IEEE Nomenclature” is a data dictionary which is used to represent devices, measurements, body sites, alerts, etc. with common codes according to the methodology described in the European standard CEN ENV 12264, Medical informatics - Categorical structures of systems of concepts - Model for representation of semantics.

• The semantic links used for medical device differentiation are: “Base Concepts”, “Has Measured”, “Has Target”, and “Device Type”.

• Nine base concepts are identified such as analyzer, meter, regulator and pump. For each base concept, possible measurements are listed such as rate, concentration, and pressure. “Has Target” link focuses on body subsystems such as blood, heart and brain for each device type.


IEEE 11073 Base Concepts

Concept Devices, or the subsystems of more complex devices, that…

Analyzer Manipulate or interpret acquired data in order to produce derivative results.

Calculator Perform calculations upon raw or derived data.

Filter Filter particles through physical or chemical means.

Generator Generate physical quantities such as heat, moisture, electrical activity, etc.

Meter Perform mensuration or measurement functions on physical properties such

as current, electrical potential, flow, etc.

Monitor Both acquire data and analyze it such as a patient multiparameter monitor.

Pump Transfer a liquid or gas from a source or container.

Regulator Maintain or control the flow or parametric balance of gases, liquids,

electrical current, or other physiological analogues.

Stimulator Generate physical quantities such as heat, moisture, electrical activity, etc.)

System That consist of transducive, analytical, and therapeutic components, such as

anesthesia system and most ventilators.


IEEE 11073 Device Functionality

“Has Measured Property” • Concentration • Electrical Potential • Flow • Multi-Parameter • Negative • Oxy • Pressure • Rate • Resistance • Temperature • Volume

“Has Target” • Airway • Blood • Body • Brain • Gas • Heart • Infusion • Intra-Aorta • Lung • Multi-Gas • Muscle

• Physiologic • Renal • Resp • Skin/Tissue • Urine


Review HL7 Event Triggers

• Comprehend “Observation Reporting” section of the HL7 Messaging Standard, especially the unsolicited observation messages – Unsolicited Observation Message (Event R01) – Unsolicited Laboratory Observation Message (Event R21) – Query for Results of Observation (Events R02, R04) – Unsolicited Point-of-Care Observation Message - Place Order (Event

R30) – Unsolicited New Point-of-Care Observation Message - Search Order

(Event R31) – Unsolicited Pre-ordered Point-of-Care Observation (Event R32) – Unsolicited Specimen Oriented Observation Message (Event R22) – Unsolicited Specimen Container Oriented Observation Message (Event – R23) – Unsolicited Order Oriented Observation Message (Event R24)


Review IHE

• Comprehend “Integrating the Healthcare Enterprise” (IHE) guidance documents (IHE is not a standard but an “approach” to interoperability)

– Review 8 technical frameworks but focus on “Patient Care Devices (PCD)”

– Pay special attention to the Device Enterprise Communication (DEC)


Review OMG IDL

• Learn the Object Management Group’s Interface Definition Language (IDL), which is used to define the strongly-typed data for DDS messages

struct DeviceStatus { string deviceId; string serialNumber; short batteryStatus; string deviceStatus; } struct Temperature { float data; unsigned long sensorId; //key };

• The following primitive data types are supported by IDL: – char – octet – short – unsigned short – long – unsigned long – long long – unsigned long long – float – double – long double – boolean – enum – array and bounded sequence of the

above types – string


OMG IDL Examples

NOTE: device info is optional

struct BloodPressure

{

boolean valid;

long timeOfMeasurement;

long timeOfTransmission;

short systolicPressure;

short diastolicPressure;

short pulseRatePerMinute;

short meanArterialPressure;

}

NOTE: transmit time is optional

struct PulseOximeter

{

boolean valid;

long timeOfMeasurement;

long timeOfTransmission;

short SPO2;

short pulseRatePerMinute;

short pleth;

short signalQuality;

short signalAmplification;

}


Review OMG DDS Specification

• The Object Management Group’s Data Distribution Service (DDS) is a well defined specification; learn the following concepts: – Data-Centric Publish-Subscribe (DCPS)

• Domain • Domain Participant • Data Writer • Publisher • Data Reader • Subscriber • Topic

– Data Local Reconstruction Layer (DLRL)


Inventory Devices, Generated Data, Prepare IDL (focus on spec)

Focus on data spec, you’re creating a

central data model for all sensor data

Inventory all devices Inventory all sensors

within devices

Create directory of data generated by sensors in devices

Map directory of data to IEEE 11073 DIM and

nomenclature

For each sensor, create an IDL (“table” or “data type”) file using 11073

nomenclature

For each sensor, fill out data types (“fields”) based on 11073 DIM

Define DDS domain structure

Define DDS topics tied to specific data types


Review DDS Quality of Service (QoS)

• Most of the actual functionality in DDS surrounds the specification and configuration of QoS parameters

– Instead of coding timing, latency, durability, and other similar details inside your code you create QoS configurations and let the DDS implementation take care of it for you


Review DDS Products & Vendors

• OpenDDS -- Open source, not binary compatible with other vendors

• OpenSplice – Open source with commercial support, binary compatible with RTI (less expensive than RTI, no deployment royalties)

• RTI – Commercial with support, binary compatible with OpenSplice (a bit more expensive, requires royalties, with more QoS and tooling support than OpenSplice)


Review DO-178B/C and formal methods / models • Formal methods are a class of

mathematically based techniques used for the specification, development, and verification of software.

• Formal methods: – Are most helpful with large and complex code

containing advanced algorithms. – Are used to prove that software meets

requirements. – Speed up the testing and validation phases. – Enable software engineers to look at the parts

as well as the whole of the code, and help get the software verification process started earlier.

– Help verify software components as they are developed, which reduces the need for re-verification during integration and testing, which typically cannot start until the software is nearly complete.

• Formal methods / models can help catch the following types of common defects: – Uninitialized data variables – Out-of-bounds array access – Null pointer dereference – Incorrect computation (for example, divide by

zero) – Concurrent access to shared data – Illegal type conversion – Memory leaks – Unintentional non-terminating loops

Source: http://en.wikipedia.org/wiki/DO-178C

Software Considerations in Airborne Systems

http://en.wikipedia.org/wiki/DO-178Chttp://en.wikipedia.org/wiki/DO-178Chttp://en.wikipedia.org/wiki/DO-178Chttp://en.wikipedia.org/wiki/DO-178C

QUESTIONS? Thank You.