New to Healthix


Our Member Services and

Innovation Team are available
to assist you:

Call:  877-695-4749
Email: info@healthix.org

Ready to Connect?

Here are a few steps to understanding the process of connecting. Before your organization connects to Healthix, our team will collaborate with your key business and technical personnel, as well as your EHR vendor(s), to ensure your organization is integrated as quickly and efficiently as possible.

 

Step 1: Business Agreements

The following information outlines the key steps to integration and provides some of the tools necessary to support a smooth and successful implementation. The Healthix Participant and Business Associate Agreements represent an understanding and commitment between Healthix and participating organizations to comply with New York State Dept. of Health requirements for exchanging data in New York State.  To become a Healthix Participant, these agreements must be executed.

Step 1: Documents
Review Participant Agreement or
Participant Agreement for Health Plan
Review Business Associate Agreement

Step 2.
Technical Requirements: Scoping and Kick-off Meetings

Your onboarding process begins with two critically important meetings which will help to lay out the roadmap for integration with Healthix as well as setting expectations for all parties.  Our goal is to satisfy your needs while efficiently deploying the resources necessary for successful implementation.


The Scoping Meeting

During this meeting the business and technical leads for your organization will meet with the Healthix business and technical team. The agenda will typically include:

  • Discussion of what data will be shared
  • Determination of how the systems will connect
  • Review of Healthix Privacy Policy – particularly patient consent
  • Establishment of implementation time-line

Kickoff Meeting

The Kick off Meeting is a working session that dives into greater detail and involves team members who are involved, “hands-on,” in the integration process. The teams will identify specific tasks which will require significant interaction with the Healthix technical team and full engagement from the participant organization’s IT personnel and vendor(s).

Technical Specifications

HL7 v2 (Health Level 7)

What is HL7 v2 (Health Level 7)

HL7’s Version 2.x (V2) messaging standard is the “workhorse” of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. HL7 v2 uses messages composed of re-usable segments to communicate healthcare-related information between a sending and receiving system as well as to invoke particular behavior (patient transfers, lab orders, etc.) It also supports one-way communication through notifications, provides support for queries and other workflows.

The HL7 v2 specification for ADT (Admit, Discharge & Transfers), ORU (Lab Results), OMP(Medications), RDE(Pharmacy) and MDM (Custom Document & Notes) is for organizations preparing HL7 interfaces to Healthix. It dictates the format and context of required and expected HL7 v2 message types, segments and fields. Healthix prefers HL7 version 2.5 messages but will except well-formed HL7 2.x messages.  More Information>

HL7 v3 (Health Level 7)

What is HL7 v3 (Health Level 7)

HL7 v3 is the latest of HL7’s messaging standards. It introduced a common Reference Information Model (RIM), data type model and set of vocabulary as well as a formal standards development methodology. In addition, it introduced the use of “documents” as an alternative architecture to messaging for sharing healthcare information (CDA architecture).

CDA is HL7’s most widely adopted HL7 v3 standard. It provides both a standardized header containing metadata about the document as well as the ability to convey a wide variety of clinical content organized into various sections. The document content can be un-encoded, such as a PDF through to a fully encoded HL7 v3 instance. More Information >

Clinical Event Notifications (CENs)

What is a Clinical Event Notification?

Healthix’s Clinical Event Notification (CEN) service allows clinicians who are affiliated with a Healthix participant organization to create subscriptions to events affecting their patient or a cohort of patients. Healthix delivers CEN messages to individuals and systems (e.g. EHRs) when a consenting patient has a clinical event at a Healthix acute care facility (for example, a hospital emergency room). Some of the standard clinical event types includes ED admission, ED discharge, Inpatient admission, Inpatient discharge, Admission from a Skilled Nursing Facility, Discharge from a Skilled Nursing Facility, Patient expiration (death), Incarceration at New York City jail, or Release from Incarceration.

Healthix APIs

What is a Clinical Event Notification?

Healthix API services refer to a session and user authentication services that permits a user to use one set of login credentials (e.g., name and password) to access/retrieve patient data from multiple Healthix API services like local Healthix Portal, Healthix Patient Summary, Patient Consent at Healthix and Employee Consent Registration Portal. The service authenticates the end user for all the applications the user has been given rights to, and eliminates further prompts when the user switches applications during the same session.

Healthix API services use the security assertion markup language (SAML). SAML is an XML standard that facilitates the exchange of user authentication and authorization data across secure domains. SAML-based API services involve communications between the user, an identity provider that maintains a user directory, and a service provider. When a user attempts to access an application from the service provider, the service provider will send a request to the identity provider for authentication. The service provider will then verify the authentication and log the user in. The user will not have to log in again for the rest of his/her session.  More Information >

Flat Files

What is a Provider/Payer Flat File?

Provider/Payer delimited Flat File are interfaces in which each line of text contains a patient record, and the fields in the patient record are separated by a known character “|” Participants uses Provider/Payer Flat File to register their patient at Healthix if their patient record management system cannot support HL7 v2 or v3 integrations. Participants can send patient demographic, consent and basic encounter information to Healthix using Provider/Payer Flat File. The Flat File integration does not support registration of detailed clinical information.

EDI 834

What is aEDI 834?

The EDI 834 transaction set represents a Benefit Enrollment and Maintenance document. It is used by employers, as well as government agencies or insurance agencies, to register members at Healthix. The 834 has been specified by HIPAA 5010 standards for the electronic exchange of member enrollment information, including benefits, plan subscription and employee demographic information. The 834 transaction may be used for any of the following functions relative to health plans: New member enrollments, Changes in a member’s enrollment, Reinstatement of a member’s enrollment, Disenrollment of members.

A typical 834 document may include member name, demographics, plan network identification, member eligibility and/or benefit information, member plan/service identification.

EDI 837

What is aEDI 837?

The EDI 837 transaction set is the format established to meet HIPAA requirements for the electronic exchange of healthcare claim information. The claim information included amounts to the following, for a single care encounter between patient and provider: A description of the patient, patient’s condition for which treatment was provided, services provided.

OID Registration and Instructions

What is an OID?

An OID is a globally unique ISO (International Organization for Standardization) identifier. There are multiple ways that this identifier may be represented, and HL7 has chosen to represent OID registered here and used in HL7 models using a form that consists only of numbers and dots (e.g., “2.16.840.1.113883.3.1”). OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf.

Each OID is created by a Registration Authority. Each of these authorities may, in turn, delegate assignment of new OIDs under it to other registration authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it) number that corresponds to a leaf node on the tree. The leaf may represent a registration authority (in which case the OID identifies the authority), or an instance of an object. A registration authority owns the namespace consisting of its sub-tree.

OIDs are a preferred scheme for unique identifiers in HL7. OIDs should always be used except if one of the inclusion criteria for other schemes apply. HL7 Version 3 models use OIDs to identify coding schemes and identifier namespaces. OIDs can be allocated by any organization using a unique OID root. A single message can use OIDs from various sources and a single scheme can be identified by more than one OID (e.g. by an OID from more than one organization). Once issued, an OID is never withdrawn and always identifies the same scheme or object. More Information >