Ensemble and Healthcare Communication Protocols Ensemble and by dfsiopmhy6

VIEWS: 102 PAGES: 47

									Ensemble and Healthcare Communication
Protocols
David Loveluck
2nd June 2010
Agenda

• Quick Overview of some of the many Healthcare Standards
• Messaging formats common in healthcare
   – HL7
   – DICOM
• Standards in Health Information Exchanges
    – IHE (Integrating the Healthcare Enterprise)
    – HITSP (Healthcare Information Technology Standards Panel)
Many Standards
  What related technology standards are there?

• Message formats: HL7v2, HL7v2 XML, HL7v3, CDA, CCR, CCD, CRS, X12,
 X12 CICA, NCPDP, DICOM
• Medical vocabularies: LOINC, SNOMED CT, ICD 9/10, CPT, RxNorm
• Exchange architectures: IHE, ITK
Message Formats
       •   Health Level 7 (www.hl7.org)
 HL7
       •   An extensible set of guidelines for encoding electronic data
       • Allows application providers to agree on data exchange
         through interfaces
       • Several versions
           – HL7v2
           – HL7v2.XML
           – HL7v3
       • Several exchange protocols
           – TCP
           – Files
           – FTP
           – HTTP
HL7v2 Concepts & Terminology
 • Trigger Event – assumes need for data exchange
         • Enter patient details on PAS
 • Message – has a type and group of segments
         • Demographics (ADTs), orders (ORMs), results (ORUs)
 • Segment – 3 char id and fields (optional and/or repeating)
         • PID – Patient identification
 • Field – string or delimited list
         • PID:3() – Patient Identifier List
 • Schema – messages & structure
         • 2.4:MSH~2.4:EVN~2.4:PID~[~2.4:PD1~]~[~{~2.4:ROL~}~]~[~{~
           2.4:NK1~}~]~2.4:PV1~[~2.4:PV2~] …
Example Message
MSH|^~\&|SApp|SFac|RApp|RFac|60911378003||ADT^A01|MSG10001|T|2.4|10001|
EVN|A01|60911378000
PID|1||12345678^^^BG_PDT^MR^PAS||SMITH^BARBARA^M.||3420400|F|||321 ANY
ST^^FRISCO, TX^FRISCO, TX^75034|CL||||M|||123459874|987654123^TX
NK1|1|SMITH^DON^|HUSBAND
PV1|1|I|N3^R9^B1||||||C12345678|SURGERY||||1|||00456^JONES^MARK^E.
Ensemble Components for HL7 v2

 • Pre-built HL7 Business Services and Operations
 • Specific adapter for HL7 over TCP/IP, File, FTP etc
 • Virtual document architecture
 • Standard and Custom HL7 schemas
 • Data transformations
 • Document Viewer
 • HL7 Routing rules
 • HL7 Routing engine
Ensemble and HL7 v2

 • Use HL7 v2 to populate data warehouses
 • Clinical applications generate HL7 v2
 • Clinical applications consume HL7 v2
 • Exposing HL7 v2 in interfaces in different forms
 • HL7 v2 interface engine solutions
HL7 Interface Engine
 • Receives, transforms and routes messages
 • Content and rule based routing
 • Message sequencing
 • Most common two design models
    – Individual transforms for particular source and target (replacing
       point-to-point)
    – Transform source messages to canonical form which is consumed
       by all targets
HL7 Data Transformations
 • Purpose:
    – Change HL7 message into another schema or message type
       format.
    – Make changes within message.
 • Map properties from source message to target message.
Schema definitions

 • Schema defines the message types and structures, including fields and
   subfields
 • Standard schemas for all messages in versions 2.1 through 2.6 are
   included
 • Custom schemas are based on existing schemas
 • Only need to change the items that are different to the standard
HL7 Custom Schema
Schema for non-HL7 Messages

 • It is possible to create a custom schemas for non-HL7 formats
 • Option 1: extend EnsLib.EDI.Document (override stub methods)
 • Option 2: create a service to generate an HL7 message
