1 / 45

Who’s who

Jan 2012 HL7 Working Group Cytometry Meeting. Who’s who. Harry Solomon. Interoperability Standards Development Organizations (SDO’s). Four level model of “use” in interoperability. Workflow. business process : tasks. Messaging. exchange : mail. Format. data record : document.

faolan
Download Presentation

Who’s who

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Jan 2012 HL7 Working Group Cytometry Meeting Who’s who Harry Solomon

  2. Interoperability Standards Development Organizations (SDO’s)

  3. Four level model of “use” in interoperability Workflow business process : tasks Messaging exchange : mail Format data record : document Vocabulary terminology : words

  4. Workflow Messaging Format • Vocabulary for lab tests and observations • Responsive for new tests/measurements • Vocabulary for medicine, anatomy, procedures, clinical findings • Robust concept model Vocabulary

  5. Workflow Messaging Format • General organization for cytometry; standards committee • Focused on cytometry research, small standards group • Example standards: • Data File Standard for Flow Cytometry (FCS) • Minimum Information about a Flow Cytometry Experiment • Image Cytometry Experiment Format (proposed) Vocabulary

  6. Workflow Messaging Format • Standards for clinical labs • Mostly process quality specifications, some interoperability specs • Example standards: • Laboratory Automation: Communications With Automated Clinical Laboratory Systems, Instruments, Devices, and Information Systems • Laboratory Automation: Data Content for Specimen Identification • Point-of-Care Connectivity Vocabulary

  7. Workflow Messaging Format • Interoperability standards for healthcare • Broadest healthcare standards organization, robust information modeling framework • Example standards: • HL7 v2 ADT (Patient Demographics), Orders, Observations (Results), Lab Automation Control • HL7 v3 Reference Information Model • Clinical Document Architecture • Electronic Health Record Functional Model Vocabulary

  8. Workflow Messaging Format • Interoperability standards for medical imaging • Supports bulk binary data, persistent object model, department workflow, universally implemented in radiology • Example standards: • Microscopic Image, Whole Slide Image • Modality Worklist / Performed Procedure Step • Storage Commitment Vocabulary

  9. Workflow Messaging Format • Integrating the Healthcare Enterprise, a pubilc-private collaboration promoting standards-based interoperability • Use cases from professional society participants (CAP, NAACCR) drive implementation guides, Connectathons, demonstrations • Example standards: • Anatomic Pathology Workflow Profile • Physician Reporting to Public Health – Cancer Registry • Cross-Enterprise Document Sharing Profile Vocabulary

  10. Cooperation • HL7 cooperative agreements / MoU’s / affiliations with all other SDO’s • HL7 & DICOM – Joint Working Group (IIWG/WG-20) meets at 3 annual HL7 WGMs • DICOM & LOINC / IHTSDO – DICOM submits proposed concepts for coding

  11. HL7 v2

  12. HL7 v2 Messaging Standard: What • HL7 Messaging Standard - An Application Protocol for Electronic Data Exchange in Healthcare Environments • Enables disparate healthcare applications to exchange clinical and administrative data • Defines the data content and provides the layout of messages that are exchanged between applications based upon a particular trigger event

  13. ADMIT MESSAGE (ADT) ….PID|||12345||Lorenzi^Virginia||19811231|F… PID attributes SEQ ELEMENT NAME 1 Set ID - Patient ID 2 Patient ID 3 Patient ID List 4 Alternate Patient ID 5 Patient Name 6 Mother’s Maiden Name 7 Date/Time of Birth 8 Sex 9 Patient Alias ETC. ACKNOWLEDGEMENT (ACK) SENDING APPLICATION (Patient Administration) HL7 Version 2 Messaging TRIGGER EVENT: Patient is Admitted! RECEIVING APPLICATION (Lab System)

  14. HL7 specification terms • Message - an ordered collection of segments, associated with a trigger event • Trigger event - a real world cause for the exchange of data • Segment - an ordered collection of data elements that typically share a common subject • Specifies whether the data element is required or optional and whether it may repeat. • Data element - a unit of exchanged meaning, with a data type and suggested length, and possibly a table of valid values • Data types - encoding of meaning in a constrained character string, or constructs of component data types • Limited to two levels of defined construct (components, subcomponents)

  15. Example HL7 v2 ADT Message • MSH|^~\&|ADMIN|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01^ADT_A01|MSG00001|P|2.4| <cr> • EVN|A01|198808181123||<cr> • PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M-||C|1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL| (919)379-1212| (919)271-3434||M||PATID12345001^2^M10^ADT1^AN^A|123456789|9-87654^NC|<cr> • NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr> • PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||-||ADM|A0-|<cr> • Patient William A. Jones, III was admitted on August 18, 1988 at 11:23 a.m. • His wife, Barbara K. Jones is a related family member (next of kin). • He has been assigned to room 2012, bed 01 on nursing unit 2000. • To be attended by doctor Sidney J. Lebauer (ID# 004777) for surgery. Character based, similar to mag tape records

  16. Example HL7 v2 ADT Message • MSH|^~\&|ADMIN|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01^ADT_A01|MSG00001|P|2.4| <cr> • EVN|A01|198808181123||<cr> • PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M-||C|1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL| (919)379-1212| (919)271-3434||M||PATID12345001^2^M10^ADT1^AN^A|123456789|9-87654^NC|<cr> • NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr> • PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||-||ADM|A0-|<cr> Segment Type – 3 char code for the logical group of information Trigger Event – 3 char code for the real world event causing the message Message Type – 3 char code for the type of message sent

  17. HL7 implementation architecture • “The Standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event.” • “HL7 does not explicitly support, but can be used with, systems that support store and forward and data broadcast facilities.” • HL7 push model issues • Handling multipoint ACKs • Offline systems • Typical implementation withstore and forward interface engine

  18. v2 Table of Contents • Chapter 1 - Introduction • Chapter 2 - Control (Conformance added v2.5) • Chapter 3 - Patient Administration • Chapter 4 - Order Entry • Chapter 5 - Query (in Chap 2 in v2.2-v2.3.1) • Chapter 6 - Financial Management • Chapter 7 - Observation Reporting • Chapter 8 - Master Files (added v2.2) • Chapter 9 - Medical Records (Document Mgmt) (added v2.3) • Chapter 10 - Scheduling (added v2.3) • Chapter 11 - Patient Referral (added v2.3) • Chapter 12 - Patient Care (added v2.3) • Chapter 13 - Clinical Laboratory Automation (added v2.4) • Chapter 14 - Application Management (added v2.4) • Chapter 15 - Personnel Management (added v2.4) • Chapter 16 - eClaims(added v2.6) • Chapter 17 - Materials Management (added v2.6)

  19. Look at ToC’s for Chapters 3, 4, 7, 13

  20. HL7 CDA

  21. HL7 Clinical Document Architecture • The scope of the CDA is the standardization of clinical documents for exchange. • A clinical document is a record of observations and other services with the following characteristics: • Persistence • Stewardship • Potential for authentication • Wholeness • Human readability • A CDA document is a defined and complete information object that can exist outside of a message, and can include text, images, sounds, and other multimedia content. • A CDA is not an isolated finding or measurement, or an aggregation of documents

  22. CDA documents are encoded in Extensible Markup Language (XML) CDA documents derive their meaning from the HL7 v3 Reference Information Model (RIM ) and use HL7 v3 Data Types A CDA document consists of a header and a body Headeris consistent across all clinical documents - identifies and classifies the document, provides information on patient, provider, encounter, and authentication; allows document management, compilation of an individual patient's clinical documents into an electronic patient record Body contains narrative text / multimedia content (level 1), optionally structured into sections with coded titles and tagged narrative content (level 2), optionally augmented by coded equivalents to narrative (level 3) Key Aspects of the CDA

  23. CDA Release 2 Information Model Header Body Start Here Participants Doc ID &Type Context Sections/Headings Clinical Statements/ Coded Entries Extl Refs

  24. CDA Structured Body • Arrows are Act Relationships • Has component, Derived from, etc. • Entries are coded clinical statements • Observation, Procedure, Substance administration, etc. Structured Body Section Text Section Text Section Text Section Text Section Text Section Text Entry Coded statement Entry Coded statement Entry Coded statement

  25. CDA structured body requireshuman-readable “Narrative Block”, all that is needed to reproduce the legally attested clinical content CDA allows optionalmachine-readable coded “Entries”, which drive automated processes Narrative may be flagged as derived from Entries Textual rendering of coded entries’ content, and contains no clinical content not derived from the entries General method for coding clinical statements is a hard, unsolved problem CDA allows incremental improvement to amount of coded data without breaking the model Narrative and Coded Info

  26. Narrative and Coded Entry Example

  27. Implementation Guides • CDA is a very generic structure focused on human-readable content • Great for minimally marked-up documents • Not much required to render narrative content • Machine processing (more powerful apps) requires standardization of CDA structures and entries • Implementation guides for specific clinical uses • Templates for documents, sections, entries

  28. Continuity of Care Document Ancestry 1998 - 2004 HL7 RIMData TypesVocabulary 2003 – 2007 2002 - 2005 Inherits from CDA ClinicalStatementModel 2004 - 2006 1999 - 2007 CCR ASIG O&ODomainModel 2005 - 2006 Genomics Domain Model CRS Patient CareDomainModel Other DomainModels 2005 - 2006 XDS-MS (R1) 2006 - 2007 2006 - 2007 CCD 2006 - 2007 C32 2007 XD*-LAB CDA4CDT C37 2006 - 2007 2008 PCC Technical Framework C83 2007 - 2008 2006 - 2007 2006 - 2007 2006 - 2007 APS 2007 - 2008 XDS-MS (R3) EDR XPHR FSA C80 2007 - 2008 2007 - 2008 QED EDES

  29. CDA Consolidation • Need one-stop shop for CDA templates • Consolidated CDA implementation guide incorporating HL7, IHE, and Health Story projects • Funded by ONCHIT • Basis for care coordination interoperability under Meaningful Use Stage 2 incentives (2014) • Balloted through HL7 May 2011, Approved as DSTU December 2011

  30. DICOM

  31. Scope of DICOM Standard • The International Standard for Medical Imaging and related information • Standard object formats for images, waveforms, derived structured data (measurements and assessments) • Workflow management in the imaging department • Service-based network protocol over TCP/IP; media interchange

  32. Object-oriented, persistent information objects Tagged data elements, binary encoding Client-server network services, service negotiation Image compression by encapsulation Conformance Statements DICOM Key Features

  33. Patient Name Patient ID Patient Sex Patient Birthdate Patient Module Study Unique ID Accession Number Study Date/Time Study Description Referring MD Modality Image Module General Image Module Patient Study Module General Series Module Frame of Reference Module General Equipment Module General Study Module Contrast/ Bolus Module Image Pixel Module Multi- frame Module VOI LUT Module SOP Common Module Image Plane Module Rows/Columns Bits per Pixel Photometric … DICOM Image Information Object Definition DICOM Composite Information Model Hierarchy Patient Information Study Information Series Information Image (Instance) Information

  34. Information object exchange Reliable object storage (commitment) Object repository (PACS) query / retrieve Modality worklist query Performed procedure step status notification Image print DICOM Network Services Application protocol riding on TCP/IP (at same level as FTP, HTTP)

  35. Data Element Encoding Attributes are the logical concepts associated with an information entity Data elements are how attributes are encoded in an information object Data Set order of transmission Data Elem. Data Elem. Data Elem. Data Elem. Data Element ValueRepresen-tation Value Tag Value Field Length optional field - dependent on negotiated Transfer Syntax 0020000Dhex UI 26hex 1.2.840.1.113709.9.0.0.5743.14575602.1 Study InstanceUnique Identifier(0020,000D) Instance UID encoded as “dotted decimal” Similar to TIFF

  36. Patient Information Part of a DICOM object Study Information Series Information Image (Instance) Information Tags in increasing numeric order Value length always an even number Attributes related to modules and information model levels NOT contiguous

  37. The Service-Object Pair (SOP) Class • The unit of interoperability and conformance • Service: network function between user (client) and provider (server) • Store (transfer), query, move, create, notify … • ∴SOP Classes represent functionality on information objects • Store a CT image • Store an MR image • Find (list) all studies for a patient • Find the worklist for a modality • Move a set of images • Create an image print job • Request/Notify the secure storage of images • Notify the performance of a procedure step

  38. DICOM Network Negotiation • First step application level handshake in setting up Association (network connection) • Agreement on SOP Classes, roles (client/server), image compression, security • One message roundtrip (initiator to acceptor and back)

  39. Storage Commitment • “Object Storage” is basic DICOM service for network transfer of images – but has no required receiver behavior • C-STORE acknowledgment simply means the objects were received whole • Objects can be successfully received by an image archive system, but a system failure could cause them to be lost prior to reliable storage • Storage Commitment provides an explicit acknowledgment of reliable storage of specific objects • The sending system can then safely delete objects from local store, e.g., auto-purge • Storage Commitment may incur a substantial delay • E.g., after overnight copy to tertiary storage

  40. Storage and Storage Commitment • Modality Transmits Images (or other Objects) to PACS: C-STORE transfer of images (acknowledged) • Modality Issues Storage Commitment Request to PACS: N-ACTION including List of objects to be committed (acknowledged) • PACS Notifies Modality of Success (or Failure) : N-EVENT-REPORT including List of objects committed (acknowledged) ① ② ③ PACS Modality ① ② ③

  41. Query Request PACS Query Match(es) Retrieve Request Image(s) Send Store Response(s) Query/Retrieve SCP Retrieve Response DICOM Query/Retrieve • Allows a system to query another system for a list of available images (query) • Also allows a system to request another system to send images (retrieve) Workstation Query/Retrieve SCU

  42. Managed Workflow Concepts ORDER :A request for departmental service • PROCEDURE STEP : The smallest unit of managed work in the workflowScheduled Procedure Step: ‘A unit of work to do’Performed Procedure Step: ‘A unit of work done’ REQUESTED PROCEDURE :Unit of work resulting in one Reportwith associated codified, billable acts

  43. CLINICIANOR REFERRING DOC:The Imaging Dept Customer RADIOLOGIST/ PATHOLOGIST : In Charge of producing the Report TECHNOLOGISTIn charge of acquiring images, etc. Workflow structuring is user oriented ORDER:A request for departmental service (Accession Number) REQUESTED PROCEDURE : Unit of work resulting in one Reportwith associated codified, billable acts(Requested Procedure ID) PROCEDURE STEP :The smallest unit of managed workin the workflow (modality worklist entry)

  44. DICOMModality Worklist ScheduledProcedure Step One or more series of images PerformedProcedure Step AcquisitionModality Simple Workflow Imaging Department • One Order – One Procedure – One Study – One Report ORDER A request for DepartmentalService Set of Codifiable, Billable, Acts Report Requested Procedure

  45. DICOMModality Worklist ScheduledProcedure Step A Report ScheduledProcedure Step B One or more series of images One or more series of images DICOMModality Worklist PerformedProcedure Step P1 PerformedProcedure Step P2 AcquisitionModality AcquisitionModality Multiple Modality Steps Imaging Department ORDER A request for DepartmentalService Set of Codifiable, Billable, Acts Requested Procedure

More Related