XDS Archives - Healthcare IT Systems

Cross Enterprise Document Sharing (XDS) Testing Toolkit

dkorolyk — Thu, 27 Mar 2014 23:28:23 +0000

The National Institute of Standards and Technology (NIST) has developed a XDS toolkit for testing with various IHE integration profiles. The test facilities are the IHE IT Infrastructure Technical Framework and when used are considered conformance testing against a common reference.

The primary goal of IHE is interoperability testing where implementations are tested against other implementations. Conformance testing always preceeds interoperability testing. Interoperability testing in IHE takes place at IHE Connectathons.

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

To download the XDS-i Testing Toolkit click >HERE<.

The post Cross Enterprise Document Sharing (XDS) Testing Toolkit appeared first on Healthcare IT Systems.

XDS-I and PIX/PDQv3 Testing Simulation Tools

dkorolyk — Thu, 27 Mar 2014 23:13:13 +0000

Digging around IHE.net I found some testing tools.

Here are links to XDS-I (imaging) Testing and Simulation Tools. These tools can be used to do testing related to IHE (Integrated Healthcare Enterprise) integration. The source is from the University of Quebec in Canada. The instructions are in English and the source code is located at SourceForge.net

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

The author’s contact information along with release notes, user guide and other related information can be found by clicking >HERE<.

To download the XDS Testing Toolkit click >HERE<

The post XDS-I and PIX/PDQv3 Testing Simulation Tools appeared first on Healthcare IT Systems.

What is Cross-Enterprise Document Sharing (XDS)?

dkorolyk — Mon, 10 Mar 2014 14:58:50 +0000

What is Cross-Enterprise Document Sharing (XDS)?

This is a great presentation outlining the structure and architecture of Cross a Cross-Enterprise Document Sharing (XDS) environment.

This is a 57 slide presentation. The presentation transcript is included as well.

IHE Cross-Enterprise Document Sharing (XDS) from HL7 New Zealand

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

Presentation Transcript:

