| XDS is like an engine with several parts |
This is the second part of the IHE XDS discussion that will
focus on the relationship between XDS and the other profiles in the IHE ITI
technical framework domain. Note: you can watch a video of this presentation here. As mentioned in part 1 of this series, the Integrating
Healthcare Enterprise (IHE) Cross Enterprise Document Sharing (XDS) profile has
been widely implemented and many vendors have tested and demonstrated its
functionality at the previous connectathons, however, actual deployments have
been very limited. One of the reasons is that XDS by itself does not make sense,
as it is merely an engine, which has several components. For example, if we
continue this analogy, it has a transmission, cylinders, alternator, etc. The
same is true with XDS, it consists of several actors and it is important to
validate that all parts are present to make it work. As an engine needs other
parts such as a chassis, wheels, steering controls, etc. to make it into a
fully functioning car, truck, or motorcycle, which is where the other ITI
profiles, such as security, patient information management, workflow, provider,
personnel and content management play a role.
Let’s look at each one of these
profiles needed to facilitate the XDS engine:
1.
Patient Identity Management: If a document or
image is exchanged between two enterprises, we better make sure that we know
who it belongs to, in other words, that we have unambiguously identified the
patient. There are several profiles needed to facilitate this:
a.
Patient
Administration Management (PAM) - to manage patient information locally, such
as with a hospital information system or ADT system
b.
Patient
Identifier Cross-Referencing (PIX) - to support linking patient identifiers
across multiple patient identifier domains. This allows systems to register
their patient identity, e.g. with a Patient ID, with a so-called Cross
Reference Manager, such as present in a Health Information Exchange or HIE, so
that potential consumers, i.e. physicians can query and be notified of any
changes.
c.
Patient
Demographics Query (PDQ) - to allow consumers to query for patient demographics
and visit information.
d.
Cross
Community Patient Discovery (XCPD) - to discover patient information across
communities using a gateway to talk to.
2.
Security and Privacy Management: These profiles
make sure that the information is exchanged in a secure manner using the
following profiles:
a.
Audit
Trails and Node Authentication (ATNA) - to provide authentication and also a
standard protocol and format to exchange and archive audit trails
b.
Consistent
Time (CT) - to synchronize multiple applications using a single clock. This is
critical as some of the applications need to be very tightly coupled.
c.
Enterprise
and Cross Enterprise User Authentication (EUA and XUA)- to provide a single
authentication process
d.
Basic Privacy Consent Management (BPPC) - to manage patient consents, i.e. what
he or she allows to be shared
e.
Document
Encryption and Digital Signatures (DEN and DSG) - to provide the information encryption
and data integrity.
3.
Provider and Personnel Management: These
profiles identify provider organizations and people across different
enterprises:
a.
Personnel
White Pages (PWP)- to provide a resource to determine exactly which provider is
involved
b.
A
Healthcare Provider directory (HPD) - to make sure that the right provider is
selected
4.
Workflow Management: This profile defines
workflows in the different enterprises. It uses the XDW or Cross-Enterprise
Workflow profile to do this.
5.
Content Management: The content management
profiles are not really part of the ITI domain, but rather defined in the
individual specialty domains such as patient care and several others. However I
want to mention it here as it is essential to have an agreement not only about
the protocol to be used (e.g. a HL7 transaction) but even more about the
content of these messages, otherwise the receiver will not be able to interpret
it and, for example, use it to store in its medical record system. It is easy
to send over documents such as a PDF that can be added as a document to a
patient folder, it is much harder to agree on a template for example for a
discharge or medical summary report with all of the individual fields properly
encoded so that they can be decoded and interpreted by a software application.
In conclusion, XDS needs many more parts, as it is just an
engine, it require several more profiles to be able to use it in an enterprise
setting. The next step is discussing what the XDS itself encompasses and how it
works, which will be in part 3.