HL7v3

  HL7v3   • Strengths:
             – Less of a framework and more a true standard
             – Based on object-oriented modeling
             – XML messages are a combination of human-
               readable and machine-interpretable encoding
             – Easier to discuss compliance with vendors
          • Weaknesses:
             – Complex enough to give you that “where do I
               start?” feeling
             – Verbose XML-based messages
             – Not widely adopted
HL7v3

A Messaging Standard   •   What data elements must be represented?
                       •   How are those data elements related?
                       •   What activities are involved in the process?
                       •   How are those activities related to the data?




An Information Model   • How to answer these questions with a single data
                           model?
HL7v3 Reference Information Model
RIM Classes
• Entity
    – A thing, such as a person, facility, bed, device, or medication
• Role
    – Role within a transaction, such as patient, employee, physician, or nurse
• Act
    – Action taken, such as an observation, procedure, invoice, registration, or
      transfer
• Role Link
    – Links one role to another role
        • For example, an employee could also be a patient
• Participation
    – The manner in which a role performed in the scenario (competence versus
      performance)
• Act Relationship
    – Indicates whether one action caused another action
                                           <id extension="00988137" root="2.16.528.1.1007.3.3" />
                                           </Organization>

HL7v3 Example                              </assignedEntity>
                                           </authorOrPerformer>
                                          <overseer typeCode="RESP">
                                          <assignedEntity>
                                           <id extension="000120450" root="2.16.528.1.1007.3.1" />
                                           <code code="01.015"
<MFMT_IN002101>
<!-- Transport Wrapper                    codeSystem="2.16.840.1.113883.2.4.15.111"
 -->                                      codeSystemName="RoleCode" displayName="GP" />
 <id extension="9223372036854775800" root="2.16.528.1.1007.3.2.700222.1" />
                                          <assignedPerson>
 <creationTime value="2008-01-01 12:00:00PM" />
 <versionCode code="12345" />              <name />
 <interactionId extension="MFMT_IN002101" root="2.16.840.1.113883.1.6" />
                                          <LocatedEntity>
 <processingCode code="ER" />
 <processingModeCode code="T" />           <Place />
 <acceptAckCode code="ER" />               </LocatedEntity>
<receiver>
<device>                                   </assignedPerson>
                                          <Organization>
<!-- receiving application, ID of receiving system
 -->
                                           <id extension="00988137" root="2.16.528.1.1007.3.3" />
 <id extension="000700856" root="2.16.528.1.1007.3.2" />
<name use="L">                             </Organization>
 <given>Heathcare System XYZ</given>
 </name>                                   </assignedEntity>
<agencyFor classCode="AGNT">               </overseer>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
                                           </ActReference>
 <id extension="00100100" root="2.16.528.1.1007.3.3" />
<name use="L">                             </subject2>
 <given>Organization XYZ</given>           </registrationProcess>
 </name>
 </representedOrganization>                </subject>
 </agencyFor>                              </ControlActProcess>
 </device>
 </receiver>                               </MFMT_IN002101>
<sender>
  <telecom use="WP" value="tel:+01307236354" />
<device>
<!-- sending application, ID of sending system
  -->
  <id extension="000700222" root="2.16.528.1.1007.3.2" />
<name use="L">
  <given>ABC-HIS Goodhope Hospital</given>
  </name>
<agencyFor classCode="AGNT">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
  <id extension="00600862" root="2.16.528.1.1007.3.3" />
.
.
HL7v3 Transformations

 • Why
    – Archetypes/Templates
    – Constraints
    – Terminology
    – Wrapper settings
 • How
    – DTL
    – XSLT (Extensible Stylesheet Language Transformation)
HL7v3 Transport Mechanisms

 • SOAP (Simple Object Access Protocol)
    – EnsLib.SOAP.InboundAdapter
    – EnsLib.SOAP.OutboundAdapter
 • ebXML (Electronic Business using eXtensible Markup
   Language)
    – EnsLib.ebXML package
       • Business services, processes and operations
