1. IHE Radiology –2007What IHE Delivers 1 Paul Seifert IHE Technical Committee April 25, 2007 Cross Domain Review IT Infrastructure

2. IHE Cross-Domain Review 2 Other IHE Domains used in ITI None  IT Infrastructure Profiles don’t use other domains’ profiles. ITI Profiles are intended to provide a foundation for other IHE Domains to build upon  Current examples within IHE Radiology: ATNA (extended by Radiology Option to ATNA), XDS (extended by XDS-I), PDQ Transaction (used in IRWF)

3. IHE Cross-Domain Review 3 IHE ITI Integration Profile Retrieve Information for Display (RID) Retrieve Information for Display  RID enables simple and rapid access to patient information for better care. It supports access to existing persistent documents in well- known presentation formats such as CDA, PDF, JPEG, etc. It also supports access to specific key patient-centric information such as allergies, current medications, summary of reports, etc. for presentation to a clinician.

4. IHE Cross-Domain Review 4 RID Features Enables simple, web-based access to clinical information – minimal requirements on the Display/ viewer  Information Source responsible for accuracy of info and creating in a “for presentation” form  Display is expected to be a simple web-browser Functionally similar to ARI, XDS-I  ARI requires DICOM capability on both “client” and “server”  XDS-I depends on complete XDS “infrastructure” Features extensively the same as Radiology  None

5. IHE Cross-Domain Review 5 IHE ITI Integration Profile Enterprise User Authentication (EUA) Enterprise User Authentication  EUA defines a means to establish one name per user that can then be used on all of the devices and software that participate in this integration profile. It greatly facilitates centralized user authentication management and provides users with the convenience and speed of a single sign-on.

6. IHE Cross-Domain Review 6 EUA Features Intended to enable single sign-on within an enterprise  Uses a combination of Kerberos and CCOW Kerberos – manages the assignment/ verification of user credentials CCOW – manages synchronizing the user context Features extensively the same as Radiology  None

7. IHE Cross-Domain Review 7 IHE ITI Integration Profile Patient Identifier Cross-referencing (PIX) Patient Identifier Cross-referencing  PIX supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains. These cross-referenced patient identifiers can then be used by “identity consumer” systems to correlate information about a single patient from sources that “know” the patient by different identifiers. This allows a clinician to have more complete view of the patient information..

8. IHE Cross-Domain Review 8 PIX Features Unique Profile feature - Management of multiple patient ID domains  Provides a patient ID cross-referencing (linking) service enabling multiple patient ID domains to interoperate (PIX Manager). Features extensively the same as Radiology  None

9. IHE Cross-Domain Review 9 IHE ITI Integration Profile Patient Synchronized Applications (PSA) Patient Synchronized Applications  PSA supports viewing data for a single patient among otherwise independent and unlinked applications on a user's workstation. Its implementation reduces the repetitive tasks of selecting the same patient in multiple applications. It also improves patient safety by reducing the chance of medical errors caused by viewing the wrong patient's data.

10. IHE Cross-Domain Review 10 PSA Features Unique Profile feature(s)  Enables a level of desktop integration (patient level synchronization) between multiple applications Features extensively the same as Radiology  None

11. IHE Cross-Domain Review 11 IHE ITI Integration Profile Consistent Time (CT) Consistent Time  CT defines mechanisms to synchronize the time base between multiple actors and computers. Various infrastructure, security, and acquisition profiles require use of a consistent time base on multiple computers.

12. IHE Cross-Domain Review 12 CT Features Unique Profile feature(s)  Automated synchronization of system clocks across various systems/ actors. Features extensively the same as Radiology  None

13. IHE Cross-Domain Review 13 IHE ITI Integration Profile Patient Demographics Query (PDQ) Patient Demographics Query  PDQ provides ways for multiple distributed applications to query a central patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s demographic (and, optionally, visit or visit-related) information directly into the application.

14. IHE Cross-Domain Review 14 PDQ Features Unique Profile feature(s)  Queriable repository of patient demographic information (vs. “push/ notification” model for demographics used in radiology) Concepts similar to those in Radiology  Single, central repository (source) of patient demographic information (Demographics Source = ADT) Features extensively the same as Radiology  IRWF reuses the Patient Demographics Query (ITI-21) Transaction