1. Cross-Enterprise Document Sharing (XDS)
2. XDS Big Picture Transactions and Actors Metadata How it integrates with PIX/PDQ How it integrates with ATNA Content Profiles
3. Cross-Enterprise Document Sharing (XDS) Big Picture Provide support for document-based patient EHR Support for document storage within existing products Provide support for indexing of patient documents Support query and retrieval of patient documents Scalable architecture
4. Cross-Enterprise Document Sharing (XDS) Big Picture Points of view EHR-CR : Care-delivery Record Patient information Managed by a Care Delivery Organization EHR-LR : Longitudinal Record Documents shared by EHR-CR(s) A Patient’s long term health history Tracked by Registry Clinical Affinity Domain : Group of healthcare enterprises (EHR-CR) Common set of policies Share a single registry Archival
5. Cross-Enterprise Document Sharing (XDS) Big Picture Foundation for Health IT Infrastructures: Shared Electronic Health Record, in a community, region, etc. Effective means to contribute and access: clinical documents across health enterprises. Scalable sharing of documents: between private physicians, clinics, long term care, pharmacy, acute care with different clinical IT systems. Easy access: Care providers are offered means to query and retrieve clinical documents of interest.
6. Cross-Enterprise Document Sharing (XDS) Big Picture Distributed: Each Care delivery organization “publishes” clinical information for others. Actual documents may remain in the source system. Cross-Enterprise: A Registry provides an index for published documents that can be queried! Document Centric: Published clinical data is organized into “clinical documents”. using agreed standard document types (HL7-CDA/CCD, PDF, DICOM, etc.)
7. Cross-Enterprise Document Sharing (XDS) Big Picture Document Content Neutral: Document content is processed only by source and consumer systems. Infrastructure is generic. Standardized Registry Attributes: Documents are described by standardized set of attributes. Standardized queries supported by all vendors.
8. XDS Actors Document Source Document Repository Document Registry Document Consumer
9. Document Source Has document to store Creates description (metadata) for document Submits
10. Document Repository Accepts document and metadata from Document Source Stores document Forwards metadata to Document Registry Later, reproduces document on request (allows retrieval)
11. Document Registry Accepts metadata from Repository Stored metadata Accepts queries about metadata Returns metadata matching queries
12. Document Consumer Generates queries to Registry Accepts metadata back from Registry Displays list of documents for user to choose from (probably) When user selects document from list, retrieves and displays document
13. Cross-Enterprise Document Sharing (XDS) Transaction Diagram
14. Patient Registration
15. Document Submission
16. Query and Retrieve
17. Enterprise Enterprise Enterprise Enterprise Imaging Center Hospital B Hospital A Emergency Room PCP Patient Admin Repository Repository Repository Repository Cross-Enterprise Document Registry (XDS) Cross-Enterprise Document Sharing
18. Cross-Enterprise Document Sharing (XDS) Actors Document Source Source of documents and metadata about documents Document Repository Stores documents, requests indexing in Document Registry, supports retrieval Document Registry Indexes documents, supports search Patient Identity Source Feeds identity of known patients to Document Registry Document Consumer Initiates search and retrieval for consumer of documents
19. Metadata Objects Metadata is data stored in the Registry Document – represents a real document Submission Set – included in all submissions to document the submitted “package” Folder – for grouping documents (directory metaphor) Association – Links other objects together
20. Object Structure Each Metadata Object has internal structure ebRIM standard coding used (XML)
21. Document Submission Submission Set Document Association (HasMember) Document Association (HasMember)
22. Submission Set Attributes Author person, role, specialty, institution Title, comments, submission time Availability Status Submitted or Approved Coded elements contentType (type of clinical activity) Identifiers Patient ID, Source ID, Unique ID, UUID
23. Document Attributes Author Person, role, specialty, institution Legal Authenticator Title, comments, creation time, service start/stop time Availability Status Submitted, Approved, Deprecated Identifiers Patient ID, Unique ID, UUID Demographics Source Patient ID, Patient Demographics
24. Document Attributes (cont) Coded Values Kind of Document Class Code (general catagory) Type Code (more detail) Event Code (main clinical event) Healthcare Facility Type Practice Setting Type Confidentiality Code Technical Details MIME Type Format Code (more detail) Size Hash URI Language
25. Association Attributes Type HasMember RPLC (Replace) APND (Appends) XFRM (Transformation) Signs SubmissionSetStatus Original or Reference Pointers sourceObject, targetObject
26. Multiple Document Submission Submission Set Document Association (HasMember) Document Association (HasMember)
27. Document Replacement Submission Set Status = Approved Document Status = Approved Association (HasMember) Submission Set Status = Approved Document Status = Approved Association (HasMember) Association (RPLC) Document Status = Approved Status = Deprecated
28. Digital Signature Clinical Document Stored in Repository Indexed in Registry Digital Signature (Document) Stored in Repository Indexed in Registry How is Signature “attached” to Clinical Document?
29. Digital Signature (DSG Profile) Submission Set Status = Approved Clinical Document Status = Approved Association (HasMember) Submission Set Status = Approved Signature Document Status = Approved Association (HasMember) Association (Signs)
30. Cross-Enterprise Document Sharing (XDS) Metadata handling Generates Stores Interprets Adds
31. Affinity Domain Set of organizations/systems organized around a single Registry Common set of Codes Single Patient ID Domain Involves business and legal agreements Security model/agreements
32. Cross-Enterprise Document Sharing (XDS) Standards Used Healthcare Content Standards HL7 CDA, CEN EHRcom HL7, ASTM CCR DICOM … Internet Standards HTML, HTTP, ISO, PDF, JPEG … Electronic Business Standards ebXML, SOAP …
33. Cross-Enterprise Document Sharing (XDS.a) Standards Used XDS.a Infrastructure Standards OASIS/ebXML Registry Information Model v2.0 Basis of XDS Registry Information Model Registry Services Specifications v2.0 Registry Services Messaging Services Specifications v2.0 Offline protocols ISO/IEC 9075 Database Language SQL Registry Query Language SOAP with Attachments Protocol for communication with XDS Registries and Repositories SHA-1 [ FIPS 180-1 ] Document Hashes
34. Cross-Enterprise Document Sharing (XDS) Standards Used XDS.a Infrastructure Standards (cont) HL7 Version 2.3.1 Messages for Patient Identity Management HL7 Version 2.5 Datatypes for XDS Registry Attribute values HL7 CDA Release 1 XDS Document concept definition Source of XDS Document Entry Attributes DICOM, ASTM CCR, HL7 CDA Release 2, CEN EHRcom Sources of XDS Document Entry Attributes
35. HTTP Protocol for Retrieve Document Online SOAP bindings SMTP Offline ebMS bindings IETF Language Identifiers MIME Document Type codes UTF-8 Encoding of Registry Attributes XDS.a Infrastructure Standards (cont)
36. XDS.a and XDS.b Actors are the same in both XDS.a and XDS.b Metadata is the same in both XDS.a and XDS.b XDS.a Original XDS profile, pre 2007 Based on ebXML Reg/Rep 2.1 SOAP with attachments based Provide and Register Retrieve is HTTP GET XDS.b Based on a use of the Web Services and ebXML Reg/Reg standards that is consistent with the current developments and best practices in the industry Based on ebXML Reg/Rep 3.0 MTOM based Provide and Register MTOM based retrieve HL7 V3 Patient Identity Feed
37. Cross-Enterprise Document Sharing (XDS) Standards Used Two “categories” of standards used XDS Infrastructure XDS Content
38. Cross-Enterprise Document Sharing (XDS) Content Profiles Outside scope of XDS; layer on top of XDS Content Profiles Document use cases and translation of document content into registry metadata Publishable separately Generated (mostly) by other committees (PCC, Radiology, Lab etc) Of concern only to Document Source and Document Consumer actors Base standards for Content Profiles include: HL7 CDA, DICOM, ASTM CCR
39. Cross-Enterprise Document Sharing (XDS) Options Options center around Document Source actor Basic operations Submit single document Replace existing document Optional features Off-line mode Multi-document submission Document life-cycle management Submit addendum or transformation of document Folder management Create folder, add to folder
40. Cross-Enterprise Document Sharing (XDS) PIX/PDQ integration Patient Identity Feed (PIX) Notification from ADT system to Document Registry of patient admission/registration Submission to Registry requires validated patient ID Affinity Domain Patient ID Patient Demographics Query (PDQ) Identify patient based on query of demographic information Needed by Document Source: assign correct patient ID Needed by Document Consumer: query against correct patient ID
41. Cross-Enterprise Document Sharing (XDS) Transaction Diagram
42. Cross-Enterprise Document Sharing (XDS) PIX/PDQ integration
43. Cross-Enterprise Document Sharing (XDS) Supporting Profiles Time/Audit/Authentication Constant Time (CT) Audit Trail and Node Authentication (ATNA) Cross-Enterprise User Authentication (XUA)
44. Cross-Enterprise Document Sharing (XDS) ATNA AT Audit Trail Logs release/transfer of PHI NA Node Authentication Identifies communication partner Encrypts information (if needed)
45. Cross-Enterprise Document Sharing (XDS) How does ATNA apply?
46. Cross-Enterprise Document Sharing (XDS) Where does ATNA apply?
47. Cross-Enterprise Document Sharing (XDS) Related Infrastructure Profiles Notification of Availability (NAV) Send notification that documents are available Digital Signature (DSG) Signing of documents in repository/registry Stored Query (transaction) New query transaction for XDS Cross-Enterprise Document Media Interchange (XDM) XDS content on media (CD etc) Cross-Enterprise Document Reliable Interchange (XDR) XDS content over point-to-point connection
48. XDR/XDM Point to point transmission of Shared Documents
49. Cross-Enterprise Document Media Interchange (XDM)
50. XDM Options USB CD-R ZIP over email
51. XDM Imposes File/Directory structure on the media Transport Multiple XDS Submission Sets Each Submission Set has Metadata describing documents Documents Protocol structure of XDS imposed on file/directory organization
52. XDM Uses Release of documents to patient Manual (in pocket or email) transfer of documents Local display after receipt Index.htm file required to support display These are manual operations!
53. XDS Family of Profiles XDS – the base XDM – exchange of XDS metadata and documents on Media XDR – exhange of XDS metadata and documents over reliable protocols XD* – refers to XDS, XDM, XDR together
54. Cross-Enterprise Document Reliable Interchange (XDR)
55. XDR Point-to-point transmission of XDS content over reliable communications Uses Provide and Register transaction [ITI-15] (Same as XDS) A new profile but really just documents how to use ITI-15 to perform point-to-point transfers.
56. XDR Reliable asynchronous point-to-point transfer of XDS metadata and documents Online vs Offline Online = over direct TCP connection Offline = over SMTP XDS Online mode require Offline mode optional XDR Online mode optional Offline mode required
57. XDR Receiver can forward metadata and documents to XDS Single Submission Set per transfer More like XDS than XDM Optionally identify intended recipients