Message Formats

 CDA   • Clinical Document Architecture
       • An R-MIM implementation (POCD_RM000020)
       • A container for human-readable and optionally machine-
         encoded values
       • Comprised of two parts, header and body
       • CDA is a container specification, not a content specification
       • CDA for Common Document Types
Common Document Types

  • Discharge Summary
  • Referral
  • Progress Note
  • History & Physical
  • Lab Test Result
  • Medication Prescription Rx
  • Public Health Report
Major Components of CDA
 <ClinicalDocument>
 ... CDA Header ...
         <StructuredBody>
                 <section>
                 <text>...</text>
                 <Observation>...</Observation>
                 <Observation>
                  <reference>
                          <ExternalObservation>...</ExternalObservation>
                  </reference>
                 </Observation>
                 </section>
                 <section>
                          <section>...</section>
                 </section>
         </StructuredBody>
 </ClinicalDocument>
Message Formats

CCR •   Continuity of Care Record (www.astm.org)
    •   XML-based clinical summary document
    •   A good format for a PHRs
    •   Comprised of a header, body, and footer
    •   Care Record Summary (www.hl7.org)
CRS
    •   Commonly used in transfer-of-care scenarios
    •   One of the first practical uses of CDA

    •   Continuity of Care Document (www.hl7.org)
CCD
    •   A cooperative effort between ASTM and HL7
    •   CCR content with adherence to CDA structure
Common Medical Vocabularies
              • Systematized Nomenclature of Medicine (Clinical Terms)
SNOMED/CT     • 11 axes, such as Topography, Chemicals, and Function

              • Logical Observation Identifiers Names and Codes
    LOINC     • Laboratory and Radiology

              • International Classification of Diseases
   ICD 9/10   • Diagnoses, Procedures, Diseases

              • Current Procedural Terminology
      CPT     • Procedures

              • Standardized nomenclature for drugs and dosage
   RxNorm     • Medications
Common Medical Vocabularies

UMLS • Unified Medical Language System
     • Created 1986 by National Library of Medicine (www.nlm.nih.gov)
     • A controlled compendium of many vocabularies, including a
           mapping structure between them
         • Three primary knowledge components:
             –   Metathesaurus: concepts and relationships between coding systems
             –   Semantic Network: categorize concepts and relationships
             –   SPECIALIST Lexicon: rich indexes based on single- or multi-word
                 syntax, form and structure, and spelling
Ensemble’s Use of Vocabularies

 • Within content of messages
    – Routing
    – Localisation
 • Via a service with scheduled retrieval and caching
     – Apelon terminology server
     – UK Terminology Centre
Message Formats

 NCPDP   • National Council for Prescription Drug Programs
           (www.ncpdp.org)
         • Telecommunication Standard defines encoding for
           pharmacy messages
         • Transaction set includes:
             –   eligibility checking
             –   claim and service billing
             –   prior authorizations
             –   information reporting
             –   controlled substance reporting
             –   reversals
Message Formats

ASC X12   • Accredited Standards Committee (www.x12.org)
          • X12 was designed primarily as the standard for EDI
            transactions in North America
          • In 1997, a global EDI standard emerged out of X12, called
            EDIFACT.
          • More than 315 EDI transaction sets
          • Common uses in healthcare include HIPAA, billing, and
            dental transactions
          • X12 CICA: next generation X12 format based on XML
ASC X12 in Ensemble

 • Similar in many ways
   to HL7
 • Used across many
   industries
 • Used mainly for payor
   transactions in US
   Healthcare
 • HIPAA mandates use
   of certain transactions
ASTM 1394 - 97

 ASTM   • ASTM 1394 - 97
           – Covers bi-directional communication between
             clinical instruments and computer systems
           – Now a part of LIS02-A2
           – Uses virtual document to allow same approach to
             routing rules, transformation, etc.