15. IHE Cross-Domain Review 15 IHE ITI Integration Profile Audit Trail and Node Authentication (ATNA) Audit Trail and Node Authentication  ATNA establishes security measures which, together with the Security Policy and Procedures, provide patient information confidentiality, data integrity and user accountability. This environment is considered the Security Domain and can scale from a department, to enterprise or affinity domain.

16. IHE Cross-Domain Review 16 ATNA Features Unique Profile feature(s)  Defines secure connection mechanism between systems/ actors  Defines WHAT should be audited for privacy/ security purposes  Domains are required to define WHEN auditing should occur based on the transactions within their domain. ATNA was based off of Radiology’s Basic Security (now retired).  Radiology Option on ATNA defines the “WHEN” for radiology transactions by extending Record Audit event (ITI-20) transaction

17. IHE Cross-Domain Review 17 IHE ITI Integration Profile Personnel White Pages (PWP) Personnel White Pages  PWP provides access to basic human workforce user directory information. The information can be used to enhance the clinical workflow (contact information), enhance the user interface (user friendly names and titles), and ensure identity (digital certificates).

18. IHE Cross-Domain Review 18 PWP Features Unique Profile feature(s)  Use of existing IT standards (LDAP, DNS) to provide access to healthcare provider information User Demographics (displayable names, titles, etc) Contact Information (phone, email, etc) Features extensively the same as Radiology  None

19. IHE Cross-Domain Review 19 IHE ITI Integration Profile Cross-Enterprise Document Sharing (XDS) Cross-Enterprise Document Sharing  XDS enables a number of healthcare delivery organizations belonging to a clinical affinity domain (e.g. a community of care) to cooperate in the care of a patient by sharing clinical records in the form of documents as they proceed with their patients’ care delivery activities. Document repositories and a document registry create a longitudinal record of information about a patient within a given clinical affinity domain.

20. IHE Cross-Domain Review 20 XDS Features Unique Profile feature(s)  Centralized Document Registry and Repository needed to enable sharing of documents (information) across enterprises  Profile is “content neutral”, though it does define base set of metadata needed to support queries. Features “extended” by Radiology (XDS-I)  Sharing of images (DICOM objects): Imaging Document Consumers MUST retrieve the images directly from the Imaging Document Source (either via WADO or DICOM retrieve)  Radiology specific extensions made to based XDS metadata (e.g., radiology vocabulary). Features extensively reused by Radiology  Interaction between Registry and Repository, and Document Consumer and Registry

21. IHE Cross-Domain Review 21 IHE ITI Trial Implementation Integration Profile Cross Enterprise Sharing of Scanned Documents (XDS-SD) Cross Enterprise Sharing of Scanned Documents  XDS-SD defines how to share information such as legacy paper, film, electronic and scanner outputted formats, represented within a structured HL7 CDA R2 header, with a PDF or plaintext formatted document containing clinical information.

22. IHE Cross-Domain Review 22 XDS-SD Features XD* Content Profile  Source of information content is “legacy” paper, film, electronic and scanned formats  Constrains the CDA R2 header to provide adequate annotation for the resulting document Describes details of the “scanning process”  Unlike XDS-I, is a “pure” content profile. Must be “bound” with a cross-enterprise document transport (XDS, XDR, XDM) Binding concept is not clearly described. Features similar to Radiology  Document content encoded as plaintext or PDF (same as RAD reports in XDS-I)  XDS metadata XDS-I metadata for radiology reports was patterned after XDS- SD

23. IHE Cross-Domain Review 23 IHE ITI Trial Implementation Integration Profile Cross-Enterprise Document Media Interchange (XDM) Cross-Enterprise Document Media Interchange  XDM provides document interchange using a common file and directory structure over several standard media. This permits the patient to use physical media to carry medical documents. This also permits the healthcare providers to use person-to-person email to convey medical documents.

