Conformance Guide

From Direct Project
Jump to navigation Jump to search



Documentation and Testing Workgroup > Documentation Priorities > Conformance Guide

Status - In Progress

Abstract

The Direct Project conformance guide provides a high-level and complete list of Direct Project requirements for any clinical information exchange implementation to be "unconditionally compliant" or "conditionally compliant." Primary audiences for this document include, but not limited to, the actors defined by "Direct Project Abstract Model": health message source and destination systems and the HISPs (Health Information Service Providers) responsible for health information exchange needs. Using this checklist, entities assuming the role of the above-mentioned actors will be able to certify their implementation for Direct Project compliance.

Introduction


The Direct Project conformance guide is intended to provide a comprehensive list of requirements for the transport protocols among entities (Direct Project actors) responsible for clinical information exchange. In doing so this document describes the different Direct Project definitions and states requirements and assumptions before outlining conformance criteria for all possible transport channels in the “Conformance” section. The conformance is defined at two levels. First set is the conformance criteria required by ‘ALL SYSTEMS’ participating in the transport independent of the role they are playing in information exchange. Second level is granular in that it enlists the conformance criteria applicable to each actor pertaining to its role in the transport protocol. Those protocols are Source to Source HISP, Source HISP to Destination HISP, and Destination HISP to Destination. Using this document checklist an entity can certify any clinical information exchange implementation for Direct Project compliance.

Definitions

Fill in from other specifications where needed.
Source Provider - A healthcare provider that is authorized by their Source Organization to send messages via the Direct Project.
Source Organization - A healthcare organization that sends messages.
Source System - An actor from which messages are originated, and which communicates with a Source HISP
Source HISP - A health information service provider that sends messages to a Destination HISP.
Source Address - A Direct Project address that identifies the Source Provider that sent a message.
Destination Organization - A healthcare organization that receives messages.
Destination System - An actor to which messages are delivered, and which communicates with a Destination HISP
Destination HISP - A health information service provider that receives messages from a Source HISP.
Destination Address - A Direct Project address that identifies one or more recipients of a Direct Project message at a Destination Organization.
Source Security Agent - A software component that is responsible for ensuring the security of outbound communications from a Source HISP.
Destination Security Agent - A software component that is responsible for ensuring the security of inbound communications from a Destination HISP.
Direct Project Address - An address that identifies one or more Source or Destination Providers that send or who are designated to receive a Direct Project message. It is composed of a Health Domain Name and a Health Endpoint Name.
Health Domain Name - (See Addressing Specification)
Health Endpoint Name - (See Addressing Specification)
Health Information Service Provider (HISP) -
Health Message -

Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
  An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

Assumptions

The Direct Project specifications rest on the following assumptions:
  1. The Source Organization has fulfilled all legal, regulatory and policy requirements such as consent, authorization, accounting of disclosure, privacy notices, data use restrictions incumbent on the Destination, and the like prior to initiating transport
  2. The Source and Destination Organization have ensured that their agents (for example, HIO, HISP, intermediary) are authorized to act as such and are authorized to handle PHI according to law and policy.
  3. Source Provider intends to send to the Destination Organization and has verified and confirmed the accuracy of address at the Destination Organization prior to initiating transport

Conformance critiera will not be established to verify these assumptions.

Conformance

An ‘unconditionally compliant’ system MUST implement all SHALL/SHALL NOT and SHOULD/SHOULD NOT criteria.
A ‘conditionally complaint’ system MUST implement all SHALL/SHALL NOT criteria but does not need to implement all/any of the SHOULD/SHOULD NOT criteria.
Optional (MAY criteria) can be implemented by all the systems based on their specific requirements.

The following conformance criteria apply to information systems that take on one or more of the roles defined above.

All Systems

  1. SHALL communicate over a channel secured using TLS.
  2. SHALL use X.509 certificates with TLS communications.
  3. SHALL support the configuration of the certificates or Certificate Authorities from or to which communications are supported.
  4. SHALL terminate communications with any system that attempts to communicate but does not possess a valid and authorized certificate.
  5. SHALL log inbound and outbound messages and attempts to communication whether successful or not.
  6. SHALL log information including… (was this an assumption?)
  7. SHOULD log information including… (was this an assumption?)

Source System to Source HISP Protocol

A Source System that claims conforms to the Direct Project specification for this protocol:

  1. SHALL be able to communicate to the Source HISP using the SMTP protocol.
  2. SHALL convey health messages in a MIME package.
  3. SHALL include the following MIME Content Headers…
  4. MAY include the following MIME Content Headers…
  5. SHOULD convey health messages containing one or more file attachments using the IHE XDM format in a single mime attachment.
  6. SHALL include the IHE required subject content in the subject header when conveying an XDM package
  7. SHALL NOT include the IHE required subject content in the subject header when conveying something other than an XDM package
  8. using the IHE XDM format;
    1. SHALL convey one and only one attachment.
    2. SHALL include the IHE required subject string.
    3. SHOULD support the disposition protocol
    4. SHALL specify the attachment MIME type as application/zip
    5. SHALL name the attachment IHE_XDM.ZIP


A Source HISP that claims conformance to the Direct Project specification for this protocol:

  1. SHALL accept inbound messages from Source Systems using SMTP.
  2. SHALL forward those messages to the recipient(s) identified in the message through the best available means.


Source HISP to Destination HISP Protocol

A Source HISP that claims conforms to the Direct Project specification for this protocol:

  1. SHALL be able to communicate with destination HISP using SMTP
  2. SHALL be able to accept encrypted messages from source and deliver to destination HISP without any further transformation
  3. SHALL reject unencrypted payloads if not able to perform payload signing & encryption using ‘Security Agent Algorithm’
  4. MAY be able to communicate with destination HISP with other protocols (which are - IHE-XDD*/anything else?) if mutually supported by destination HISP.


A Destination HISP that claims conforms to the Direct Project specification for this protocol:

  1. SHALL accept inbound messages from Source HISP using SMTP.
  2. SHALL verify provenance and trust of the transaction using the Security Agent algorithm, and reject all transactions that fail to verify if it has assumed the responsibility for decryption & verification.
  3. SHALL send Message Disposition Notification (MDN) as appropriate to inform the Source of transaction receipt or error.
  4. MAY be able to accept transactions with other protocols (which are - IHE-XDD*/anything else?) if mutually supported by source HISP.


Destination HISP to Destination System Protocol

A Destination HISP that claims conforms to the Direct Project specification for this protocol:
..........

A Destination System that claims conforms to the Direct Project specification for this protocol:
.........
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Conformance_Guide&oldid=178"