HISPDirect Operations Policy

RosettaHealth has adopted these Policies and Procedures as part of a comprehensive approach to ensure secure and compliant operations of the RosettaHealth Platform's HISP (Health Information Service Provider) functions. These functions are performed by the HISPDirect service component of the RosettaHealth Platform.

Demonstrated competence in the requirements of this policy is an important part of the responsibilities of every member of the workforce. Officers, agents, employees, Business Associates, contractors, affected vendors, temporary workers, and volunteers must read, understand, and comply with this policy in full and at all times.

Scope of Policy

This policy covers the following aspects of HISPDirect operations:

  • Conformance to ONC and Direct Trust Specifications

  • Certificate Management

  • Trust Management

  • CA/RA Operations

  • Direct Message Management

  • Client Interfaces

  • Server Time Synchronization

Conformance to ONC and DirectTrust Direct Specifications

HISPDirect implements the following ONC Direct Specifications.

  • Applicability Statement for Secure Health Transport v 1.2

  • Implementation Guide for Delivery Notification in Direct v1.0

  • XDR and XDM for Direct Messaging Specification v1.0

HISPDirect implements and is operated in accordance with the following Direct Trust Policies

  • DirectTrust HISP Policy v1.1.1

Conformance to these requirement is the responsibility of the RosettaHealth Security Officer as specified in Compliance Roles

Certificate Management

Certificate Request Process

All HISPDirect users must have a trust certificate associated specifically with their organization (domain bound certificates). In order to facilitate that process, and meet the applicable requirement for certificate issuance as detailed in the DirectTrust Community X.509 Certificate Policy v.1.2, the following process has been established.

  1. Customer requests a certificate via the RosettaHealth Portal

  2. RosettaHealth Support reviews the certificate request

  3. RosettaHealth Support creates the CSR and send the request to Digicert via the Digicert Portal

  4. Digicert performs ID Proofing on the Customer

  5. Digicert creates certificate and notifies RosettaHealth

  6. RosettaHealth Key Management system downloads the certificate and installs it into HISPDirect.

  7. RosettaHealth Support notifies the Customer their service is ready.

Certificate Management and Storage

As part of the certificate process described above a certificate signing request (CSR) and private key are created. The private and public keys are encrypted using SHA2 and stored in the RosettaHealth Key Management system. Keys are encrypted stored across multiple data centers to provide high availability. The RosettaHealth Security Officer is responsible for all controls on all customer trust certificates (see Compliance Roles.)

Certificate Usage and Publishing

Any key usages stipulated as critical within a public key will be enforced via the HISPDirect Security and Trust Agent components certificate rules. Specifically this will be applied to check against CRL/OSCP mechanisms to ensure the certificate is still valid.

Public keys associated with HISPDirect users are published and discoverable via DNS as per Applicability Statement for Secure Health Transport v 1.2. HISPDirect can discover public keys for HISP addresses using either DNS or LDAP.

Trust Management

Counterparty Trust

RosettaHealth uses a whitelist approach to establish trust for purposes of HISP to HISP exchange. Trust will only be created if the other party presents a certificate from a Certificate Authority that is either part of the DirectTrust Accredited Trust Bundle or meets the LOA requirements specified below. All other exchanges will be rejected. If previously accepted certificate is found to be revoked, expired or otherwise invalid, any Direct messages associated to that certificate will be rejected. If RosettaHealth is informed that a particular counterparty (either HISP Direct domain or specific Direct address) is required to be blocked, then that domain or address will be blocklisted and blocked at the SMTP server.

Level Of Assurance Policy

This policy governs our approach to ensuring that exchanges of Direct messages to and from another HISP can only occur at Level of Assurance equal to or greater than those defined by the policies of the RA and CA used by RosettaHealth.

  • RosettaHealth will only exchange with HISP partners whose certificate proofing meets the requirements defined in NIST Special Publication 800-63-2 LoA Level 3

  • Certificates in any recognized DirectTrust Trust Anchor Bundle must meet NIST Special Publication 800-63-2 LoA Level 3

  • Except by exception trust is only accepted to other Direct Trust members who have certificates in the appropriate Trust Anchor Bundle.

  • If trust must be established with a HISP that is not part of a DirectTrust Trust Anchor Bundle then

    • The certificate chain for that HISP must be reviewed by the RosettaHealth Security Officer

      • certificate must come from a valid certificate authority

      • certificate from that HISP must meet the requirement of NIST Special Publication 800-63-2 LoA Level 3

      • the HISP must provide evidence (if ePHI is part of the exchange) that a HIPAA Privacy and Security policy exists.

DirectTrust Anchor Bundle(s)

The DirectTrust Anchor Trust Bundle(s) are updated every 72 hours so as to ensure trust with the latest approved CAs.

CA/RA Operations

All Certificate Authority and Registration Authority duties performed on behalf of RosettaHealth and/or its customers must be done by an ENHAC DTAAP-CA/DTAAP-RA certified organization. This is currently handled by Digicert Inc (ENHAC Certification).

Direct Message Management

Direct Message Metadata

As part of Direct message exchange operations (audit, routing, ...), HISPDirect accesses metadata related to Direct messages. These metadata includes:

  • Message header information (ex. To, From, message-Id, Date, …)

  • Message size

  • Attachment content-type, mime-type, name, size

For sending of Direct Messages, header information is wrapped as defined by the Applicability Statement for Secure Health Transport v 1.2. sec 2.4. Additionally HISPDirect will accept and process both wrapped and unwrapped Direct messages.

Message Delivery Notification

HISPDirect manages MDN processing according to the following policies:

  1. HISPDirect will issue an MDN with a disposition of processed upon successful receipt, decryption, and trust validation of a Direct message from another HISP.

  2. HISPDirect will respond to any properly formatted request for Final Delivery Notification with an MDN conforming to RFC3798 with a disposition-type of dispatched and an extension-field of X-DIRECT-FINAL-DESTINATIONDELIVERY.

  3. All messages sent from HISPDirect to another HISP will be tracked for receipt of a processed MDN from the other HISP. If a MDN is not received within 1 hr of the original messages being sent, the sender of the message will be informed that the verification of receipt has not be received.

Client Interfaces

All client integration with HISPDirect must be via one of the secure, supported interfaces:

  • S/SMTP via port 587

  • S/IMAP via port 993

  • HTTPS via port 443

All of these mechanism use TLS1.2 for securing communication between the client and service.

Server Time Synchronization

All RosettaHealth production servers utilize the NIST NTP master service at time.nist.gov as the first NTP service in the chronyd NTP daemon configuration.