Transcript Chapter 3 Health Information Interchange

‫استانداردهای تبادل الکترونیکی اطالعات پزشکی‬
The Electronic Data Interchange Standards for
Medical Data
Dr. Ali M. Hadianfard
Faculty member of AJUMS
http://www.alihadianfard.info/download.html
2
Further reading
• Biomedical informatics computer applications in health care and biomedicine (3rd edition),
Edward H. Shortliffe, 2006 (chapter 7).
• Principles of Health Interoperability HL7 and SNOMED, Tim Benson, 2010 (whole book).
• From Patient Data to Medical Knowledge The Principles and Practice of Health
Informatics, Paul Taylor, 2006 (chapter 9).
• SNOMED user guide, http://www.ihtsdo.org/fileadmin/user_upload/doc/en_us/ug.html
•
HL7 organization, the official website, http://www.hl7.org/
• Medical imaging informatics, Alex A.T. Bui and Ricky K. Taira, 2010 (chapter 3).
• PACS and Imaging Informatics Basic Principles and Applications, H. K. Huang, 2010
(chapter 9).
‫‪3‬‬
‫استاندارد‬
‫در لغت به معنای قاعده یا اصل می باشد‪.‬‬
‫ی که‌ از طرف عموم‪ ،‬سنت‪ ،‬تصمیم سازمانی یا قرارداد‬
‫هر چیز ‌‬
‫بعنوان مبنا یا پیمانه ای ‌برای‌ اندازه‌گیری‌ یا مقایسه‌‬
‫پذیرفته ‌شود‪.‬‬
‫‪4‬‬
‫اهمیت وجود استاندارد‬
‫ایجاد سازگاری‬
‫برقراری هماهنگی‬
‫تضمین امنیت‬
‫گسترش ارتباطات‬
‫توسعه کمی و کیفی‬
‫‪5‬‬
‫توسعه استانداردها‬
‫استانداردهای از طریق‪:‬‬
‫– برآورده نمودن منافع مشترک افراد یا مؤسسات‬
‫– غیر رسمی بوسیله شرکتها یا مؤسسات بزرگ‬
‫– رسمی با تصویب قوانین و آئینامه ها بوسیله مراجع دولتی و قانونی‬
‫– توافق بین افراد‪ ،‬گروهها و مؤسسات محلی و بین املللی‬
‫ایجاد و توسعه می یابد‪.‬‬
6
‫سطوح موسسات استاندارد‬
National
‫سطح ملی‬
.I
.‫ به تصویب رسید‬1339 ‫مؤسسه استاندارد و تحقیقات صنعتی ایران (ماتصا) در سال‬
Institute of Standards and Industrial Research of Iran (ISIRI)
American National Standards Institute (ANSI)
Regional
‫ سطح منطقه ای‬.II
European Committee for Standardization (CEN), Brussels, Belgium
International
International Organization for Standardization (ISO)
(1947, Geneva, Switzerland)
‫ سطح جهانی‬.III
‫‪7‬‬
‫تبادل الکترونیکی داده ها‬
‫)‪Electronic Data Interchange (EDI‬‬
‫انتقال داده ها یا مستندات الکترونیکی از یک سیستم (کامپیوتر) به سیستم دیگر‪.‬‬
‫بطور مثال انتقال داده ها با استفاده از شبکه های خصوص ی‬
‫‪(VAN) Value Added Network‬‬
‫و یا اینترنت‪.‬‬
‫‪ ASC X12‬مجموعه ای از استاندارهایی است که برای تبادل الکترونیکی داده های‬
‫مستندات تجاری‌(معامالتی) نظیر فاکتورهای فروش ‪ ،‬بین شرکتها استفاده می شود و توسط‬
‫مؤسسه استاندار ملی آمریکا پذیرفته شده است‪ .‬در حال حاضر ‪ 300‬نوع سند در آن‬
‫استاندارد شده است‪.‬‬
‫‪8‬‬
‫زیر ساختهای انتقال اطالعات پزشکی‬
‫انتقال الکترونیکی اطالعات پزشکی نیاز به ‪ 4‬گروه زیر ساخت اصلی دارد‪:‬‬
‫‪ (1‬زیر ساختهای تکنولوژیک (فنی)؛ شامل تجهیزات پزشکی دیجیتال‪ ،‬سخت افزار کامپیوتر‪ ،‬شبکه های‬
‫کامپیوتری‪ ،‬سیستم های عامل و نرم افزارهای کاربردی‬
‫‪ (2‬استانداردهای لغات و واژگان پزشكي‬
‫به طورمثال از طريق‬
‫)‪(Medical Vocabulary‬‬
‫؛‬
‫‪SNOMED CT‬‬
‫‪ (3‬استانداردهای تبادل اطالعات‬
‫پزشکی؛ نظیر ‪HL7‬‬
‫‪ (4‬زیر ساختهای حفظ امنیت داده ها؛ شامل حفظ محرمانگی و جلوگیری از دسترس ی غیر مجاز نظیر‬
‫استانداردهای )‪Secure Sockets Layer (SSL), Transport Layer Security (TLS‬‬
‫البته سایر زیر ساختها نظیر زیر ساختهای فرهنگی‪ ،‬اجتماعی‪ ،‬اقتصادی و سیاس ی بطور غیر مستقیم مؤثر می‬
‫باشند‪.‬‬
9
The standardization of medical terminology
Clinicians and organizations use different clinical terms that mean the same
thing. For example, the terms heart attack, myocardial infarction, and MI
may mean the same thing to a cardiologist, but, to a computer, they are all
different. There is a need to exchange clinical information consistently
between different health care providers, care settings, researchers and others
because medical information is recorded differently from place to place (on
paper or electronically), a comprehensive, unified medical terminology
system is needed as part of the information infrastructure.
The terminology enables clinicians, researchers and patients to share
comparable data.
10
SNOMED CT
SNOMED CT is a comprehensive clinical terminology
Originally created by the College of American Pathologists (CAP)
and, as of April 2007, owned, maintained, and distributed by
the International Health Terminology Standards Development
Organization (IHTSDO, http://www.ihtsdo.org), a non-for-profit
association in Denmark.
The CAP continues to support SNOMED CT operations under
contract to the IHTSDO and provides SNOMED-related products
and services as a licensee of the terminology.
11
SNOMED Predecessors
• SNDO (Standard Nomenclature of Diseases and Operations) •
•
•
•
•
•
•
•
Academy of Medicine, 1961
SNOP (Systematic Nomenclature for Pathology)- 1965
SNOMED (Systematized Nomenclature of Medicine)- 1974
SNOMED II - 1979
SNOMED Version 3.0 (Systematized Nomenclature of Human
and Veterinary Medicine) - 1993
LOINC (Logical Observation Identifiers Names and Codes)
codes integrated into SNOMED - 1997
SNOMED Version 3.5 - 1998
SNOMED RT (Systematized Nomenclature of MedicineReference Terminology)- 2000
SNOMED CT (Systematized Nomenclature of Medicine-Clinical
Terms) - First release January 2002
12
SNOMED CT - Continue
SNOMED CT has been created by combining SNOMED RT and a
computer based nomenclature and classification known as Clinical
Terms Version 3 (CTV3 ) developed by the National Health Service
of the United Kingdom, formerly known as Read Codes Version 3
Over a period of 40 years SNOMED has evolved from a pathology-
centric terminology distributed and used in print format to a
comprehensive clinical terminology, which is only available in
electronic format and needs to be integrated with clinical applications
software.
13
14
SNOMED CT - Continue
SNOMED CT is
A clinical healthcare terminology
A resource with comprehensive, scientifically-validated content
essential for electronic health records
A terminology that can cross-map to other international standards
already used in more than fifty countries
SNOMED CT is both a coding scheme, identifying concepts and
terms, and a multidimensional classification, enabling concepts to be
related to each other, grouped, and analyzed according to different
criteria.
15
SNOMED CT - Continue
SNOMED CT provides the core general terminology for the
electronic health record (EHR) and contains more than 311,000
active concepts with unique meanings and formal logic-based
definitions organized into hierarchies, 990,000 English
descriptions, and 1.38 million relationships. When implemented
in software applications, SNOMED CT can be used to represent
clinically relevant information consistently, reliably and
comprehensively as an integral part of producing electronic health
records.
16
SNOMED CT - Continue
SNOMED CT is a systematically organized computer process able collection
of medical terminology covering most areas of clinical information such as diseases,
findings, procedures, microorganisms, pharmaceuticals and etc.
It allows a consistent way to index, store, retrieve, and aggregate clinical data across
specialties and sites of care. It also helps organizing the content of medical records,
reducing the variability in the way data is captured, encoded and used for clinical care
of patients and research.
It is a mistake to assume that SNOMED CT applies to human medicine only. Many
codes are applicable to both human and non-human subjects. Some codes are
applicable to non-human subjects only, and these non-human codes are identified in
the non-human subset provided with the International Release.
17
SNOMED CT components
1. Concept Codes: numerical codes that identify clinical terms, primitive or defined,
organized in hierarchies. The SCTID (SNOMED CT Identifiers) is an integer
between 6 and 18 digits long. The sequence of digits in a Concept Identifier does
not convey any information about the meaning or nature of the Concept. The
meaning of Concept is represented in human-readable forms by Descriptions
and in a computer processable form by Relationships with other Concepts. For
example 22298006 means myocardial infarction (MI).
2. Descriptions: textual descriptions of Concept Codes
3. Relationships: relationships between Concept Codes that have a related meaning
Reference Sets: used to group Concepts or Descriptions into sets, including
reference sets and cross-maps to other classifications and standards
18
Top Level Concepts
• Clinical finding
• Linkage concept
• Procedure
• Physical force
• Observable entity
• Event
• Body structure
• Environment or geographical location
• Organism
• Social context
• Substance
• Situation with explicit context
• Pharmaceutical / biologic product
• Staging and scales
• Specimen
• Physical object
• Special concept
• Qualifier value
• Record artifact
19
Concepts
20
Example of descriptions
Some of the Descriptions associated with ConceptId 22298006:
Fully Specified Name: | Myocardial infarction (disorder) | DescriptionId
751689013
Preferred term: Myocardial infarction DescriptionId 37436014
Synonym: Cardiac infarction DescriptionId 37442013
Synonym: Heart attack DescriptionId 37443015
Synonym: Infarction of heart DescriptionId 37441018
Each of the above Descriptions has a unique DescriptionId, and all of these
Descriptions are associated with a single Concept (and the single ConceptId
22298006).
21
Relationships
Each concept in SNOMED CT is logically defined through its
relationships to other concepts.
| is a | relationships are also known as "Supertype - Subtype
relationships " or "Parent - Child relationships ". | is a | relationships
are the basis of SNOMED CT 's hierarchies. A concept can have
more than one | is a | relationship to other concepts.
An attribute Relationship is an association between two concepts that
specifies a defining characteristic of one of the concepts (the source of
the Relationship). Each Attribute Relationship has a name (the type of
Relationship) and a value (the destination of the Relationship)
22
Examples of relationships
23
SNOMED CT guides
1) The SNOMED CT User Guide
2) Technical Reference Guide(TRG)
3) Technical Implementation Guide (TIG)
They are three key documents describing SNOMED CT in detail.
24
Standards Development Organizations (SDOs)
ANSI-accredited SDOs have responsibility for:
HL7 focuses on the domain of clinical and administrative data.
Pharmacy (NCPDC)
Medical devices (IEEE)
Imaging (ACR/NEMA)
Insurance (claims processing) transactions (X12)
Dentistry (ADA)
‫‪25‬‬
‫‪HL7‬‬
‫در تالش ی گروهی توسط ارائه کنندگان‬
‫در سال ‪‌ 1986‬‬
‫)‪‌ :HL-7(Health Level 7‬‬
‫مراقبت سالمت ‌و ارائه کنندگان تکنولوژی ایجاد شد‪ .‬استانداردی برای تبادل اطالعات بالینی و‬
‫دیگر اطالعات (پذیرش‪ ،‬ترخیص‪ ،‬انتقال‪ ،‬دستورات پزشک‪ ،‬اقدامات‪ ،‬نتایج آزمایشات ‌و‬
‫انواع ‌‬
‫ی است‪.‬‬
‫اطالعات مالی) بین سیستمهای کامپیوتر ‌‬
‫‪(For Exchanging, Integrating, Sharing, and Retrieving electronic health‬‬
‫)‪information.‬‬
‫اکنون‌ مورد توافق بیش از ‪ 55‬کشور‌ ‌از قبیل آمریکا‪ ،‬کانادا‪ ،‬استرالیا‪ ،‬آملان‪ ،‬هلند‪ ،‬ژاپن‪،‬‬
‫نیوزیلند و ‪ ...‬می باشد‪.‬‬
‫استاندار ملی آمریکا می باشد‪.‬‬
‫‌‬
‫در زمره موسسات‬
‫‪‌ HL7‬‬
‫نام ‪‌ HL7‬بر گرفته ‌از الیه هفتم مدل مرجع ‪ ISO/OSI‬است‪.‬‬
‫‪26‬‬
‫مدل مرجع ‪OSI‬‬
‫‪Open System Interconnection Reference Model‬‬
‫یک الگوی‌ مرجع برای ایجاد شبکه ‌و برقراری‌ ارتباط بین کامپیوترها می باشد که توسط ‪ISO‬‬
‫توسعه یافته است‪‌ .‬از هفت سطح (الیه) تشکیل شده است‪ .‬الیه های زیرین جنبه سخت‬
‫باالتر جنبه نرم افزاری‌ دارند‪ .‬الیه های باالیی ‌بر روی تبادل پیامها‬
‫‌‬
‫افزاری‌ (فیزیکی) ‌و الیه های‬
‫متمرکز شده اند‪.‬‬
‫‌‬
‫بین کاربران ‌و برنامه های کاربردی‬
‫اليه هفتم با سيستم عامل ‌و يا برنامه هاي کاربردي ارتباط دارد‪ .‬کاربران با استفاده ‌از نرم افزارهاي‬
‫قادر به انجام عمليات مرتبط با شبکه خواهند بود‪ .‬اين اليه‪ ،‬محتواي اطالعات را‬
‫کاربردي متفاوت ‌‬
‫مشخص مي كند ‌و انتقال آن‌ها بین برنامه هاي كاربردي را فراهم می‌کند‪ .‬مث ‌ال کاربران مي توانند اقدام‬
‫در این سطح قر ‌ار‬
‫به خواندن پيام‪ ،‬ارسال پيام و ‪ ...‬نمايند‪ .‬پروتکلهایی نظیر‪‌ HTTP, FTP , HL7‬‬
‫می گیرند‪.‬‬
27
OSI Model
Data unit
Function
7. Application
Network process to application
6. Presentation
Data representation, encryption and
decryption
5. Session
Inter host communication
Segments
4. Transport
End-to-end connections and reliability,
Flow control
Packet
3. Network
Path determination and logical addressing
Frame
2. Data Link
Physical addressing
Bit
1. Physical
Media, signal and binary transmission
Data
Host
layers
Media
layers
Layer
28
HL7 standards
HL7 develops:
Conceptual Standards (e.g., HL7 RIM)
Document Standards (e.g., HL7 CDA)
Application Standards (e.g., HL7 CCOW)
Messaging Standards (e.g., HL7 v2.x and v3.0)
29
HL7 ‫ویرایشهای‬
Version 2 (V2.x) : 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1 and 2.6, 2.7
originally created in 1987.
All 2.x versions are backwards-compatible with earlier versions. This
means that an older application can receive and process messages from
newer applications using newer HL7 versions.
HL7 v2.x mostly uses a textual, non-XML encoding syntax.
Version 3 (V3): 3.0, first released in late 2005.
The V3 is not backwards compatible with V2.
30
HL7 V2.x
The HL7 Standard covers messages that exchange information in the general areas of:
• Patient Demographics
• Patient Charges and Accounting
• Patient Insurance and Guarantor
• Clinical Observations
• Encounters including Registration, Admission, Discharge and Transfer
• Orders for Clinical Service (Tests, Procedures, Pharmacy, Dietary and Supplies)
• Observation Reporting including Test Results
• The synchronization of Master Files between systems
• Medical Records Document Management
• Scheduling of Patient Appointments and Resources
• Patient Referrals—Specifically messages for primary care referral
• Patient Care and problem-oriented records.
31
HL7 V2.x Messaging
HL7 v2.x messages use a human-readable (ASCII), non-XML encoding syntax based
on segments (lines) and one-character delimiters. Segments have composites
(fields) separated by the composite delimiter. A composite can have sub-composites
(subcomponents) separated by the sub-composite delimiter, and sub-composites
can have sub-sub-composites (subcomponents) separated by the sub-sub-composite
delimiter. The default delimiters are vertical bar or pipe (|) for the field separator,
caret (^) for the component separator, and ampersand (&) for the subcomponent
separator. The tilde (~) is the default repetition separator. The first field (composite)
in each segment contains the 3-character segment name. Each segment of the
message contains one specific category of information. Every message has Message
Header (MSH) as its first segment, which includes a field that identifies the message
type. The message type determines the expected segment names in the message. The
segment names for a particular message type are specified by the segment grammar
notation used in the HL7 standards.
32
Example of HL7 V2.x Laboratory Message
MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4<cr>
PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^
^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520<cr>
OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||
555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD<cr>
OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F<cr>
The PID (Patient Identification) segment contains the demographic
The
Header)
segmentsegment
contains identifies
the message
type,
The MSH
OBR
(Observation
Request)
the
observation
The
OBX(Message
(Observation)
segment
contains
the results
of in
thethis case,as
information of the patient. Eve E. Everywoman was born on 1962-03-20 and
ORU^R01,
which identifies
message type and the
trigger
event. The
sender
it was orignally
ordered:the
15545^GLUCOSE.
The
observation
was
observation:
182OH.
mg/dl.
lives in Statesville
Her patient ID number (presumably assigned to her by
is
the
GHH
Lab
in
ELAB-3.
The receiving
is the
OE system
ordered by Particia Primary
MD andapplication
performed
by GHH
Howard
the Good Health Hospital) is 555-44-4444.
located in BLDG4. The message was sent on 2002-02-15 at 09:30. The MSH
Hippocrates MD.
segment is the initial segment of the message structure.
33
HL7 V3
HL7
Version
3
is
mainly
used
in
large
interoperability projects, such as the National
Health Service (NHS) Connecting for Health
program in the UK, Health InfoWay in Canada, etc.
HL7 messages are XML (extended markup language)
documents, which look somewhat similar to HTML.
34
Why HL7 V3?
HL7 V3 is designed to be
Comprehensive in scope
Complete in detail
Extensible as requirements change
Up-to-date
Model-based
Conformance testable
Technology-independent
35
HL7 RIM
The Reference Information Model (RIM) is the
cornerstone of the HL7 Version 3 development
process. The HL7 RIM specifies the grammar of HL7
messages and, specifically, the basic building blocks
of the language and their permitted relationships.
Structural attributes are used to specify more
precisely what each RIM class means when used in a
message.
36
The RIM structure
The underlying structure of the RIM is based on six core
classes:
• Act: represents any action that occurs and is documented
throughout the process as health care is managed and
provided.
• Entity: represents any physical thing and/or beings that are
of interest to, and take part in health care.
• Role: describes the task that Entities play/provide as they
participate in health care acts.
• Participation: refers to an association between a Role and
an Act.
• Act-relationship: is the association between a pair of Acts.
• Role-link: is the connection that may exist between two
roles that expresses a dependency between those roles.
37
Backbone Class: Act
Structural attribute (Example)
The structural attribute
classCode determines
whether an Act is an
observation (such as tests,
diagnoses, and examination
findings), an encounter, or a
procedure.
moodCode indicates
whether an Act has
happened (an event),
is a request for something to
happen, a goal, or a criterion.
For example, “weight =
100kg” is an observation
event; “measure weight
daily” is a request; “reduce
weight to 80Kg” is a goal and
“if weight is greater than
80Kg” is a criterion.
Act:
A record of something that is being done, has
been done, can be done, or is intended or
requested to be done.
Act has the following sub-classes:
Account
ControlAct
DeviceTask
DiagnosticImage
Diet
FinancialContract
FinancialTransaction
InvoiceElement
Observation
Participation
PatientEncounter
Procedure
PublicHealthCase
SubstanceAdministration
Supply
WorkingList
38
Backbone Class: Entity
Structural attribute
(Example)
Person has the
attributes inherited
from Entity and Living
Subject as well
as its own.
name is an attribute of
Entity, while sex
(administrativeGenderCode), date of birth
(birthTime), and date
of death
(deceasedTime) is each
an attribute
of LivingSubject.
Entity:
cover the whole universe of:
• Living things such as people, animals, plants,
and microorganisms
• Nonliving things such as places, manufactured
items, and chemical substances
• Abstract things such as organizations
Entity has the following sub-classes:
Container
Device
LanguageCommunication
LivingSubject
ManufacturedMaterial
Material
NonPersonLivingSubject
Organization
Person
Place
39
Backbone Class: Role
Roles:
Structural attribute
(Example)
A responsibility or part played by an entity (e.g. Person in a role
of patient, employee, etc.).
Attributes for person
are patient, name,
address, and patient id
• People, such as patient, practitioner, or employee
• Places, such as hospital, home, clinic, or place of birth
• Organizations, such as care provider, employer, or
supplier
• Things, such as drug, instrument, or computer system
• Responsible entities, such as parent, employer, or
manufacturer
There is a wide variety of Roles, which can be played by:
Role has the following sub-classes:
Access
Employee
LicensedEntity
Patient
40
Backbone Class: ActRelationship
Structural attribute (Example)
typeCode describes the type of
association between Acts:
• Composition comprises
entries
• Discharge summary
documents a hospital visit
• Test report fulfills a test
request
• Discharge summary refers
to a referral
• Final report replaces a
preliminary report
ActRelationship:
A directed association between a source
Act and a target Act. A point from a later
instance to a earlier instance OR point
from collector instance to component
instance.
ActRelationship has no sub-classes.
41
Backbone Class: Participation
Structural attribute (Example)
Type Code describes the
type of association between
an Act and each
participating Role:
Performer of act (surgeons,
observers, practitioners)
Participation:
An association between an Act and a Role with
an Entity playing that Role.
Participation has the following sub-class:
ManagedParticipation
42
Backbone Class: RoleLink
Example
An employee of type
"manager" may have
authority over employees of
type "analyst" which would
be indicated by a role link
for "direct authority".
RoleLink:
A connection between two roles expressing a
dependency between those roles.
RoleLink has no sub-classes.
43
Diagram Notation
HL7 uses a special graphical notation:
Each Act is represented as a red rectangle
Role as a yellow rectangle
Entity as a green rectangle
ActRelationship is usually shown as pink (salmon), arrow-shaped pentagon
Participation as a cyan (light blue) pentagon
RoleLink as a light yellow pentagon.
44
HL7 CDA
The CDA (Clinical Document Architecture) provides an exchange model for
clinical documents (such as discharge summaries and progress notes) and
brings the healthcare industry closer to the realization of an electronic medical
record. By leveraging the use of XML, the HL7 RIM and coded vocabularies, the
CDA makes documents both machine readable and human readable.
Release 1, published in 2000, is a simple standard, describing a header and
body.
Only the header is based on the HL7 V3 RIM, while the body uses a variety of
human-readable non-XML formats such as text or images.
Release 2, published in 2005, is more complex and both the header and the
body are based on the HL7 V3 RIM, allowing fine granularity of structured
data. The body may be non-XML (providing backward compatibility to
Release 1) or it may be organized into one or more sections, which may have
structured entries.
45
The properties of document
The CDA defines a clinical document as having the following
characteristics:
− Persistence: While it exists, it remains a single coherent whole.
− Stewardship: At any time, some body or organization is responsible for
looking after it.
− Authentication: Each document may be signed, physically or
electronically.
− Context and Wholeness: : Each document is complete and whole in
itself, including context information, such as who created it, when, where,
and for what purpose.
− Human readability: Meaning, as perceived by the human reader, is
paramount.
46
HL7 CCOW
Clinical Context Object Workgroup (CCOW), more commonly known as Clinical
Context Management or Health Level Seven Context Management Standard (CMS) , is an
interoperability specification for visual integration of applications that allows users to
experience an integrated computer-user session on the desktop. The CCOW standard
provides a mechanism for applications to share information so that they appear to
behave as a single system. This shared information is known as the context. The CCOW is
a standard protocol designed to enable disparate applications to share user context and
patient context in real-time, and at the user-interface level. To allow clinical applications
to share information at the point of care. This means that when a clinician signs onto one
application within a CCOW environment, and selects a patient, that same sign-on is
simultaneously executed on all other applications within the same environment, and the
same patient is selected in all the applications, saving clinician time and improving
efficiency. The CCOW offers a series of recommendations that, when followed by
application developers will produce a cohesive and uniform set of CCOW-compliant
behaviors.
47
An example of using the HL7-CCOW
Here would be a step-by-step example of a CCOW exchange:
1) The computer boots up and the medical applications load.
2) Each application logs into CCOW using its secret passcode (and unique application name).
3) The compliant application displays a login prompt, and the user logs in as “Mary Jane”.
4) Mary Jane has a “CCOW ID”. Let us assume that her CCOW ID is “MJane”.
5) The compliant application notifies the CCOW vault that “MJane” is now logged in.
6) Once CCOW verifies that “MJane” is a valid CCOW user, the vault notifies all the other
applications that “MJane” is logged in.
7) All of the other applications realize that the CCOW ID “MJane” is referring to “Mary Jane”
(because they have been configured as such). They login “Mary Jane” automatically.
8) The transaction is complete. All of the applications running on the machine have been
automatically logged in as “Mary Jane”.
48
.‫منتشر شد‬
‌
1993 ‫در سال‬
‌ ‫ توسط کالج رادیولوژی آمریکا ‌و انجمن ملی سازندگان ابز ‌ار الکترونیک‬DICOM
(American College of Radiology, ACR and National Electrical Manufacturers Association, NEMA)
‫ ذخیره ‌و انتقال انواع‬،‫تصاویر دیجیتالی پزشکی است ‌و شامل دستیابی‬
‌
‫این استاندارد جهت انتقال داده های مربوط به‬
.‫تصاویر پزشکی می باشد‬
‌
‫مختلف داده های تصویری‌ و داده های همراه با‬
.‫ را فراهم می نماید‬PACS ‫در سیستم‬
‌ ‫تصاویر‬
‌
‫دایکام امکان ذخیره‬
.‫ ‌و پس ‌از آن بطور‌ پیوسته به رو ‌ز می شود‬1993 – 3 ‫ویرایش‬
- 1988 -2 ‫ ویرایش‬- 1985 – 1 ‫ویرایش‬
DICOM (Digital Imaging and Communications in Medicine) is a standard for
handling, storing, printing, and transmitting information in medical imaging. It
includes a file format definition and a network communications protocol that uses
TCP/IP to communicate between systems. DICOM is known as NEMA standard
PS3.
49
The usage of DICOM
1. A set of protocols for network communication followed by
devices conformance to the DICOM standard.
2. A syntax and semantics for commands and associated
information that can be exchanged using these protocols.
3. A set of media storage services to be followed by standard
compliant devices, as well as a file format and a directory
structure to facilitate access to images, waveform data, and
related information.
50
The current DICOM standard (V3.0 in year 2008) includes 16 parts
3.9: Point-to-Point Communication Support for Message Exchange (Retired)
3.13: Print Management Point-to-Point Communication Support (Retired)
Medical imaging informatics, Alex A.T. Bui and Ricky K. Taira, 2010 (page 122).
51
The fundamental components of DICOM
Object Class
Service Class
52
The fundamental components of DICOM
Object Class
In DICOM, all data is represented within an information object
class. Thus, any entity such as a patient’s demographics, image
acquisition variables, and the image data itself is specified by
an object class. DICOM distinguishes between normalized
object classes (which basically are atomic entities) versus
composite objects that are constructed from two or more
normalized classes
53
PACS and Imaging Informatics Basic Principles and Applications, H. K. Huang, 2010 (page 277).
54
The fundamental components of DICOM - Service Class
A service class refers to a process upon which data is generated,
operated (transformed), or communicated. Examples of services are
storage, querying, retrieval, and printing of images. Like its object
class counterpart, services classes are divided between normalized
and composite services.
Service classes consider the role of a device in a requested operation:
for example, is the device invoking the service, or is the device
performing the operation? The former is referred to as a service class
user (SCU), the latter a service class provider (SCP).For a given
service class, a device may be capable of acting as the SCU, the SCP,
or both dependent on its function in an overall PACS.
55
PACS and Imaging Informatics Basic Principles and Applications, H. K. Huang, 2010 (page 277).
56
A service is built on top of a set of “DICOM message service elements” (DIMSEs).
These DIMSEs are computer software programs written to perform specific
functions.
PACS and Imaging Informatics Basic Principles and Applications, H. K. Huang, 2010 (page 281).
57
A service is built on top of a set of “DICOM message service elements” (DIMSEs).
These DIMSEs are computer software programs written to perform specific
functions.
PACS and Imaging Informatics Basic Principles and Applications, H. K. Huang, 2010 (page 281).
58
The fundamental components of DICOM
Service-Object Pairs (SOPs)
The service classes and information object classes are
combined to form the fundamental units of DICOM, called
Service-Object Pairs (SOPs). The interchange of data in
DICOM is governed by the concept of service-object pair
(SOP) classes. SOP classes are defined for transmission and
storage of documents that describe or refer to the images or
waveforms or the features they contain.
59
DICOM file format
• A file format is a standard way that information is
encoded for storage in a computer file. It specifies how
bits are used to encode information in a digital storage
medium. File formats may be either proprietary or free
and may be either unpublished or open.
• The DICOM file starts with header (the DICOM file
meta information) that is optional, followed by the bit
stream of data set, and ends with the image pixel data if
it is a DICOM image file.
• The DICOM file meta information includes file
identification information.
• A Data Set represents an instance of a real world
Information Object.
• DICOM provides a mechanism for supporting the use
of JPEG Image Compression.
• DICOM files typically have a .dcm file extension
60
New Features in DICOM
1)
Visible Light (VL) Image: The visible light (VL) image information object
definition (IOD) for endoscopy, microscopy, and photography has become
available.
2) Mammography
CAD
(Computer-Aided
Detection):
It
uses
the
mammography CAD output for analysis of mammographic findings.
3) Waveform IOD: It was mainly developed for imaging cardiac waveforms, for
example, ECG and cardiac electrophysiology (EP).
4) Structured Reporting (SR) Object: Structured reporting is for radiologists
to shorten their reporting time. SR SOP classes provide the capability to record
the structured information to enhance the precision and value of clinical
documents and enable users to link the text data to particular images or
waveforms. The DICOM standard allows different patterns of an SR report,
called SR templates
5) Content Mapping Resource: This defines the templates and context groups
used in other DICOM parts.
61
The base hierarchy of patient and imaging data concepts, which is often
referred to as DICOM’s “model of the real-world.”
Medical imaging informatics, Alex A.T. Bui and Ricky K. Taira, 2010 (page 123).
‫‪62‬‬
‫‪EDIFACT‬‬
‫‪Administration,‬‬
‫‪For‬‬
‫‪Interchange‬‬
‫‪Data‬‬
‫‪(Electronic‬‬
‫‪EDIFACT‬‬
‫)‪Commerce and Transport‬‬
‫ی ‌و حمل ‌و نقل ارائه‬
‫در سال ‪ 1986‬برای تبادل داده های الکترونیکی اداری‪ ،‬تجار ‌‬
‫شد‪.‬‬
‫در ‌بر می گیرد‪.‬‬
‫نیز ‌‬
‫عالوه ‌بر آن بخش سالمت ‌و مراقبتهای بهداشتی را ‌‬
‫در اروپا توسعه بیشتری‌ یافته است‪.‬‬
‫‌‬
63
Using an EDIFACT message, An example
• For example: You order a particular product from your supplier using an EDIFACT
message (ORDERS). The recipient of the products can now automatically process your
data in its in-house system. Many of the factors required for delivery of the product (e.g.
product, delivery date, delivery address, customer name, etc.) are already available.
• The goods are transferred to the carrier with a transport order (IFTMIN). The consignee
receives notification of delivery (INSDES) at the same time. Both the consignor and
consignee can track the consignment and retrieve useful information (e.g. estimated date
of arrival, current location of the consignment, etc.). A status report (IFTSTA) from the
carrier automatically informs the consignor and consignee of any delays.
• Notification of arrival is automatically generated (IFTMAN) when the goods arrive at the
destination station. When the consignee confirms receipt of the goods, the transport
invoice (IFTFCC) is issued to the consignor or consignee, depending on the payment
method.
64
‫استانداردهای رایج تبادل اطالعات پزشکی – استانداردهای اروپایی‬
CEN/TC251 ( European Committee for Standardization [1961]
/
Technical
Committee
251)
is
a
workgroup
within
the European Union working on standardization in the
field
of
Health
Technology (HICT).
Information
and
Communications
65
The Workgroups in CEN/TC251
• Information models (WG I)
Development of European standards to facilitate communication between independent
information systems within and between organisations.
• Terminology and knowledge representation (WG II)
Semantic organisation of information and knowledge so as to make it of practical use in
the domains of health informatics and telematics. Provision of information and criteria
to support harmonisation in health care and terminological consistency within TC251.
• Security, Safety and Quality (WG III)
Techniques for technical protection of confidentiality, integrity, availability and
accountability as well as guidelines for security management.
• Technology for Interoperability (WG IV)
Work on middleware and most of the work on medical imaging and multimedia
(although the focus in this area is on international standards) and medical device
communication in integrated healthcare.
66
CEN/TC251 ‫نمونه ای از مستندات‬
• ENV 1613: Medical informatics - Messages for exchange of
laboratory information – 1995 [WG I]
• ENV 12017 : Medical Informatics - Vocabulary - 1997 [WG II]
• ENV 12388: Medical Informatics - Algorithm for Digital Signature
Services in Health Care – 1996 [WG III], used for digital
signatures in medicine information exchange.
• ENV 13734 : Health Informatics -Vital signs information
representation – 1999 [WG IV] , Used in Medical device
communication.