1.
EVOLUTION OF MEDICAL STANDARDS
The evolution of medical standards refers to the historical and ongoing development
of standardized practices, protocols, regulations, and technologies in healthcare. These
standards are crucial to ensure patient safety, interoperability, quality care, data accuracy,
and global collaboration.
Early Medical Practices (Before 19th Century)
• Lack of formal standards: Medicine was based on local traditions and beliefs.
• Practices varied widely between regions and practitioners.
• Documentation was minimal or inconsistent.
Foundations of Modern Medical Standards (19th–Early 20th Century)
• Establishment of medical licensing: Countries began regulating who could practice
medicine.
• Standardization of education: Medical schools started using formal curricula.
• Rise of evidence-based medicine: Clinical decisions began shifting from anecdotal to
scientific basis.
• Medical coding origins: Early efforts to classify diseases (e.g., Bertillon Classification
→ ICD).
Mid-20th Century – Institutional and Global Standardization
• World Health Organization (WHO) (1948): Helped create global health standards,
including the International Classification of Diseases (ICD).
• Formation of regulatory bodies: E.g., FDA (USA), MHRA (UK), and CDSCO (India)
for drug/device safety.
• Ethical guidelines: Nuremberg Code (1947), Declaration of Helsinki (1964) – for
research ethics.
Late 20th Century – Technological Integration and Digital Health
• Health informatics emerged: Leading to data standardization (e.g., HL7, DICOM).
• Electronic Health Records (EHRs): Standards like HL7, SNOMED CT, and LOINC
were developed for data interoperability.
• Clinical practice guidelines (CPGs): Issued by medical associations for evidence-
based care.
21st Century – Interoperability, Patient-Centricity, and Global Health Initiatives
• Widespread adoption of EHRs and digital health tools.
• FHIR (Fast Healthcare Interoperability Resources): A modern standard for
exchanging healthcare data digitally.
• Medical device standards: ISO 13485 for quality management, IEC 60601 for
electrical safety.
• AI and telemedicine standards: Ongoing efforts to regulate AI diagnostics, remote
care (e.g., WHO Digital Health Guidelines).
• GDPR & HIPAA: Data privacy standards in healthcare (EU & US).
2. IEEE 11073
IEEE 11073 is a family of standards developed by the Institute of Electrical and
Electronics Engineers (IEEE) to ensure interoperability and seamless communication
between personal health devices, clinical equipment, and healthcare information systems.
These standards are essential for mobile health (mHealth), remote patient monitoring, and
personal health informatics. It defines standardized data formats, communication protocols,
and device specializations to support plug-and-play integration, enabling real-time data
exchange across diverse healthcare environments. It applies to devices such as blood pressure
monitors, pulse oximeters, thermometers, infusion pumps, and ventilators, and ensures
smooth connectivity with healthcare IT infrastructures like gateways and Electronic Health
Record (EHR) or Electronic Medical Record (EMR) systems, thereby improving data
accuracy and management efficiency.
Architecture of IEEE 11073
The architecture of IEEE 11073 is structured to facilitate interoperable communication
between medical devices and healthcare systems through a layered, object-oriented approach.
It consists of three key components:
1. Domain Information Model (DIM)
• Represents the logical structure of the data within a medical device.
• Organizes data into objects, such as vital signs, measurements, and device attributes.
• Uses a hierarchical model with classes like Medical Device System, Metric, and
Numeric.
• Enables standardized representation of physiological parameters (e.g., heart rate,
temperature).
2. Service Model
• Defines the communication services used to interact with and control devices.
• Includes:
o GET/SET operations for reading or modifying data.
o Event reporting for notifying changes (e.g., alarm triggered).
o Action services for executing specific device commands.
• Supports both real-time data transmission and asynchronous communication.
3. Communication Model
• Specifies how messages are exchanged between devices and managers (e.g., PCs,
smartphones, gateways).
• Utilizes the Agent-Manager paradigm:
o Agent: The medical device that collects and sends data.
o Manager: The system (like a gateway or EHR) that receives, displays, or
stores the data.
• Common transport protocols:
o USB
o Bluetooth Health Device Profile (HDP)
o Zigbee
o TCP/IP (for clinical settings)
IEEE 11073 Protocol Stack
The IEEE 11073 protocol stack defines how health data is structured, exchanged, and
transported between personal health devices (agents) and managing systems (managers). It
provides a layered architecture that ensures interoperability, modularity, and scalability
across different health monitoring applications.
1. Application Layer
• IEEE 11073-10201 (DIM): Defines the object-oriented data model for representing
device data (e.g., blood pressure, heart rate).
• IEEE 11073-10101 (Nomenclature): Standard terms and codes for observations,
units, and device types.
• Service Model: Defines communication services (e.g., event reporting, data access).
2. Optimized Exchange Protocol Layer
• IEEE 11073-20601:
o Core protocol managing association, configuration, data exchange, and
disassociation.
o Uses ASN.1 encoded messages and Application Protocol Data Units
(APDUs).
o Ensures device capabilities are communicated and data flows reliably.
3. Transport Profile Layer
• Specifies how data is transmitted between agent and manager over a given medium.
• Common protocols include:
o Bluetooth Health Device Profile (HDP) – used with IEEE 11073 over
Bluetooth.
o USB Personal Healthcare Device Class (PHDC).
o Zigbee Health Care Profile – for low-power mesh networking.
o NFC – for short-range data exchange.
4. Physical Layer
• The actual hardware connection or wireless interface (e.g., Bluetooth radio, USB port,
Zigbee antenna).
Categories of IEEE 11073 Standards
Category Description
11073-10101 Nomenclature for consistent naming of observations, units, metrics
11073-10201 Domain Information Model (DIM) for device data structuring
Personal Health Device Specializations (e.g., for thermometer,
11073-104xx
glucose meter)
11073-20601 Optimized Exchange Protocol for personal health devices
11073-20702 Application profile for Bluetooth HDP
Examples of IEEE 11073-104xx Standards
Standard Device
11073-10406 Pulse oximeter
11073-10407 Blood pressure monitor
11073-10408 Thermometer
11073-10417 Glucose meter
11073-10441 Weighing scale
11073-10442 Medication monitor
3. HL7 (Health Level Seven)
HL7, stands for Health Level Seven International, is a set of international standards for
the exchange, integration, sharing, and retrieval of electronic health information. It enables
communication between different healthcare systems, such as hospitals, clinics, laboratories,
pharmacies, and insurance providers, ensuring interoperability and consistency in clinical and
administrative data.
The term "Level Seven" refers to the 7th layer (Application Layer) of the OSI (Open
Systems Interconnection) model. This layer supports application-level functions like data
exchange and user interface operations—exactly where HL7 operates
Goals of HL7
• To facilitate the standardized exchange of health information.
• To ensure interoperability between disparate healthcare IT systems (EHRs, LIS, RIS,
HIS).
• To support clinical workflows, billing, reporting, and patient care coordination.
Main HL7 Standards
Standard Description
Widely used messaging standard in hospitals (lab results,
HL7 v2.x
ADT, billing). Flexible and text-based (pipe `
XML-based, more structured and consistent, but less
HL7 v3
adopted due to complexity.
CDA (Clinical Document Standard for encoding clinical documents (e.g., discharge
Architecture) summaries, imaging reports).
CCD (Continuity of Care A CDA-based document for summarizing patient care (used
Document) in the U.S.).
Modern standard using RESTful APIs and JSON/XML.
FHIR (Fast Healthcare
Lightweight and web-friendly—rapidly growing in
Interoperability Resources)
adoption.
Working of HL7
The working of HL7 revolves around enabling structured, standardized communication
between different healthcare systems (like EHRs, labs, radiology, billing systems, etc.) so
they can exchange patient-related data efficiently and accurately.
1. HL7 Message Structure
HL7 operates primarily through messages — each one representing a healthcare event (e.g.,
patient admission, lab result, discharge).
Each message:
• Has a message type (e.g., ADT for Admission/Discharge/Transfer, ORU for
Observation Result).
• Is composed of segments, which are lines of information.
• Each segment is made up of fields, separated by pipes |.
• Fields may contain components and subcomponents separated by ^ and &.
Example: HL7 v2.x Message for Lab Result (ORU^R01)
MSH|^~\&|LAB|XYZ_HOSPITAL|EHR|XYZ_EHR|20250630||ORU^R01|123456|P|2.3|
PID|1||789456^^^XYZ_HOSPITAL^MR||Doe^John||19800101|M|
OBR|1||1234|TEST^Blood Test^L||
OBX|1|NM|GLU^Glucose Level^L||105|mg/dL|70-110|N|||F
Segment Meaning
MSH Message Header
PID Patient Identification
OBR Observation Request
OBX Observation Result
2. Roles Involved
Role Description
Sending System The system that creates and sends the HL7 message (e.g., a lab system
(Source) sending test results).
Receiving System The system that receives and interprets the message (e.g., EHR system
(Target) updating patient record).
A middleware that transforms, routes, and validates HL7 messages
Interface Engine
between systems. Examples: Mirth Connect, Rhapsody.
3. Workflow Example: Patient Admission (ADT Message)
1. Registration Clerk enters new patient data in the hospital information system (HIS).
2. HIS generates an HL7 ADT^A01 (Admit) message.
3. The message is sent via an interface engine to the EHR and other systems like billing
and pharmacy.
4. All connected systems update their records with the same patient info.
4. Types of HL7 Messages
Message Type Purpose
Patient movements (admit, discharge, transfer,
ADT (Admit Discharge Transfer)
update).
ORM (Order Message) Orders for tests, medications, procedures.
ORU (Observation Result) Lab results, vital signs, diagnostic findings.
DFT (Detailed Financial Transaction) Billing and financial records.
SIU (Scheduling Information
Appointments and scheduling.
Unsolicited)
5. Communication Protocols Used
HL7 messages are exchanged over:
• MLLP (Minimal Lower Layer Protocol) – for TCP/IP transmission.
• Web services (SOAP/REST) – used more in HL7 FHIR.
• File drop, shared DB, or APIs – in older or custom implementations.
6. HL7 Versions and Working Differences
Version How it Works
HL7 v2.x Text-based, delimited, real-time messaging for clinical events. Widely adopted.
HL7 v3 XML-based messages with strict modeling (less practical due to complexity).
Web-based using RESTful APIs and JSON/XML for modern, app-friendly data
HL7 FHIR
exchange (e.g., mobile apps, cloud EHRs).