استانداردهای تبادل الکترونیکی اطلاعات پزشکی The Electronic Data Interchange Standards for Medical Data

1. استانداردهای تبادل الکترونیکی اطلاعات پزشکی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 مؤسسه استاندارد و تحقیقات صنعتی ایران (ماتصا) در سال 1339 به تصویب رسید. Institute of Standards and Industrial Research of Iran (ISIRI) American National Standards Institute (ANSI) • سطح منطقه ایRegional European Committee for Standardization (CEN), Brussels, Belgium • سطح جهانیInternational International Organization for Standardization (ISO) (1947, Geneva,  Switzerland)

7. تبادل الکترونیکی داده هاElectronic Data Interchange (EDI) انتقال داده ها یا مستندات الکترونیکی از یک سیستم (کامپیوتر) به سیستم دیگر. بطور مثال انتقال داده ها با استفاده از شبکه های خصوصی Value Added Network(VAN) و یا اینترنت. X12ASC مجموعه ای از استاندارهایی است که برای تبادل الکترونیکی داده های مستندات تجاری(معاملاتی) نظیر فاکتورهای فروش ، بین شرکتها استفاده می شود و توسط مؤسسه استاندار ملی آمریکا پذیرفته شده است. در حال حاضر 300 نوع سند در آن استاندارد شده است.

8. زیر ساختهایانتقال اطلاعات پزشکی انتقال الکترونیکی اطلاعات پزشکی نیاز به 4 گروه زیر ساخت اصلی دارد: • زیر ساختهای تکنولوژیک(فنی)؛ شامل تجهیزات پزشکی دیجیتال، سخت افزار کامپیوتر، شبکه های کامپیوتری، سیستم های عامل و نرم افزارهای کاربردی • استانداردهای لغات و واژگان پزشكي(Medical Vocabulary) ؛ به ‌طورمثال از طريقSNOMED CT • استانداردهای تبادل اطلاعات پزشکی؛ نظیر HL7 • زیر ساختهای حفظ امنیت داده ها؛ شامل حفظ محرمانگی و جلوگیری از دسترسی غیر مجاز نظیر استانداردهای 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. CTSNOMED 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. PredecessorsSNOMED • 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 Medicine-Reference 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.

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 andetc. 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 • Procedure • Observable entity • Body structure • Organism • Substance • Pharmaceutical / biologic product • Specimen • Special concept • Linkage concept • Physical force • Event • Environment or geographical location • Social context • Situation with explicit context • Staging and scales • Physical object • 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 • The SNOMED CT User Guide • Technical Reference Guide(TRG) • 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 HL-7(Health Level 7):در سال 1986 در تلاشی گروهی توسط ارائه کنندگان مراقبت سلامت و ارائه کنندگان تکنولوژی ایجاد شد. استانداردی برای تبادل اطلاعات بالینی و انواع دیگر اطلاعات (پذیرش، ترخیص، انتقال، دستورات پزشک، اقدامات، نتایج آزمایشات و اطلاعات مالی) بین سیستمهای کامپیوتری است. (For Exchanging, Integrating, Sharing, and Retrieving electronic health information.) اکنون مورد توافق بیش از 55 کشور از قبیل آمریکا، کانادا، استرالیا، آلمان، هلند، ژاپن، نیوزیلند و ... می باشد. HL7 در زمره موسسات استاندار ملی آمریکا می باشد. نام HL7 بر گرفته از لایه هفتم مدل مرجع ISO/OSI است.