The post What is Cross-Enterprise Document Sharing (XDS)? appeared first on Healthcare IT Systems.

IHE – XDS Notifications

dkorolyk — Mon, 01 Apr 2013 12:22:01 +0000

IHE – XDS Notifications

Here is an interesting article regarding XDS notifications. A lot of us here about XDS, but I don’t think many of us venture ‘under the hood’ and see what XDS is doing and what can be done.

A highly passionate discussion happened today regarding the use of XDS and the case of ‘how does an individual know that they have documents of interest they should look at’.

One specific example is when the individual is a key individual of a workflow step. It could be as well that the individual should be simply interested in new content.The discussion got heated because there is interest in getting a very targeted notification. As elaborated there is indeed no specific IHE profile capability to do this notification.

There is however many ways that the functionality can be implemented. No single functionality is universal, there are really good reasons for each method.

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

The XDS notification functionality methods are:

Poll: An individual (system) can poll XDS. That is to use Queries one for each patient that system has individuals that are interested in. How often should it poll is left as a configurable parameter as there are good reasons to have this configurable.

** Note this is very much what e-mail uses at the technical level with POP. Clearly as users we are not polling, nor do we know our machines (cellular phones) are polling. This is the most basic, and most robust mechanism. But this is also cumbersome and causes unnecessary traffic and query processing.

