Data Interchange Standards: Relevance for the Lab Professional

1
Data Interchange Standards Relevance for the
Lab Professional

• Victor Brodsky MD
• Pathology Informatics Fellow
• Massachusetts General Hospital
• John Gilbertson, MD
• Associate Chief of Pathology
• Director of Pathology Informatics
• Massachusetts General Hospital
• Associate Professor
• Harvard Medical School

2
Life without standards

• Manual workarounds
• Repetitive data entry by hand, paperwork
• Consulting fees for integration
• Redone with system upgrades
• Difficult to search unstructured data
• Vendor lock-in
• Bottom line Inconvenient and expensive!

3
Types of Standards

• Storage formats
• XML
• CSV
• RDF
• Data compression
• JPEG
• ZIP

4
Types of Standards

• Controlled vocabularies
• ICD9
• CPT
• SNOMED-CT - Systemized Nomenclature for Medicine
• Loinc
• Layout
• PDF
• HTML

5
Types of Standards

• Messaging between equipment or software
• DICOM Digital Imaging and Communication in
  Medicine
• HL7 Health Level 7

6
DICOM
7
DICOM

• DICOM is a global Information-Technology
  standard that is used in virtually all hospitals
  worldwide.
• Its current structure, which was developed in
  1993, is designed to ensure the interoperability
  of systems used to
• Produce, Store, Display, Process, Send, Retrieve,
  Query or Print
• medical images and derived structured documents
  as well as to manage related workflow
• Source DICOM Brochure
• Currently in Version 3

8
DICOM

• Produced by
• ACR (American College of Radiology) in
  partnership with the NEMA (National Electrical
  Manufacturers Association)
• Consists of Working Groups developing supplements
  to the standards
• Working Group 26 covers Anatomic Pathology
• Headed by Drs. Beckwith and Klossa
• Working Group 6 reviews supplements

9
DICOM History

• 1970s Introduction of digital imaging
• 1983 Recognition of problem in radiology
  sending digital images to printers, formation of
  ACR-NEMA
• 1985 publication of ACR-NEMA standard, 50 pin
  parallel interface (16-bit data bus)
• 1988 Publication of ACR-NEMA standard version 2
• 1993 Publication of DICOM (ver.3), based on
  network communications in accordance with ISO
  Open System Integration (OSI) standard model,
  first defined Image Object