26. مدل مرجع OSIOpen System Interconnection Reference Model یک الگوی مرجع برای ایجاد شبکه و برقراری ارتباط بین کامپیوترها می باشد که توسط ISO توسعه یافته است. از هفت سطح (لایه) تشکیل شده است. لایه های زیرین جنبه سخت افزاری (فیزیکی) و لایه های بالاتر جنبه نرم افزاری دارند. لایه های بالایی بر روی تبادل پیامها بین کاربران و برنامه های کاربردی متمرکز شده اند. لايه هفتم با سيستم عامل و يا برنامه هاي کاربردي ارتباط دارد. کاربران با استفاده از نرم افزارهاي کاربردي متفاوت قادر به انجام عمليات مرتبط با شبکه خواهند بود. اين لايه، محتواي اطلاعات را مشخص مي كند و انتقال آن‌ها بين برنامه هاي كاربردي را فراهم می‌کند.  مثلا کاربران مي توانند اقدام به خواندن پيام، ارسال پيام و ... نمايند. پروتکلهایی نظیرHTTP, FTP , HL7در این سطح قرار می گیرند.

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 The MSH (Message Header) segment contains the message type, in this case, ORU^R01, which identifies the message type and the trigger event. The sender is the GHH Lab in ELAB-3. The receiving application is the GHHOE system located in BLDG4. The message was sent on 2002-02-15 at 09:30. The MSH segment is the initial segment of the message structure. The PID (Patient Identification) segment contains the demographic information of the patient. Eve E. Everywoman was born on 1962-03-20 and lives in Statesville OH. Her patient ID number (presumably assigned to her by the Good Health Hospital) is 555-44-4444. The OBR (Observation Request) segment identifies the observation as it was orignally ordered: 15545^GLUCOSE. The observation was ordered by Particia Primary MD and performed by Howard Hippocrates MD. The OBX (Observation) segment contains the results of the observation: 182 mg/dl.

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 Act: Arecord 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 The structural attribute classCodedetermines 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. Structural attribute (Example)

38. Backbone Class: Entity Structural attribute (Example) • Entity: • cover the whole universe of: • Living thingssuch 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 Person has the attributes inherited from Entity and Living Subject as well as its own. name is an attribute of Entity, while sex (administrativeGender- Code), date of birth (birthTime), and date of death (deceasedTime) is each an attribute of LivingSubject.

39. Backbone Class: Role Roles: A responsibility or part played by an entity (e.g. Person in a role of patient, employee, etc.). There is a wide variety of Roles, which can be played by: • 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 Role has the following sub-classes: Access Employee LicensedEntity Patient Attributes for person are patient, name, address, and patient id Structural attribute (Example)

40. Backbone Class: ActRelationship 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. • typeCodedescribes the type of association between Acts: • Composition comprisesentries • Discharge summary documentsa hospital visit • Test report fulfillsa test request • Discharge summary refersto a referral • Final report replacesa preliminary report Structural attribute (Example)

41. Backbone Class: Participation Participation: An association between an Act and a Role with an Entity playing that Role. Participation has the following sub-class: ManagedParticipation Type Codedescribes the type of association between an Act and each participating Role: Performer of act (surgeons, observers, practitioners) Structural attribute (Example)

42. Backbone Class: RoleLink RoleLink: A connection between two roles expressing a dependency between those roles. RoleLink has no sub-classes. An employee of type "manager" may have authority over employees of type "analyst" which would be indicated by a role link for "direct authority". Example

43. Diagram Notation HL7 uses a special graphical notation: Each Actis represented as a red rectangle Roleas a yellow rectangle Entityas a green rectangle ActRelationshipis usually shown as pink (salmon), arrow-shaped pentagon Participationas a cyan (light blue) pentagon RoleLinkas 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 HL7V3 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 CDAdefines 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 CCOWoffers 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: • The computer boots up and the medical applications load. • Each application logs into CCOW using its secret passcode (and unique application name). • The compliant application displays a login prompt, and the user logs in as “Mary Jane”. • Mary Jane has a “CCOW ID”. Let us assume that her CCOW ID is “MJane”. • The compliant application notifies the CCOW vault that “MJane” is now logged in. • Once CCOW verifies that “MJane” is a valid CCOW user, the vault notifies all the other applications that “MJane” is logged in. • 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. • The transaction is complete. All of the applications running on the machine have been automatically logged in as “Mary Jane”.

48. DICOMتوسط کالج رادیولوژی آمریکا و انجمن ملی سازندگان ابزار الکترونیک در سال 1993 منتشر شد. (American College of Radiology,ACRand National Electrical Manufacturers Association, NEMA) این استاندارد جهت انتقال داده های مربوط به تصاویر دیجیتالی پزشکی است و شامل دستیابی، ذخیره و انتقال انواع مختلف داده های تصویری و داده های همراه با تصاویر پزشکی می باشد. دایکام امکان ذخیره تصاویر در سیستم PACS را فراهم می نماید. ویرایش 1 – 1985 - ویرایش 2- 1988 - ویرایش 3 – 1993 و پس از آن بطور پیوسته به روز می شود. 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 • A set of protocols for network communication followed by devices conformance to the DICOMstandard. • A syntax and semantics for commands and associated information that can be exchanged using these protocols. • 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).