*** Note that doing date specific queries are not easy to do, but can be done; and there is a Change Proposal to enhance the query.

Notification: The Notification of Document Availability (NAV) Profile is a little known supplement. It defines a simple XML encoded manifest of document references, and indicates to send this in an e-mail message. This is just a list of document ID values, so it is not exposing patient privacy in any direct way.

This e-mail could surely be sent using encrypted email if you have that capability. The drawback is that it does require that someone knows that you need to be notified, and that you would like to be notified in this way. *Note that the profile does have a specification of how to encode this on paper as well.

** Note a degenerate form is simply an e-mail with no information, just a ‘ping’ that you might recognize, however this isn’t interoperability. *** Of course you could also just pick up the phone as well.

PUSH: That is to Push the content using XDR or XDM. This could be a copy of the documents, because they are globally uniquely identified there is no problem that they get duplicated.

** Clearly again the publisher must know who to next notify *** Because this is full content one must secure the communications.

Subscription: There is the Document Subscription (DSUB) profile that allows a system to ‘subscribe’ to be notified. This subscription contains a filter criteria that would constrain why a notification would happen. Although this is a rather technically easy profile, it is not implemented often. It is not clear how big does a notification system need to be to satisfy a growing population of systems that want notification. This profile is also tied to SOAP webservices, and really only works within a single XDS domain.

Atom Feed: This is really a polling query, but the results often is seen as a form of notification. The Atom feed is a part of the Mobile Health Documents (MHD) profile.

Is there a pattern that we don’t have? I know of some creative ways to use TCP sessions that are left in a closing state, where the one that knows who to notify closes the connection when there is something useful to pull, thus causing the system to poll only when this session close event happens. This is a very low overhead, but does require the systems handle many failure-modes robustly. This is what happens in some mobile APIs to help limit the polling traffic.

Specific to workflows, in the Cross-Enterprise Document Workflow (XDW) profile we did document that a workflow does need to have a system watching to make sure workflows do progress normally. This system could notice a workflow document that seems to have stalled, and give notice via a mechanism like NAV.

It seems we have plenty of ways to achieve the functionality. This technical solution should not be confused with what the user sees or feels.

Click here to read the original article about IHE – XDS Notifications

The post IHE – XDS Notifications appeared first on Healthcare IT Systems.

Connectathon 2013 – BridgeHead now qualified IHE XDS-I.b IDS

dkorolyk — Wed, 20 Mar 2013 06:10:55 +0000

BridgeHead Software announced today it has successfully completed the IHE North American (NA) Connectathon 2013, held in Chicago, Illinois.

The Connectathon is an annual event that demonstrates the benefits of interoperability, where health information systems (HIS) work together to share information across organizational boundaries.

The testing showcased the abilities of BridgeHead’s Vendor Neutral Archive (VNA) DICOMStore(TM) to successfully integrate with other leading healthcare information systems, and the solution now qualifies as a full XDS-I.b Imaging Document Source.

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