• Recognition of and imaging problem in
  cardiology (500 Mb data in digital angiography
• Recognition of the workflow problem regarding
  the need to manage process of image acquisition
• European equipment manufacturers join
• 1995 Extension of the standard to media
  interchange (particularly CD-R)
• Recognition of reporting and vocabulary problem

10
Key DICOM Features

• Application protocol on TCP/IP and is same level
  as HTP or FTP
• Object Oriented
• Consists of tagged data elements
• Uses binary encoding
• Addresses conformance

11
DICOM Service

• Network function between user (client) and
  provider (server)
• Compliance with DICOM means having to confirm to
  one or more specific services
• Such as Store (transfer), query, move, create,
  notify
• Handshake Hi I can . Response Ill accept
  

12
DICOM Framework

• Patient (has a)
• Study (resulting in)
• Series (consisting of)
• Image (s)
• IOD Information Object Definition
• Collection of attributes describing an object (a
  patient for example attributes are listed in a
  DICOM dictionary
• AE Application entities (devices or programs)

13
DICOM Conformance Statement

• Every DICOM compliant application has to have a
  conformance statement, listing services and UIDs
  which are supported
• UID is a unique identifier code (for images,
  reports, or transfer syntaxes), with 4 being
  mandatory for each image
• SOP Class UID
• Study Authority UID
• Series Authority UID
• Image UID
• Service Object Pair (SOP)
• Naturally associated objects and the services
  performed using them by application entities

14
DICOM Structured Report Examples

• Web Access to DICOM Persistent Objects (WADO)
• Key object Selection (KO) Flag one or more images
• Procedure Log (For extended duration procedures
  (e.g. cath)
• Radiation Dose Report Projection X-ray CT

15
To get involved in DICOM WG26

• Contact
• Bruce A. Beckwith, MD
• Chief, Laboratory Medicine
• Department of Pathology
• NorthShore Medical Center
• 81 Highland Ave.
• Salem, MA 01970
• bbeckwith_at_partners.org

16
HL7
17
HL7

• Health Level Seven is one of several American
  National Standards Institute (ANSI) -accredited
  Standards Developing Organizations (SDOs)
  operating in the healthcare arena.
• Most SDOs produce standards (sometimes called
  specifications or protocols) for a particular
  healthcare domain such as pharmacy, medical
  devices, imaging or insurance (claims processing)
  transactions.
• Health Level Sevens domain is clinical and
  administrative data.
• Source HL7 Website

18
HL7 Organizational Structure

• HL7 is managed by a Board of Directors (8 elected
  and 3 appointed positions)
• Technical Committees (now Working Groups)
• Each with one or more chair/co-chairs
• Co-chairs comprise Technical Steering Committee
• Technical Steering Committee votes on standards
• Board of Directors makes the final decision
• Special Interest Groups

19
HL7 Scope

• Version 2.x
• Messaging
• An entrenched, adopted standard
• Version 3.x
• Relatively new
• XML based
• driven by XMLITS, XML Implementation Technology
  Specification
• Addresses
• Messaging
• CDA Clinical Document Architecture

20
HL7 Messaging

• Artifacts identifiable fragments of information
• Domains (total of 28)
• ex. Patient Administration, divided into
• Topics
• ex. Emergency Encounter
• Realms
• Universal vs US Specific

21
HL7 Messaging

• Shared Messages
• Act Status
• Message type to communicate status (aborted
  suspended etc)
• Act reference
• Registry/summary sharing
• Annotation
• Masking
• Broadcast
• Retraction
• Retract prior message (as if it never happened)
• Verification
• Ping the other application

22
HL7 CMETS

• Express a common reusable concept
• A message type fragment
• Reference Information not the focus of the
  message
• Example Patient and Encounter on an Orders
  message
• NOT content specific

23
HL7 ADT

• ADT Admit Discharge Transfer System
• If Pt. is admitted, v2 message could be AO1 or
  AO4
• Each entity can play many roles
• Message response Interaction
• Trigger Events
• Often state transition based

24
HL7 Application Roles

• Describe types of system components that send and
  or receive messages
• An application can play more than one role
• Role stereotypes
• Placer making a request
• Fulfiller expects to receive and send a
  response
• Informer talks without caring who is listening
• Tracker listens
• Role means supporting specified interactions

25
HL7 RIMM

• Information model that shows all the data for a
  particular message or message set
• 1 RIM many RMIMs
• Can be used to show the structure of the document

26
HL7 DMIM

• Domain message information model
• Organize classes of your domain detailed view of
  the domain
• Large models
• Derived from RIM
• Contains all information specific to a particular
  functional domain (such as patient
  administration)
• Can have multiple entry points
• RMIMs are refinements of the DMIM

27
HL7 HMD

• Hierarchical message descriptor
• Derived/refinement of an RMIM
• Potentially multiple HMDs per RMIM
• Format is different it is linear
• HMD Attributes
• Cardinality
• Mandatory Flag
• Class
• Data Type
• Coding Strength Concept Domain
• Default Value
• Text definition/constraint/notes

28
HL7 MT

• Message type
• Derived/refinement of an HMD
• Potentially multiple MTs per HMD
• Both HMD and MT can be generated by doing the
  walk through the RMIM

29
HL7 Future

• CIM
• Constrained Information model (replaces RMIM)
• DIM
• Domain Information model (replaces DMIM)
• DAM
• Domain Analysis Model (higher level model)

30
HL7 Message Wrappers

• Packaging messaging for transmission
• Transmission infrastructure (HL7 version 2
  control)
• Packaging, Delivery and Receipt of Messages
• Transmission Wrapper containing Control Act
  Wrapper, in turn containing Content
• All together is called the Composite Message

31
HL7 Message Wrappers

• Transmission wrapper
• Message ID, creation time, Version ID,
  Interaction ID, Profile ID, Sender Info, Receiver
  Info, Responder Info, How to respond
  (respondModeCode, Sequence Number)
• Control Act Wrapper
• What was the trigger event, when did event occur
  (effective time), when was it recorded (activity
  time, data enterer time), who recorded it (data
  enterer), who performed the event (performer),
  who authorized it (author)

32
HL7 CDA

• Clinical Document Architecture
• XML based
• Aimed at the creation of structured reports
• Discharge summaries, progress notes, (anatomic
  pathology reports?)
• Release 1.0 became an ANSI-approved HL7 standard
  in November 2000, Version 2.0 in 2005
• Can include text, audio, images, etc
• Structure makes documents machine readable and
  parsable

33
Implementation Mechanism?

• IHE
• Provides implementation guidelines for
  recommended standards
• HITSB
• Requires IHE-backed standards in order to receive
  medicare/medicaid payments

34
HL7 References

• Book
• Understanding Version 3 by Andrew Hinchley
• Website
• www.hl7.org
• Join HL7 Anatomic Pathology Work Group
• Current chair David L. Booker, MD
• david.booker_at_claripath.com
• One of current members Victor Brodsky, MD
• victor.brodsky_at_pathologysystems.com