Direct Abstract Model

From Direct Project
Jump to navigation Jump to search

Direct Abstract Model


Version 2.2

Overview


This model attempts to provide a representation of the actors and transactions involved in an Direct exchange that serves all agreed-upon push-based User Stories. Three separable interactions are addressed here. Each is intended to be an applicable domain for Direct specifications. The interactions are:

  1. Health Message Source System (Source) to HISP
  2. HISP to HISP
  3. HISP to Health Message Destination System (Destination)


Conceptually, the transactions between HISP and Source/Destination actors are intended to outline a standard pluggable method for systems to interface with HISPs.

Note that each concrete implementation should provide robust error handling mechanisms.

The Abstract Model Examples page provides a variety of non-normative expressions of how this abstract model could map to real-world deployments. Examples do not appear in the abstract model itself to avoid unintentionally specifying implementation or deployment semantics.

Terms


Source

  • Health Message Source System. An actor from which messages are originated, and which communicates with an HISP.


Destination

  • Health Message Destination System. An actor to which messages are delivered, and which communicates with an HISP.


HISP

  • Health Information Service Provider. An actor that serves the backbone exchange needs of Source and Destination actors. In the current state of this Abstract Model, an HISP should be thought of in the context of message delivery/receipt and not in the context of governance responsibilities.


Direct Message


Direct Source Edge Protocol

  • A Direct-prescribed communication protocol between a Source and an HISP.


Direct Destination Edge Protocol

  • An Direct-prescribed communication protocol between a Destination and an HISP.


Direct Address


Direct HISP Address Directory

  • An Direct-prescribed directory for securely obtaining the service IP address of the HISP associated with the destination Direct Address.


Direct Backbone Protocol

  • An Direct-prescribed communication protocol between two HISPs.



Source to HISP


Configuration
Each concrete implementation of this Abstract Model SHALL define a mechanism (e.g., port and domain, REST URI, URI hosting a WSDL) by which a Source conformant to the Source Edge Protocol can locate the HISP by standard configuration.

Transaction 1.1: Source authenticates to HISP

  • Using an authentication mechanism that meets Direct minimum standards provided in each concrete implementation (but is not prescribed by Direct), the Source authenticates a sending user (or automated process) to the HISP.


Transaction 1.2: Source sends Direct Message to HISP

  • The Source creates an Direct Message based on user (or automated process) input.
  • The Source obtains the well-defined Direct Address for the destination of the message based on user (or automated process) input.
  • The Source negotiates a secure link to the HISP meeting minimum Direct standards.
  • The Source sends the Direct Message to the HISP over the secure link using the Direct Source Edge Protocol. The destination Direct Address is sent as a standard part of the Direct Source Edge Protocol.
  • The HISP ensures the authenticity, integrity and confidentiality of the message in a way that traces the provenance of the message to the Source
  • If the destination Direct Address is handled by a different HISP, the source HISP ensures that the destination HISP is a trusted actor.
  • The HISP cleanly terminates the Direct Source Edge Protocol session with the Source.


Transaction 1.3: Source receives message status information

  • The Source receives supported status information (which shall at least indicate ACK/NACK status) on previously sent Direct Messages.


Note that a particular implementation or deployment MAY combine the functions of Source and HISP.


HISP to HISP


Transaction 2.1: Source HISP and destination HISP mutually authenticate each other

  • Using an authentication mechanism that meets Direct minimum standards, the source HISP and the destination HISP authenticate to a sufficient degree to verify mutual trust.


Transaction 2.2: Source HISP sends Direct Message to destination HISP

  • The source HISP securely sends the Direct Message to the destination HISP using the Direct Backbone Protocol. This protocol includes the destination Direct Address. The destination HISP is found using the Direct HISP Address Directory.
  • The destination HISP persists the Direct Message and associates it with the specified Direct Address.


Transaction 2.3: Source HISP receives message status from destination HISP

  • The destination HISP securely sends message status information to the source HISP.



HISP to Destination


Configuration
Each concrete implementation of this Abstract Model SHALL define a mechanism (e.g., port and domain, REST URI, URI hosting a WSDL) by which either (a) a Destination conformant to the Destination Edge Protocol can locate the HISP by standard configuration (for pull configurations), or (b) a HISP can locate a Destination (for push configurations).

Transaction 3.1: Destination authenticates to HISP, or HISP and Destination mutually authenticate each other

  • Using an authentication mechanism that meets Direct minimum standards provided in each concrete implementation, the Destination authenticates a receiving user (or automated process) to the HISP.


Transaction 3.2: HISP MAY provide the Destination a list of available Direct Messages

  • The Destination MAY be provided a list of new messages available for the receiving user (or automated process) from the HISP.
  • The Destination MAY be provided a list of older messages which may be available based on the HISPs record retention policies.


Transaction 3.3: HISP provides an Direct Message to the Destination

  • The Destination may request or be provided the default format as provided by the HISP or the original format as sent by the Source.
  • The Destination obtains each Direct Message from the HISP using the Direct Destination Edge Protocol.


Transaction 3.4: Destination updates message status with the HISP

  • The Destination updates the status of the message to indicate ACK, NACK status.
  • The HISP and Destination cleanly terminate the Direct Destination Edge Protocol session.


Note that a particular implementation or deployment MAY combine the functions of Destination and HISP.

Calls for Consensus


The Abstract Model Workgroup Call for Consensus on Abstract Model Version 1.0 is archived here.

The Abstract Model Implementation Group Call for Consensus on Abstract Model Version 1.1 is archived here.

At the May 6, 2010 Implementation Group face-to-face meeting, version 2.1 of the Abstract Model was unanimously approved with the caveat that certain HISP-to-Destination language be changed. Those changes were made and advertised resulting in version 2.2 archived here. Thus version 2.2 is considered to have achieved Implementation Group consensus .
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Direct_Abstract_Model&oldid=218"