The 14th annual IHE NA Connectathon drew hundreds of the industry’s top engineers with 8 IHE domains tested on over 160 systems. New features included testing of HL7’s Consolidated Clinical Document Architecture(R) (C-CDA) and a new qualification in standards and certification criteria for Meaningful Use Stage 2 in the U.S.

“Healthcare IT integration companies such as BridgeHead Software help make the Connectathon a success,” said Joyce Sensmeier, president of IHE USA. “This year, 500 systems engineers from 101 companies engaged in testing at the event. Collectively, we are driving the industry forward and improving quality care with interoperable systems.”

Read the rest of the news release about Connectathon 2013 and IHE XDS

The post Connectathon 2013 – BridgeHead now qualified IHE XDS-I.b IDS appeared first on Healthcare IT Systems.

What Is XDS and How Do You Use it?

dkorolyk — Mon, 16 Jul 2012 15:43:30 +0000

The Cross-Enterprise Document Sharing (XDS) IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records It provides a standards-based specification for managing the sharing of documents between any healthcare enterprise.

Group of healthcare enterprises that have agreed to work together using a common set of policies and XDS-based infrastructures for sharing patient clinical documents.

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

XDS can be used in some of the following scenarios:

• Regional community of care
• Nationwide EHR
• Specialized or disease-oriented (cardio, diabetes, oncology)
• Government-sponsored or federation of enterprises
• Insurance provider supported communities

XDS profile is designed to accommodate a wide range of policies on:

• Patient identification and consent
• Controlling access to information
• Format, content, structure, and representation of clinical information

Click here to view the entire PDF from IHE

Read related article:

The post What Is XDS and How Do You Use it? appeared first on Healthcare IT Systems.

XDS – XDS-I Cross Document Sharing

dkorolyk — Wed, 23 May 2012 03:41:50 +0000

Sectra became the first vendor in the UK with a successful XDS implementation. This will allow radiology based image data and reports to be available at patient point of care regardless of patient location.

Sectra was the chosen vendor for a regional PACS/RIS implementation that spanned 27 hospitals in Northern Ireland, however two hospitals did not sign on to the regional project and used an alternate vendor. As a result a solution was needed in order for the separate vendor systems to share data.

Sectra’s XDS technology enabled this functionality. XDS is an IHE framework that leverages existing standards for communicating clinical data between disparate systems.

There is an excellent white paper from Sectra on the topic of XDS. You can view the document on their web site by clicking here.

The post XDS – XDS-I Cross Document Sharing appeared first on Healthcare IT Systems.

What Is The Difference Between XDS,XDS.a,XDS.b and XDS-I?

dkorolyk — Wed, 23 May 2012 03:24:54 +0000

IHE (Integrating the Healthcare Enterprise) create a profile called XDS, which is a generic term to reference all XDS profiles. XDS.a and XDS.b are implementation profiles that describe technically how the implementation will be done. XDS-I is an XDS implementation specifically for medical imaging.

XDS now refers to both XDS.a and XDS.b ( a family of profiles )

XDS.a is what you thought of as XDS last year.

XDS.b is a new profile which introduces:

Updated web services including the use of WS-Addressing
Updated Registry standard (ebRIM and ebRS 3.0)
Use of MTOM in the Provide and Register transaction (and in the new WS Retrieve transaction as well)
WS Retrieve – a full web services document retrieve to replace HTTP GET which uses MTOM and is capable of retrieving multiple documents in a single request

With XDS.b you loose the following capabilities from XDS.a:

SQL query (remember that SQL query is optional in XDS.a Registry implementations)
Retrieve via HTTP Get
Use of SOAP with Attachments

The illustration below shows data flow in a typical XDS environment. When data is initially created, it is stored in its native repository (database). Once the data is stored, the repository announces the existences of the document to the XDS Registry. The repository sends the document metadata as well as information about where it is stored to the Registry.

A consumer can then Query the XDS Registry to see if there are any documents regarding a patient. If the Registry contains a document the Consumer wants, the document can be accessed directly from the Consumer’s workstation or application. As you recall information about the document’s location was sent to the Registry. The Registry doesn’t contain the document, however it does contain the document metadata as well as it’s storage location.

For more information please go to www.ihe.net

The post What Is The Difference Between XDS,XDS.a,XDS.b and XDS-I? appeared first on Healthcare IT Systems.