24. IHE Cross-Domain Review 24 XDM Features Provides cross enterprise document sharing via media and email  Profiled “media” include CD-R and USB memory devices, and ZIP files transferred via email.  Document content “neutral” (like XDS) Features similar to Radiology  Using CD-R media to transfer clinical information. No discussion of relationship between XDM and PDI included in Supplement (even though ‘Closed Issues’ says this is covered in Appendix E) Transaction definition appears to have large overlap with PDI PDI and XDM media appear to be compatible based on initial inspection. A more thorough analysis may be warranted.

25. IHE Cross-Domain Review 25 IHE ITI Trial Implementation Integration Profile Cross-Enterprise Document Reliable Interchange (XDR) Cross-Enterprise Document Reliable Interchange  XDR providing a standards-based specification for managing the interchange of documents that healthcare enterprises (anywhere from a private physician to a clinic to an acute care in-patient facility) have decided to explicitly exchange using a reliable point-to-point network communication. It is a natural complement to the IHE ITI XDS Integration Profile (for cross-enterprise document sharing) when a sharing infrastructure (repositories and registry) is not needed.

26. IHE Cross-Domain Review 26 XDR Features Provides cross enterprise document sharing via a single point-to-point, secured transmission  Can be used in place of XDS when XDS infrastructure (Registry & Repository) is not needed.  Use of SMTP for off-line mode, and HTTP/ SOAP for on-line mode.  Document content “neutral” (like XDS) Features similar to Radiology  None

27. IHE Cross-Domain Review 27 IHE ITI Trial Implementation Integration Profile Retrieve Form for Data Capture (RFD) Retrieve Form for Data Capture  RFD provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of forms from a form source, display and completion of a form, and return of instance data from the display application to the source application.

28. IHE Cross-Domain Review 28 RFD Features Provides a standards-based way to manage the gathering of clinical information via form completion  Use cases include Clinical Trials data gathering, Cardiology data registry submissions, pre-approval for experimental radiology procedures, etc.  Use of Xforms standard to retrieve, submit and archive forms  Actual transmission of forms is done using HTTP (GET/ POST) Features similar to Radiology  None

29. IHE Cross-Domain Review 29 IHE ITI Trial Implementation Supplement Registry Stored Query Transaction for XDS Profile Registry Stored Query Transaction for XDS Profile  The Stored Query Supplement introduces an optimized query that simplifies implementation both on the XDS Document Registry and XDS Document Consumer. As this Stored Query is functionally identical to the required subset of the existing Query Registry transaction [ITI-16], it has been decided to make this new Stored Query mandatory and the existing query optional both on the XDS Document Registry and Document Consumer.

30. IHE Cross-Domain Review 30 Stored Query Supplement Features Addition of Stored Query Transaction to XDS Profile  Replaces existing SQL-based query as the required ‘Query Registry mechanism. SQL-based query now becomes optional.  Rationale cited: allows for variations in internal Registry schemas, keeps query performance in control of Registry Features similar to Radiology  XDS-I’s dependency on XDS Query Registry transaction – does this require a change to XDS-I to also REQUIRE the Stored Query?

31. IHE Cross-Domain Review 31 IHE ITI Trial Implementation Supplement Patient Identifier Cross-Reference (PIX) and Patient Demographic Query (PDQ) HL7 v3 Patient Identifier Cross-Reference (PIX) and Patient Demographic Query (PDQ) HL7 v3  This supplement extends the Patient Identifier Cross- Reference profiles leveraging HL7 version 3. The scope of the Patient Identity Feed, Patient Identity Query, and the Patient Update Notification is identical as that for the HL7 v2.5 messages (i.e. same transactions, same message constraints).  The Patient Demographic and Visit Query Transaction is not included in the version 3 stream as this is not yet a balloted standard.

32. IHE Cross-Domain Review 32 “PIX / PDQ HL7 v3” Features IHE’s first attempt at incorporating HL7 v3 messaging  Adds an “HL7 v3” options for all 3 PIX transactions and 1 PDQ transaction (Patient Demographics Query).  Provides a “technology refresh” with no additional interoperability benefits. Features similar to Radiology  Question about what (if anything) to do about use of Patient Demographics Query in IRWF