ASTM 1394 -97
Message Formats

 DICOM   • Digital Imaging and Communications in Medicine
           (http://medical.nema.org)
         • A standard for handling, storing, printing, and transmitting
           information in medical imaging
         • Every image is associated with a header that includes
           patient identification information
         • Image data can be compressed into a variety of standards
           such as JPEG or RLE
DICOM

• Messaging protocol for RIS, PACS and medical devices
• Messages can include images and be very large
• Messages include metadata as well as images
• All data is in the form of tag-value pairs
• Metadata tags are binary not ascii
DICOM Vocabulary

 • Vocabulary
    – Modality – a device such as an X-Ray machine
    – AET – Application Entity Title
    – Association
    – SCU – Service Class User
    – SCP – Service Class Provider
    – SOP – Service Object Pair
DICOM Message Types

 • Very few basic message types
    – C-ECHO, C-FIND, C-STORE, C-GET, C-MOVE
 • Schema determined by type of information
    – E.g. attributes C-STORE for an X-Ray and ECG will be
      different
Two Common Use Cases

 • Worklist server
 • Radiology Practice Router
Worklist Server

 • At the beginning of the day, a modality needs a list of work to
   be done.
    – Modality sends a C-FIND request to Ensemble
    – The C-FIND-Request specifies that a worklist is wanted
    – Ensemble find the information
    – Ensemble Constructs a C-FIND-Response
    – Ensemble sends it to the modality
Radiology practice router

 • A radiology practice receives X-Rays from several hospitals
   and stores them in a PACS to be ‘read’. The radiologist reads
   the X-Ray, dictates the interpretation and a results system
   returns the interpretation to the hospital as HL7.
 • The order numbers must be made unique across hospitals
   before storing in the PACS
 • Details of the patient data must be entered into the results
   system before the radiologist reads the X-Ray.
 • The results must be routed back to the correct hospital.
Radiology practice router (2)

 • Hospital sends image using C-STORE-Request, specifying
   that this is an X-Ray
 • Ensemble accepts the message
 • A BP extracts the patient data and sends it to the results
   system as HL7.
 • The BP updates the order number by adding a prefix to
   represent the hospital and forwards it to the PACS
 • The results system send the results to Ensemble as HL7
 • Ensemble recognizes the prefix and knows where to send the
   results, having removed the prefix.
DICOM Ensemble implementation

 • DICOM message is class EnsLib.DICOM.Document
 • Data (including metadata) is stored in external file
 • Messages can be manipulated as virtual documents
Message Format Production Examples

 • Ensemble Management Portal
 • ENSDEMO namespace
 • Productions
    – Demo.DICOM.Production.Storage
    – Demo.DICOM.Production.WorkList
    – Demo.HL7.MsgRouter.Production
    – Demo.HL7v3.Production.InterfaceEngine
    – Demo.X12.BatchSortProduction
 • See also EDI / HL7 Manager for schemas
Exchange Architectures

        • Healthcare Information Technology Standards Panel
HITSP
        • Harmonizing and integrating standards that will meet clinical and
            business needs for sharing information among organizations
            and systems
        •   Interoperability Specifications
        •   Transactions
        •   Transaction Packages
        •   Components
        •   Publishes use cases for Medication Management,
            Biosurveillance, Results Reporting, Public Health…
Exchange Architectures

       • Integrating the Healthcare Enterprise (www.ihe.net)
 IHE
       • Evolving set of standards for integrating healthcare
       • Defines “Integration Profiles”
           – Describe a clinical information need or workflow scenario
           – Document how to accomplish it with established standards
       • XDS Integration Profile
           – Cross-enterprise Document Sharing
           – Defines Registry and Repository Actors
       • Large international presence and recognition
Why Data Standards?

 • Emerging Opportunities call for interoperability
    – Health IT
    – Health Information Exchange
    – Adoption Incentives
    – Community Health Centers
    – Broadband and Telehealth
Thanks



         Questions ?
Ensemble and Healthcare Messaging
Protocols

David.Loveluck@intersystems.com

								
To top