33. IHE Cross-Domain Review 33 IHE ITI Actors Actor(s) that are extensively the same as Radiology  Patient Identity Source is roughly equivalent to the Radiology’s “ADT Patient Registration” actor  Portable Media Creator, Portable Media Importer (PDI & XDM) List of Actors “used” by Radiology  Display (PDI), Document Consumer (XDS-I), Document Registry (XDS-I), Document Repository (XDS-I), Patient Demographics Supplier (IRWF), Actors that are unique to ITI  All the rest

34. IHE Cross-Domain Review 34 IHE ITI Transactions Transactions that are extensively the same as Radiology  Patient Identity Feed (ITI-8) roughly equivalent to parts of Patient Registration (RAD-1) and Patient Update (RAD-12)  Distribute Document Set on Media (ITI-32) is roughly equivalent to Distribute Imaging Information on Media (RAD- 47) List of Transactions “used” by Radiology  Patient Demographics Query (ITI-21) in (IRWF)  Record Audit Event (ITI-20) in RAD Option to ATNA  Register Document Set (ITI-15) in XDS-I  Query Registry (ITI-16) in XDS-I  Retrieve Document (ITI-17) in XDS-I Transactions unique to ITI  All the rest

35. IHE Cross-Domain Review 35 Standards Used in ITI StandardStandard Version Profile(s) Used NTP, SNTPVersion 3CT (ATNA) Kerberos (RFC1510) V5EUA HL7 CCOW V1.4PSA, EUA HL7V2.3.1PIX (Patient Identity Feed) HL7V2.5PIX, XDS, PDQ

36. IHE Cross-Domain Review 36 Standards Used in ITI (2) StandardStandard Version Profile(s) Used HTTP, WSDL, XHTML, XML V1.1, V1.1, V1.0, V1.0 RID, XDS (HTTP), ATNA (XML), XDM (XHTML), XDR, RFD ebXML (ebRIM, ebRS) V2.1XDS, XDR ebXML (ebRIM, ebRS) V3.0XDS – Stored Query HL7 CDAR1XDS

37. IHE Cross-Domain Review 37 Standards Used in ITI (3) StandardStandard Version Profile(s) Used MIMERFC2045 - RFC2049 XDS, XDR SMTPRFC2821XDS (off-line), XDR TLSV1.0ATNA Syslog, Reliable Syslog RFC3164, RFC3195 ATNA Security Audit Msg Definition RFC3881ATNA

38. IHE Cross-Domain Review 38 Standards Used in ITI (4) StandardStandard Version Profile(s) Used DICOMSupp 95, Supp 67 ATNA (95), PWP (67) ASTM: E2147-01 ??ATNA DNSRFC2181, RFC2219, RFC2782 PWP

39. IHE Cross-Domain Review 39 Standards Used in ITI (5) StandardStandard Version Profile(s) Used LDAPRFC2251 - RFC2253, RFC2256, RFC2798, RFC2829, RFC2830 PWP DICOM PS3.10, PS3.12 2006XDM HL7V3.0 (2006)PIX/PDQ HL7v3 Xforms1.0RFD

40. IHE Cross-Domain Review 40 Summary of ITI ProfileIssue DescriptionHow to Handle (see Key) VariousWhat is the best way to track changes made to ITI Profiles and Transactions that RAD has used/ extended? 5?? XDS/ XDS-IWhat should RAD do with new Stored Query transaction? 2 XDMNeed to confirm compatibility of XDM/ PDI media 5??

41. IHE Cross-Domain Review 41 Summary of ITI (2) ProfileIssue DescriptionHow to Handle (see Key) VariousDocument benefits of using ITI profiles in conjunction with RAD profiles (e.g., CT with almost any RAD, RID with RWF, etc) 1 or 2

42. IHE Cross-Domain Review 42 Key to Domain issues 1. Issue should result in CP in Radiology 2. Consider addition in Radiology 3. Conflict between Radiology and other Domain 4. Radiology Profile should be handed-off to other Domain 5. Gap has been identified that may result in New Opportunity

43. IHE Cross-Domain Review 43